I controller di dominio gestiti da Managed Service per Microsoft Active Directory espongono un certo numero di servizi, tra cui LDAP, DNS, Kerberos e RPC. A seconda dei casi d’uso,le macchine virtuali (VM) distribuite su Google Cloud e le macchine in esecuzione in locale potrebbero aver bisogno di accedere a questi servizi per sfruttare ActiveDirectory.
Per ridurre la superficie di attacco dei controller di dominio e delle macchine virtuali, è necessario utilizzare i firewall per impedire qualsiasi comunicazione di rete non strettamente necessaria.Questo articolo descrive come configurare i firewall per accogliere i casi d’uso comuni di ActiveDirectory mentre non consente altre comunicazioni di rete.
Accesso contro autenticazione
Mentre i termini accesso e autenticazione sono spesso usati in modo intercambiabile,hanno significati diversi nel contesto della sicurezza di Windows. Logondescrive il processo che si verifica sul sistema a cui un utente sta accedendo to.In al contrario, l’autenticazione viene eseguita dal computer su cui risiede l’account dell’utente.
Quando si utilizza un account locale per accedere a una macchina, sia l’accesso che l’autenticazione vengono gestiti dalla macchina di destinazione. In un Directoryenvironment attivo, è più comune utilizzare un utente di dominio per accedere. In questo caso, l’accesso viene gestito dalla macchina di destinazione, mentre l’autenticazione viene eseguita da un controller di dominio.
Per autenticarsi, un client può utilizzare eitherKerberos o NTLM .Una volta che un client si autentica, la macchina di destinazione deve elaborare l’accesso.A seconda del tipo di logon richiesto dal client, ciò potrebbe richiedere un’interazione aggiuntiva con i controller di dominio che utilizzano protocolli come Kerberos, NTLM,LDAP ,RPC o SMB .
Poiché l’autenticazione e l’elaborazione degli accessi richiedono protocolli diversi, è utile distinguere tra i due concetti quando si identifica la configurazione rightfirewall.
Casi d’uso comuni
Le sezioni seguenti descrivono casi d’uso comuni per l’accesso a Microsoft AD gestito e mostrano quali regole del firewall è necessario configurare per ogni caso d’uso.
Se non si prevede di integrare Managed Microsoft AD con una directory on-premisesActive, è sufficiente leggere la prima sezione di questo articolo,Accedendo Managed Microsoft AD dall’interno del VPC. Se si intende creare una relazione di attendibilità tra Microsoft AD gestito e ActiveDirectory locale, si applica l’intero articolo.
È possibile utilizzare i registri delle regole del firewall per analizzare se potrebbero essere necessarie porte aggiuntive. Poiché la regola di negazione dell’ingresso è disabilitata, è necessario innanzitutto creare una regola firewall personalizzata a bassa priorità che nega tutto il traffico di ingresso, ma ha la registrazione del firewall abilitata. Con thisrule in atto, qualsiasi tentativo di connessione non riuscita fa sì che una voce di registro sia pubblicata su Stackdriver. Poiché le regole del firewall possono produrre un volume significativo di registri, considerare di disabilitare nuovamente la registrazione del firewall una volta completata l’analisi.
Accesso a Microsoft AD gestito dall’interno del VPC
Quando si utilizza la rete predefinita per distribuire Microsoft AD gestito, non è necessaria alcuna ulteriore configurazione per abilitare le VM nel VPC per accedere a Active Directory.
Se è stata personalizzata la configurazione VPC o le regole del firewall, è necessario garantire che la configurazione del firewall consenta ancora la comunicazione con Microsoft AD gestito. Le sezioni seguenti descrivono le regole del firewall potrebbe essere necessario creare.
Domain name resolution
Quando una VM tenta di risolvere un nome DNS, non interroga direttamente un domaincontroller. Invece, la query DNS viene inviata al server dei metadati, che è il server DNS predefinito configurato per le VM del motore di elaborazione. Il server di metadati invia quindi la query a una zona di inoltro privata DNS CLOUD creata da Microsoft AD gestita. Questa zona di inoltro inoltra quindi la query al controller di dominio appropriato.
Non è necessario configurare alcuna regola firewall per abilitare questo caso d’uso.La comunicazione al Cloud DNS (1) è sempre permessa per le VM in un VPC e Managed Microsoft AD consente di inoltrare richieste DNS da Cloud DNS Cloud DNS(2) per impostazione predefinita.
Autenticazione a una VM utilizzando Kerberos
Un utente che ha effettuato l’accesso a una VM potrebbe richiedere l’accesso a un servizio fornito da una VM diversa. Ad esempio,un utente potrebbe tentare di aprire una connessione RDP, accedere a una condivisione di file o accedere a una risorsa HTTP che richiede l’autenticazione.
Per consentire a un utente di autenticarsi alla VM server utilizzando Kerberos, il client vmha per ottenere un ticket Kerberos appropriato da uno dei controllori Microsoft AD gestiti prima.
Per consentire alle VM di autenticarsi a un’altra utilizzando Kerberos, la seguente comunicazione deve essere consentita dalle regole del firewall:
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | Client VM | Managed Microsoft AD subnet | Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 2 | Allow | Client VM | Server VM | Protocol used to access VM, such as HTTP (TCP/80, TCP/443) or RDP (TCP/3389) |
| 3 | Allow | Server VM | Managed Microsoft AD subnet | See processing logons. |
Autenticazione su una VM utilizzando NTLM
Sebbene Windowspreferisca Kerberos su NTLM nella maggior parte dei casi, i client potrebbero occasionalmente dover ricorrere all’utilizzo di NTLM per l’autenticazione. NTLM si basa sull’autenticazione pass-through e pertanto richiede al server di comunicare con uno dei controller di dominio Microsoft AD gestiti per autenticare l’utente.
Per consentire alle VM di autenticare altre VM utilizzando NTLM, la seguente comunicazione deve essere consentita dalle regole del firewall:
| Azione | Da | Per | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Client VM | Server VM | Protocollo utilizzato per accedere VM, come HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Consenti | Client VM | Microsoft Gestito ANNUNCIO subnet | Vedere elaborazione di accessi. |
Accesso al dominio e all’elaborazione
Per operare come membro del dominio e elaborare gli accessi dagli utenti, una macchina deve essere in grado di interagire con Active Directory. Il set esatto di protocolli utilizzatidipende dal tipo di accesso richiesto dai singoli client. Per supportare tutti commonscenarios, è necessario consentire la seguente combinazione di protocolli.
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | Server VM | Managed Microsoft AD subnet | 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/3268) |
Additionally, depending on your exact use case, you might also want to permitthe seguenti protocolli:
| Azione | Da | Per | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Server VM | Microsoft Gestito ANNUNCIO subnet | Kerberos modifica della password (UDP/464, TCP/464) LDAP Protetto (TCP/636, TCP/3269) |
Amministrazione di Microsoft Gestito ANNUNCIO
È necessario utilizzare adomain-unito VMto gestire Gestito ANNUNCI di Microsoft. Per utilizzare strumenti come Active DirectoryAdministrative Center su questa VM, la VM deve anche essere in grado di accedere ai servizi Web Directory attivi esposti dai controllori Microsoft AD domaincontrollers gestiti.
| Azione | Da | Per | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Admin VM | Microsoft Gestito ANNUNCIO subnet | ANNUNCIO di Web Services (TCP/9389) |
Collegamenti Gestiti ANNUNCI di Microsoft a un locale di Active Directory
collegare Gestito ANNUNCI di Microsoft a un locale di Active Directory, si haveto creare una relazione di trust tra i boschi. Inoltre, dovresti abilitare la risoluzione dei nomi NS tra Google Cloud e il tuo ambiente locale.
Creazione e verifica del trust
Per creare e verificare un trust forestale, i controller Microsoft ADdomain gestiti e i controller di dominio root della foresta locale devono essere in grado di comunicare in modo bidirezionale.
Per abilitare la creazione e la verifica del trust, configurare il firewall on-premise per consentire il traffico di ingresso ed uscita che corrisponde a queste caratteristiche:
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | On-premises AD | Managed Microsoft AD | DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Kerberos password change (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
| 2 | Allow | Managed Microsoft AD | On-premises AD | DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Kerberos password change (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Microsoft Gestito ANNUNCIO è preconfigurato per consentire il traffico di corrispondenza thesecharacteristics, quindi non è necessario configurare le regole di firewall aggiuntive su google + Cloud.
Risoluzione dei nomi DNS di Google Cloud da locali
Sono disponibili due modi per consentire alle macchine locali di risolvere i nomi DNS in Microsoft AD gestito: delega DNS e inoltro DNS condizionale.
Delega DNS
Il dominio DNS utilizzato da Microsoft AD gestito potrebbe essere un sottodominio del dominio DNS utilizzato in locale. Ad esempio, è possibile utilizzare cloud.example.com forManaged ANNUNCIO Microsoft durante l’utilizzo example.com nei locali. Per consentire ai clienti on-premisesclients di risolvere i nomi DNS delle risorse di Google Cloud, è possibile impostare la delega upDNS.
Quando si utilizza la delega DNS, si tenta di risolvere il nome DNS di aGoogle Cloud resource prima di eseguire una query su un server DNS locale. Il DNSserver quindi reindirizza il client al Cloud DNS, che a sua volta inoltra therequest a uno dei controller di dominio Microsoft AD gestiti.
L’esposizione del Cloud DNS alle reti locali richiede la creazione e la politica del server in entrata.Questo creerà un indirizzo IP dello spedizioniere in entrata che fa parte del tuo VPC.
Per utilizzare l’indirizzo dello spedizioniere in locale, configurare on-premisesfirewall in modo da consentire il traffico in uscita corrispondente alle caratteristiche riportate di seguito.
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | On-premises AD | Managed Microsoft AD | DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Kerberos password change (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
| 2 | Allow | Managed Microsoft AD | On-premises AD | DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Kerberos password change (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Inoltro DNS condizionale
Il dominio DNS utilizzato da Microsoft AD gestito potrebbe non essere un sottodominio del DNS dominio utilizzato in locale. Ad esempio, è possibile utilizzarecloud.example.com forManaged Microsoft AD mentre si utilizza corp.example.local in locale.
In scenari in cui i domini DNS non sono correlati, è possibile impostare DNSforwarding condizionale nel DNS Active Directory locale. Tutte le query che corrispondono al nome DNS utilizzato da Microsoft AD gestito verranno quindi inoltrate al Cloud DNS.
Per utilizzare l’inoltro DNS condizionale, è necessario impostare la politica aDNS che abilita l’inoltro DNS inboundfirst. Per utilizzare l’indirizzo dello spedizioniere risultante da locale, configurare il firewall locale youron in modo da consentire il traffico in uscita che corrisponde a characteristicsbelow.
| Azione | Da | Per | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | locali AD | DNS di inoltro indirizzo IP | DNS (UDP/53, TCP/53) |
Google Cloud lato, creare una regola di firewall topermit classe di traffico corrispondenti a questi criteri.
Non è necessario configurare alcuna regola firewall per abilitare la comunicazione da theDNS Forwarder a Cloud DNS (2).
Risoluzione dei nomi DNS locali da Google Cloud
Managed Microsoft AD utilizza l’inoltro DNS condizionale per risolvere i nomi DNS nella foresta locale. Per consentire anche ai client in esecuzione in Google Cloud di risolvere i nomi DNS gestiti da una Active Directory locale, è possibile creare una zona di inoltro privata con DNS DNS ad alta voce che inoltra le query ai controller di dominio locali.
Per abilitare la risoluzione dei nomi DNS locali da Google Cloud, configurare il firewall locale per consentire il traffico di ingresso secondo la seguente tabella.
| Azione/th> | Da | Per | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Gestito ANNUNCI di Microsoft | locali AD | DNS (UDP/53, TCP/53) |
| 2 | Consenti | Cloud DNS (35.199.192.0/19) | On-premise AD | DNS (UDP/53, TCP/53) |
Google Cloud consente il traffico di uscita corrispondente per impostazione predefinita.
Accesso alle risorse Microsoft AD gestite da locali
Se la foresta Microsoft AD gestita è configurata in modo da considerare attendibile la foresta locale,è possibile che gli utenti e le macchine locali possano accedere alle risorse nella foresta Microsoft AD gestita.
Autenticazione a una macchina virtuale da locale utilizzando Kerberos
Un utente che ha effettuato l’accesso a una macchina locale potrebbe richiedere l’accesso a aservice fornito da una macchina virtuale che gira su Google Cloud ed è membro di una foresta di ANNUNCI Microsoft gestita. Ad esempio, un utente potrebbe tentare di aprire un RDPconnection, accedere a una condivisione di file o accedere a una risorsa HTTP che richiede l’autenticazione.
Per consentire agli utenti di autenticarsi alla VM server utilizzando Kerberos, clientmachine deve ottenere un ticket Kerberos appropriato. Ciò richiede la comunicazione con uno dei controller di dominio locali e con uno dei controller di dominio Microsoft AD gestiti.
Per abilitare l’autenticazione delle VM locali utilizzando Kerberos, configurare il firewall locale di youron per consentire il seguente traffico di uscita.
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | Client machine (on-premises) | Managed Microsoft AD subnet | LDAP (UDP/389, TCP/389) Kerberos (UDP/88, TCP/88) |
| 2 | Allow | Client machine (on-premises) | Server VM (GCP) | Protocol used by application, such as HTTP (TCP/80, TCP/443) or RDP (TCP/3389) |
| 3 | Allow | Server VM | Managed Microsoft AD subnet | See processing logons. |
Sul lato Google Cloud, creare regole firewall per limitare il traffico di ingresso per (1) e (2). Il traffico in uscita verso Microsoft AD gestito (3) è consentito per impostazione predefinita.
Autenticazione a una VM da locale utilizzando NTLM
Quando si utilizza NTLM per autenticare un utente da un Directoryforest attivo locale a una VM server collegata a una foresta Microsoft AD gestita, i controller di dominio Microsoft AD gestiti devono comunicare con i controller di dominio locali.
Per abilitare l’autenticazione delle VM locali utilizzando NTLM, configurare il firewall locale di youron per consentire il traffico in ingresso ed uscita come segue.
| Azione | Da | Per | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | la macchina del Cliente (on-premise) | VM Server (Google Cloud) | il Protocollo di applicazione, come HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Consenti | Server VM | Microsoft Gestito ANNUNCIO subnet | Vedere elaborazione di accessi. |
| 3 | Consenti | Microsoft Gestito ANNUNCIO subnet | locali AD | LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Google Cloud lato, creare regole di firewall topermit il transito in ingresso (1). Il traffico in uscita per (2) e (3) è consentito per impostazione predefinita.
Elaborazione degli accessi per gli utenti della foresta locale
Per elaborare un accesso per un utente della foresta locale, una VM deve essere in grado di interagire con Active Directory locale. L’insieme esatto di protocolsused dipende dal tipo di thelogon che il cliente ha richiesto. Per supportare tutti gli scenari comuni, configurare il firewall youron-premises per consentire il traffico di ingresso che corrisponde a queste caratteristiche.
| Azione | Da | Per | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM Server (Google Cloud) | locali AD subnet | 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/3268) |
a Seconda di caso d’uso, si potrebbe anche voler consentire la followingprotocols.
- Kerberos password change (UDP/464, TCP/464)
- Secure LDAP (TCP/636, TCP/3269)
Sul lato Microsoft AD gestito, il traffico in uscita corrispondente è consentito per impostazione predefinita.
Sulle macchine virtuali amministrative, è possibile che non si preveda di consentire gli accessi da utenti della foresta locale. Un’attività che probabilmente è necessario eseguire onadministrative VM tuttavia è la gestione di appartenenze di gruppo. Ogni volta che si utilizza theobject picker per fare riferimento a un utente o gruppo formano la foresta locale, theobject picker richiederà l’accesso ai controller di dominio locali. Per funzionare, la VM amministrativa richiede lo stesso accesso ai controller di dominio della directory attiva in locale come per l’elaborazione degli accessi per gli utenti della foresta locale.
Accesso alle risorse on-premise di Active Directory da Google Cloud
Se la foresta on-premise è configurata per l’attendibilità della foresta Microsoft AD gestita,è possibile che gli utenti della foresta Microsoft AD gestita siano in grado di accedere alle risorse on-premise.
Autenticazione a una VM locale utilizzando Kerberos
Un utente che ha effettuato l’accesso a una VM in esecuzione su Google Cloud e che fa parte della foresta Microsoft AD gestita potrebbe richiedere l’accesso a un servizio fornito da una macchina locale membro della foresta locale.Ad esempio, l’utente potrebbe tentare di aprire una connessione RDP, accedere a una condivisione file o accedere a una risorsa HTTP che richiede l’autenticazione.
Per consentire all’utente di autenticarsi sulla macchina locale utilizzando Kerberos, theVM deve ottenere un ticket Kerberos appropriato. Ciò richiede innanzitutto la comunicazione con uno dei controller Microsoft AD gestiti e quindi con i controller di dominio locali.
Per abilitare l’autenticazione delle VM locali utilizzando Kerberos, configurare il firewall youron-premises per consentire il traffico di ingresso che corrisponde alle caratteristichebelow.
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | Client VM (Google Cloud) | Managed Microsoft AD subnet | Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) Implied by processing logons |
| 2 | Allow | Client VM (Google Cloud) | On-premises AD | Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 3 | Allow | Client VM (Google Cloud) | Server machine (on-premises) | Protocol used by applicazione, come HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
Sul lato Google Cloud, il traffico in uscita corrispondente è consentito per impostazione predefinita.
Autenticazione a una VM locale utilizzando NTLM
Quando si utilizza NTLM per autenticare un utente dalla macchina server Microsoft AD forest gestita a un server collegato alla foresta locale, i controller principali locali devono essere in grado di comunicare con i controller di dominio Microsoft AD gestiti:
Per abilitare l’autenticazione delle VM locali utilizzando Kerberos, configurare il firewall youron-premises per consentire il traffico di ingresso ed uscita che corrisponde a queste caratteristiche.
| Azione | Da | Per | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Client VM (Google Cloud) | macchina Server (locale) | il Protocollo di applicazione, per esempio, HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Consenti | locali AD | Microsoft Gestito ANNUNCIO subnet | LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Google Cloud lato, l’uscita di traffico (1) e la penetrazione del traffico per la(2) è consentito dalla predefinito.
Elaborazione degli accessi per gli utenti della foresta Microsoft AD gestita
Per elaborare un accesso per un utente della foresta Microsoft AD gestita, un machinerunning on-premise deve essere in grado di interagire con i controller Microsoft ADdomain gestiti. L’esatto set di protocolli utilizzati dipende dal tipo di logon richiesto dal client. Per supportare tutti gli scenari comuni, dovresti consentirela seguente combinazione di protocolli.
| Azione | Da | Per | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | macchina Server (in locale) | Microsoft Gestito ANNUNCIO subnet | 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/3268) |
a Seconda di caso d’uso, si potrebbe anche desidera consentire i seguenti protocolli.
- Kerberos password change (UDP/464, TCP/464)
- Secure LDAP (TCP/636, TCP/3269)
Assicurarsi che i firewall locali consentano il traffico in uscita che corrisponde a queste caratteristiche. Non è necessario configurare alcuna regola del firewall inoogle Cloud per abilitare il traffico di ingresso corrispondente alla gestione di Microsoft AD.
Sulle macchine amministrative, è possibile che non si preveda di consentire gli accessi dagli utenti della foresta Microsoft AD gestita. Un’attività che probabilmente devi eseguire su macchine amministrative è la gestione delle appartenenze al gruppo. Ogni volta che si utilizza il selettore di oggetti per fare riferimento a un utente o gruppo da Microsoft ADforest gestito, il selettore di oggetti richiederà l’accesso ai controller Microsoft ADdomain gestiti. Per funzionare, la macchina amministrativa richiede lo stesso accesso ai controller di dominio Microsoft AD gestiti come farebbe per l’elaborazione degli accessi per gli utenti della foresta Microsoft AD gestita.