I controller di dominio gestiti da Managed Service for Microsoft Active Directory espongono una serie di servizi, tra cui LDAP, DNS, Kerberos e RPC. A seconda dei casi d'uso, le macchine virtuali (VM) di cui è stato eseguito il deployment su Google Cloud, nonché le macchine in esecuzione on-premise, potrebbero dover accedere a questi servizi per sfruttare Active Directory.
Per ridurre la superficie di attacco dei controller di dominio e delle VM, devi utilizzare i firewall per non consentire alcuna comunicazione di rete non strettamente necessaria. Questo articolo descrive come configurare i firewall per supportare i casi d'uso comuni di Active Directory, impedendo al contempo altre comunicazioni di rete.
Accesso e autenticazione
Sebbene i termini accesso e autenticazione vengano spesso usati in modo intercambiabile, hanno significati diversi nel contesto della sicurezza di Windows. Accesso descrive la procedura che si verifica nel sistema a cui un utente sta ottenendo l'accesso. L'autenticazione, invece, viene eseguita dal computer su cui risiede l'account dell'utente.
Quando utilizzi un account locale per accedere a una macchina, sia l'accesso che l'autenticazione vengono gestiti dalla macchina di destinazione. In un ambiente Active Directory, è 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 l'autenticazione, un client può utilizzare Kerberos o NTLM . Una volta autenticato un client, il computer di destinazione deve elaborare l'accesso. A seconda del tipo di accesso richiesto dal client, potrebbe essere necessaria un'ulteriore interazione 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 corretta del firewall.
Casi d'uso comuni
Le sezioni seguenti descrivono casi d'uso comuni per accedere a AD Microsoft gestito e mostrano le regole firewall da configurare per ciascun caso d'uso.
Se non prevedi di integrare Managed Microsoft AD con un Active Directory on-premise, devi solo leggere la prima sezione di questo articolo, Accesso a Managed Microsoft AD dall'interno del VPC. Se intendi creare un rapporto di attendibilità tra Microsoft AD gestito e un Active Directory on-premise, si applica l'intero articolo.
Puoi utilizzare i log delle regole firewall per analizzare se potrebbero essere necessarie porte aggiuntive. Poiché il logging è disabilitato per la regola implicita per negare tutto il traffico in entrata, devi prima creare una regola firewall personalizzata con priorità bassa che neghi tutto il traffico in entrata, ma con il logging firewall abilitato. Con questa regola in vigore, qualsiasi tentativo di connessione non riuscito comporta la pubblicazione di una voce di log in Stackdriver. Poiché le regole firewall possono produrre un volume significativo di log, ti consigliamo di disattivare di nuovo il logging del firewall al termine dell'analisi.
Accedere a Managed Microsoft AD dalla VPC
Quando utilizzi la rete predefinita per eseguire il deployment di AD Microsoft gestito, non è necessaria alcuna configurazione aggiuntiva per consentire alle VM nel VPC di accedere ad Active Directory.
Se hai personalizzato la configurazione del VPC o le regole del firewall, devi assicurarti che la configurazione del firewall consenta ancora la comunicazione con AD Microsoft gestito. Le sezioni seguenti descrivono le regole firewall che potresti dover creare.
Risoluzione del nome di dominio
Quando una VM tenta di risolvere un nome DNS, non esegue query direttamente su un controller di dominio. La query DNS viene invece inviata al server metadati, ovvero al server DNS predefinito configurato per le VM Compute Engine. Il server di metadati poi forwarda la query a una zona di inoltro DNS privata di Cloud DNS creata da AD Microsoft gestito. Questa zona di inoltro inoltra quindi la query al controller di dominio appropriato.
Non è necessario configurare regole firewall per attivare questo caso d'uso. La comunicazione con Cloud DNS è sempre consentita per le VM in una VPC e Managed Microsoft AD consente per impostazione predefinita le richieste DNS inoltrate da Cloud DNS .
Autenticazione in una VM tramite Kerberos
Un utente che ha eseguito l'accesso a una VM potrebbe richiedere l'accesso a un servizio fornito da un'altra VM. Ad esempio, un 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 a un utente di autenticarsi alla VM server utilizzando Kerberos, la VM client deve prima ottenere un ticket Kerberos appropriato da uno dei controller AD di Microsoft gestiti.
Per consentire alle VM di autenticarsi l'una con l'altra utilizzando Kerberos, la seguente comunicazione deve essere consentita dalle regole del firewall:
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM client | Subnet Managed Microsoft AD |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 2 | Consenti | VM client | VM server | Protocollo utilizzato per accedere alla VM, ad esempio HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 3 | Consenti | VM server | Subnet Managed Microsoft AD | Consulta la sezione Elaborare gli accessi. |
Autenticazione in una VM tramite NTLM
Sebbene Windows preferisca Kerberos a NTLM nella maggior parte dei casi, a volte i client potrebbero dover ricorrere all'utilizzo di NTLM per l'autenticazione. NTLM si basa sull'autenticazione passthrough e, pertanto, richiede che il server comunichi con uno dei controller di dominio Microsoft AD gestiti per autenticare l'utente.
Per consentire alle VM di autenticare altre VM utilizzando NTLM, le seguenti comunicazioni devono essere consentite dalle regole del firewall:
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM client | VM server | Protocollo utilizzato per accedere alla VM, ad esempio HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Consenti | VM client | Subnet Managed Microsoft AD | Consulta la sezione Elaborare gli accessi. |
Accesso al dominio ed elaborazione degli accessi
Per operare come membro di un dominio ed elaborare gli accessi degli utenti, un computer deve essere in grado di interagire con Active Directory. L'insieme esatto di protocolli utilizzati dipende dal tipo di accesso richiesto dai singoli client. Per supportare tutti gli scenari comuni, devi consentire la seguente combinazione di protocolli.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM server | Subnet Managed Microsoft AD |
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) |
Inoltre, a seconda del caso d'uso specifico, potresti voler consentire anche i seguenti protocolli:
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM server | Subnet Managed Microsoft AD |
Modifica della password Kerberos (UDP/464, TCP/464) LDAP sicuro (TCP/636, TCP/3269) |
Amministrazione di Managed Microsoft AD
Per gestire Microsoft AD gestito, devi utilizzare una VM associata a un dominio. Per utilizzare strumenti come il Centro amministrativo di Active Directory su questa VM, la VM deve essere in grado di accedere anche ai servizi web di Active Directory esposti dai domain controller Microsoft AD gestiti.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM amministratore | Subnet Managed Microsoft AD | Servizi web AD (TCP/9389) |
Connessione di Managed Microsoft AD a un Active Directory on-premise
Per connettere Microsoft AD gestito a un Active Directory on-premise, devi creare una relazione di attendibilità tra le foreste. Inoltre, devi attivare la risoluzione dei nomi DNS tra Google Cloud e il tuo ambiente on-premise.
Creazione e verifica della attendibilità
Per creare e verificare una relazione di attendibilità tra foreste, i controller di dominio Microsoft Active Directory gestito e i controller di dominio principale della foresta on-premise devono essere in grado di comunicare in modo bidirezionale.
Per abilitare la creazione e la verifica della attendibilità, configura il firewall on-premise in modo da consentire il traffico in entrata e in uscita che corrisponde a queste caratteristiche:
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | AD on-premise | Microsoft Active Directory gestito |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Modifica della password Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
| 2 | Consenti | Microsoft Active Directory gestito | AD on-premise |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Modifica della password Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
AD di Microsoft gestito è preconfigurato per consentire il traffico corrispondente a queste caratteristiche, pertanto non è necessario configurare regole firewall aggiuntive su Google Cloud.
Risolvere i nomi DNS di Google Cloud dall'on-premise
Esistono due modi per consentire alle macchine on-premise di risolvere i nomi DNS in AD di Microsoft gestito: la delega DNS e il forwarding DNS condizionale.
Delegazione DNS
Il dominio DNS utilizzato da Microsoft Active Directory gestito potrebbe essere un sottodominio del dominio DNS utilizzato on-premise. Ad esempio, potresti utilizzare cloud.example.com per AD di Microsoft gestito e example.com on-premise. Per consentire ai client on-premise di risolvere i nomi DNS delle risorse Google Cloud, puoi configurare la delega DNS.
Quando utilizzi la delega DNS, i tentativi di risoluzione del nome DNS di una risorsa Google Cloud eseguono prima una query su un server DNS on-premise. Il server DNS reindirizza quindi il client a Cloud DNS, che a sua volta inoltra la richiesta a uno dei controller di dominio Microsoft AD gestiti.
L'esposizione di Cloud DNS alle reti on-premise richiede la creazione di un criterio del server in entrata. Verrà creato un indirizzo IP del forwarder in entrata che fa parte della tua VPC.
Per utilizzare l'indirizzo del forwarder on-premise, configura il firewall on-premise per consentire il traffico in uscita che corrisponde alle caratteristiche riportate di seguito.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | AD on-premise | Microsoft Active Directory gestito |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Modifica della password Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
| 2 | Consenti | Microsoft Active Directory gestito | AD on-premise |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Modifica della password Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Forwarding DNS condizionale
Il dominio DNS utilizzato da Managed Microsoft AD potrebbe non essere un sottodominio del dominio DNS utilizzato on-premise. Ad esempio, puoi utilizzare cloud.example.com per
Microsoft Active Directory gestito e corp.example.local on-premise.
Negli scenari in cui i domini DNS non sono correlati, puoi configurare il forwarding DNS conditional nel DNS Active Directory on-premise. Tutte le query che corrispondono al nome DNS utilizzato da Microsoft Active Directory gestito verranno inoltrate a Cloud DNS.
Per utilizzare il forwarding DNS condizionale, devi prima configurare un criterio DNS che abiliti il forwarding DNS in entrata. Per utilizzare l'indirizzo del forwarder risultante on-premise, configura il firewall on-premise in modo da consentire il traffico in uscita che corrisponde alle caratteristiche riportate di seguito.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | AD on-premise | Indirizzo IP del forwarding DNS | DNS (UDP/53, TCP/53) |
Sul lato di Google Cloud, crea una regola firewall per consentire il traffico in entrata che corrisponde a questi criteri.
Non è necessario configurare regole del firewall per abilitare la comunicazione dal forwarder DNS a Cloud DNS (2).
Risolvere i nomi DNS on-premise da Google Cloud
Microsoft Active Directory gestito utilizza il forwarding DNS condizionale per risolvere i nomi DNS nella foresta on-premise. Per consentire anche ai client in esecuzione in Google Cloud di risolvere i nomi DNS gestiti da un Active Directory on-premise, puoi creare una zona di inoltro privata in Cloud DNS che inoltra le query ai controller di dominio on-premise.
Per consentire la risoluzione dei nomi DNS on-premise da Google Cloud, configura il firewall on-premise in modo da consentire il traffico in entrata in base alla tabella seguente.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Microsoft Active Directory gestito | AD on-premise | DNS (UDP/53, TCP/53) |
| 2 | Consenti | Cloud DNS (35.199.192.0/19) | AD on-premise | DNS (UDP/53, TCP/53) |
Google Cloud consente il traffico in uscita corrispondente per impostazione predefinita.
Accesso alle risorse di Microsoft AD gestito on-premise
Se la foresta Microsoft AD gestita è configurata per considerare attendibile la foresta on-premise, potresti volere che gli utenti e le macchine on-premise possano accedere alle risorse della foresta Microsoft AD gestita.
Autenticazione a una VM da un ambiente on-premise utilizzando Kerberos
Un utente che ha eseguito l'accesso a un computer on-premise potrebbe richiedere l'accesso a un servizio fornito da una VM che gira su Google Cloud ed è membro di una foresta Microsoft AD gestita. Ad esempio, un utente potrebbe tentare di aprire una connessione RDP, accedere a una condivisione file o a una risorsa HTTP che richiede l'autenticazione.
Per consentire agli utenti di autenticarsi nella VM del server utilizzando Kerberos, la macchina client deve ottenere un ticket Kerberos appropriato. Ciò richiede la comunicazione con uno dei controller di dominio on-premise e con uno dei controller di dominio Microsoft AD gestiti.
Per consentire alle VM on-premise di autenticarsi utilizzando Kerberos, configura il firewall on-premise in modo da consentire il seguente traffico in uscita.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Computer client (on-premise) | Subnet Managed Microsoft AD |
LDAP (UDP/389, TCP/389) Kerberos (UDP/88, TCP/88) |
| 2 | Consenti | Computer client (on-premise) | VM server (Google Cloud) | Protocollo utilizzato dall'applicazione, ad esempio HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 3 | Consenti | VM server | Subnet Managed Microsoft AD | Consulta la sezione Elaborare gli accessi. |
Sul lato di Google Cloud, crea regole firewall per consentire il traffico in entrata per (1) e (2). Il traffico in uscita verso Microsoft Active Directory gestito (3) è consentito per impostazione predefinita.
Autenticazione in una VM da un ambiente on-premise utilizzando NTLM
Quando utilizzi NTLM per autenticare un utente da una foresta Active Directory on-premise a una VM server unita a una foresta Microsoft AD gestita, i controller di dominio Microsoft AD gestiti devono comunicare con i controller di dominio on-premise.
Per consentire alle VM on-premise di autenticarsi utilizzando NTLM, configura il firewall on-premise in modo da consentire il traffico in entrata e in uscita come segue.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Computer client (on-premise) | VM server (Google Cloud) | Protocollo utilizzato dall'applicazione, ad esempio HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Consenti | VM server | Subnet Managed Microsoft AD | Consulta la sezione Elaborare gli accessi. |
| 3 | Consenti | Subnet Managed Microsoft AD | AD on-premise |
LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Sul lato di Google Cloud, crea regole firewall per consentire il traffico in entrata per (1). Il traffico in uscita per (2) e (3) è consentito per impostazione predefinita.
Elaborazione degli accessi per gli utenti della foresta on-premise
Per elaborare un accesso per un utente della foresta on-premise, una VM deve essere in grado di interagire con Active Directory on-premise. L'insieme esatto di protocolli utilizzati dipende dal tipo di accesso richiesto dal client. Per supportare tutti gli scenari comuni, configura il firewall on-premise in modo da consentire il traffico in entrata che corrisponde a queste caratteristiche.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM server (Google Cloud) | Subnet AD on-premise |
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 del caso d'uso specifico, ti consigliamo di consentire anche i seguenti protocolli.
- Modifica della password Kerberos (UDP/464, TCP/464)
- LDAP sicuro (TCP/636, TCP/3269)
Sul lato di Microsoft AD gestito, il traffico in uscita corrispondente è consentito per impostazione predefinita.
Nelle VM amministrative, potresti non pianificare di consentire gli accessi degli utenti della foresta on-premise. Tuttavia, un'attività che probabilmente dovrai eseguire sulle VM amministrative è la gestione dell'appartenenza ai gruppi. Ogni volta che utilizzi il selettore di oggetti per fare riferimento a un utente o a un gruppo della tua foresta on-premise, il selettore di oggetti richiede l'accesso ai controller di dominio on-premise. Affinché questo funzioni, la VM amministrativa richiede lo stesso accesso ai controller di dominio Active Directory on-premise necessario per l'elaborazione degli accessi degli utenti della foresta on-premise.
Accesso alle risorse Active Directory on-premise da Google Cloud
Se la foresta on-premise è configurata per considerare attendibile la foresta Microsoft AD gestita, potresti volere che gli utenti della foresta Microsoft AD gestita possano accedere alle risorse on-premise.
Autenticazione in una VM on-premise utilizzando Kerberos
Un utente che ha eseguito l'accesso a una VM in esecuzione su Google Cloud e che è un membro della foresta Microsoft AD gestita potrebbe richiedere l'accesso a un servizio fornito da una macchina on-premise che è un membro della foresta on-premise. Ad esempio, l'utente potrebbe tentare di aprire una connessione RDP, accedere a una condivisione di file o a una risorsa HTTP che richiede l'autenticazione.
Per consentire all'utente di autenticarsi alla macchina on-premise utilizzando Kerberos, la VM deve ottenere un ticket Kerberos appropriato. Per farlo, è necessario prima comunicare con uno dei controller Microsoft Active Directory gestito e poi con i controller di dominio on-premise.
Per consentire alle VM on-premise di autenticarsi utilizzando Kerberos, configura il firewall on-premise in modo da consentire il traffico in entrata che corrisponde alle caratteristiche riportate di seguito.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM client (Google Cloud) | Subnet Managed Microsoft AD |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) Implied by processing logons |
| 2 | Consenti | VM client (Google Cloud) | AD on-premise |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 3 | Consenti | VM client (Google Cloud) | Macchina server (on-premise) | Protocollo utilizzato dall'applicazione, ad esempio HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
Sul lato di Google Cloud, il traffico in uscita corrispondente è consentito per impostazione predefinita.
Autenticazione in una VM on-premise tramite NTLM
Quando utilizzi NTLM per autenticare un utente dalla foresta Microsoft AD gestita a un computer server unito alla foresta on-premise, i controller di dominio on-premise devono essere in grado di comunicare con i controller di dominio Microsoft AD gestiti:
Per consentire alle VM on-premise di autenticarsi utilizzando Kerberos, configura il firewall on-premise in modo da consentire il traffico in entrata e in uscita che corrisponde a queste caratteristiche.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM client (Google Cloud) | Macchina server (on-premise) | Protocollo utilizzato dall'applicazione, ad esempio HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Consenti | AD on-premise | Subnet Managed Microsoft AD |
LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Sul lato di Google Cloud, il traffico in uscita per (1) e il traffico in entrata per (2) sono consentiti per impostazione predefinita.
Elaborazione degli accessi per gli utenti della foresta Microsoft AD gestita
Per elaborare un accesso per un utente della foresta Microsoft AD gestita, un computer eseguito on-premise deve essere in grado di interagire con i controller di dominio Microsoft AD gestiti. L'insieme esatto di protocolli utilizzati dipende dal tipo di accesso richiesto dal client. Per supportare tutti gli scenari comuni, devi consentire la seguente combinazione di protocolli.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Macchina server (on-premise) | Subnet Managed Microsoft AD |
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 del caso d'uso specifico, ti consigliamo di consentire anche i seguenti protocolli.
- Modifica della password Kerberos (UDP/464, TCP/464)
- LDAP sicuro (TCP/636, TCP/3269)
Assicurati che i firewall on-premise consentano il traffico in uscita che corrisponde a queste caratteristiche. Non è necessario configurare regole firewall in Google Cloud per abilitare il traffico in entrata corrispondente in AD Microsoft gestito.
Sui computer amministrativi, potresti non pianificare di consentire gli accessi degli utenti della foresta AD di Microsoft gestita. Un'attività che probabilmente dovrai svolgere sulle macchine amministrative è la gestione dell'appartenenza ai gruppi. Ogni volta che utilizzi il selettore di oggetti per fare riferimento a un utente o a un gruppo della foresta AD di Microsoft gestita, il selettore di oggetti richiede l'accesso ai controller di dominio AD di Microsoft gestiti. Affinché ciò funzioni, la macchina amministrativa richiede lo stesso accesso ai controller del dominio Microsoft AD gestito necessario per elaborare gli accessi degli utenti della foresta Microsoft AD gestita.