Les contrôleurs de domaine exploités par Managed Service pour Microsoft Active Directory exposent un certain nombre de services, notamment LDAP, DNS, Kerberos et RPC. Selon vos cas d’utilisation, les machines virtuelles déployées sur Google Cloud, ainsi que les machines exécutées sur site, peuvent avoir besoin d’accéder à ces services pour tirer parti d’ActiveDirectory.
Pour réduire la surface d’attaque des contrôleurs de domaine et des machines virtuelles, vous devez utiliser firewalls pour interdire toute communication réseau qui n’est pas strictement requise.Cet article décrit comment configurer les pare-feu pour s’adapter aux cas d’utilisation courants d’ActiveDirectory tout en interdisant les autres communications réseau.
Connexion versus authentification
Bien que les termes connexion et authentification soient souvent utilisés de manière interchangeable, ils ont des significations différentes dans le contexte de la sécurité Windows. Logondécrit le processus qui se produit sur le système auquel un utilisateur accède to.In en revanche, l’authentification est effectuée par l’ordinateur sur lequel réside le compte de l’utilisateur.
Lorsque vous utilisez un compte local pour vous connecter à une machine, l’ouverture de session et l’authentification sont gérées par la machine cible. Dans un environnement Directoryenvironment actif, il est plus courant d’utiliser un utilisateur de domaine pour se connecter. Dans ce cas, l’ouverture de session est gérée par la machine cible, tandis que l’authentification est effectuée par un contrôleur de domaine.
Pour s’authentifier, un client peut utiliser Kerberos ou NTLM.Une fois qu’un client s’authentifie, la machine cible doit traiter l’ouverture de session.Selon le type de logon demandé par le client, cela peut nécessiter une interaction supplémentaire avec les contrôleurs de domaine utilisant des protocoles tels que Kerberos, NTLM, LDAP, RPC ou SMB.
Parce que l’authentification et le traitement des connexions nécessitent des protocoles différents, il est utile de distinguer les deux concepts lors de l’identification de la configuration rightfirewall.
Cas d’utilisation courants
Les sections suivantes décrivent les cas d’utilisation courants d’accessingManaged Microsoft AD et montrent quelles règles de pare-feu vous devez configurer pour chaque cas d’utilisation.
Si vous ne prévoyez pas d’intégrer Microsoft AD géré à un répertoire on-premisesActive, il vous suffit de lire la première section de cet article, en accédant à Microsoft AD géré depuis votre VPC. Si vous avez l’intention de créerune relation de confiance entre Microsoft AD géré et un ActiveDirectory sur site, l’article entier s’applique.
Vous pouvez utiliser les journaux de règles de pare-feu pour analyser si des ports supplémentaires peuvent être nécessaires. Étant donné que la règle de refus d’entrée impliée est désactivée, vous devez d’abord créer une règle de pare-feu personnalisée à faible priorité qui refuse tout le trafic d’entrée, mais la journalisation du pare-feu est activée. Avec cette règle en place, toute tentative de connexion échouée entraîne la publication d’une entrée de journal dans Stackdriver. Comme les règles de pare-feu peuvent produire un volume important de journaux, envisagez de désactiver à nouveau la journalisation du pare-feu une fois votre analyse terminée.
Accès à Microsoft AD géré depuis votre VPC
Lorsque vous utilisez le réseau par défaut pour déployer Microsoft AD géré, aucune autre configuration n’est requise pour activer les machines virtuelles dans le VPC pour accéder à Active Directory.
Si vous avez personnalisé votre configuration VPC ou vos règles de pare-feu, vous devezassurez que votre configuration de pare-feu autorise toujours la communication avec Microsoft AD géré. Les sections suivantes décrivent les règles de pare-feu que vous devrez peut-être créer.
Résolution de nom de domaine
Lorsqu’une machine virtuelle tente de résoudre un nom DNS, elle n’interroge pas directement un contrôleur de domaine. Au lieu de cela, la requête DNS est envoyée au serveur de métadonnées, qui est le serveur DNS par défaut configuré pour les machines virtuelles du moteur de calcul. Le serveur de métadonnées transfère ensuite la requête vers une zone de transfert privée DNS Cloud créée par Microsoft AD géré. Cette zone de transfert transmet ensuite la requête au contrôleur de domaine approprié.
Vous n’avez pas besoin de configurer de règles de pare-feu pour activer ce cas d’utilisation.La communication vers Cloud DNS(1) est toujours autorisée pour les machines virtuelles dans un VPC et Microsoft AD géré autorise les requêtes DNS traitées depuis Cloud DNS Cloud DNS (2) par défaut.
S’authentifier auprès d’une machine virtuelle à l’aide de Kerberos
Un utilisateur qui s’est connecté à une machine virtuelle peut nécessiter l’accès à un service fourni par une autre machine virtuelle. Par exemple, un utilisateur peut tenter d’ouvrir une connexion RDP, d’accéder à un partage de fichiers ou d’accéder à une ressource HTTP nécessitant une authentification.
Pour permettre à un utilisateur de s’authentifier auprès de la machine virtuelle du serveur à l’aide de Kerberos, le client doit d’abord obtenir un ticket Kerberos approprié auprès de l’un des contrôleurs AD Microsoft gérés.
Pour permettre aux machines virtuelles de s’authentifier à une autre à l’aide de Kerberos, la communication suivante doit être autorisée par les règles de pare-feu:
| 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. |
Authentification auprès d’une machine virtuelle à l’aide de NTLM
Bien que Windowsprefère Kerberos sur NTLM dans la plupart des cas, les clients peuvent parfois avoir besoin de revenir à l’utilisation de NTLM pour l’authentification. NTLM s’appuie sur l’authentification passe-par-passe et nécessite donc que le serveur communique avec l’un des contrôleurs de domaine Microsoft AD gérés pour authentifier l’utilisateur.
Pour permettre aux machines virtuelles d’authentifier d’autres machines virtuelles à l’aide de NTLM, la communication suivante doit être autorisée par les règles de pare-feu:
| Action | De | À | Protocoles | |
|---|---|---|---|---|
| 1 | Autoriser | Machine virtuelle client | Machine virtuelle serveur | Protocole utilisé pour accéder aux machines virtuelles, tel que HTTP(TCP /80, TCP/443) ou RDP (TCP/3389) |
| 2 | Autoriser | Machine virtuelle client | Sous-réseau Microsoft AD géré | Voir les connexions de traitement. |
Connexions de connexion et de traitement de domaine
Pour fonctionner en tant que membre de domaine et traiter les connexions des utilisateurs, une machine doit pouvoir interagir avec Active Directory. L’ensemble exact de protocoles utilisésdépend du type d’ouverture de session demandé par les clients individuels. Pour prendre en charge tous les scénarios communs, vous devez autoriser la combinaison de protocoles suivante.
| 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 les protocoles suivants:
| Action | De | À | Protocoles | |
|---|---|---|---|---|
| 1 | Autoriser | Machine virtuelle du serveur | Sous-réseau Microsoft AD géré | Changement de mot de passe Kerberos ( UDP/464, TCP/464) LDAP sécurisé (TCP/636, TCP/3269) |
Administration de Microsoft AD géré
Vous devez utiliser VMto adomain pour gérer Microsoft AD géré. Pour utiliser des outils tels que Active DirectoryAdministrative Center sur cette machine virtuelle, la machine virtuelle doit également pouvoir accéder aux Services Web d’annuaire actifs exposés par des contrôleurs de domaines Microsoft AD gérés.
| Action | De | À | Protocoles | |
|---|---|---|---|---|
| 1 | Autoriser | Machine virtuelle d’administration | Sous-réseau AD Microsoft géré | Services Web AD (TCP/9389 ) |
Connexion de Microsoft AD géré à un Active Directory sur site
Pour connecter Microsoft AD géré à un Active Directory sur site, vous devez créer une relation de confiance entre les forêts. De plus, vous devez activer la résolution de noms de réseau entre Google Cloud et votre environnement sur site.
Création et vérification de confiance
Afin de créer et de vérifier une confiance forestière, les contrôleurs Microsoft ADdomain gérés et les contrôleurs de domaine racine de votre forestmust sur site doivent pouvoir communiquer bidirectionnellement.
Pour activer la création et la vérification de confiance, configurez votre pare-feu sur site pour permettre le trafic d’entrée et de sortie correspondant à ces caractéristiques:
| 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) |
L’AD Microsoft géré est préconfiguré pour permettre le trafic correspondant à ces caractéristiques, vous n’avez donc pas besoin de configurer des règles de pare-feu supplémentaires Nuage onGoogle.
Résolution des noms DNS de Google Cloud à partir de sites
Il existe deux façons d’autoriser les machines sur site à résoudre les noms DNS gérés par Microsoft AD : la délégation DNS et le transfert DNS conditionnel.
Délégation DNS
Le domaine DNS utilisé par Microsoft AD géré peut être un sous-domaine du domaine DNS utilisé sur site. Par exemple, vous pouvez utiliser cloud.example.com Formanagé Microsoft AD lors de l’utilisation example.com sur place. Pour permettre aux clients sur site de résoudre les noms DNS des ressources Google Cloud, vous pouvez définir la délégation upDNS.
Lors de l’utilisation de la délégation DNS, les tentatives de résolution du nom DNS de la ressource Cloud aGoogle interrogent d’abord un serveur DNS local. Le serveur DNSserver redirige ensuite le client vers Cloud DNS, qui à son tour transmet la requête à l’un de vos contrôleurs de domaine Microsoft AD gérés.
L’exposition du DNS Cloud aux réseaux locaux nécessite une stratégie de création et de serveur entrant.Cela créera une adresse IP d’expéditeur entrant qui fait partie de votre VPC.
Pour utiliser l’adresse du transitaire sur site, configurez votre firewall sur site pour autoriser le trafic de sortie correspondant aux caractéristiques ci-dessous.
| 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) |
Transfert DNS conditionnel
Le domaine DNS utilisé par Microsoft AD géré peut ne pas être un sous-domaine de Domaine theDNS utilisé sur site. Par exemple, vous pouvez utiliser cloud.example.compour Microsoft AD géré lors de l’utilisation de corp.example.local sur site.
Dans les scénarios où les domaines DNS ne sont pas liés, vous pouvez configurer des DNSforwarding conditionnels dans votre DNS Active Directory local. Toutes les requêtes qui correspondent au nom DNS utilisé par Microsoft AD géré seront ensuite transférées vers Cloud DNS.
Pour utiliser le transfert DNS conditionnel, vous devez configurer une stratégie aDNS qui active d’abord le transfert DNS entrant. Pour utiliser l’adresse de transitaire résultante sur site, configurez votre pare-feu sur site pour autoriser le trafic de sortie correspondant aux caractéristiques ci-dessous.
| Action | De | À | Protocoles | |
|---|---|---|---|---|
| 1 | Autoriser | AD sur site | Adresse IP de transfert DNS | DNS(UDP/53, TCP/IP/ 53) |
Du côté de Google Cloud, créez une règle de pare-feu pour éliminer le trafic entrant correspondant à ces critères.
Vous n’avez pas besoin de configurer de règles de pare-feu pour activer la communication du transitaire DNSAU Cloud DNS (2).
Résolution des noms DNS sur site à partir de Google Cloud
Microsoft AD géré utilise le transfert DNS conditionnel pour résoudre les noms DNS dans votre forêt sur site. Pour permettre également aux clients s’exécutant dans Google Cloud de résoudre des noms DNS gérés par un Active Directory sur site, vous pouvez créer une zone de transfert privée inCloud DNS DNS qui transmet les requêtes aux contrôleurs de domaine sur site.
Pour permettre la résolution des noms DNS sur site à partir de Google Cloud, configurez votre pare-feu sur site pour autoriser le trafic entrant selon le tableau suivant.
| Action/th> | De | À | Protocoles | |
|---|---|---|---|---|
| 1 | Autoriser | Géré Microsoft AD | AD sur site | DNS (UDP/53, TCP/53) |
| 2 | Autoriser | DNS Cloud (35.199.192.0/19) | AD sur site | DNS(UDP/53, TCP/53) |
Google Cloud permet le trafic de sortie correspondant par défaut.
Accès aux ressources Microsoft AD gérées sur site
Si la forêt Microsoft AD gérée est configurée de manière à faire confiance à votre forêt sur site, vous souhaiterez peut-être que les utilisateurs et les machines sur site puissent accéder aux ressources de la forêt Microsoft AD gérée.
S’authentifier sur une machine virtuelle depuis un site à l’aide de Kerberos
Un utilisateur qui s’est connecté à une machine sur site peut nécessiter un accès à un service fourni par une machine virtuelle qui s’exécute sur Google Cloud et qui est membre d’une forêt d’annonces Microsoft gérée. Par exemple, un utilisateur peut tenter d’ouvrir une RDPconnection, d’accéder à un partage de fichiers ou d’accéder à une ressource HTTP nécessitant une authentification.
Pour permettre aux utilisateurs de s’authentifier auprès de la machine virtuelle du serveur à l’aide de Kerberos, la machine client doit obtenir un ticket Kerberos approprié. Cela nécessite la communication avec l’un des contrôleurs de domaine sur site, ainsi qu’avec l’un des contrôleurs de domaine Microsoft AD gérés.
Pour permettre aux machines virtuelles sur site de s’authentifier à l’aide de Kerberos, configurez votre pare-feu local pour autoriser le trafic de sortie suivant.
| 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. |
Du côté de Google Cloud, créez des règles de pare-feu pour limiter le trafic entrant pour (1) et (2). Le trafic de sortie vers Microsoft AD(3) géré est autorisé par défaut.
Authentification sur une machine virtuelle depuis un site à l’aide de NTLM
Lors de l’utilisation de NTLM pour authentifier un utilisateur depuis un Directoryforest actif sur site vers une machine virtuelle serveur jointe à une forêt d’annonces Microsoft gérée, les contrôleurs de domaine Microsoft AD gérés doivent communiquer avec les contrôleurs de domaine sur site.
Pour permettre aux machines virtuelles sur site de s’authentifier à l’aide de NTLM, configurez votre pare-feu sur site pour autoriser le trafic d’entrée et de sortie comme suit.
| Action | De | À | Protocoles | |
|---|---|---|---|---|
| 1 | Autoriser | Machine cliente (sur site) | Machine virtuelle serveur (Google Cloud) | Protocole utilisé par l’application , tels que HTTP (TCP/80, TCP/443) ou RDP (TCP/3389) |
| 2 | Autoriser | Machine virtuelle serveur | Sous-réseau Microsoft AD géré | Voir les connexions de traitement. |
| 3 | Autoriser | Sous-réseau AD Microsoft géré | AD sur site | LDAP(UDP/389, TCP/389) SMB(UDP/445, TCP/445) |
Du côté de Google Cloud , créer des règles de pare-feu pour limiter le trafic d’entrée pour (1). Le trafic de sortie pour (2) et (3) est autorisé par défaut.
Traitement des connexions pour les utilisateurs de la forêt sur site
Pour traiter une connexion pour un utilisateur de la forêt sur site, une machine virtuelle doit pouvoir interagir avec Active Directory sur site. L’ensemble exact de protocoles utilisés dépend du type de logon demandé par le client. Pour prendre en charge tous les scénarios courants, configurez votre pare-feu local pour autoriser le trafic entrant correspondant à ces caractéristiques.
| Action | De | À | Protocoles | |
|---|---|---|---|---|
| 1 | Autoriser | Machine virtuelle serveur (Google Cloud) | Sous-réseau AD sur site | 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) |
Selon votre cas d’utilisation exact, vous pouvez également autoriser les protocoles suivants.
- Changement de mot de passe Kerberos (UDP/464, TCP/464)
- LDAP sécurisé (TCP/636, TCP/3269)
Du côté de Microsoft AD géré, le trafic de sortie correspondant est autorisé par défaut.
Sur les machines virtuelles administratives, il est possible que vous ne prévoiriez pas d’autoriser les connexions des utilisateurs de theon-premises forest. Cependant, une activité que vous devez probablement effectuer sur les machines virtuelles administratives consiste à gérer les adhésions aux groupes. Chaque fois que vous utilisez theobject picker pour référencer un utilisateur ou un groupe de votre forêt sur site, theobject picker nécessite l’accès aux contrôleurs de domaine sur site. Pour que cela fonctionne, la machine virtuelle d’administration nécessite le même accès à vos contrôleurs de domaine d’annuaire actifs sur site que pour le traitement des connexions pour les utilisateurs de la forêt sur site.
Accès aux ressources Active Directory sur site à partir de Google Cloud
Si votre forêt sur site est configurée pour faire confiance à la forêt Microsoft AD gérée, vous souhaiterez peut-être que les utilisateurs de la forêt Microsoft AD gérée puissent accéder aux ressources sur site.
S’authentifier auprès d’une machine virtuelle sur site à l’aide de Kerberos
Un utilisateur qui s’est connecté à une machine virtuelle fonctionnant sur Google Cloud et qui est membre de la forêt d’annonces Microsoft gérée peut nécessiter l’accès à un serviceproved par une machine sur site membre de votre forêt sur site.Par exemple, l’utilisateur peut tenter d’ouvrir une connexion RDP, d’accéder à un partage de fichiers ou d’accéder à une ressource HTTP nécessitant une authentification.
Pour permettre à l’utilisateur de s’authentifier sur la machine sur site à l’aide de Kerberos, theVM doit obtenir un ticket Kerberos approprié. Cela nécessite d’abord la communication avec l’un des contrôleurs Microsoft AD gérés, puis avec les contrôleurs de domaine sur site.
Pour permettre aux machines virtuelles sur site de s’authentifier à l’aide de Kerberos, configurez votre pare-feu sur site pour autoriser le trafic entrant correspondant aux caractéristiques ci-dessous.
| 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 application, telle que HTTP (TCP/80, TCP/443) ou RDP (TCP/3389) |
Du côté de Google Cloud, le trafic de sortie correspondant est autorisé par défaut.
Authentification sur une machine virtuelle sur site à l’aide de NTLM
Lorsque vous utilisez NTLM pour authentifier un utilisateur à partir de la forêt Microsoft AD gérée vers un serveur connecté à votre forêt sur site, les contrôleurs de domaine sur site doivent pouvoir communiquer avec les contrôleurs de domaine Microsoft AD gérés:
Pour permettre aux machines virtuelles sur site de s’authentifier à l’aide de Kerberos, configurez votre pare-feu sur site pour autoriser le trafic d’entrée et de sortie correspondant à ces caractéristiques.
| Action | De | À | Protocoles | |
|---|---|---|---|---|
| 1 | Autoriser | Machine virtuelle client (Google Cloud) | Machine serveur (sur site) | Protocole utilisé par l’application par exemple, HTTP (TCP/80, TCP/443) ou RDP (TCP/3389) |
| 2 | Autoriser | AD sur site | Sous-réseau AD Microsoft géré | LDAP(UDP/389, TCP/389) SMB(UDP/445, TCP/445) |
Du côté de Google Cloud, le trafic de sortie pour (1) et le trafic d’entrée pour (2) sont autorisés par défaut.
Traitement des connexions pour les utilisateurs de la forêt AD Microsoft gérée
Pour traiter une connexion pour un utilisateur de la forêt AD Microsoft gérée, un machinerunning sur site doit pouvoir interagir avec les contrôleurs Addomains Microsoft gérés. L’ensemble exact de protocoles utilisés dépend du type de logon demandé par le client. Pour prendre en charge tous les scénarios courants, vous devez autoriserla combinaison de protocoles suivante.
| Action | De | À | Protocoles | |
|---|---|---|---|---|
| 1 | Autoriser | Machine serveur (sur site) | Sous-réseau Microsoft AD géré | 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) |
Selon votre cas d’utilisation exact, vous pouvez également autoriser les protocoles suivants.
- Changement de mot de passe Kerberos (UDP/464, TCP/464)
- LDAP sécurisé (TCP/636, TCP/3269)
Assurez-vous que vos pare-feu sur site permettent un trafic de sortie correspondant à ces caractéristiques. Vous n’avez pas besoin de configurer de règles de pare-feu dans le cloud Google pour activer le trafic entrant correspondant à Microsoft AD géré.
Sur les machines d’administration, il est possible que vous n’ayez pas l’intention d’autoriser les connexions des utilisateurs de la forêt d’annonces Microsoft gérée. Une activité que vous devez probablement effectuer surles machines administratives gèrent les adhésions aux groupes. Chaque fois que vous utilisez le sélecteur d’objets pour référencer un utilisateur ou un groupe à partir de Microsoft ADforest géré, le sélecteur d’objets nécessite l’accès aux contrôleurs d’addomaine Microsoft gérés. Pour que cela fonctionne, la machine d’administration nécessite le même accès aux contrôleurs de domaine Microsoft AD gérés que pour le traitement des connexions pour les utilisateurs de la forêt Microsoft AD gérée.