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 e le macchine in esecuzione on-premise potrebbero aver bisogno di accedere a questi servizi per utilizzare Active Directory.
Per ridurre la superficie di attacco dei controller di dominio e delle VM, devi utilizzare i firewall per non consentire le comunicazioni di rete non strettamente richieste. In questo articolo viene descritto come configurare i firewall per supportare i comuni casi d'uso di Active Directory, impedendo altre comunicazioni di rete.
Accesso e autenticazione
Sebbene i termini di accesso e autenticazione sono spesso utilizzati in modo intercambiabile, hanno significati diversi nel contesto della sicurezza di Windows. Logon descrive il processo che si verifica nel sistema a cui un utente sta accedendo. Al contrario, l'autenticazione viene eseguita dal computer in cui si trova l'account dell'utente.
Quando usi un account locale per accedere a una macchina, l'accesso e 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 è gestito dalla macchina di destinazione, mentre l'autenticazione viene eseguita da un controller di dominio.
Per eseguire l'autenticazione, un client può utilizzare Kerberos o NTLM. Una volta che un client è stato autenticato, la macchina di destinazione deve elaborare l'accesso. A seconda del tipo di accesso richiesto dal client, potrebbe essere necessaria un'interazione aggiuntiva con i controller di dominio che utilizzano protocolli come Kerberos, NTLM, LDAP, RPC o SMB.
Poiché l'autenticazione e l'elaborazione dei log richiedono protocolli diversi, è utile distinguere tra i due concetti quando si identifica la configurazione del firewall corretta.
Casi d'uso comuni
Le seguenti sezioni descrivono i casi d'uso comuni per accedere a Microsoft AD gestito e mostrano quali regole firewall devi configurare per ogni caso d'uso.
Se non prevedi di integrare Microsoft Active Directory gestito con una Active Directory on-premise, devi solo leggere la prima sezione di questo articolo, Accesso a Microsoft AD gestito dall'interno del VPC. Se intendi creare una relazione di trust tra Microsoft Active Directory gestito e 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é la regola implicita di negazione in entrata ha disattivato il logging, devi prima creare una regola firewall personalizzata con priorità bassa che nega tutto il traffico in entrata, ma ha attivato il logging del firewall. Con questa regola in atto, qualsiasi tentativo di connessione non riuscito fa sì che una voce di log venga pubblicata in Stackdriver. Poiché le regole firewall possono produrre un volume considerevole di log, ti consigliamo di disattivare nuovamente il logging del firewall dopo aver completato l'analisi.
Accesso a Microsoft AD gestito dall'interno del VPC
Quando utilizzi la rete predefinita per eseguire il deployment di Microsoft AD gestito, non sono necessarie ulteriori configurazioni per abilitare le VM nel VPC ad accedere ad Active Directory.
Se hai personalizzato la configurazione VPC o le regole firewall, devi assicurarti che la configurazione del firewall consenta comunque la comunicazione con Microsoft AD gestito. Le seguenti sezioni 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 di metadati, che è il server DNS predefinito configurato per le VM di Compute Engine. Il server di metadati inoltra la query a una zona di inoltro DNS privata di Cloud DNS creata dalla versione gestita di Microsoft AD. Questa zona di inoltro inoltra la query al controller di dominio appropriato.
Non è necessario configurare alcuna regola firewall per abilitare questo caso d'uso. La comunicazione con Cloud DNS è sempre consentita per le VM in un VPC e l'account gestito Microsoft AD consente le richieste DNS inoltrate da Cloud DNS Cloud DNS per impostazione predefinita.
Autenticazione a una VM tramite Kerberos
Un utente che ha eseguito 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 file o accedere a una risorsa HTTP che richiede l'autenticazione.
Per consentire a un utente di eseguire l'autenticazione nella VM server utilizzando Kerberos, la VM client deve prima ottenere un ticket Kerberos appropriato da uno dei controller Microsoft AD gestiti.
Per abilitare le VM all'autenticazione a un'altra utilizzando Kerberos, le seguenti comunicazioni devono essere consentite dalle regole firewall:
| Azione | Da | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM client | Subnet Microsoft AD gestita |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 2 | Consenti | VM client | VM server | Protocollo utilizzato per accedere alla VM, come HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 3 | Consenti | VM server | Subnet Microsoft AD gestita | Vedi Elaborazione dei log. |
Autenticazione a una VM tramite NTLM
Sebbene Windows preferisci Kerberos su NTLM nella maggior parte dei casi, a volte i client potrebbero dover utilizzare 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 abilitare le VM ad autenticare altre VM utilizzando NTLM, è necessario che le seguenti comunicazioni siano consentite dalle regole firewall:
| Azione | Da | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM client | VM server | Protocollo utilizzato per accedere alla VM, come HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Consenti | VM client | Subnet Microsoft AD gestita | Vedi Elaborazione dei log. |
Accesso al dominio ed elaborazione degli accessi
Per operare come membro di dominio ed elaborare gli accessi da parte di utenti, una macchina deve essere in grado di interagire con Active Directory. L'esatto insieme 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 | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM server | Subnet Microsoft AD gestita |
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 esatto, puoi anche consentire i seguenti protocolli:
| Azione | Da | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM server | Subnet Microsoft AD gestita |
Modifica password Kerberos (UDP/464, TCP/464) LDAP sicuro (TCP/636, TCP/3269) |
Amministrazione di Microsoft AD gestito
Devi utilizzare una VM facente parte del dominio per gestire Microsoft AD gestito. Per utilizzare strumenti come il Centro amministrativo di Active Directory su questa VM, la VM deve essere anche in grado di accedere ai servizi web di Active Directory esposti dai controller di dominio Microsoft AD gestiti.
| Azione | Da | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM amministratore | Subnet Microsoft AD gestita | Servizi web AD (TCP/9389) |
Connessione di Microsoft AD gestito a un Active Directory on-premise
Per connettere Microsoft Active Directory gestito a una Active Directory on-premise, devi creare una relazione di attendibilità tra le foreste. Devi inoltre abilitare la risoluzione dei nomi DNS tra Google Cloud e l'ambiente on-premise.
Considera attendibile la creazione e la verifica
Per creare e verificare un trust forestale, i controller di dominio Microsoft AD gestiti 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 di attendibilità, configura il firewall on-premise in modo da consentire il traffico in entrata e in uscita che corrisponda a queste caratteristiche:
| Azione | Da | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | ANNUNCIO 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 | ANNUNCIO 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) |
Microsoft Active Directory gestito è preconfigurato per consentire il traffico corrispondente a queste caratteristiche, quindi non è necessario configurare regole firewall aggiuntive su Google Cloud.
Risolvere i nomi Google Cloud DNS da on-premise
Esistono due modi per consentire alle macchine on-premise di risolvere i nomi DNS in Microsoft AD gestito: delega DNS e forwarding DNS condizionale.
Delega DNS
Il dominio DNS utilizzato da Microsoft AD gestito potrebbe essere un sottodominio del dominio DNS utilizzato on-premise. Ad esempio, puoi utilizzare cloud.example.com per Microsoft AD gestito mentre utilizzi example.com on-premise. Per consentire ai client on-premise di risolvere i nomi DNS delle risorse Google Cloud, puoi configurare una delega DNS.
Quando utilizzi la delega DNS, tenta di risolvere il nome DNS di una risorsa di Google Cloud prima di eseguire 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 a reti on-premise richiede la creazione di criteri server in entrata e in entrata. Verrà creato un indirizzo IP di forwarding in entrata che fa parte del tuo VPC.
Per utilizzare l'indirizzo del forwarding da on-premise, configura il tuo firewall on-premise per consentire il traffico in uscita che corrisponde alle caratteristiche di seguito.
| Azione | Da | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | ANNUNCIO 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 | ANNUNCIO 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) |
Inoltro DNS condizionale
Il dominio DNS utilizzato da Microsoft AD gestito potrebbe non essere un sottodominio del dominio DNS utilizzato on-premise. Ad esempio, potresti utilizzare cloud.example.com per Microsoft Active Directory gestito mentre utilizzi corp.example.local on-premise.
Negli scenari in cui i domini DNS non sono correlati, puoi configurare l'inoltro DNS condizionale nel tuo DNS Active Directory on-premise. Tutte le query che corrispondono al nome DNS utilizzato da Microsoft AD gestito verranno quindi inoltrate a Cloud DNS.
Per utilizzare l'inoltro DNS condizionale, devi prima configurare un criterio DNS che attiva l'inoltro DNS in entrata. Per utilizzare l'indirizzo di forwarding risultante da on-premise, configura il firewall on-premise per consentire il traffico in uscita che corrisponde alle caratteristiche di seguito.
| Azione | Da | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | ANNUNCIO on-premise | Indirizzo IP di inoltro DNS | DNS (UDP/53, TCP/53) |
Sul lato Google Cloud, crea una regola del firewall per consentire il traffico in entrata corrispondente a questi criteri.
Non è necessario configurare alcuna regola firewall per abilitare la comunicazione dall'inoltro DNS a Cloud DNS (2).
Risolvere i nomi DNS on-premise da Google Cloud
Microsoft Active Directory gestito utilizza l'inoltro 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 una directory Active Directory on-premise, puoi creare una zona di forwarding privata in Cloud DNS DNS che inoltri le query ai controller di dominio on-premise.
Per abilitare la risoluzione dei nomi DNS on-premise da Google Cloud, configura il tuo firewall on-premise in modo da consentire il traffico in entrata in base alla tabella seguente.
| Azione | Da | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Microsoft Active Directory gestito | ANNUNCIO on-premise | DNS (UDP/53, TCP/53) |
| 2 | Consenti | Cloud DNS (35.199.192.0/19) | ANNUNCIO on-premise | DNS (UDP/53, TCP/53) |
Google Cloud consente il traffico in uscita corrispondente per impostazione predefinita.
Accesso alle risorse Microsoft AD gestite on-premise
Se la foresta di Microsoft AD gestita è configurata in modo da considerare attendibile la foresta on-premise, gli utenti e le macchine on-premise devono essere in grado di accedere alle risorse nella foresta di Microsoft AD gestita.
Autenticazione a una VM da on-premise con Kerberos
Un utente che ha eseguito l'accesso a una macchina on-premise potrebbe richiedere l'accesso a un servizio fornito da una VM in esecuzione 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 accedere a una risorsa HTTP che richiede l'autenticazione.
Per consentire agli utenti di eseguire l'autenticazione nella VM server tramite 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 abilitare le VM on-premise a eseguire l'autenticazione utilizzando Kerberos, configura il firewall on-premise in modo da consentire il seguente traffico in uscita.
| Azione | Da | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Computer client (on-premise) | Subnet Microsoft AD gestita |
LDAP (UDP/389, TCP/389) Kerberos (UDP/88, TCP/88) |
| 2 | Consenti | Computer client (on-premise) | VM server (Google Cloud) | Protocollo utilizzato da un'applicazione, ad esempio HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 3 | Consenti | VM server | Subnet Microsoft AD gestita | Vedi Elaborazione dei log. |
Sul lato Google Cloud, crea regole firewall per consentire il traffico in entrata per (1) e (2). Il traffico in uscita verso Microsoft AD gestito (3) è consentito per impostazione predefinita.
Autenticazione a una VM da on-premise con NTLM
Quando utilizzi NTLM per autenticare un utente da una foresta Active Directory on-premise a una VM server che fa parte di una foresta Microsoft AD gestita, i controller di dominio Microsoft AD gestiti devono comunicare con i controller di dominio on-premise.
Per abilitare le VM on-premise a eseguire l'autenticazione utilizzando NTLM, configura il firewall on-premise in modo da consentire il traffico in entrata e in uscita come segue.
| Azione | Da | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Computer client (on-premise) | VM server (Google Cloud) | Protocollo utilizzato da un'applicazione, ad esempio HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Consenti | VM server | Subnet Microsoft AD gestita | Vedi Elaborazione dei log. |
| 3 | Consenti | Subnet Microsoft AD gestita | ANNUNCIO on-premise |
LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Sul lato 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 di un utente della foresta on-premise, una VM deve essere in grado di interagire con l'Active Directory on-premise. L'esatto insieme di protocolli utilizzati dipende dal tipo di accesso richiesto dal client. Per supportare tutti gli scenari comuni, configura il firewall on-premise per consentire il traffico in entrata che corrisponde a queste caratteristiche.
| Azione | Da | To | 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 esatto, può essere utile anche consentire i seguenti protocolli.
- Modifica password Kerberos (UDP/464, TCP/464)
- LDAP sicuro (TCP/636, TCP/3269)
Sul lato gestito di Microsoft AD, il traffico in uscita corrispondente è consentito per impostazione predefinita.
Sulle VM amministrative, potresti non pianificare l'autorizzazione degli accessi da parte degli utenti della foresta on-premise. Un'attività che probabilmente dovrai eseguire sulle VM di amministrazione è gestire le iscrizioni ai gruppi. Ogni volta che utilizzi il selettore oggetti per fare riferimento a un utente o a un gruppo nella tua foresta on-premise, il selettore oggetti richiederà l'accesso ai controller di dominio on-premise. Per questo lavoro, la VM di amministrazione richiede lo stesso accesso ai controller di dominio Active Directory on-premise di quello utilizzato per l'elaborazione dei log per gli utenti della foresta on-premise.
Accesso alle risorse Active Directory on-premise da Google Cloud
Se la foresta on-premise è configurata in modo da considerare attendibile la foresta di Microsoft AD gestita, gli utenti della foresta di Microsoft AD gestita devono essere in grado di accedere alle risorse on-premise.
Autenticazione a una VM on-premise mediante Kerberos
Un utente che ha eseguito l'accesso a una VM in esecuzione su Google Cloud e che è membro della foresta Microsoft Active Directory gestita potrebbe richiedere l'accesso a un servizio fornito da una macchina on-premise membro della foresta on-premise. Ad esempio, l'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 all'utente di eseguire l'autenticazione nella macchina on-premise utilizzando Kerberos, la VM deve ottenere un ticket Kerberos appropriato. Ciò richiede la prima comunicazione con uno dei controller Microsoft AD gestiti e quindi con i controller di dominio on-premise.
Per abilitare l'autenticazione delle VM on-premise utilizzando Kerberos, configura il firewall on-premise in modo da consentire il traffico in entrata che corrisponde alle caratteristiche seguenti.
| Azione | Da | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM client (Google Cloud) | Subnet Microsoft AD gestita |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) Implicato da elaborazione dei log |
| 2 | Consenti | VM client (Google Cloud) | ANNUNCIO on-premise |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 3 | Consenti | VM client (Google Cloud) | Computer (on-premise) | Protocollo utilizzato da un'applicazione, ad esempio 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 on-premise utilizzando NTLM
Quando utilizzi NTLM per autenticare un utente dalla foresta di Microsoft AD gestita a una macchina server che fa parte della foresta on-premise, i controller di dominio on-premise devono essere in grado di comunicare con i controller di dominio di Microsoft AD gestiti:
Per abilitare l'autenticazione delle VM on-premise 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 | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM client (Google Cloud) | Computer (on-premise) | Protocollo utilizzato dall'applicazione, ad esempio HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 2 | Consenti | ANNUNCIO on-premise | Subnet Microsoft AD gestita |
LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Sul lato Google Cloud, il traffico in uscita per (1) e il traffico in entrata per (2) è consentito per impostazione predefinita.
Elaborazione degli accessi per gli utenti della foresta gestita di Microsoft AD
Per elaborare un accesso di un utente della foresta gestita di Microsoft AD, una macchina in esecuzione on-premise deve essere in grado di interagire con i controller di dominio Microsoft AD gestiti. L'esatto insieme 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 | To | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Computer (on-premise) | Subnet Microsoft AD gestita |
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 esatto, potresti anche consentire i seguenti protocolli.
- Modifica 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 alcuna regola firewall in Google Cloud per abilitare il traffico in entrata corrispondente verso Microsoft AD gestito.
Sulle macchine amministrative, potrebbe non essere opportuno consentire gli accessi da parte degli utenti della foresta gestita di Microsoft AD. Un'attività che probabilmente dovrai eseguire sulle macchine amministrative è la gestione delle iscrizioni ai gruppi. Ogni volta che utilizzi il selettore oggetti per fare riferimento a un utente o a un gruppo nella foresta gestita di Microsoft AD, il selettore oggetti richiede l'accesso ai controller di dominio Microsoft AD gestiti. Per funzionare, la macchina amministrativa richiede lo stesso accesso ai controller di dominio Microsoft AD gestiti di cui deve eseguire l'elaborazione dei log per gli utenti della foresta di Managed Microsoft AD.