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 aver bisogno di 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 le comunicazioni di rete non strettamente necessarie. Questo articolo descrive come configurare i firewall per i casi d'uso comuni di Active Directory, impedendo al contempo altre comunicazioni di rete.
Accesso e autenticazione
Sebbene i termini accesso e autenticazione siano spesso usati in modo intercambiabile, hanno significati diversi nel contesto della sicurezza di Windows. Accesso descrive il processo che si verifica sul sistema a cui un utente ottiene l'accesso. Al contrario, l'autenticazione viene eseguita dal computer su cui si trova l'account dell'utente.
Quando utilizzi un account locale per accedere a una macchina, sia l'accesso sia l'autenticazione vengono gestiti dalla macchina di destinazione. In un ambiente Active Directory, è più comune utilizzare un utente di dominio per effettuare l'accesso. 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 . Dopo l'autenticazione del client, la macchina 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 i due concetti quando si identifica la corretta configurazione del firewall.
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 AD gestito con un'Active Directory on-premise, ti basta leggere la prima sezione di questo articolo, Accedere a Microsoft AD gestito dal VPC. Se intendi creare una relazione di attendibilità tra Microsoft AD gestito e una Active Directory on-premise, viene applicato l'intero articolo.
Puoi utilizzare i log delle regole firewall per analizzare se potrebbero essere necessarie porte aggiuntive. Poiché la regola in entrata implicita ha il logging disabilitato, devi prima creare una regola firewall personalizzata a bassa priorità che neghi tutto il traffico in entrata, ma che abbia il logging del firewall abilitato. Se questa regola è attiva, qualsiasi tentativo di connessione non riuscito determina la pubblicazione di una voce di log in Stackdriver. Poiché le regole firewall possono produrre un volume significativo di log, ti consigliamo di disabilitare nuovamente il logging del firewall dopo aver completato l'analisi.
Accesso a Microsoft AD gestito dal VPC
Quando utilizzi la rete predefinita per eseguire il deployment di Microsoft AD gestito, non sono necessarie ulteriori configurazioni per consentire alle VM nel VPC di accedere ad Active Directory.
Se hai personalizzato la configurazione VPC o le regole firewall, devi assicurarti che la configurazione del firewall consenta ancora 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 una query diretta 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 dei metadati inoltra quindi la query a una zona di forwarding DNS privata di Cloud DNS creata da Microsoft AD gestito. 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 con Cloud DNS è sempre consentita per le VM in un VPC e Microsoft AD gestito 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 un'altra VM. 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 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 consentire l'autenticazione di una VM con un'altra utilizzando Kerberos, le regole firewall devono consentire la seguente comunicazione:
| Azione | Da | A | 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, ad esempio HTTP (TCP/80, TCP/443) o RDP (TCP/3389) |
| 3 | Consenti | VM server | Subnet Microsoft AD gestita | Vedi Elaborazione degli accessi. |
Autenticazione su una VM mediante NTLM
Anche se nella maggior parte dei casi Windows preferisce Kerberos rispetto a NTLM, a volte i client potrebbero dover ricorrere all'utilizzo di NTLM per l'autenticazione. NTLM si basa sull'autenticazione passthrough, 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 regole firewall devono consentire le seguenti comunicazioni:
| 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 Microsoft AD gestita | Vedi Elaborazione degli accessi. |
Aggiunta ed elaborazione degli accessi per i domini
Per operare come membro del dominio ed elaborare gli accessi degli utenti, una macchina 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, dovresti consentire la seguente combinazione di protocolli.
| Azione | Da | A | 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 tuo caso d'uso esatto, potresti voler consentire anche i seguenti protocolli:
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM server | Subnet Microsoft AD gestita |
Modifica della password Kerberos (UDP/464, TCP/464) LDAP sicuro (TCP/636, TCP/3269) |
Gestione di Microsoft AD gestito
Devi utilizzare una VM aggiunta al dominio per gestire Microsoft AD gestito. Per utilizzare su questa VM strumenti come Active Directory Administration Center, la VM deve essere in grado di accedere anche ai servizi web Active Directory esposti dai controller di dominio Microsoft AD gestiti.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | VM amministratore | Subnet Microsoft AD gestita | Servizi web AD (TCP/9389) |
Connessione di Microsoft AD gestito ad Active Directory on-premise
Per connettere Microsoft AD gestito a un Active Directory on-premise, devi creare una relazione di attendibilità tra foreste. Inoltre, devi abilitare la risoluzione dei nomi DNS tra Google Cloud e il tuo ambiente on-premise.
Creazione e verifica dell'attendibilità
Per creare e verificare un trust trust, 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 dell'attendibilità, configura il firewall on-premise in modo da consentire il traffico in entrata e in uscita che corrisponda alle seguenti 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 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 password Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Microsoft AD gestito è preconfigurato per consentire il traffico corrispondente a queste caratteristiche, quindi non è necessario configurare regole firewall aggiuntive su Google Cloud.
Risoluzione dei nomi DNS di Google Cloud da on-premise
Esistono due modi per consentire alle macchine on-premise di risolvere i nomi DNS nella versione gestita di Microsoft AD: 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 la delega DNS.
Quando utilizzi la delega DNS, i tentativi di risolvere il 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 e un criterio del server in entrata. Verrà creato un indirizzo IP del forwarding in entrata che fa parte del tuo VPC.
Per utilizzare l'indirizzo del forwarding dall'ambiente on-premise, configura il tuo 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 | Microsoft Active Directory gestito |
DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Modifica 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 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 AD gestito mentre utilizzi corp.example.local on-premise.
Negli scenari in cui i domini DNS non sono correlati, puoi configurare l'inoltro del DNS condizionale nel DNS di Active Directory on-premise. Tutte le query che corrispondono al nome DNS utilizzato da Microsoft AD gestito verranno inoltrate a Cloud DNS.
Per utilizzare l'inoltro DNS condizionale, devi prima configurare un criterio DNS che consenta l'inoltro DNS in entrata. Per utilizzare l'indirizzo di forwarding risultante dall'ambiente on-premise, configura il firewall on-premise in modo da consentire il traffico in uscita che corrisponda alle caratteristiche riportate di seguito.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | AD on-premise | Indirizzo IP di forwarding DNS | DNS (UDP/53, TCP/53) |
Sul lato Google Cloud, crea una regola firewall per consentire il traffico in entrata corrispondente a questi criteri.
Non è necessario configurare alcuna regola firewall per abilitare la comunicazione dal forwarding DNS a Cloud DNS (2).
Risoluzione dei nomi DNS on-premise da Google Cloud
Microsoft AD gestito utilizza l'inoltro DNS condizionale per risolvere i nomi DNS nella foresta on-premise. Per consentire anche ai client in esecuzione su Google Cloud di risolvere nomi DNS gestiti da Active Directory on-premise, puoi creare una zona di forwarding privata in Cloud DNS DNS che inoltra le query ai controller di dominio on-premise.
Per abilitare la risoluzione dei nomi DNS on-premise da Google Cloud, configura il firewall on-premise per 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 Microsoft AD gestite da on-premise
Se la foresta Microsoft AD gestita è configurata in modo da considerare attendibile la foresta on-premise, potresti volere che gli utenti e le macchine on-premise siano in grado di accedere alle risorse della foresta Microsoft AD gestita.
Autenticazione su una VM dall'ambiente on-premise mediante 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 e che è 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 eseguire l'autenticazione nella VM server utilizzando Kerberos, il computer client deve ottenere un ticket Kerberos appropriato. Ciò richiede la comunicazione con uno dei controller di dominio on-premise, nonché con uno dei controller di dominio Microsoft AD gestiti.
Per abilitare l'autenticazione delle VM on-premise mediante Kerberos, configura il firewall on-premise in modo da consentire il seguente traffico in uscita.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Macchina client (on-premise) | Subnet Microsoft AD gestita |
LDAP (UDP/389, TCP/389) Kerberos (UDP/88, TCP/88) |
| 2 | Consenti | Macchina 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 Microsoft AD gestita | Vedi Elaborazione degli accessi. |
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 su una VM dall'ambiente on-premise mediante NTLM
Quando utilizzi NTLM per autenticare un utente da una foresta Active Directory on-premise a una VM server aggiunta a una foresta Microsoft AD gestita, i controller di dominio Microsoft AD gestiti devono comunicare con i controller di dominio on-premise.
Per abilitare l'autenticazione delle VM on-premise mediante NTLM, configura il firewall on-premise in modo da consentire il traffico in entrata e in uscita nel seguente modo.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Macchina 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 Microsoft AD gestita | Vedi Elaborazione degli accessi. |
| 3 | Consenti | Subnet Microsoft AD gestita | AD 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 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 tuo caso d'uso esatto, potresti voler consentire anche i seguenti protocolli.
- Modifica della password Kerberos (UDP/464, TCP/464)
- LDAP sicuro (TCP/636, TCP/3269)
Sul lato Microsoft AD gestito, il traffico in uscita corrispondente è consentito per impostazione predefinita.
Sulle VM amministrative, potresti non pianificare di consentire gli accessi degli utenti della foresta on-premise. Un'attività che probabilmente devi eseguire sulle VM amministrative è però la gestione delle iscrizioni ai gruppi. Ogni volta che utilizzi il selettore di oggetti per fare riferimento a un utente o a un gruppo dalla foresta on-premise, il selettore di oggetti richiederà l'accesso ai controller di dominio on-premise. Affinché questo processo funzioni, la VM amministrativa richiede l'accesso ai controller di dominio Active Directory on-premise necessario per l'elaborazione degli accessi per gli utenti della foresta on-premise.
Accesso alle risorse Active Directory on-premise da Google Cloud
Se la tua foresta on-premise è configurata in modo da considerare attendibile la foresta Microsoft AD gestita, potresti volere che gli utenti della foresta Microsoft AD gestita siano 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 AD gestita potrebbe richiedere l'accesso a un servizio fornito da una macchina on-premise che fa parte 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 eseguire l'autenticazione sulla macchina on-premise utilizzando Kerberos, la VM deve ottenere un ticket Kerberos appropriato. Ciò richiede prima la comunicazione con uno dei controller Microsoft AD gestiti e poi con i controller di dominio on-premise.
Per abilitare l'autenticazione delle VM on-premise mediante 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 Microsoft AD gestita |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) Implicato dall'elaborazione degli accessi |
| 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 Google Cloud, il traffico in uscita corrispondente è consentito per impostazione predefinita.
Autenticazione su una VM on-premise mediante NTLM
Quando utilizzi NTLM per autenticare un utente dalla foresta Microsoft AD gestita su un computer server aggiunto 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 abilitare l'autenticazione delle VM on-premise mediante 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 Microsoft AD gestita |
LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Sul lato Google Cloud, il traffico in uscita per (1) e quello in entrata per (2) è consentito 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, una macchina eseguita 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, dovresti consentire la seguente combinazione di protocolli.
| Azione | Da | A | Protocolli | |
|---|---|---|---|---|
| 1 | Consenti | Macchina server (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 tuo caso d'uso esatto, potresti voler 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 alcuna regola firewall in Google Cloud per abilitare il traffico in entrata corrispondente verso Microsoft AD gestito.
Sulle macchine amministrative, potresti non pianificare di consentire gli accessi da parte degli utenti della foresta Microsoft AD gestita. Un'attività che probabilmente dovrai eseguire sulle macchine amministrative è la gestione delle iscrizioni ai gruppi. Ogni volta che utilizzi il selettore di oggetti per fare riferimento a un utente o a un gruppo della foresta di Microsoft AD gestito, il selettore di oggetti richiederà l'accesso ai controller di dominio Microsoft AD gestito. Affinché questo comando funzioni, la macchina amministrativa richiede lo stesso accesso ai controller di dominio Microsoft AD gestito che avrebbe per l'elaborazione degli accessi per gli utenti della foresta di Microsoft AD gestito.