Dokumen ini menjelaskan cara mengonfigurasi Cloud Identity atau Google Workspace untuk menggunakan Active Directory sebagai IdP dan sumber otoritatif.
Dokumen ini membandingkan struktur logis Active Directory dengan struktur yang digunakan oleh Cloud Identity dan Google Workspace, serta menjelaskan cara memetakan forest, domain, pengguna, dan grup Active Directory. Dokumen ini juga menyediakan diagram alir yang membantu Anda menentukan pendekatan pemetaan terbaik untuk skenario Anda.
Dokumen ini mengasumsikan bahwa Anda sudah memahami Active Directory.
Menerapkan penggabungan
Google Cloud menggunakan identitas Google untuk autentikasi dan pengelolaan akses. Menyimpan identitas Google secara manual untuk setiap karyawan dapat menambahkan overhead pengelolaan yang tidak diperlukan jika semua karyawan sudah memiliki akun di Active Directory. Dengan menggabungkan identitas pengguna antara Google Cloud dan sistem pengelolaan identitas yang sudah ada, Anda dapat mengotomatiskan pengelolaan identitas Google dan mengaitkan siklus prosesnya dengan pengguna yang sudah ada di Active Directory.
Menyiapkan penggabungan antara Active Directory dan Cloud Identity atau Google Workspace memerlukan dua langkah:
Penyediaan pengguna: Pengguna dan grup yang relevan disinkronkan secara berkala dari Active Directory ke Cloud Identity atau Google Workspace. Proses ini memastikan bahwa saat Anda membuat pengguna baru di Active Directory, pengguna tersebut dapat dirujuk di Google Cloud bahkan sebelum pengguna terkait login untuk pertama kalinya. Proses ini juga memastikan bahwa penghapusan akun pengguna sedang diterapkan.
Penyediaan bekerja dengan satu cara, yang berarti perubahan pada Active Directory direplikasi ke Google Cloud, tetapi tidak sebaliknya. Selain itu, penyediaan tidak menyertakan sandi. Dalam penyiapan gabungan, Active Directory tetap menjadi satu-satunya sistem yang mengelola kredensial ini.
Single sign-on: Setiap kali pengguna perlu melakukan autentikasi, Google Cloud akan mendelegasikan autentikasi tersebut ke Active Directory dengan menggunakan protokol Security Assertion Markup Language (SAML). Delegasi ini memastikan bahwa hanya Active Directory yang mengelola kredensial pengguna dan penerapan kebijakan atau mekanisme autentikasi multi-faktor (MFA) apa pun yang berlaku juga diterapkan. Namun, agar proses login berhasil, pengguna yang bersangkutan harus telah disediakan sebelumnya.
Untuk menerapkan federasi, Anda dapat menggunakan alat berikut:
- Google Cloud Directory Sync (GCDS) adalah alat gratis yang disediakan Google untuk menerapkan proses sinkronisasi. GCDS berkomunikasi dengan Google Cloud melalui Secure Sockets Layer (SSL) dan biasanya berjalan di lingkungan komputasi yang ada.
- Active Directory Federation Services (AD FS) disediakan oleh Microsoft sebagai bagian dari Windows Server. Dengan AD FS, Anda dapat menggunakan Active Directory untuk autentikasi gabungan. AD FS biasanya berjalan dalam lingkungan komputasi yang ada.
Karena API untuk Google Cloud tersedia secara publik dan SAML adalah standar terbuka, banyak alat yang tersedia untuk menerapkan federasi. Dokumen ini berfokus pada penggunaan GCDS dan AD FS.
Struktur logis Active Directory
Dalam infrastruktur Active Directory, komponen tingkat teratas adalah forest. Forest berfungsi sebagai penampung untuk satu atau beberapa domain dan mengambil namanya dari domain root forest. Domain di forest Active Directory saling percaya, sehingga memungkinkan pengguna yang diautentikasi dalam satu domain untuk mengakses resource yang ada di domain lain. Kecuali jika forest terhubung dengan menggunakan kepercayaan lintas forest, forest yang terpisah tidak akan saling percaya secara default, dan pengguna yang diautentikasi di satu forest tidak dapat mengakses resource yang berada di forest berbeda.
Domain Active Directory adalah penampung untuk mengelola resource dan dianggap sebagai batas administratif. Memiliki beberapa domain di forest adalah salah satu cara untuk menyederhanakan administrasi atau menerapkan struktur tambahan, tetapi domain di forest tidak merepresentasikan batas keamanan.
Struktur logis Google Cloud
Di Google Cloud, organisasi berfungsi sebagai container untuk semua resource dan dapat dikelompokkan lebih lanjut dengan menggunakan folder dan project. Oleh karena itu, organisasi, folder, dan project memiliki tujuan yang mirip dengan domain Active Directory.
Active Directory memperlakukan pengguna sebagai resource, sehingga pengelolaan dan autentikasi pengguna terikat dengan domain. Sebaliknya, Google Cloud tidak mengelola pengguna di organisasi, kecuali untuk akun layanan. Sebagai gantinya, Google Cloud mengandalkan Cloud Identity atau Google Workspace untuk mengelola pengguna.
Akun Cloud Identity atau Google Workspace berfungsi sebagai direktori pribadi untuk pengguna dan grup. Sebagai administrator akun, Anda dapat mengontrol siklus proses dan konfigurasi pengguna dan grup serta menentukan cara melakukan autentikasi.
Saat Anda membuat akun Cloud Identity atau Google Workspace, organisasi Google Cloud akan otomatis dibuat untuk Anda. Akun Cloud Identity atau Google Workspace dan organisasi Google Cloud yang terkait dengannya memiliki nama yang sama dan terikat satu sama lain. Namun, organisasi Google Cloud diizinkan untuk mereferensikan pengguna dan grup dari akun Cloud Identity atau Google Workspace lain.
Mengintegrasikan Active Directory dan Google Cloud
Terlepas dari adanya kesamaan antara struktur logis Active Directory dan Google Cloud, tidak ada pemetaan tunggal di antara dua struktur yang berfungsi dengan baik di semua skenario. Sebaliknya, pendekatan yang tepat untuk mengintegrasikan dua sistem dan memetakan struktur bergantung pada beberapa faktor:
- Cara memetakan domain dan forest ke akun Cloud Identity atau Google Workspace
- Cara memetakan domain DNS
- Cara memetakan pengguna
- Cara memetakan grup
Bagian berikut membahas masing-masing faktor.
Memetakan hutan
Khususnya di organisasi yang lebih besar, Anda sering menggunakan lebih dari satu domain Active Directory untuk mengelola identitas dan akses di seluruh perusahaan. Saat Anda berencana untuk melakukan federasi Active Directory dan Google Cloud, faktor pertama yang harus dilihat adalah topologi infrastruktur Active Directory Anda.
Forest tunggal, domain tunggal
Jika forest hanya menyertakan satu domain, Anda dapat memetakan seluruh forest Active Directory ke satu akun Cloud Identity atau Google Workspace. Akun ini kemudian menyediakan dasar untuk satu organisasi Google Cloud yang dapat Anda gunakan untuk mengelola resource Google Cloud.
Dalam lingkungan satu domain, pengontrol domain dan server katalog global memberikan akses ke semua objek yang dikelola di Active Directory. Dalam sebagian besar kasus, Anda dapat menjalankan satu instance GCDS untuk menyinkronkan akun dan grup pengguna ke Google Cloud, serta untuk mengelola satu instance atau fleet AD FS untuk menangani single sign-on.
Satu forest, beberapa domain
Jika forest berisi beberapa domain Active Directory, Anda dapat mengaturnya dalam satu atau beberapa hierarki domain. Pada kedua kasus tersebut, Anda dapat memetakan seluruh forest ke satu akun Cloud Identity atau Google Workspace. Akun ini kemudian menyediakan dasar untuk satu organisasi Google Cloud yang dapat Anda gunakan untuk mengelola resource Google Cloud.
Dalam lingkungan multi-domain, ada perbedaan antara informasi yang dapat diambil dari pengontrol domain dan informasi yang dapat dikueri dari server katalog global. Meskipun pengontrol domain hanya menayangkan data dari domain lokalnya, server katalog global menyediakan akses ke informasi dari semua domain dalam forest. Yang terpenting, data yang ditayangkan oleh server katalog global bersifat sebagian dan tidak memiliki atribut LDAP tertentu. Batasan ini dapat memengaruhi cara Anda mengonfigurasi GCDS untuk menyinkronkan grup.
Bergantung pada cara Anda berencana memetakan grup, penggabungan forest multi-domain dengan Google Cloud memerlukan satu atau beberapa instance GCDS, tetapi hanya satu instance atau fleet AD FS untuk menangani single sign-on.
Beberapa forest dengan kepercayaan lintas forest
Dalam organisasi yang lebih besar, tidak jarang memiliki lebih dari satu forest Active Directory, sering kali akibat merger atau akuisisi. Anda dapat mengombinasikan forest ini menggunakan kepercayaan lintas forest dua arah sehingga pengguna dapat berbagi dan mengakses resource melintasi batas-batas satu forest.
Jika semua forest memiliki hubungan kepercayaan dua arah dengan Forest lainnya, Anda dapat memetakan seluruh lingkungan ke satu akun Cloud Identity atau Google Workspace. Akun ini menyediakan dasar untuk satu organisasi Google Cloud yang dapat Anda gunakan untuk mengelola resource Google Cloud.
Meskipun server katalog global menyediakan akses ke data dari beberapa domain, cakupannya terbatas pada satu forest. Jadi, dalam lingkungan multi-forest, Anda harus membuat kueri beberapa pengontrol domain atau server katalog global untuk mendapatkan, misalnya, daftar lengkap pengguna. Akibat keterbatasan ini, penggabungan lingkungan multi-forest dengan Google Cloud memerlukan setidaknya satu instance GCDS per forest. Kepercayaan lintas forest memungkinkan autentikasi pengguna berfungsi di seluruh batas forest, sehingga satu instance atau fleet AD FS sudah cukup untuk menangani single sign-on.
Jika lingkungan Anda mencakup beberapa Forest tanpa kepercayaan lintas forest, tetapi semua domain Active Directory yang relevan untuk penggabungan dengan Google Cloud terhubung melalui kepercayaan eksternal, pertimbangan yang sama akan berlaku.
Beberapa forest tanpa kepercayaan lintas forest
Dalam lingkungan yang diilustrasikan di sini, melakukan autentikasi atau mengakses resource melintasi batas forest tidak mungkin dilakukan. Selain itu, satu instance atau fleet AD FS tidak dapat menangani permintaan single sign-on untuk pengguna dari semua forest.
Oleh karena itu, Anda tidak dapat memetakan beberapa forest yang tidak memiliki kepercayaan lintas forest ke satu akun Cloud Identity atau Google Workspace. Sebagai gantinya, setiap forest harus dipetakan ke akun Cloud Identity atau Google Workspace terpisah, yang melibatkan pengoperasian minimal satu instance GCDS dan satu server atau grup AD FS per forest.
Di Google Cloud, organisasi yang terpisah dibuat untuk setiap akun Cloud Identity atau Google Workspace. Pada umumnya, Anda tidak perlu mengelola beberapa organisasi terpisah. Anda dapat memilih salah satu organisasi dan menghubungkannya dengan akun Cloud Identity atau Google Workspace lainnya, yang secara efektif menciptakan organisasi yang digabungkan dengan beberapa forest Active Directory. Organisasi lain tetap tidak digunakan.
Memetakan domain DNS
DNS memainkan peran penting di Active Directory, Cloud Identity, dan Google Workspace. Faktor kedua yang perlu diperhatikan saat Anda berencana menghubungkan Active Directory dan Google Cloud adalah cara membagikan atau memetakan domain DNS antara Active Directory dan Google Cloud.
Penggunaan domain DNS di Active Directory
Di forest Active Directory, domain DNS digunakan di beberapa tempat:
- Domain DNS Active Directory: Setiap domain Active Directory sesuai dengan domain DNS. Domain ini mungkin bersifat global, seperti
corp.example.com, atau dapat berupa nama domain lokal seperticorp.localataucorp.internal. - Domain pertukaran email (MX): Alamat email menggunakan domain DNS. Dalam beberapa kasus, domain ini sama dengan domain DNS Active Directory, tetapi dalam banyak kasus, domain yang berbeda dan sering kali lebih pendek seperti
example.comdigunakan. Idealnya, pengguna di Active Directory memiliki alamat email yang dikaitkan dengan atributmailopsional. - Domain akhiran UPN: Domain ini digunakan untuk Nama Utama Pengguna
(UPN). Secara default, domain DNS Active Directory dari domain pengguna
digunakan untuk membuat UPN. Untuk pengguna john di domain
corp.example.com, UPN default akan membacajohn@corp.example.com. Namun, Anda dapat mengonfigurasi forest untuk menggunakan domain DNS tambahan sebagai akhiran UPN yang tidak terkait dengan domain DNS Active Directory maupun domain MX. UPN bersifat opsional dan disimpan di kolomuserPrincipalNamepengguna. - Domain endpoint: Server yang ditampilkan kepada publik seperti server AD FS biasanya
diberi nama DNS, seperti
login.external.example.com. Domain yang digunakan untuk tujuan ini dapat tumpang-tindih dengan domain MX, akhiran UPN, atau domain DNS Active Directory, atau dapat berupa domain yang sama sekali berbeda.
Penggunaan domain DNS di Google Cloud
Login dengan Google, yang diandalkan Google Cloud untuk autentikasi, menggunakan alamat email untuk mengidentifikasi pengguna. Menggunakan alamat email tidak hanya menjamin bahwa alamat email tersebut unik secara global, tetapi juga memungkinkan Google Cloud untuk mengirimkan pesan notifikasi ke alamat tersebut.
Login dengan Google menentukan direktori atau penyedia identitas yang akan digunakan untuk melakukan
autentikasi pengguna berdasarkan bagian domain alamat email
yang mengikuti @. Misalnya, untuk alamat email yang menggunakan domain gmail.com,
Login dengan Google menggunakan direktori pengguna Gmail untuk
autentikasi.
Saat mendaftar ke akun
Google Workspace
atau
Cloud Identity, Anda membuat direktori pribadi yang digunakan sebagai proses Login
dan juga dapat digunakan untuk autentikasi. Dengan cara yang sama seperti direktori Gmail
yang dikaitkan dengan domain gmail.com, akun Google Workspace dan
Cloud Identity harus dikaitkan dengan domain kustom.
Ada tiga jenis domain yang berbeda:
- Domain primer: Domain ini mengidentifikasi akun Cloud Identity atau Google Workspace dan digunakan sebagai nama untuk organisasi di Google Cloud. Saat mendaftar ke Cloud Identity atau Google Workspace, Anda harus menentukan nama domain ini.
- Domain sekunder: Bersama dengan domain primer, Anda dapat mengaitkan
domain sekunder lain dengan akun Cloud Identity atau
Google Workspace. Setiap
pengguna dalam direktori ini dikaitkan dengan domain primer atau
salah satu domain sekunder. Dua pengguna,
johndoe@example.comdanjohndoe@secondary.example.com, dianggap sebagai pengguna terpisah jikaexample.comadalah domain primer dansecondary.example.comadalah domain sekunder. - Domain alias: Domain alias adalah nama alternatif untuk domain lain.
Artinya,
johndoe@example.comdanjohndoe@alias.example.commerujuk ke pengguna yang sama jikaalias.example.comdisiapkan sebagai domain alias untukexample.com.
Semua domain harus memenuhi persyaratan berikut:
- Nama tersebut harus berupa nama domain DNS global yang valid. Selama proses penyiapan, Anda mungkin memerlukan akses administratif ke zona DNS masing-masing untuk memverifikasi kepemilikan domain.
- Domain, seperti
example.com, hanya dapat merujuk ke satu direktori. Namun, Anda dapat menggunakan subdomain yang berbeda, sepertisubdomain.example.com, untuk merujuk ke direktori yang berbeda. - Domain primer dan sekunder harus memiliki data MX yang valid agar pesan yang dikirim ke alamat email yang dibentuk dengan menggunakan nama domain ini dapat terkirim dengan benar.
Untuk mengaktifkan sinkronisasi antar-direktori, beberapa pemetaan diperlukan antara domain Active Directory dan domain yang digunakan Cloud Identity atau Google Workspace. Menentukan pemetaan yang tepat bergantung pada cara Anda menggunakan Active Directory dan memerlukan pemeriksaan lebih lanjut tentang cara pengguna diidentifikasi di forest Active Directory dan cara mereka dapat dipetakan ke Cloud Identity atau Google Workspace.
Map users (Petakan pengguna)
Faktor ketiga yang harus diperhatikan saat berencana menggabungkan Active Directory dan Google Cloud adalah cara memetakan pengguna antara Active Directory dan Cloud Identity atau Google Workspace.
Mengidentifikasi pengguna di Active Directory
Secara internal, Active Directory menggunakan dua ID untuk mengidentifikasi pengguna secara unik:
objectGUID: ID unik secara global ini dibuat saat pengguna dibuat, dan tidak pernah berubah.objectSID: SID, atau ID keamanan, digunakan untuk semua pemeriksaan akses. Meskipun ID ini unik dan stabil dalam domain, ada kemungkinan bahwa saat dipindahkan ke domain lain di forest, pengguna mungkin diberi SID baru.
Kedua ID ini tidak bermakna bagi pengguna, sehingga Active Directory menawarkan dua cara yang mudah dipahami untuk mengidentifikasi pengguna:
UPN (
userPrincipalName): Cara yang lebih disukai untuk mengidentifikasi pengguna adalah dengan UPN. UPN mengikuti format alamat email RFC 822 dan dibuat dengan menggabungkan nama pengguna dengan domain akhiran UPN, seperti dalamjohndoe@corp.example.com. Meskipun menjadi cara yang disukai untuk mengidentifikasi pengguna, UPN bersifat opsional, sehingga beberapa pengguna di forest Active Directory Anda mungkin tidak memiliki UPN.Meskipun dianggap sebagai praktik terbaik bahwa UPN adalah alamat email yang valid, Active Directory tidak menerapkan praktik ini.
Nama login pra-Windows 2000 (
sAMAccountName): Nama ini menggabungkan nama domain NetBIOS dan nama pengguna menggunakan formatdomain<var>user, seperti dalamcorp\johndoe. Meskipun dianggap sebagai nama lama, nama ini masih umum digunakan dan merupakan satu-satunya ID wajib pengguna.
Perlu diperhatikan bahwa Active Directory tidak menggunakan alamat email pengguna (mail) untuk
mengidentifikasi pengguna. Akibatnya, kolom ini tidak wajib dan tidak wajib
unik di forest.
Semua ID ini dapat diubah kapan saja.
Petakan identitas pengguna
Pemetaan pengguna Active Directory ke pengguna Cloud Identity atau Google Workspace memerlukan dua informasi untuk setiap pengguna:
- ID unik yang stabil yang dapat Anda gunakan selama sinkronisasi untuk melacak
pengguna Active Directory mana yang sesuai dengan pengguna di
Cloud Identity atau Google Workspace. Di sisi AD,
objectGUIDsangat cocok untuk tujuan ini. - Alamat email yang bagian domainnya sesuai dengan
domain primer, sekunder, atau alias akun Cloud Identity atau
Google Workspace Anda. Karena alamat email ini akan digunakan di seluruh Google Cloud, pastikan alamat tersebut bermakna. Mendapatkan alamat dari
objectGUIDtidak praktis, begitu pula alamat email lain yang dibuat secara otomatis.
Untuk pengguna Active Directory, ada dua kolom yang dapat digunakan untuk memberikan alamat email Cloud Identity atau Google Workspace: userPrincipalName dan mail.
Memetakan berdasarkan nama utama pengguna
Penggunaan kolom userPrincipalName mengharuskan dua kriteria terpenuhi untuk semua pengguna yang tunduk pada sinkronisasi:
- Nama utama pengguna (UPN) harus berupa alamat email yang valid. Semua domain yang digunakan sebagai domain akhiran UPN juga harus berupa domain MX dan harus disiapkan agar email yang dikirim ke UPN pengguna dikirim ke kotak masuk email mereka.
Penetapan UPN harus selesai. Semua pengguna yang melakukan sinkronisasi harus memiliki UPN yang ditetapkan. Perintah PowerShell berikut dapat membantu Anda menemukan pengguna yang tidak memiliki UPN:
Get-ADUser -LDAPFilter "(!userPrincipalName=*)"
Jika kedua kriteria ini terpenuhi, Anda dapat dengan aman memetakan UPN ke alamat email Cloud Identity atau Google Workspace. Anda dapat menggunakan salah satu domain akhiran UPN sebagai domain primer di Cloud Identity atau Google Workspace dan menambahkan domain akhiran UPN lainnya sebagai domain sekunder.
Jika salah satu kriteria tidak terpenuhi, Anda masih dapat memetakan UPN ke alamat email Cloud Identity atau Google Workspace, tetapi pengecualian berikut berlaku:
- Jika UPN bukan alamat email yang valid, pengguna mungkin tidak menerima email notifikasi yang dikirim oleh Google Cloud, yang dapat menyebabkan pengguna melewatkan informasi penting.
- Pengguna tanpa UPN akan diabaikan selama sinkronisasi.
- Anda dapat mengonfigurasi sinkronisasi untuk mengganti domain akhiran UPN dengan domain yang berbeda. Namun, saat Anda menggunakan beberapa domain akhiran UPN di forest, pendekatan ini dapat membuat duplikat, karena semua domain akhiran UPN akan diganti dengan satu domain. Jika ada duplikat, hanya satu pengguna yang dapat disinkronkan.
Keuntungan utama penggunaan UPN untuk memetakan pengguna adalah UPN dijamin akan unik di seluruh forest, dan menggunakan kumpulan domain pilihan, yang membantu menghindari potensi masalah sinkronisasi.
Memetakan berdasarkan alamat email
Penggunaan kolom mail memerlukan pemenuhan kriteria berikut untuk semua pengguna
yang melakukan sinkronisasi:
Penetapan email harus selesai. Semua pengguna yang melakukan sinkronisasi harus mengisi kolom
mail. Perintah PowerShell berikut dapat membantu Anda menemukan pengguna yang kolom ini tidak diisi:Get-ADUser -LDAPFilter "(!mail=*)"
Alamat email harus menggunakan kumpulan domain yang diseleksi, yang semuanya milik Anda. Jika beberapa pengguna Anda menggunakan alamat email yang merujuk ke perusahaan partner atau penyedia email konsumen, alamat email tersebut tidak dapat digunakan.
Semua alamat email harus unik di seluruh forest. Karena Active Directory tidak menerapkan keunikan, Anda mungkin harus menerapkan pemeriksaan atau kebijakan kustom.
Jika semua pengguna yang relevan memenuhi kriteria ini, Anda dapat mengidentifikasi semua domain yang digunakan oleh alamat email ini dan menggunakannya sebagai domain utama dan sekunder di Cloud Identity atau Google Workspace.
Jika salah satu kriteria tidak terpenuhi, Anda masih dapat memetakan alamat email ke alamat email Cloud Identity atau Google Workspace, dengan pengecualian berikut:
- Selama sinkronisasi, pengguna tanpa alamat email akan diabaikan, begitu pula pengguna dengan alamat email yang menggunakan domain yang tidak terkait dengan akun Cloud Identity atau Google Workspace.
- Jika dua pengguna memiliki alamat email yang sama, hanya satu pengguna yang akan disinkronkan.
- Anda dapat mengonfigurasi sinkronisasi untuk mengganti domain alamat email dengan domain yang berbeda. Proses ini dapat membuat duplikat, dan dalam hal ini hanya satu pengguna yang akan disinkronkan.
Grup peta
Faktor keempat yang harus diperhatikan ketika Anda berencana menggabungkan Active Directory dan Google Cloud adalah perlu atau tidaknya menyinkronkan grup antara Active Directory dan Google Cloud serta cara memetakannya.
Di Google Cloud, grup biasanya digunakan sebagai cara untuk mengelola akses secara efisien di seluruh project. Daripada menetapkan masing-masing pengguna ke peran IAM di setiap project, Anda dapat menentukan kumpulan grup yang memodelkan peran umum dalam organisasi Anda, lalu menetapkan grup tersebut ke sekumpulan peran IAM. Dengan mengubah keanggotaan grup, Anda dapat mengontrol akses pengguna ke seluruh set resource.
Active Directory membedakan antara dua jenis grup: grup distribusi dan grup keamanan. Grup distribusi digunakan untuk mengelola daftar email. Menyinkronkan grup distribusi relevan saat Anda bermigrasi dari Microsoft Exchange ke Google Workspace, sehingga GCDS dapat menangani grup distribusi reguler dan dinamis. Namun, grup distribusi bukan masalah dalam pengelolaan akses dan identitas untuk Google Cloud, sehingga diskusi ini berfokus secara eksklusif pada grup keamanan.
Pemetaan grup antara Active Directory dan Google Cloud bersifat opsional. Setelah menyiapkan penyediaan pengguna, Anda dapat membuat dan mengelola grup secara langsung di Cloud Identity atau Google Workspace. Artinya, Active Directory tetap menjadi sistem pusat untuk pengelolaan identitas, tetapi bukan untuk pengelolaan akses. Untuk mempertahankan Active Directory sebagai sistem pusat untuk pengelolaan identitas dan pengelolaan akses, sebaiknya sinkronkan grup keamanan dari Active Directory, bukan mengelolanya di Cloud Identity atau Google Workspace. Dengan pendekatan ini, Anda dapat menyiapkan IAM sehingga Anda dapat menggunakan keanggotaan grup di Active Directory untuk mengontrol siapa yang memiliki akses ke resource tertentu di Google Cloud.
Grup keamanan di Active Directory
Grup security memainkan peran dasar dalam keamanan Windows dan pengelolaan akses Active Directory. Peran ini difasilitasi oleh tiga jenis grup Active Directory yang berbeda: grup lokal domain, grup global, dan grup universal.
- Grup lokal domain
- Grup ini hanya relevan dalam cakupan satu domain dan tidak dapat dirujuk di domain lain. Karena daftar anggotanya tidak perlu direplikasi di seluruh forest, grup lokal domain menjadi yang paling fleksibel sehubungan dengan jenis anggota yang dapat mereka sertakan.
- Grup global
- Grup ini ditampilkan ke dan dapat dirujuk di domain lain. Namun, daftar anggotanya tidak direplikasi. Batasan ini membatasi jenis anggota yang dapat disertakan dalam grup ini. Grup ini hanya dapat menyertakan pengguna dan grup global lainnya dari domain yang sama.
- Grup universal
- Grup ini, beserta daftar anggotanya, direplikasi di seluruh forest. Oleh karena itu, grup ini dapat direferensikan di domain lain dan dapat mencakup tidak hanya pengguna dan grup universal lainnya, tetapi juga grup global dari semua domain.
Jika forest Active Directory Anda hanya berisi satu domain, Anda dapat menyinkronkan ketiga jenis grup keamanan menggunakan GCDS. Jika forest Active Directory Anda menggunakan lebih dari satu domain, jenis grup akan menentukan apakah dan bagaimana grup tersebut dapat disinkronkan ke Cloud Identity atau Google Workspace.
Karena grup lokal dan global domain tidak sepenuhnya direplikasi di seluruh forest, server katalog global berisi informasi yang tidak lengkap tentang keduanya. Meskipun batasan ini disengaja dan membantu mempercepat replikasi direktori, batasan ini menjadi halangan saat Anda ingin menyinkronkan grup tersebut ke Cloud Identity atau Google Workspace. Khususnya, jika Anda mengonfigurasi GCDS untuk menggunakan server katalog global sebagai sumber, alat ini akan dapat menemukan grup dari semua domain di seluruh forest. Namun, hanya grup yang berada dalam domain yang sama dengan server katalog global yang akan berisi daftar keanggotaan dan cocok untuk replikasi. Untuk menyinkronkan grup lokal atau global domain dalam forest multi-domain, Anda harus menjalankan instance GCDS terpisah per domain.
Karena grup universal direplikasi sepenuhnya di seluruh forest, mereka tidak memiliki batasan ini. Satu instance GCDS dapat menyinkronkan grup universal dari beberapa domain.
Sebelum menyimpulkan bahwa Anda memerlukan beberapa instance GCDS untuk menyinkronkan beberapa domain Active Directory ke Cloud Identity atau Google Workspace, perlu diingat bahwa tidak semua grup mungkin perlu disinkronkan. Karena alasan ini, ada baiknya untuk memperhatikan bagaimana berbagai jenis grup keamanan biasanya digunakan di seluruh forest Active Directory Anda.
Penggunaan grup keamanan di Active Directory
Bagian berikut menjelaskan jenis grup keamanan yang digunakan di Active Directory.
Grup resource
Windows menggunakan model akses yang berdasarkan daftar kontrol akses, access control lists (ACL). Setiap resource seperti file atau objek LDAP memiliki ACL terkait yang mengontrol pengguna mana yang memiliki akses ke resource tersebut. Resource dan ACL sangat terperinci, sehingga ada banyak resource dan ACL. Untuk menyederhanakan pemeliharaan ACL, sebaiknya buat grup resource untuk memaketkan resource yang sering digunakan dan diakses bersama. Anda menambahkan grup resource ke semua ACL yang terpengaruh satu kali, dan mengelola akses lebih lanjut dengan mengubah keanggotaan grup resource, bukan dengan mengubah ACL.
Resource yang dipaketkan dengan cara ini biasanya berada di satu domain. Akibatnya, grup resource juga cenderung hanya direferensikan dalam satu domain, baik di ACL maupun oleh grup resource lainnya. Karena sebagian besar grup resource bersifat lokal, grup tersebut biasanya diterapkan menggunakan grup lokal domain di Active Directory.
Grup peran dan organisasi
Grup resource membantu menyederhanakan pengelolaan akses, tetapi dalam lingkungan yang besar, Anda mungkin perlu menambahkan pengguna baru ke sejumlah besar grup resource. Karena alasan ini, grup resource biasanya dilengkapi dengan grup peran atau grup organisasi.
Grup peran menggabungkan izin yang diperlukan peran tertentu di organisasi. Misalnya, grup peran yang bernama Engineering Documentation Viewer dapat memberikan akses hanya baca kepada anggota untuk semua dokumentasi engineering. Secara praktis, Anda akan menerapkannya dengan membuat grup peran dan menjadikannya anggota dari semua grup resource yang digunakan untuk mengontrol akses ke berbagai jenis dokumentasi.
Dengan cara yang sama, grup organisasi menggabungkan izin yang diperlukan oleh departemen dalam organisasi. Misalnya, grup organisasi yang bernama Engineering dapat memberikan akses ke semua resource yang biasanya diperlukan anggota departemen Engineering.
Secara teknis, tidak ada perbedaan antara grup peran dan grup resource, dan keduanya biasanya digunakan secara bersamaan. Namun, tidak seperti grup resource, grup peran dan organisasi dapat memiliki relevansi di luar batas domain. Agar grup tersebut dapat direferensikan oleh grup resource di domain lain, grup peran dan organisasi biasanya diimplementasikan menggunakan grup global, yang dibatasi pada anggota domain tunggal, dan terkadang dilengkapi dengan grup universal, yang memungkinkan anggota dari domain yang berbeda.
Diagram berikut menunjukkan pola bertingkat yang umum digunakan di lingkungan Active Directory multi-domain.
Grup di Cloud Identity dan Google Workspace
Di Cloud Identity dan Google Workspace, hanya ada satu jenis grup. Grup di Cloud Identity dan Google Workspace tidak terbatas pada cakupan akun Cloud Identity atau Google Workspace tempat grup tersebut ditentukan. Sebaliknya, grup dapat menyertakan pengguna dari akun Cloud Identity atau Google Workspace yang berbeda, dukungan untuk direferensikan dan digabung dengan akun lain, serta digunakan di seluruh organisasi Google Cloud.
Seperti yang dilakukan pengguna, Cloud Identity dan Google Workspace mengidentifikasi grup berdasarkan alamat email. Alamat email tidak harus sesuai dengan kotak surat yang sebenarnya, tetapi harus menggunakan salah satu domain yang terdaftar untuk masing-masing akun Cloud Identity.
Tidak seperti grup Active Directory, anggota grup Cloud Identity atau Google Workspace tidak secara implisit diberi izin untuk mencantumkan anggota lain dari grup yang sama. Sebagai gantinya, membuat kueri keanggotaan grup umumnya memerlukan otorisasi eksplisit.
Penggunaan grup di Google Cloud
Google Cloud menggunakan model akses berbasis peran, bukan model akses berbasis ACL. Peran berlaku untuk semua resource dari jenis tertentu yang berada dalam cakupan tertentu. Misalnya, peran Developer Kubernetes Engine memiliki akses penuh ke objek Kubernetes API di dalam semua cluster dalam project tertentu. Karena sifat peran, Anda tidak perlu mengelola grup resource di Google Cloud, dan jarang perlu menyinkronkan grup resource ke Google Cloud.
Grup peran dan grup organisasi sama relevannya di Google Cloud seperti di Active Directory, karena memudahkan pengelolaan akses untuk banyak pengguna. Menyinkronkan grup peran dan organisasi membantu mempertahankan Active Directory sebagai tempat utama untuk mengelola akses.
Jika Anda secara konsisten menerapkan grup resource sebagai grup lokal domain, serta grup peran dan organisasi sebagai grup global atau universal, Anda dapat menggunakan jenis grup untuk memastikan bahwa hanya grup peran dan organisasi yang disinkronkan.
Pertanyaan apakah cukup untuk menjalankan satu instance GCDS per forest multi-domain atau apakah Anda memerlukan beberapa instance GCDS kemudian menjadi pertanyaan apakah Anda menggunakan grup global atau tidak. Jika Anda menerapkan semua grup peran dan organisasi menggunakan grup universal, satu instance GCDS sudah cukup; jika tidak, Anda memerlukan instance GCDS per domain.
Memetakan identitas grup
Pemetaan grup keamanan Active Directory ke grup Cloud Identity atau Google Workspace memerlukan ID umum. Di Cloud Identity dan Google Workspace, ID ini harus berupa alamat email yang bagian domainnya sesuai dengan domain primer, sekunder, atau alias akun Cloud Identity atau Google Workspace. Karena alamat email ini akan digunakan di seluruh Google Cloud, alamat tersebut harus dapat dibaca manusia. Alamat email tidak perlu berkaitan dengan kotak surat.
Di Active Directory, grup diidentifikasi dengan nama umum (cn)
atau dengan nama login pra-Windows 2000 (sAMAccountName). Serupa dengan akun
pengguna, grup juga dapat memiliki alamat email (mail), tetapi alamat email
adalah atribut opsional untuk grup, dan Active Directory tidak memverifikasi
keunikan.
Anda memiliki dua opsi untuk memetakan identitas grup antara Active Directory dan Cloud Identity atau Google Workspace.
Memetakan berdasarkan nama umum
Keuntungan menggunakan nama umum (cn) adalah nama tersebut dijamin akan
tersedia dan, setidaknya dalam unit organisasi, unik. Namun, nama umum bukan alamat email, sehingga memerlukan akhiran @DOMAIN yang ditambahkan untuk menjadi alamat email.
Anda dapat mengonfigurasi GCDS untuk otomatis menangani penambahan akhiran ke nama grup. Karena Active Directory memastikan bahwa nama grup dan nama pengguna tidak bertentangan, alamat email yang berasal dari cara ini juga tidak akan menyebabkan konflik.
Jika forest Active Directory Anda berisi lebih dari satu domain, peringatan berikut berlaku:
- Jika dua grup di domain yang berbeda memiliki nama yang sama, alamat email yang berasal dari nama tersebut akan bertentangan, sehingga menyebabkan satu grup diabaikan selama sinkronisasi.
- Anda hanya dapat menyinkronkan grup dari domain satu forest. Jika Anda menyinkronkan grup dari beberapa forest dengan menggunakan instance GCDS terpisah, alamat email yang berasal dari nama umum tidak mencerminkan forest mana yang terkait. Ambiguitas ini akan menyebabkan instance GCDS menghapus grup apa pun yang sebelumnya telah dibuat dari forest berbeda oleh instance GCDS lainnya.
- Anda tidak dapat memetakan grup berdasarkan nama umum jika menggunakan penggantian domain untuk memetakan pengguna.
Memetakan berdasarkan alamat email
Menggunakan alamat email (mail) untuk memetakan identitas grup berarti Anda harus memenuhi
kriteria yang sama seperti saat menggunakan alamat email untuk memetakan pengguna:
Penetapan email harus selesai. Meskipun grup distribusi biasanya memiliki alamat email, grup keamanan sering kali tidak memiliki atribut ini. Untuk menggunakan alamat email guna memetakan identitas, grup keamanan yang tunduk pada sinkronisasi harus memiliki kolom
mailyang terisi. Perintah PowerShell berikut dapat membantu Anda menemukan akun yang kolom ini tidak diisi:Get-ADGroup -LDAPFilter "(!mail=*)"
Alamat email harus menggunakan kumpulan domain yang diseleksi, yang semuanya Anda miliki. Jika beberapa pengguna Anda menggunakan alamat email yang merujuk ke perusahaan partner atau penyedia email konsumen, Anda tidak dapat menggunakan alamat tersebut.
Semua alamat email harus unik di seluruh forest. Karena Active Directory tidak menerapkan keunikan, Anda mungkin harus menerapkan pemeriksaan atau kebijakan kustom.
Jika semua grup yang relevan memenuhi kriteria tersebut, Anda dapat mengidentifikasi semua domain yang digunakan oleh alamat email ini dan memastikan bahwa daftar domain DNS yang terdaftar di Cloud Identity atau Google Workspace mencakup domain ini.
Jika salah satu kriteria tidak terpenuhi, Anda masih dapat memetakan UPN ke alamat email Cloud Identity atau Google Workspace, dengan ketentuan berikut:
- Grup tanpa alamat email akan diabaikan selama sinkronisasi, begitu pula alamat email yang menggunakan domain yang tidak terkait dengan akun Cloud Identity atau Google Workspace.
- Jika dua grup memiliki alamat email yang sama, hanya salah satunya yang akan disinkronkan.
Pemetaan grup menurut alamat email tidak didukung jika forest Active Directory berisi lebih dari satu domain dan Anda menggunakan penggantian domain untuk memetakan pengguna.
Memetakan unit organisasi
Sebagian besar domain Active Directory menggunakan unit organisasi secara ekstensif untuk mengelompokkan dan mengatur resource secara hierarkis, mengontrol akses, dan menerapkan kebijakan.
Di Google Cloud, folder dan project memiliki tujuan yang serupa, meskipun jenis resource yang dikelola dalam organisasi Google Cloud sangat berbeda dengan resource yang dikelola di Active Directory. Akibatnya, hierarki folder Google Cloud yang sesuai untuk perusahaan cenderung berbeda secara signifikan dengan struktur unit organisasi di Active Directory. Oleh karena itu, pemetaan unit organisasi ke folder dan project secara otomatis jarang praktis dan tidak didukung oleh GCDS.
Tidak terkait dengan folder, Cloud Identity dan Google Workspace mendukung konsep unit organisasi. Unit organisasi dibuat untuk mengelompokkan dan mengelola pengguna, mirip dengan Active Directory. Tapi tidak seperti di Active Directory, ketentuan ini hanya berlaku untuk pengguna, bukan untuk grup.
GCDS menawarkan opsi untuk menyinkronkan unit organisasi Active Directory ke Cloud Identity atau Google Workspace. Dalam penyiapan saat Cloud Identity hanya digunakan untuk memperluas pengelolaan identitas Active Directory ke Google Cloud, pemetaan unit organisasi biasanya tidak diperlukan.
Memilih pemetaan yang tepat
Seperti yang disebutkan di awal dokumen ini, tidak ada satu cara terbaik untuk memetakan struktur Active Directory dan Google Cloud. Untuk membantu Anda memilih pemetaan yang tepat untuk skenario Anda, grafik keputusan berikut merangkum kriteria yang telah dibahas di bagian sebelumnya.
Pertama, lihat diagram berikut untuk mengidentifikasi jumlah akun Cloud Identity atau Google Workspace, instance GCDS, dan instance atau fleet AD FS yang akan Anda perlukan.
Kemudian, lihat diagram kedua untuk mengidentifikasi domain yang akan dikonfigurasi di akun Cloud Identity atau Google Workspace Anda.
Langkah berikutnya
- Baca praktik terbaik untuk merencanakan akun dan organisasi serta praktik terbaik untuk menggabungkan Google Cloud dengan penyedia identitas eksternal.
- Mengonfigurasi GCDS untuk menyinkronkan pengguna dan grup Active Directory ke Cloud Identity.
- Mengonfigurasi single sign-on antara Active Directory dan Google Cloud.
- Pelajari praktik terbaik untuk mengelola akun administrator super