Menggabungkan Google Cloud dengan Active Directory

Last reviewed 2023-02-27 UTC

Artikel ini menjelaskan cara mengonfigurasi Cloud Identity atau Google Workspace untuk menggunakan Active Directory sebagai IdP dan sumber resmi.

Artikel ini membandingkan struktur logis dari Active Directory dengan struktur yang digunakan oleh Cloud Identity dan Google Workspace, serta menjelaskan cara memetakan forest, domain, pengguna, dan grup Active Directory. Artikel ini juga menyediakan diagram alir yang membantu Anda menentukan pendekatan pemetaan terbaik untuk skenario Anda.

Artikel ini mengasumsikan bahwa Anda sudah memahami Active Directory.

Menerapkan sistem gabungan

Google Cloud menggunakan identitas Google untuk autentikasi dan pengelolaan akses. Mempertahankan identitas Google secara manual untuk setiap karyawan dapat menambahkan overhead pengelolaan yang tidak perlu jika semua karyawan sudah memiliki akun di Active Directory. Dengan menggabungkan identitas pengguna antara Google Cloud dan sistem pengelolaan identitas yang ada, Anda dapat mengotomatiskan pemeliharaan identitas Google dan mengaitkan siklus proses mereka dengan pengguna yang 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 direferensikan di Google Cloud bahkan sebelum pengguna terkait login untuk pertama kalinya. Proses ini juga memastikan bahwa penghapusan pengguna sedang diterapkan.

  Penyediaan bekerja dengan satu cara, yang berarti perubahan pada Active Directory} akan direplikasi ke Google Cloud, tetapi tidak sebaliknya. Selain itu, penyediaan tidak menyertakan sandi. Dalam konfigurasi 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 ke Active Directory menggunakan protokol Security Assertion Markup Language (SAML). Delegasi ini memastikan bahwa hanya Active Directory yang mengelola kredensial pengguna dan bahwa kebijakan atau mekanisme autentikasi multi-faktor (MFA) yang berlaku akan diterapkan. Namun, agar proses login berhasil, masing-masing pengguna harus sudah disediakan sebelumnya.

Untuk menerapkan penggabungan, Anda dapat menggunakan alat berikut:

• Google Cloud Directory Sync adalah alat gratis yang disediakan Google untuk menerapkan proses sinkronisasi. Google Cloud Directory Sync 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 untuk umum dan SAML adalah standar terbuka, banyak alat yang tersedia untuk mengimplementasikan penggabungan. Artikel ini berfokus pada penggunaan Google Cloud Directory Sync 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 container 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, organizations 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

Meskipun ada kesamaan antara struktur logis Active Directory dan Google Cloud, tidak ada satu pemetaan tunggal yang berfungsi dengan baik di semua skenario. Sebaliknya, pendekatan yang tepat untuk mengintegrasikan kedua 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 forest

Terutama 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 menggabungkan Active Directory dan Google Cloud, faktor pertama yang harus diperhatikan 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 menjadi dasar untuk satu organisasi Google Cloud yang dapat Anda gunakan untuk mengelola resource Google Cloud.

Dalam lingkungan domain tunggal, pengontrol domain dan server katalog global memberikan akses ke semua objek yang dikelola di Active Directory. Pada umumnya, Anda dapat menjalankan satu instance Google Cloud Directory Sync untuk menyinkronkan akun pengguna dan grup ke Google Cloud, dan untuk mempertahankan 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 menjadi 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 yang dapat dikueri dari server katalog global. Meskipun pengontrol domain hanya menyajikan data dari domain lokalnya, server katalog global memberikan akses ke informasi dari semua domain di forest tersebut. Data yang ditayangkan oleh server katalog global bersifat sebagian dan tidak memiliki atribut LDAP tertentu. Keterbatasan ini dapat memengaruhi cara Anda mengonfigurasi Google Cloud Directory Sync untuk menyinkronkan grup.

Bergantung pada rencana Anda untuk memetakan grup, proses federasi hutan multi-domain dengan Google Cloud memerlukan satu atau beberapa instance Google Cloud Directory Sync, 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 memberikan 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-hutan, 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 Google Cloud Directory Sync 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 hutan harus dipetakan ke akun Cloud Identity atau Google Workspace yang terpisah, yang melibatkan pengoperasian setidaknya satu instance Google Cloud Directory Sync dan satu server atau fleet AD FS per hutan.

