Les contrôleurs de domaine exploités par le service géré pour Microsoft Active Directory exposent un certain nombre de services, notamment LDAP, DNS, Kerberos et RPC. Selon vos cas d'utilisation, les machines virtuelles (VM) déployées sur Google Cloud, ainsi que les machines exécutées sur site, peuvent avoir besoin d'accéder à ces services afin d'exploiter Active Directory.
Pour réduire la surface d'attaque des contrôleurs de domaine et des VM, vous devez configurer des pare-feu pour bloquer les communications réseau qui ne sont pas strictement requises. Cet article décrit comment configurer les pare-feu afin de gérer les cas d'utilisation courants d'Active Directory tout en interdisant les autres communications réseau.
Ouverture de session et authentification
Bien que les termes d'ouverture de session (ou connexion) et d'authentification soient souvent utilisés de manière interchangeable, ils ont des significations différentes dans le contexte de la sécurité Windows. L'ouverture de session décrit le processus ayant lieu sur le système auquel un utilisateur obtient l'accès. 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 Active Directory, 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 est authentifié, la machine cible doit traiter l'ouverture de session. Selon le type d'ouverture de session demandé par le client, cela peut nécessiter des interactions supplémentaires avec les contrôleurs de domaine à l'aide de protocoles tels que Kerberos, NTLM, LDAP, RPC, ou SMB .
Étant donné que l'authentification et le traitement des ouvertures de session nécessitent des protocoles différents, il est utile de distinguer les deux concepts pour identifier la bonne configuration de pare-feu.
Cas d'utilisation courants
Les sections suivantes décrivent des cas d'utilisation courants d'accès au service Microsoft AD géré et indiquent les règles de pare-feu que vous devez configurer pour chaque cas d'utilisation.
Si vous ne prévoyez pas d'intégrer le service Microsoft AD géré à un annuaire Active Directory local, il vous suffit de lire la première section de cet article, Accéder au service Microsoft AD géré depuis votre VPC. Si vous avez l'intention de créer une relation d'approbation entre le service Microsoft AD géré et un annuaire Active Directory local, l'article complet s'applique.
Vous pouvez utiliser la journalisation des règles de pare-feu pour analyser si des ports supplémentaires sont nécessaires. La journalisation étant désactivée dans la règle implicite d'entrée interdite, vous devez d'abord créer une règle de pare-feu personnalisée de faible priorité qui refuse tout le trafic entrant, mais pour laquelle la journalisation de règle de pare-feu est activée. Une fois cette règle en place, toute tentative de connexion ayant échoué entraîne la publication d'une entrée de journal dans Stackdriver. Étant donné que les règles de pare-feu peuvent produire un volume de journaux important, envisagez de désactiver à nouveau la journalisation des règles de pare-feu une fois l'analyse terminée.
Accéder au service Microsoft AD géré depuis votre VPC
Lorsque vous utilisez le réseau par défaut pour déployer le service Microsoft AD géré, aucune configuration supplémentaire n'est requise pour permettre aux VM situées dans le VPC d'accéder à Active Directory.
Si vous avez personnalisé votre configuration VPC ou vos règles de pare-feu, vous devez vous assurer que votre configuration de pare-feu autorise toujours la communication avec le service Microsoft AD géré. Les sections suivantes décrivent les règles de pare-feu que vous pouvez être amené à créer.
Résolution de nom de domaine
Lorsqu'une VM 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 VM Compute Engine. Le serveur de métadonnées transmet ensuite la requête à une zone de transfert DNS privée Cloud DNS créée par le service 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 avec Cloud DNS est toujours autorisée pour les VM situées dans un VPC et le service Microsoft AD géré autorise les requêtes DNS transférées depuis Cloud DNS par défaut.
Authentification sur une VM à l'aide de Kerberos
Un utilisateur qui s'est connecté à une VM peut avoir besoin d'accéder à un service fourni par une autre VM. Par exemple, un utilisateur peut tenter d'ouvrir une connexion RDP, d'accéder à un partage de fichiers ou encore d'accéder à une ressource HTTP qui nécessite une authentification.
Pour permettre à un utilisateur de s'authentifier auprès de la VM serveur à l'aide de Kerberos, la VM cliente doit tout d'abord obtenir un ticket Kerberos approprié auprès de l'un des contrôleurs Microsoft AD gérés.
Pour permettre aux VM de s'authentifier auprès d'une autre VM à l'aide de Kerberos, la communication suivante doit être autorisée par les règles de pare-feu :
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | VM cliente | Sous-réseau Microsoft AD géré | Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 2 | Autoriser | VM cliente | VM serveur | Protocole utilisé pour accéder aux VM, tel que HTTP (TCP/80, TCP/443) ou RDP (TCP/3389) |
| 3 | Autoriser | VM serveur | Sous-réseau Microsoft AD géré | Reportez-vous à la section traitement des ouvertures de session. |
S'authentifier auprès d'une VM à l'aide de NTLM
Bien que, dans la plupart des cas, Windows préfère Kerberos à NTLM, les clients sont parfois contraints de recourir à NTLM pour l'authentification. NTLM repose sur l'authentification directe et nécessite donc que le serveur communique avec l'un des contrôleurs de domaine Microsoft AD géré pour authentifier l'utilisateur.
Pour permettre aux VM de s'authentifier auprès d'autres VM à l'aide de NTLM, la communication suivante doit être autorisée par les règles de pare-feu :
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | VM cliente | VM serveur | Protocole utilisé pour accéder aux VM, tel que HTTP (TCP/80, TCP/443) ou RDP (TCP/3389) |
| 2 | Autoriser | VM cliente | Sous-réseau Microsoft AD géré | Reportez-vous à la section traitement des ouvertures de session. |
Joindre le domaine et traiter les ouvertures de session
Pour fonctionner en tant que membre d'un domaine et traiter les ouvertures de session des utilisateurs, une machine doit pouvoir interagir avec Active Directory. L'ensemble exact de protocoles utilisés dépend du type d'ouverture de session demandé par les clients individuels. Pour autoriser tous les scénarios courants, vous devez autoriser la combinaison de protocoles suivante.
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | VM serveur | 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) |
En outre, suivant votre cas d'utilisation particulier, vous pouvez également autoriser les protocoles suivants :
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | VM 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) |
Administrer Microsoft AD géré
Pour gérer le service Microsoft AD géré, vous devez utiliser une VM jointe au domaine. Pour utiliser des outils tels que le Centre d'administration Active Directory sur cette VM, celle-ci doit également être en mesure d'accéder aux services Web Active Directory exposés par les contrôleurs de domaine Microsoft AD géré.
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | VM d'administration | Sous-réseau Microsoft AD géré | Services Web AD (TCP/9389) |
Connecter le service Microsoft AD géré à un service Active Directory sur site
Pour connecter le service Microsoft AD géré à un service Active Directory sur site, vous devez créer une relation d'approbation entre forêts. En outre, vous devez activer la résolution de noms DNS entre Google Cloud et votre environnement sur site.
Créer et vérifier une approbation
Pour créer et vérifier une approbation entre forêts, les contrôleurs de domaine Microsoft AD géré et les contrôleurs de domaine racines de votre forêt sur site doivent pouvoir communiquer de manière bidirectionnelle.
Pour permettre la création et la validation de l'approbation, configurez votre pare-feu sur site afin qu'il autorise le trafic d'entrée et de sortie correspondant aux caractéristiques suivantes :
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | AD sur site | Service Microsoft AD géré | DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Changement de mot de passe Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
| 2 | Autoriser | Service Microsoft AD géré | AD sur site | DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Changement de mot de passe Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Le service Microsoft AD géré est préconfiguré pour autoriser le trafic correspondant à ces caractéristiques. Vous n'avez donc pas besoin de configurer des règles de pare-feu supplémentaires sur Google Cloud.
Résoudre des noms DNS Google Cloud sur site
Il existe deux façons d'autoriser les machines sur site à résoudre les noms DNS dans le service Microsoft AD géré : la délégation DNS et le transfert DNS conditionnel.
Délégation DNS
Le domaine DNS utilisé par le service Microsoft AD géré peut être un sous-domaine du domaine DNS utilisé sur site. Par exemple, vous pouvez utiliser cloud.example.com pour le service Microsoft AD géré tout en utilisant example.com sur site. Pour permettre aux clients sur site de résoudre les noms DNS des ressources Google Cloud, vous pouvez configurer la délégation DNS.
Lorsque vous utilisez la délégation DNS, les tentatives de résolution du nom DNS d'une ressource Google Cloud interrogent d'abord un serveur DNS sur site. Le serveur DNS redirige ensuite le client vers Cloud DNS, qui à son tour transfère la requête à l'un de vos contrôleurs de domaine Microsoft AD géré.
Exposer Cloud DNS à des réseaux sur site nécessite la création d'une stratégie de serveur entrant. Cela créera une adresse IP de redirecteur entrant qui fait partie de votre VPC.
Pour utiliser l'adresse du redirecteur depuis un emplacement sur site, configurez votre pare-feu local pour autoriser le trafic sortant qui correspond aux caractéristiques ci-dessous.
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | AD sur site | Service Microsoft AD géré | DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Changement de mot de passe Kerberos (UDP/464, TCP/464) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
| 2 | Autoriser | Service Microsoft AD géré | AD sur site | DNS (UDP/53, TCP/53) Kerberos (UDP/88, TCP/88) Changement de mot de passe Kerberos (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 le service Microsoft AD géré peut ne pas être un sous-domaine du domaine DNS utilisé sur site. Par exemple, vous pouvez utiliser cloud.example.com pour le service Microsoft AD géré tout en utilisant corp.example.local sur site.
Dans les scénarios où les domaines DNS ne sont pas liés, vous pouvez configurer le transfert DNS conditionnel dans votre DNS Active Directory sur site. Toutes les requêtes qui correspondent au nom DNS utilisé par le service Microsoft AD géré seront alors transmises à Cloud DNS.
Pour utiliser le transfert DNS conditionnel, vous devez d'abord configurer une règle DNS qui autorise le transfert DNS entrant. Pour utiliser l'adresse du redirecteur résultant depuis un emplacement sur site, configurez votre pare-feu local pour autoriser le trafic sortant qui correspond aux caractéristiques ci-dessous.
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | AD sur site | Adresse IP de redirection DNS | DNS (UDP/53, TCP/53) |
Côté Google Cloud, créez une règle de pare-feu pour autoriser le trafic entrant correspondant à ces critères.
Vous n'avez pas besoin de configurer de règles de pare-feu pour autoriser la communication entre le redirecteur DNS et Cloud DNS (2).
Résoudre des noms DNS sur site à partir de Google Cloud
Le service 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 exécutés dans Google Cloud de résoudre les noms DNS gérés par un annuaire Active Directory sur site, vous pouvez créer une zone de transfert privée dans Cloud DNS qui transmet les requêtes aux contrôleurs de domaine sur site.
Pour activer la résolution des noms DNS locaux à partir de Google Cloud, configurez votre pare-feu local pour autoriser le trafic entrant selon le tableau suivant.
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | Service Microsoft AD géré | AD sur site | DNS (UDP/53, TCP/53) |
| 2 | Autoriser | Cloud DNS (35.199.192.0/19) | AD sur site | DNS (UDP/53, TCP/53) |
Google Cloud autorise par défaut le trafic de sortie correspondant.
Accéder sur site aux ressources du service Microsoft AD géré
Si la forêt Microsoft AD gérée est configurée pour approuver votre forêt sur site, vous souhaiterez peut-être que les utilisateurs et les machines sur site aient accès aux ressources de la forêt Microsoft AD gérée.
S'authentifier auprès d'une VM depuis une machine sur site à l'aide de Kerberos
Un utilisateur qui s'est connecté à une machine sur site peut avoir besoin d'accéder à un service fourni par une VM qui s'exécute dans Google Cloud et est membre d'une forêt Microsoft AD gérée. Par exemple, un utilisateur peut tenter d'ouvrir une connexion RDP, d'accéder à un partage de fichiers ou encore d'accéder à une ressource HTTP qui nécessite une authentification.
Pour permettre aux utilisateurs de s'authentifier auprès de la VM serveur à l'aide de Kerberos, la machine cliente doit obtenir un ticket Kerberos approprié. Cela nécessite de communiquer avec l'un des contrôleurs de domaine sur site, ainsi qu'avec l'un des contrôleurs de domaine Microsoft AD géré pour authentifier l'utilisateur.
Pour permettre aux VM sur site de s'authentifier à l'aide de Kerberos, configurez votre pare-feu local pour autoriser le trafic de sortie suivant.
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | Machine cliente (sur site) | Sous-réseau Microsoft AD géré | LDAP (UDP/389, TCP/389) Kerberos (UDP/88, TCP/88) |
| 2 | Autoriser | Machine cliente (sur site) | VM serveur (Google Cloud) | Protocole utilisé par l'application, tel que HTTP (TCP/80, TCP/443) ou RDP (TCP/3389) |
| 3 | Autoriser | VM serveur | Sous-réseau Microsoft AD géré | Reportez-vous à la section traitement des ouvertures de session. |
Côté Google Cloud, créez des règles de pare-feu afin d'autoriser le trafic entrant pour (1) et (2). Le trafic sortant vers le service Microsoft AD géré (3) est autorisé par défaut.
S'authentifier auprès d'une VM depuis une machine sur site à l'aide de NTLM
Lorsque vous utilisez NTLM pour authentifier un utilisateur d'une forêt Active Directory sur site sur une VM serveur jointe à une forêt Microsoft AD gérée, les contrôleurs de domaine Microsoft AD géré doivent communiquer avec les contrôleurs de domaine sur site.
Pour permettre aux VM sur site de s'authentifier à l'aide de NTLM, configurez votre pare-feu sur site afin d'autoriser le trafic d'entrée et de sortie comme suit.
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | Machine cliente (sur site) | VM serveur (Google Cloud) | Protocole utilisé par l'application, tel que HTTP (TCP/80, TCP/443) ou RDP (TCP/3389) |
| 2 | Autoriser | VM serveur | Sous-réseau Microsoft AD géré | Reportez-vous à la section traitement des ouvertures de session. |
| 3 | Autoriser | Sous-réseau Microsoft AD géré | AD sur site | LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Côté Google Cloud, créez des règles de pare-feu afin d'autoriser le trafic entrant pour (1). Le trafic sortant pour (2) et (3) est autorisé par défaut.
Traiter les ouvertures de session pour les utilisateurs de la forêt sur site
Pour traiter l'ouverture d'une session pour un utilisateur de la forêt sur site, une VM doit être en mesure d'interagir avec le service Active Directory sur site. L'ensemble exact de protocoles utilisés dépend du type d'ouverture de session demandé par le client. Pour gérer tous les scénarios courants, configurez votre pare-feu sur site afin d'autoriser le trafic entrant correspondant aux caractéristiques suivantes.
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | VM serveur (Google Cloud) | Sous-réseau AD local | 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) |
Suivant votre cas d'utilisation particulier, 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é du service Microsoft AD géré, le trafic de sortie correspondant est autorisé par défaut.
Sur les VM d'administration, vous ne prévoyez peut-être pas d'autoriser les ouvertures de session des utilisateurs de la forêt sur site. Cependant, une activité qu'il est probablement nécessaire d'effectuer sur les VM d'administration est la gestion des appartenances aux groupes. Chaque fois que vous utilisez le sélecteur d'objet pour référencer un utilisateur ou un groupe de votre forêt sur site, le sélecteur d'objet nécessite un accès aux contrôleurs de domaine sur site. Pour que cela fonctionne, la VM d'administration nécessite le même accès à vos contrôleurs de domaine Active Directory sur site que pour le traitement des ouvertures de session pour les utilisateurs de la forêt sur site.
Accéder aux ressources Active Directory sur site à partir de Google Cloud
Si votre forêt sur site est configurée pour approuver la forêt Microsoft AD gérée, vous souhaiterez peut-être que les utilisateurs de la forêt Microsoft AD gérée aient accès aux ressources sur site.
S'authentifier auprès d'une VM sur site à l'aide de Kerberos
Un utilisateur qui s'est connecté à une VM exécutée sur Google Cloud et qui est membre de la forêt Microsoft AD gérée peut avoir besoin d'accéder à un service fourni par une machine sur site qui est 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 encore d'accéder à une ressource HTTP qui nécessite une authentification.
Pour permettre à l'utilisateur de s'authentifier auprès de la machine sur site à l'aide de Kerberos, la VM doit obtenir un ticket Kerberos approprié. Cela nécessite de communiquer en premier lieu avec l'un des contrôleurs de domaine Microsoft AD géré, puis avec les contrôleurs de domaine sur site.
Pour permettre aux VM sur site de s'authentifier à l'aide de Kerberos, configurez votre pare-feu sur site afin d'autoriser le trafic entrant qui correspond aux caractéristiques ci-dessous.
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | VM cliente (Google Cloud) | Sous-réseau Microsoft AD géré | Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) Implicite en raison du traitement des ouvertures de session |
| 2 | Autoriser | VM cliente (Google Cloud) | AD sur site | Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 3 | Autoriser | VM cliente (Google Cloud) | Machine serveur (sur site) | Protocole utilisé par l'application, tel 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.
S'authentifier auprès d'une VM sur site à l'aide de NTLM
Lorsque vous utilisez NTLM pour authentifier un utilisateur de la forêt Microsoft AD gérée sur une machine serveur jointe à 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é :
Pour permettre aux VM sur site de s'authentifier à l'aide de Kerberos, configurez votre pare-feu local pour autoriser le trafic d'entrée et de sortie correspondant aux caractéristiques suivantes.
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 1 | Autoriser | VM cliente (Google Cloud) | Machine serveur (sur site) | Protocole utilisé par l'application, tel que HTTP (TCP/80, TCP/443) ou RDP (TCP/3389) |
| 2 | Autoriser | AD sur site | Sous-réseau Microsoft AD géré | LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) |
Côté Google Cloud, le trafic sortant pour (1) et le trafic entrant pour (2) sont autorisés par défaut.
Traiter les ouvertures de session pour les utilisateurs de la forêt Microsoft AD gérée
Pour traiter l'ouverture d'une session pour un utilisateur de la forêt Microsoft AD gérée, une machine exécutée sur site doit pouvoir interagir avec les contrôleurs de domaine Microsoft AD géré. L'ensemble exact de protocoles utilisés dépend du type d'ouverture de session demandé par le client. Pour autoriser tous les scénarios courants, vous devez autoriser la combinaison de protocoles suivante.
| Action | De | À | Protocole | |
|---|---|---|---|---|
| 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) |
Suivant votre cas d'utilisation particulier, 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 autorisent le trafic de sortie correspondant à ces caractéristiques. Vous n'avez pas besoin de configurer de règles de pare-feu dans Google Cloud pour autoriser le trafic entrant correspondant vers le service Microsoft AD géré.
Sur les machines d'administration, vous ne prévoyez peut-être pas d'autoriser les ouvertures de session des utilisateurs de la forêt Microsoft AD gérée. Cependant, une activité qu'il est probablement nécessaire d'effectuer sur les machines d'administration est la gestion des appartenances aux groupes. Chaque fois que vous utilisez le sélecteur d'objet pour référencer un utilisateur ou un groupe de la forêt Microsoft AD gérée, le sélecteur d'objet nécessite un accès aux contrôleurs de domaine Microsoft AD géré. Pour que cela fonctionne, la machine d'administration nécessite le même accès aux contrôleurs de domaine Microsoft AD géré que pour le traitement des ouvertures de session pour les utilisateurs de la forêt Microsoft AD gérée.