Ringkasan Active Directory yang dikelola pelanggan (CMAD)

Halaman ini berisi informasi untuk ditinjau sebelum Anda memulai integrasi. Setelah meninjau informasi berikut, termasuk batasan, lihat Menggunakan Active Directory yang dikelola pelanggan.

Anda dapat mengintegrasikan Cloud SQL untuk SQL Server dengan Microsoft Active Directory yang dikelola pelanggan (juga disebut AD yang dikelola pelanggan (CMAD)).

Autentikasi, otorisasi, dan lainnya tersedia melalui CMAD. Misalnya, menggabungkan instance ke domain CMAD memungkinkan Anda login menggunakan Autentikasi Windows dengan identitas berbasis AD. Mengintegrasikan Cloud SQL untuk SQL Server dengan domain AD memiliki keuntungan tambahan, yaitu Google Cloud integrasi dengan domain AD lokal Anda.

Sebelum memulai

Anda dapat berintegrasi dengan CMAD, menambahkan dukungan untuk Autentikasi Windows ke instance. Namun, sebelum mengintegrasikan, hal berikut diperlukan untuk projectGoogle Cloud Anda:

  • Agar autentikasi berfungsi, instance Cloud SQL Anda harus memiliki konektivitas jaringan ke semua domain Active Directory yang relevan. Hal ini mencakup domain utama yang diikuti instance, serta domain tepercaya atau domain turunan yang berisi pengguna yang perlu mengakses Cloud SQL untuk SQL Server. Untuk mengaktifkannya, pastikan port berikut (TCP dan UDP) terbuka antara instance Cloud SQL Anda dan semua pengontrol domain Anda: 53, 88, 135, 389, 445, 464, 3268, 3269, dan 49152 hingga 65535.
  • Anda harus membuat unit organisasi (OU) untuk menyimpan semua objek integrasi terkait.
    • Dalam OU ini, Anda juga memerlukan akun administrator yang memiliki izin berikut:
      • Membuat objek Komputer
      • Menghapus objek Komputer
      • Membuat objek Pengguna
      • Menghapus objek Pengguna
      • Menulis semua properti
      • Reset sandi
      • Waktu penguncian baca, waktu penguncian tulis
    • Sebaiknya berikan izin akun administrator ini untuk mengelola data DNS, misalnya, dengan menambahkannya ke grup DnsAdmins.

      Jika Anda tidak memberikan izin ini, integrasi akan tetap berhasil. Namun, untuk terhubung ke instance, Anda harus membuat data DNS yang diperlukan secara manual, seperti yang dijelaskan dalam Menghubungkan ke instance dengan pengguna.

      Alternatifnya adalah terhubung menggunakan alamat IP instance, yang memiliki batasan dan tidak akan berfungsi untuk koneksi dari domain tepercaya.

  • Anda harus menyimpan kredensial administrator di secret Secret Manager, menggunakan format JSON berikut:
        {
          "credentials": [
            {
              "validAfterUTC": "VALID_AFTER_UTC_VALUE",
              "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_1",
              "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_1"
            },
            {
              "validAfterUTC": "VALID_AFTER_UTC_VALUE_2",
              "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_2",
              "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_2"
            }
          ]
        }
        

    Ganti kode berikut:

    • VALID_AFTER_UTC_VALUE_1: nilai UTC pertama yang ingin Anda gunakan, yang diberikan dalam format YYYY-MM-DDThh:mm:ssZ. Contohnya mungkin 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_1: login administrator pertama yang ingin Anda gunakan, seperti myadmin. Jangan sertakan nama domain dalam nilai. Entri yang mirip dengan myadmin@my-domain-name.com tidak didukung.
    • ADMINISTRATOR_PASSWORD_VALUE_1: sandi administrator.
    • VALID_AFTER_UTC_VALUE_2: nilai UTC kedua yang ingin Anda gunakan, yang diberikan dalam format YYYY-MM-DDThh:mm:ssZ. Contohnya mungkin 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_2: login administrator kedua yang ingin Anda gunakan, seperti myadmin2. Demikian pula, jangan sertakan nama domain dalam nilai. Entri yang mirip dengan myadmin2@my-domain-name.com tidak didukung.
    • ADMINISTRATOR_PASSWORD_VALUE_2: sandi administrator kedua.

    File ini dapat berisi beberapa entri kredensial untuk mengurangi masalah dengan propagasi yang lambat atau untuk mengakomodasi rotasi yang direncanakan dan dilakukan di awal.

    Kolom validAfterUTC bersifat opsional. Jika tidak ditentukan, kredensial akan dianggap selalu valid. Sebaiknya simpan kredensial ini secara permanen di Secret Manager dan gunakan otomatisasi untuk memperbarui sandi jika Anda mengganti kredensial.

    Meskipun Anda dapat menghapus secret setelah pembuatan instance, perlu diketahui bahwa operasi mendatang seperti meng-clone atau menambahkan replika baca akan menyebabkan instance baru tidak bergabung ke domain.

    Selain itu, menghapus instance asli akan membuat objek tanpa induk, seperti akun komputer, di CMAD Anda.

  • Memiliki daftar alamat IP server DNS untuk Active Directory yang dikelola pelanggan, yang biasanya merupakan pengontrol domain Anda. Sebaiknya gunakan alamat IP statis untuk server ini.
  • Tetapkan akun layanan Per-Produk, Per-Project.