Di Google Cloud, organisasi yang terpisah dibuat untuk setiap akun Cloud Identity atau Google Workspace. Pada umumnya, Anda tidak perlu mengelola banyak organisasi terpisah. Anda dapat memilih salah satu organisasi dan hubungkan 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 serta Cloud Identity dan Google Workspace. Faktor kedua yang harus diperhatikan ketika Anda berencana menggabungkan 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 dapat bersifat global, seperti corp.example.com, atau dapat berupa nama domain lokal seperti corp.local atau corp.internal.
• Domain mail exchange (MX): Alamat email menggunakan domain DNS. Dalam beberapa kasus, domain ini sama dengan domain DNS Active Directory, tetapi di banyak kasus, domain yang berbeda dan sering kali lebih pendek seperti example.com digunakan. Idealnya, pengguna di Active Directory memiliki alamat email yang dikaitkan dengan atribut mail opsional.
• Domain akhiran UPN: Domain ini digunakan untuk User Principal Names (UPN). Secara default, domain DNS Active Directory dari domain pengguna digunakan untuk membuat UPN. Untuk pengguna john dalam domain corp.example.com, UPN default akan membaca [e-mail]. 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 kolom userPrincipalName pengguna.
• 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, UPN, atau domain DNS Active Directory, atau bisa juga merupakan 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, [e-mail] dan [e-mail], dianggap sebagai pengguna terpisah jika example.com adalah domain primer dan secondary.example.com adalah domain sekunder.
• Domain alias: Domain alias adalah nama alternatif untuk domain lain. Artinya, [e-mail] dan [e-mail] merujuk ke pengguna yang sama jika alias.example.com disiapkan sebagai domain alias untuk example.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, seperti subdomain.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 antardirektori, diperlukan beberapa pemetaan 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 pengamatan lebih mendalam tentang cara identifikasi pengguna di hutan Active Directory dan cara pemetaannya ke Cloud Identity atau Google Workspace.

Memetakan pengguna

Faktor ketiga yang perlu dipertimbangkan 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 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.

Tidak satu pun ID ini yang berarti bagi pengguna, sehingga Active Directory menawarkan dua cara yang mudah digunakan manusia untuk mengidentifikasi pengguna:

• UPN (userPrincipalName): Cara yang direkomendasikan untuk mengidentifikasi pengguna adalah dengan UPN. UPN mengikuti format alamat email RFC 822 dan dibuat dengan menggabungkan nama pengguna dengan domain akhiran UPN, seperti [e-mail]. Meskipun menjadi cara yang disukai untuk mengidentifikasi pengguna, UPN bersifat opsional, sehingga beberapa pengguna di forest Active Directory Anda mungkin tidak memiliki UPN.

  Meskipun UPN 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 dan nama pengguna NetBIOS dengan menggunakan format domain<var>user, seperti dalam corp\johndoe. Meskipun dianggap sebagai nama lama, nama ini masih umum digunakan dan merupakan satu-satunya ID wajib pengguna.

Secara khusus, 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.

Memetakan identitas pengguna

Untuk setiap pengguna, pemetaan pengguna Active Directory ke Cloud Identity atau Google Workspace memerlukan dua informasi:

• ID unik dan 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, objectGUID sangat cocok untuk tujuan ini.
• Alamat email yang bagian domainnya sesuai dengan domain primer, sekunder, atau alias dari akun Cloud Identity atau Google Workspace Anda. Karena alamat email ini akan digunakan di seluruh Google Cloud, pastikan alamat tersebut bermakna. Memperoleh alamat dari objectGUID tidak praktis, seperti halnya alamat email lain yang dibuat secara otomatis.

Bagi pengguna Active Directory, dua kolom adalah kandidat 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:

• UPN harus berupa alamat email yang valid. Semua domain yang digunakan sebagai domain akhiran UPN juga harus berupa domain MX dan harus diatur sehingga email yang dikirim ke UPN pengguna dikirim ke kotak masuk email mereka.

• Tugas UPN harus selesai. Semua pengguna yang tunduk pada 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 memetakan UPN dengan aman 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 peringatan 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 duplikasi, 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 mengharuskan pemenuhan kriteria berikut untuk semua pengguna yang tunduk pada sinkronisasi:

• Penetapan email harus selesai. Semua pengguna yang bergantung pada sinkronisasi harus memiliki kolom mail yang terisi. Perintah PowerShell berikut dapat membantu Anda menemukan pengguna yang tidak memiliki kolom ini:

  Get-ADUser -LDAPFilter "(!mail=*)"

• Alamat email harus menggunakan kumpulan domain pilihan, yang semuanya dimiliki oleh 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 mengimplementasikan 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 primer 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 peringatan berikut:

• Selama sinkronisasi, pengguna tanpa alamat email akan diabaikan, begitu juga pengguna dengan alamat email yang menggunakan domain yang tidak terkait dengan akun Cloud Identity atau Google Workspace.
• Jika dua pengguna menggunakan alamat email yang sama, hanya satu pengguna yang akan disinkronkan.
• Anda dapat mengonfigurasi sinkronisasi untuk mengganti domain alamat email dengan domain lain. Proses ini dapat membuat duplikasi, dalam hal ini hanya satu pengguna yang akan disinkronkan.

Memetakan grup

Faktor keempat yang harus dipertimbangkan kapan Anda berencana menggabungkan Active Directory dan Google Cloud adalah apakah akan 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 di organisasi Anda, lalu menetapkan grup tersebut ke kumpulan peran IAM. Dengan mengubah keanggotaan grup, Anda dapat mengontrol akses pengguna ke seluruh set resource.

Active Directory membedakan dua jenis grup: grup distribusi dan grup keamanan. Grup distribusi digunakan untuk mengelola daftar email. Sinkronisasi grup distribusi perlu dilakukan saat Anda bermigrasi dari Microsoft Exchange ke Google Workspace, sehingga Google Cloud Directory Sync dapat menangani grup distribusi reguler dan dinamis. Namun, grup distribusi bukan merupakan masalah dalam pengelolaan akses dan identitas untuk Google Cloud, sehingga diskusi ini hanya berfokus 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 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: grup lokal domain, grup global, dan grup universal.

Grup lokal domain

Grup ini hanya relevan dalam cakupan satu domain dan tidak dapat direferensikan dalam 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 dan dapat dirujuk di domain lain. Namun, daftar anggotanya tidak direplikasi. Batasan ini membatasi jenis anggota yang dapat disertakan oleh 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, mereka dapat dirujuk di domain lain dan dapat menyertakan 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 Google Cloud Directory Sync. Jika hutan Active Directory Anda menggunakan lebih dari satu domain, jenis grup menentukan apakah dan bagaimana grup 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 pembatasan ini disengaja dan membantu mempercepat replikasi direktori, hal ini menjadi hambatan ketika Anda ingin menyinkronkan grup tersebut ke Cloud Identity atau Google Workspace. Khususnya, jika Anda mengonfigurasi Google Cloud Directory Sync untuk menggunakan server katalog global sebagai sumber, alat ini akan dapat menemukan grup dari semua domain di seluruh forest. Namun, hanya grup yang berada di 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 Google Cloud Directory Sync terpisah per domain.

Karena grup universal direplikasi sepenuhnya di seluruh forest, mereka tidak memiliki batasan ini. Satu instance Google Cloud Directory Sync dapat menyinkronkan grup universal dari beberapa domain.

Sebelum menyimpulkan bahwa Anda memerlukan beberapa instance Google Cloud Directory Sync 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

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 dapat mengaksesnya. Resource dan ACL sangat terperinci, jadi jumlahnya ada banyak. Untuk menyederhanakan pemeliharaan ACL, biasanya Anda membuat grup resource untuk memaketkan resource yang sering digunakan dan diakses bersama. Anda menambahkan grup resource ke semua ACL yang terpengaruh sekali, 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 atau oleh grup resource lainnya. Karena sebagian besar grup resource bersifat lokal, grup resource tersebut biasanya diimplementasikan 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 dalam organisasi. Grup peran yang bernama Engineering Documentation Viewer, misalnya, dapat memberi anggota akses hanya baca ke semua dokumentasi teknik. 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 suatu organisasi. Misalnya, grup organisasi yang bernama Engineering mungkin memberikan akses ke semua resource yang biasanya diperlukan oleh anggota departemen Teknik.

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 biasa 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 halnya 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 dalam 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 termasuk dalam cakupan tertentu. Misalnya, peran Kubernetes Engine Developer memiliki akses penuh ke objek Kubernetes API di dalam semua cluster dalam project tertentu. Karena sifat peran, pengelolaan grup resource di Google Cloud tidak perlu dilakukan, dan sinkronisasi grup resource ke Google Cloud jarang terjadi.

Grup peran dan grup organisasi sama relevannya di Google Cloud seperti halnya di Active Directory, karena keduanya mempermudah pengelolaan akses untuk sejumlah besar pengguna. Menyinkronkan grup peran dan organisasi akan membantu mempertahankan Active Directory sebagai tempat utama untuk mengelola akses.

