Pengontrol domain yang dioperasikan oleh Layanan Terkelola untuk Microsoft Active Directory mengekspos sejumlah layanan, termasuk LDAP, DNS, Kerberos, dan RPC. Bergantung pada kasus penggunaan Anda, Virtual Machine (VM) yang di-deploy di Google Cloud, serta mesin yang berjalan di infrastruktur lokal, mungkin memerlukan akses ke layanan ini untuk memanfaatkan Active Directory.
Untuk mengurangi permukaan serangan pengontrol domain dan VM, Anda harus menggunakan firewall untuk melarang komunikasi jaringan apa pun yang tidak benar-benar diperlukan. Artikel ini menjelaskan cara mengonfigurasi firewall untuk mengakomodasi kasus penggunaan Direktori Aktif yang umum, sekaligus melarang komunikasi jaringan lainnya.
Logon versus autentikasi
Meskipun istilah {i>logon<i} dan autentikasi sering digunakan secara bergantian, keduanya memiliki arti yang berbeda dalam konteks keamanan Windows. Logon menjelaskan proses yang terjadi pada sistem yang diakses pengguna. Sebaliknya, autentikasi dilakukan oleh komputer tempat akun pengguna berada.
Saat Anda menggunakan akun lokal untuk login ke komputer, proses login dan autentikasi ditangani oleh mesin target. Dalam lingkungan Active Directory, lebih umum menggunakan pengguna domain untuk login. Dalam hal ini, login ditangani oleh komputer target, sedangkan autentikasi dilakukan oleh pengontrol domain.
Untuk mengautentikasi, klien dapat menggunakan Kerberos atau NTLM . Setelah klien mengotentikasi, komputer target perlu memproses {i>logon<i}. Bergantung pada jenis login yang diminta klien, hal ini mungkin memerlukan interaksi tambahan dengan pengontrol domain menggunakan protokol seperti Kerberos, NTLM, LDAP, RPC, atau SMB .
Karena autentikasi dan pemrosesan logon memerlukan protokol yang berbeda, sebaiknya bedakan kedua konsep saat mengidentifikasi konfigurasi firewall yang tepat.
Kasus penggunaan umum
Bagian berikut menjelaskan kasus penggunaan umum untuk mengakses Microsoft AD Terkelola dan menunjukkan aturan firewall yang perlu dikonfigurasi untuk setiap kasus penggunaan.
Jika tidak berencana mengintegrasikan Microsoft AD Terkelola dengan Active Directory lokal, Anda hanya perlu membaca bagian pertama artikel ini, Mengakses Microsoft AD Terkelola dari dalam VPC Anda. Jika Anda ingin membuat hubungan kepercayaan antara Microsoft AD Terkelola dan Active Directory lokal, seluruh artikel juga berlaku.
Anda dapat menggunakan log aturan firewall untuk menganalisis apakah port tambahan mungkin diperlukan. Karena aturan penolakan traffic masuk yang tersirat telah menonaktifkan logging, Anda harus terlebih dahulu membuat aturan firewall kustom berprioritas rendah yang menolak semua traffic masuk, tetapi mengaktifkan logging firewall. Dengan aturan ini, setiap upaya koneksi yang gagal akan menyebabkan entri log dipublikasikan ke Stackdriver. Karena aturan firewall dapat menghasilkan log dalam volume yang signifikan, pertimbangkan untuk menonaktifkan logging firewall lagi setelah Anda menyelesaikan analisis.
Mengakses Microsoft AD Terkelola dari dalam VPC
Saat Anda menggunakan jaringan default untuk men-deploy Microsoft AD Terkelola, tidak ada konfigurasi lebih lanjut yang diperlukan untuk mengaktifkan VM di VPC untuk mengakses Active Directory.
Jika telah menyesuaikan konfigurasi VPC atau aturan firewall, Anda harus memastikan bahwa konfigurasi firewall masih mengizinkan komunikasi dengan Microsoft AD Terkelola. Bagian berikut menjelaskan aturan firewall yang mungkin perlu Anda buat.
Resolusi nama domain
Saat mencoba me-resolve nama DNS, VM tidak secara langsung membuat kueri pengontrol domain. Sebagai gantinya, kueri DNS dikirim ke server metadata, yang merupakan server DNS default yang dikonfigurasi untuk VM Compute Engine. Kemudian, server metadata meneruskan kueri ke zona penerusan DNS pribadi Cloud DNS yang dibuat oleh Microsoft AD Terkelola. Zona penerusan ini kemudian meneruskan kueri ke pengontrol domain yang sesuai.
Anda tidak perlu mengonfigurasi aturan firewall apa pun untuk mengaktifkan kasus penggunaan ini. Komunikasi ke Cloud DNS selalu diizinkan untuk VM di VPC, dan Microsoft AD Terkelola mengizinkan permintaan DNS yang diteruskan dari Cloud DNS Cloud DNS secara default.
Mengautentikasi ke VM menggunakan Kerberos
Pengguna yang telah login ke satu VM mungkin memerlukan akses ke layanan yang disediakan oleh VM lain. Misalnya, pengguna mungkin mencoba membuka koneksi RDP, mengakses berbagi file, atau mengakses resource HTTP yang memerlukan autentikasi.
Agar pengguna dapat melakukan autentikasi ke VM server menggunakan Kerberos, VM klien harus mendapatkan tiket Kerberos yang sesuai terlebih dahulu dari salah satu pengontrol Microsoft AD Terkelola.
Agar VM dapat mengautentikasi ke VM lainnya menggunakan Kerberos, komunikasi berikut harus diizinkan oleh aturan firewall:
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | VM klien | Subnet Microsoft AD terkelola |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 2 | Izinkan | VM klien | VM Server | Protokol yang digunakan untuk mengakses VM, seperti HTTP (TCP/80, TCP/443) atau RDP (TCP/3389) |
| 3 | Izinkan | VM Server | Subnet Microsoft AD terkelola | Lihat memproses login. |
Mengautentikasi ke VM menggunakan NTLM
Meskipun Windows lebih menyukai Kerberos daripada NTLM pada umumnya, klien terkadang mungkin perlu beralih kembali menggunakan NTLM untuk autentikasi. NTLM mengandalkan autentikasi pass-through, sehingga mengharuskan server berkomunikasi dengan salah satu pengontrol domain Microsoft AD Terkelola untuk mengautentikasi pengguna.
Agar VM dapat mengautentikasi VM lain menggunakan NTLM, komunikasi berikut harus diizinkan oleh aturan firewall:
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | VM klien | VM Server | Protokol yang digunakan untuk mengakses VM, seperti HTTP (TCP/80, TCP/443) atau RDP (TCP/3389) |
| 2 | Izinkan | VM klien | Subnet Microsoft AD terkelola | Lihat memproses login. |
Bergabung dan memproses login domain
Untuk beroperasi sebagai anggota domain dan memproses login dari pengguna, mesin harus dapat berinteraksi dengan Active Directory. Set protokol yang tepat yang digunakan tergantung pada jenis {i>logon<i} yang diminta masing-masing klien. Untuk mendukung semua skenario umum, Anda harus mengizinkan kombinasi protokol berikut.
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | VM Server | Subnet Microsoft AD terkelola |
Kerberos (UDP/88, TCP/88) NTP (UDP/123) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) LDAP GC (TCP/32) |
Selain itu, bergantung pada kasus penggunaan yang tepat, Anda mungkin juga ingin mengizinkan protokol berikut:
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | VM Server | Subnet Microsoft AD terkelola |
Perubahan sandi Kerberos (UDP/464, TCP/464) LDAP Aman (TCP/636, TCP/3269) |
Mengelola Microsoft AD Terkelola
Anda harus menggunakan VM yang bergabung dengan domain untuk mengelola Microsoft AD Terkelola. Untuk menggunakan alat seperti Active Directory Administrative Center pada VM ini, VM juga harus dapat mengakses Layanan Web Direktori Aktif yang diekspos oleh pengontrol domain Microsoft AD Terkelola.
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | VM Admin | Subnet Microsoft AD terkelola | Layanan Web AD (TCP/9389) |
Menghubungkan Microsoft AD Terkelola ke Active Directory lokal
Untuk menghubungkan Microsoft AD Terkelola ke Active Directory lokal, Anda harus membuat hubungan kepercayaan antar-forest. Selain itu, Anda harus mengaktifkan resolusi nama DNS antara Google Cloud dan lingkungan lokal Anda.
Pembuatan dan verifikasi kepercayaan
Untuk membuat dan memverifikasi kepercayaan hutan, pengontrol domain Microsoft AD Terkelola dan pengontrol domain root untuk hutan lokal harus dapat berkomunikasi secara dua arah.
Untuk mengaktifkan pembuatan dan verifikasi kepercayaan, konfigurasikan firewall lokal Anda untuk mengizinkan traffic masuk dan keluar yang cocok dengan karakteristik berikut:
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | AD Lokal | Managed Microsoft AD |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Perubahan sandi Kerberos (UDP/464, TCP/464) TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) |
| 2 | Izinkan | Managed Microsoft AD | AD Lokal |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Perubahan sandi Kerberos (UDP/464, TCP/464) TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) |
Microsoft AD terkelola telah dikonfigurasi untuk mengizinkan traffic yang cocok dengan karakteristik ini, sehingga Anda tidak perlu mengonfigurasi aturan firewall tambahan di Google Cloud.
Menyelesaikan nama DNS Google Cloud dari infrastruktur lokal
Ada dua cara untuk mengizinkan mesin lokal me-resolve nama DNS di Microsoft AD Terkelola: Delegasi DNS dan penerusan DNS bersyarat.
Delegasi DNS
Domain DNS yang digunakan oleh Microsoft AD Terkelola mungkin merupakan subdomain dari domain DNS yang digunakan secara lokal. Misalnya, Anda dapat menggunakan cloud.example.com untuk Microsoft AD Terkelola saat menggunakan example.com di infrastruktur lokal. Agar klien lokal dapat me-resolve nama DNS resource Google Cloud, Anda dapat menyiapkan delegasi DNS.
Saat menggunakan delegasi DNS, upaya untuk me-resolve nama DNS resource Google Cloud terlebih dahulu akan mengkueri server DNS lokal. Server DNS kemudian mengalihkan klien ke Cloud DNS, yang kemudian meneruskan permintaan ke salah satu pengontrol domain Microsoft AD Terkelola Anda.
Untuk mengekspos Cloud DNS ke jaringan lokal, Anda harus membuat kebijakan server masuk dan keluar. Tindakan ini akan membuat alamat IP penerus masuk yang merupakan bagian dari VPC Anda.
Untuk menggunakan alamat penerusan dari infrastruktur lokal, konfigurasikan firewall lokal Anda untuk mengizinkan traffic keluar yang sesuai dengan karakteristik di bawah.
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | AD Lokal | Managed Microsoft AD |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Perubahan sandi Kerberos (UDP/464, TCP/464) TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) |
| 2 | Izinkan | Managed Microsoft AD | AD Lokal |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Perubahan sandi Kerberos (UDP/464, TCP/464) TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) |
Penerusan DNS bersyarat
Domain DNS yang digunakan oleh Microsoft AD Terkelola mungkin bukan subdomain dari
domain DNS yang digunakan di infrastruktur lokal. Misalnya, Anda dapat menggunakan cloud.example.com untuk
Microsoft AD yang Terkelola saat menggunakan corp.example.local secara lokal.
Jika domain DNS tidak terkait, Anda dapat menyiapkan penerusan DNS bersyarat di DNS Active Directory lokal Anda. Semua kueri yang cocok dengan nama DNS yang digunakan oleh Microsoft AD Terkelola akan diteruskan ke Cloud DNS.
Untuk menggunakan penerusan DNS bersyarat, Anda perlu menyiapkan kebijakan DNS yang mengaktifkan penerusan DNS masuk terlebih dahulu. Untuk menggunakan alamat forwarder yang dihasilkan dari infrastruktur lokal, konfigurasikan firewall lokal untuk mengizinkan traffic keluar yang sesuai dengan karakteristik di bawah.
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | AD Lokal | Alamat IP penerusan DNS | DNS (UDP/53, TCP/53) |
Di sisi Google Cloud, buat aturan firewall untuk mengizinkan traffic masuk yang cocok dengan kriteria ini.
Anda tidak perlu mengonfigurasi aturan firewall apa pun untuk mengaktifkan komunikasi dari DNS Forwarder ke Cloud DNS (2).
Menyelesaikan nama DNS lokal dari Google Cloud
Microsoft AD terkelola menggunakan penerusan DNS kondisional untuk me-resolve nama DNS di hutan lokal Anda. Agar klien yang berjalan di Google Cloud dapat me-resolve nama DNS yang dikelola oleh Active Directory lokal, Anda dapat membuat zona penerusan pribadi di Cloud DNS DNS yang meneruskan kueri ke pengontrol domain lokal.
Agar nama DNS lokal dapat ditetapkan dari Google Cloud, konfigurasikan firewall lokal untuk mengizinkan traffic masuk sesuai tabel berikut.
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | Managed Microsoft AD | AD Lokal | DNS (UDP/53, TCP/53) |
| 2 | Izinkan | Cloud DNS (35.199.192.0/19) | AD Lokal | DNS (UDP/53, TCP/53) |
Google Cloud mengizinkan traffic keluar yang sesuai secara default.
Mengakses resource Microsoft AD Terkelola dari infrastruktur lokal
Jika Forest Microsoft AD Terkelola disiapkan untuk memercayai hutan lokal Anda, Anda mungkin ingin agar pengguna dan mesin lokal dapat mengakses resource di forest Microsoft AD yang Dikelola.
Mengautentikasi ke VM dari lokal menggunakan Kerberos
Pengguna yang telah login ke komputer lokal mungkin memerlukan akses ke layanan yang disediakan oleh VM yang berjalan di Google Cloud dan merupakan anggota dari forest Microsoft AD Terkelola. Misalnya, pengguna mungkin mencoba membuka koneksi RDP, mengakses berbagi file, atau mengakses resource HTTP yang memerlukan autentikasi.
Agar pengguna dapat melakukan autentikasi ke VM server menggunakan Kerberos, mesin klien harus mendapatkan tiket Kerberos yang sesuai. Hal ini memerlukan komunikasi dengan salah satu pengontrol domain lokal, serta dengan salah satu pengontrol domain Microsoft AD Terkelola.
Agar VM lokal dapat mengautentikasi menggunakan Kerberos, konfigurasikan firewall lokal Anda untuk mengizinkan traffic keluar berikut.
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | Mesin klien (lokal) | Subnet Microsoft AD terkelola |
LDAP (UDP/389, TCP/389) Kerberos (UDP/88, TCP/88) |
| 2 | Izinkan | Mesin klien (lokal) | VM Server (Google Cloud) | Protokol yang digunakan oleh aplikasi, seperti HTTP (TCP/80, TCP/443) atau RDP (TCP/3389) |
| 3 | Izinkan | VM Server | Subnet Microsoft AD terkelola | Lihat memproses login. |
Di sisi Google Cloud, buat aturan firewall untuk mengizinkan traffic masuk untuk (1) dan (2). Traffic keluar ke Microsoft AD Terkelola (3) diizinkan secara default.
Mengautentikasi ke VM dari infrastruktur lokal menggunakan NTLM
Saat menggunakan NTLM untuk mengautentikasi pengguna dari hutan Active Directory lokal ke VM server yang digabungkan ke hutan Microsoft AD Terkelola, Pengontrol domain Microsoft AD yang Dikelola harus berkomunikasi dengan pengontrol domain lokal.
Agar VM lokal dapat mengautentikasi menggunakan NTLM, konfigurasikan firewall lokal Anda untuk mengizinkan traffic masuk dan keluar sebagai berikut.
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | Mesin klien (lokal) | VM Server (Google Cloud) | Protokol yang digunakan oleh aplikasi, seperti HTTP (TCP/80, TCP/443) atau RDP (TCP/3389) |
| 2 | Izinkan | VM Server | Subnet Microsoft AD terkelola | Lihat memproses login. |
| 3 | Izinkan | Subnet Microsoft AD terkelola | AD Lokal |
LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Pada sisi Google Cloud, buat aturan firewall untuk mengizinkan traffic masuk untuk (1). Traffic keluar untuk (2) dan (3) diizinkan secara default.
Memproses logon untuk pengguna hutan lokal
Untuk memproses login bagi pengguna hutan lokal, VM harus dapat berinteraksi dengan Active Directory lokal. Kumpulan protokol yang tepat yang digunakan bergantung pada jenis logon yang diminta klien. Untuk mendukung semua skenario umum, konfigurasikan firewall lokal Anda untuk mengizinkan traffic masuk yang cocok dengan karakteristik ini.
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | VM Server (Google Cloud) | Subnet AD lokal |
Kerberos (UDP/88, TCP/88) NTP (UDP/123) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) LDAP GC (TCP/32) |
Bergantung pada kasus penggunaan yang tepat, Anda juga dapat mengizinkan protokol berikut.
- Perubahan sandi Kerberos (UDP/464, TCP/464)
- LDAP aman (TCP/636, TCP/3269)
Di sisi Microsoft AD Terkelola, traffic keluar yang terkait diizinkan secara default.
Pada VM administratif, Anda mungkin tidak berencana untuk mengizinkan login dari pengguna hutan lokal. Namun, satu aktivitas yang mungkin harus Anda lakukan pada VM administratif adalah mengelola keanggotaan grup. Setiap kali Anda menggunakan pemilih objek untuk mereferensikan pengguna atau grup dari hutan lokal, pemilih objek akan memerlukan akses ke pengontrol domain lokal. Agar hal ini berfungsi, VM administratif memerlukan akses yang sama ke pengontrol domain Active Directory lokal Anda seperti halnya untuk memproses login bagi pengguna hutan lokal.
Mengakses resource Active Directory lokal dari Google Cloud
Jika hutan lokal Anda disiapkan untuk memercayai hutan Microsoft AD Terkelola, Anda mungkin ingin agar pengguna dari hutan Microsoft AD Terkelola dapat mengakses resource lokal.
Mengautentikasi ke VM lokal menggunakan Kerberos
Pengguna yang telah login ke VM yang berjalan di Google Cloud dan merupakan anggota dari hutan Microsoft AD Terkelola mungkin memerlukan akses ke layanan yang disediakan oleh mesin lokal yang merupakan anggota dari hutan lokal Anda. Misalnya, pengguna mungkin mencoba membuka koneksi RDP, mengakses berbagi file, atau mengakses resource HTTP yang memerlukan autentikasi.
Agar pengguna dapat melakukan autentikasi ke komputer lokal menggunakan Kerberos, VM harus mendapatkan tiket Kerberos yang sesuai. Hal ini memerlukan komunikasi terlebih dahulu dengan salah satu pengontrol Microsoft AD Terkelola, lalu dengan pengontrol domain lokal.
Agar VM lokal dapat mengautentikasi menggunakan Kerberos, konfigurasikan firewall lokal Anda untuk mengizinkan traffic masuk yang cocok dengan karakteristik di bawah ini.
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | VM Klien (Google Cloud) | Subnet Microsoft AD terkelola |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) Diimplikasikan oleh memproses logon |
| 2 | Izinkan | VM Klien (Google Cloud) | AD Lokal |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 3 | Izinkan | VM Klien (Google Cloud) | Mesin server (lokal) | Protokol yang digunakan oleh aplikasi, seperti HTTP (TCP/80, TCP/443) atau RDP (TCP/3389) |
Di sisi Google Cloud, traffic keluar yang terkait diizinkan secara default.
Mengautentikasi ke VM lokal menggunakan NTLM
Saat menggunakan NTLM untuk mengautentikasi pengguna dari hutan Microsoft AD Terkelola ke komputer server yang bergabung dengan hutan lokal Anda, pengontrol domain lokal harus dapat berkomunikasi dengan pengontrol domain Microsoft AD Terkelola:
Agar VM lokal dapat melakukan autentikasi menggunakan Kerberos, konfigurasikan firewall lokal Anda untuk mengizinkan traffic masuk dan keluar yang sesuai dengan karakteristik ini.
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | VM Klien (Google Cloud) | Mesin server (lokal) | Protokol yang digunakan oleh aplikasi, misalnya HTTP (TCP/80, TCP/443) atau RDP (TCP/3389) |
| 2 | Izinkan | AD Lokal | Subnet Microsoft AD terkelola |
LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Di sisi Google Cloud, traffic keluar untuk (1) dan traffic masuk untuk (2) diizinkan secara default.
Memproses login untuk pengguna hutan Microsoft AD Terkelola
Untuk memproses login bagi pengguna hutan Microsoft AD Terkelola, mesin yang berjalan secara lokal harus dapat berinteraksi dengan pengontrol domain Microsoft AD Terkelola. Kumpulan protokol yang digunakan bergantung pada jenis logon yang diminta klien. Untuk mendukung semua skenario umum, Anda harus mengizinkan kombinasi protokol berikut.
| Tindakan | Dari | Kepada | Protokol | |
|---|---|---|---|---|
| 1 | Izinkan | Mesin server (lokal) | Subnet Microsoft AD terkelola |
Kerberos (UDP/88, TCP/88) NTP (UDP/123) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) LDAP GC (TCP/32) |
Bergantung pada kasus penggunaan yang tepat, Anda juga dapat mengizinkan protokol berikut.
- Perubahan sandi Kerberos (UDP/464, TCP/464)
- LDAP aman (TCP/636, TCP/3269)
Pastikan firewall lokal Anda mengizinkan traffic keluar yang sesuai dengan karakteristik ini. Anda tidak perlu mengonfigurasi aturan firewall apa pun di Google Cloud untuk mengaktifkan traffic masuk yang sesuai ke Microsoft AD Terkelola.
Pada komputer administratif, Anda mungkin tidak ingin mengizinkan login dari pengguna forest Microsoft AD Terkelola. Salah satu aktivitas yang mungkin harus Anda lakukan di komputer administratif adalah mengelola keanggotaan grup. Setiap kali Anda menggunakan pemilih objek untuk merujuk pengguna atau grup dari hutan Microsoft AD Terkelola, pemilih objek akan memerlukan akses ke pengontrol domain Microsoft AD Terkelola. Agar hal ini berfungsi, mesin administratif memerlukan akses yang sama ke pengontrol domain Microsoft AD Terkelola seperti untuk memproses login bagi pengguna hutan Microsoft AD Terkelola.