Membuat dan mengonfigurasi akun layanan

Untuk membuat akun layanan dengan izin yang diperlukan, verifikasi hal berikut:

Untuk membuat akun layanan dengan gcloud CLI, jalankan perintah berikut:

  gcloud beta services identity create --service=sqladmin.googleapis.com 
--project=PROJECT_ID

Perintah tersebut menampilkan nama akun layanan dalam format berikut:

  service-PROJECT_ID@gcp-sa-cloud-sql.iam.gserviceaccount.com
  

Berikut adalah contoh nama akun layanan:

  service-333445@gcp-sa-cloud-sql.iam.gserviceaccount.com
  

Untuk memberikan izin yang diperlukan untuk integrasi, jalankan perintah berikut:

  gcloud iam roles create secretIamPolicyManager --project=PROJECT_ID 
--permissions="secretmanager.secrets.getIamPolicy,secretmanager.secrets.setIamPolicy"

Kemudian, jalankan perintah berikut:

  gcloud secrets add-iam-policy-binding ADCredentials --project="722300452883" 
--member="serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com"
--role="projects/PROJECT-ID/roles/secretIamPolicyManager"

Untuk mengetahui informasi selengkapnya, lihat gcloud beta services identity create.

Praktik terbaik untuk berintegrasi dengan CMAD

Saat melakukan integrasi dengan CMAD, sebaiknya selesaikan langkah-langkah berikut.

Prasyarat untuk integrasi

Gunakan alat Diagnosis Direktori Aktif untuk memecahkan masalah penyiapan AD dengan domain lokal dan instance Cloud SQL untuk SQL Server di konsol Google Cloud . Lewati langkah-langkah yang terkait dengan Layanan Terkelola untuk Microsoft Active Directory.

Topologi untuk berintegrasi dengan CMAD

Cloud SQL untuk SQL Server tidak mendukung grup lokal domain. Namun, alternatif berikut tersedia:

  • Tambahkan grup global atau login pengguna individual langsung di SQL Server.
  • Gunakan grup universal jika semua grup dan pengguna berada di forest yang sama.

Cloud SQL untuk SQL Server tidak mendukung grup lokal domain sebagai login. Untuk memberikan izin kepada pengguna domain, Anda harus menggunakan grup global atau universal, seperti yang dijelaskan di bagian ini.

Opsi 1: Tambahkan akun pengguna dan grup sebagai login ke SQL Server

Jika Anda memiliki beberapa domain pada beberapa forest dan beberapa grup global, Anda dapat menambahkan semua akun pengguna individual, dan grup global serta universal, secara langsung sebagai login ke SQL Server. Sebagai contoh Opsi 1, lihat diagram berikut:

Topologi CMAD, Opsi 1.

Opsi 2: Menentukan grup universal di salah satu domain Anda