Jika Anda secara konsisten mengimplementasikan 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 Google Cloud Directory Sync per forest multi-domain atau apakah Anda memerlukan beberapa instance Google Cloud Directory Sync kemudian menjadi pertanyaan apakah Anda menggunakan grup global atau tidak. Jika Anda menerapkan semua peran dan grup organisasi menggunakan grup universal, satu instance Google Cloud Directory Sync sudah cukup; jika tidak, Anda memerlukan instance Google Cloud Directory Sync 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 utama, 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 berhubungan dengan kotak surat.

Di Active Directory, grup diidentifikasi berdasarkan nama umum (cn) atau 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 bahwa nama tersebut dijamin tersedia dan, setidaknya dalam unit organisasi, unik. Namun, nama umum tersebut bukan alamat email sehingga perlu penambahan akhiran @DOMAIN agar dapat diubah menjadi alamat email.

Anda dapat mengonfigurasi Google Cloud Directory Sync untuk menangani penambahan akhiran ke nama grup secara otomatis. Karena Active Directory memastikan bahwa nama grup dan nama pengguna tidak bertentangan, alamat email yang diperoleh dengan cara ini juga tidak akan menimbulkan konflik.

Jika forest Active Directory Anda berisi lebih dari satu domain, peringatan berikut berlaku:

• Jika dua grup di domain yang berbeda menggunakan nama yang sama, alamat email turunan akan bentrok, yang 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 Google Cloud Directory Sync terpisah, alamat email yang berasal dari nama umum tidak mencerminkan forest mana yang terkait. Ambiguitas ini akan menyebabkan instance Google Cloud Directory Sync menghapus grup apa pun yang sebelumnya telah dibuat dari forest berbeda oleh instance Google Cloud Directory Sync lainnya.
• Anda tidak dapat memetakan grup berdasarkan nama umum jika menggunakan substitusi domain untuk memetakan pengguna.

Memetakan berdasarkan alamat email

Menggunakan alamat email (mail) untuk memetakan identitas grup berarti Anda harus memenuhi kriteria yang sama seperti ketika menggunakan alamat email untuk memetakan pengguna:

• Penetapan email harus selesai. Meskipun grup distribusi umumnya memiliki alamat email, grup keamanan sering kali tidak memiliki atribut ini. Agar dapat menggunakan alamat email untuk memetakan identitas, grup keamanan yang tunduk pada sinkronisasi harus memiliki kolom mail yang terisi. Perintah PowerShell berikut dapat membantu Anda menemukan akun yang tidak memiliki kolom ini:

  Get-ADGroup -LDAPFilter "(!mail=*)"

• Alamat email harus menggunakan kumpulan domain pilihan, yang semuanya milik Anda. 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 mengimplementasikan pemeriksaan atau kebijakan kustom.

Jika semua grup yang relevan memenuhi kriteria ini, 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 peringatan berikut:

• Grup tanpa alamat email akan diabaikan selama sinkronisasi, begitu juga dengan alamat email yang menggunakan domain yang tidak dikaitkan 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 banyak memanfaatkan unit organisasi untuk mengelompokkan dan mengatur resource secara hierarkis, mengontrol akses, dan memberlakukan kebijakan.

Di Google Cloud, folder dan project memiliki fungsi yang sama, 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, memetakan unit organisasi ke folder dan project secara otomatis jarang bersifat praktis dan tidak didukung oleh Google Cloud Directory Sync.

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.

Google Cloud Directory Sync menawarkan opsi untuk menyinkronkan unit organisasi Active Directory ke Cloud Identity atau Google Workspace. Dalam penyiapan yang hanya menggunakan Cloud Identity untuk memperluas pengelolaan identitas Active Directory ke Google Cloud, pemetaan unit organisasi biasanya tidak diperlukan.

Memilih pemetaan yang tepat

Seperti yang disebutkan di awal artikel ini, tidak ada cara terbaik untuk memetakan struktur Active Directory dan Google Cloud. Guna membantu Anda memilih pemetaan yang tepat untuk skenario Anda, grafik keputusan berikut merangkum kriteria yang dibahas di bagian sebelumnya.

Pertama, lihat diagram berikut untuk mengidentifikasi jumlah akun Cloud Identity atau Google Workspace, instance Google Cloud Directory Sync, 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 selanjutnya

• Baca praktik terbaik untuk merencanakan akun dan organisasi serta praktik terbaik untuk menggabungkan Google Cloud dengan penyedia identitas eksternal.
• Mengonfigurasi Google Cloud Directory Sync 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