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.

Sebelum memulai

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

  • Agar autentikasi berfungsi, instance Cloud SQL Anda harus memiliki konektivitas jaringan ke semua domain Active Directory yang relevan. Hal ini mencakup domain utama tempat instance bergabung, serta domain tepercaya atau turunan yang berisi pengguna yang perlu mengakses Cloud SQL untuk SQL Server. Untuk mengaktifkan hal ini, pastikan port berikut (TCP dan UDP) terbuka antara instance Cloud SQL 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 perlu mendelegasikan izin berikut ke akun administrator:
      • Mengelola objek Komputer (membuat objek/menghapus objek/mengubah properti objek)
      • Mengelola objek Pengguna (membuat objek/menghapus objek/mengubah properti objek)
    • 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 Terhubung 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 Manager secret, 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 di muka.

    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 merotasi 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 yatim piatu, 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.
  • Menetapkan akun layanan Per Produk dan 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 berintegrasi dengan CMAD, sebaiknya selesaikan langkah-langkah berikut.

Prasyarat untuk integrasi

Gunakan alat Diagnosis Active Directory untuk memecahkan masalah penyiapan AD dengan domain lokal dan instance Cloud SQL untuk SQL Server di Google Cloud konsol. 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:

  • Menambahkan grup global atau login pengguna individual langsung di SQL Server.
  • Menggunakan 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 sebagai gantinya, 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. Kemudian, Anda dapat menambahkan semua akun pengguna individual, dan grup global serta universal, sebagai turunan dari grup universal yang ditentukan tersebut, dan tambahkan 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 ketika 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 Google Cloud konsol akan diberi peran CustomerDbRootRole, yang mencakup Peran database SQL Server Agent yang tetap: 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, 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 adalah 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 secret terbaru akan selalu digunakan. Secret harus aktif dan tidak dapat dihancurkan.

Endpoint Active Directory dan koneksi TLS

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

Jika koneksi gagal dan salah satu sertifikat Anda dibuat sebelum 15 Maret 2025, Anda harus merotasi 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 kesehatan 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