Jika domain Anda berada di forest yang sama, Anda dapat menentukan grup universal di salah satu domain Anda. Kemudian, Anda dapat menambahkan semua akun pengguna individual, dan grup global serta universal, sebagai turunan dari grup universal yang ditentukan tersebut, dan menambahkan grup universal yang ditentukan sebagai login SQL Server. Sebagai contoh Opsi 2, lihat diagram berikut:

Topologi CMAD, Opsi 2.

Batasan dan alternatif

Batasan berikut berlaku saat berintegrasi dengan CMAD:

  • Instance Cloud SQL untuk SQL Server yang menggunakan Private Service Connect (PSC) untuk konektivitas pribadi tidak didukung. Gunakan akses layanan pribadi (PSA) sebagai gantinya.
  • Grup lokal domain tidak didukung, tetapi Anda dapat menambahkan grup global atau login pengguna individual langsung di SQL Server. Atau, Anda dapat menggunakan grup universal jika semua grup dan pengguna berada di forest yang sama.
  • Jika ada domain tepercaya tambahan dan Anda berencana mengakses instance SQL Server dengan nama pengguna dari sana, domain tersebut harus terhubung melalui kepercayaan dua arah. Kepercayaan satu arah dan eksternal tidak didukung.
  • Secara umum, pengguna baru yang dibuat melalui konsol Google Cloud akan diberi peran CustomerDbRootRole, yang memiliki peran database tetap SQL Server Agent: SQLAgentUserRole. Namun, pengguna yang dibuat melalui SQL Server secara langsung, seperti pengguna CMAD, tidak dapat diberi peran ini atau menggunakan SQL Server Agent, karena database MSDB yang harus diberi peran ini dilindungi.
  • Nama domain yang sepenuhnya memenuhi syarat (FQDN) tidak didukung oleh SQL Server. Oleh karena itu, gunakan nama domain (nama pendek), bukan FQDN, saat Anda membuat login SQL Server. Misalnya, jika nama domain Anda adalah ad.mydomain.com, maka buat login SQL Server untuk ad\user, bukan untuk ad.mydomain.com\user.
  • Untuk mengakses instance SQL Server, selalu gunakan FQDN. Misalnya, Anda dapat menggunakan FQDN yang mirip dengan private.myinstance.us-central1.myproject.cloudsql.mydomain.com. Nama Netbios tidak didukung, begitu juga nama pendek apa pun jika suffix DNS tidak disertakan.
  • Login SQL Server yang didasarkan pada pengguna dan grup Active Directory tidak dapat dikelola dari konsol Google Cloud .
  • Autentikasi Windows tidak akan berfungsi dengan kepercayaan eksternal. Error yang ditampilkan mungkin sebagai berikut:
      "The target principal name is incorrect. Cannot generate SSPI context."
      
    Selain itu, terkait dengan Rekomendasi Microsoft, gunakan kepercayaan forest, bukan kepercayaan eksternal untuk autentikasi Kerberos.
  • Versi terbaru secret akan selalu digunakan. Secret harus aktif dan tidak dapat dimusnahkan.

Endpoint Active Directory dan koneksi TLS

Jika Anda menggunakan Autentikasi Windows dan ingin membuat koneksi TLS tanpa memercayai sertifikat server, Anda harus merotasi sertifikat setelah Autentikasi Windows diaktifkan di instance.

Jika koneksi gagal dan salah satu sertifikat Anda dibuat sebelum 15 Maret 2025, Anda harus mengganti sertifikat server lagi dan mencoba koneksi lagi.

Tidak didukung untuk integrasi

Fitur berikut tidak didukung saat berintegrasi dengan CMAD:

  • Grup lokal domain.
  • Autentikasi NTLM.
  • Login dengan alamat IP dari domain yang terhubung melalui hubungan kepercayaan.
  • Instance dengan nama panjang (lebih dari 63 karakter).

Pemantauan

Anda dapat menggunakan metrik berikut untuk memantau status dan kondisi CMAD:

cloudsql.googleapis.com/database/active_directory/domain_reachable

Metrik ini melaporkan apakah CMAD dapat dijangkau dari instance Cloud SQL. Ini adalah alat yang berguna untuk membantu memecahkan masalah jaringan:

cloudsql.googleapis.com/database/active_directory/instance_available

Langkah berikutnya