none
Controleur de domaine derrière un NAT RRS feed

  • Question

  • Bonjour Tout le monde,

    J'ai mis en place un Controleur domaine sous Windows serveur 2008 R2 dont l'adresse ip est NATé comme suit

    mon DC a comme adresse: 192.168.0.1 mais accessible via l'adresse 192.168.10.21 

    je n'arrive pas à faire la résolution DNS au moment de l'intégration d'une machine dans le domaine, meme le Nslookup me renvoi ::: Unknow

    Merci


    hussein demo

    vendredi 6 septembre 2019 07:17

Réponses

  • Bonjour,

    Si vous avez NATé votre DC initialement en 192.168.0.1 sur l'adresse 192.168.10.21 :

    • Vos postes de travail doivent utiliser l'IP 192.168.10.21 comme DNS Principal
    • Votre zone DNS de votre domaine, doit être mise à jour pour ajouter 192.168.10.21 comme IP supplémentaire de votre DC :
      Exemple : si votre DC s'appelle mondc.mondomaine.local, ajoutez un enregistrement mondc.mondomaine.local qui pointe vers 192.168.10.21
    • Toujours dans le DNS, créez une zone reverse 10.168.192.in-addr.arp, avec un enregistrement 192.168.10.21 -> mondc.mondomaine.local
    • Dans Sites Active Directory, pensez à déclarer le subnet 192.168.10.21 et l'associer avec votre Site-Par-Défaut

    Normalement avec tout ça (et si vos règles de pare-feu laissent passer tous les protocoles nécessaires), il ne devrait pas y avoir de problèmes.


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    • Marqué comme réponse Hussein demo vendredi 6 septembre 2019 10:52
    vendredi 6 septembre 2019 07:31
  • En complément, avez-vous bien autorisé tous les ports nécessaires au niveau de firewall pour que votre contrôleur de domaine soit accessible par les postes de travail ?
    https://serverfault.com/questions/565775/minimum-number-of-port-need-to-open-between-windows-client-domain-controller-o

    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    • Marqué comme réponse Hussein demo mardi 10 septembre 2019 08:55
    lundi 9 septembre 2019 08:47
  • Bonjour Sylvain, 

    le résultat sur les tests :

    - DNS request timed out

      server: unknown

      adress: 192.168 .... il me renvoie l'adresse DNS

    - Ping request could not find host mondomaine.com. Please check the name and try again

    - The specified network name is longer available.

    En complement, 

    un poste de travail sur le meme RX se connecte au domaine sans problème.

    mais plutôt tous les postes se trouvant devant le NAT pose problème 

    Merci. 


    hussein demo

    • Marqué comme réponse Hussein demo mardi 10 septembre 2019 08:55
    mardi 10 septembre 2019 08:55
  • Il faut vérifier la communication complète : :

    [poste] ----> [Firewall/Routeur NAT ]  ----> [Serveur]

    Le pare-feu des postes doit laisser ces ports autorisés en sortie vers l'IP du serveur

    Le pare-feu du serveur doit laisser ces ports autorisés en entrée depuis les IP des postes

    Le "Firewall/routeur NAT" (l'équipement qui interconnecte le LAN des postes avec votre 2nde salle), soit autoriser l'accès des postes au serveur sur les ports en question.

    Le "Firewall/routeur NAT" doit rediriger les ports en question depuis l'interface où sont connectés les postes, vers l'interface où est connecté le serveur.

    Mais là, on est sur des compétences réseau, plus vraiment du Windows...


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    • Marqué comme réponse Hussein demo mardi 10 septembre 2019 15:22
    mardi 10 septembre 2019 12:01

Toutes les réponses

  • Bonjour,

    Si vous avez NATé votre DC initialement en 192.168.0.1 sur l'adresse 192.168.10.21 :

    • Vos postes de travail doivent utiliser l'IP 192.168.10.21 comme DNS Principal
    • Votre zone DNS de votre domaine, doit être mise à jour pour ajouter 192.168.10.21 comme IP supplémentaire de votre DC :
      Exemple : si votre DC s'appelle mondc.mondomaine.local, ajoutez un enregistrement mondc.mondomaine.local qui pointe vers 192.168.10.21
    • Toujours dans le DNS, créez une zone reverse 10.168.192.in-addr.arp, avec un enregistrement 192.168.10.21 -> mondc.mondomaine.local
    • Dans Sites Active Directory, pensez à déclarer le subnet 192.168.10.21 et l'associer avec votre Site-Par-Défaut

    Normalement avec tout ça (et si vos règles de pare-feu laissent passer tous les protocoles nécessaires), il ne devrait pas y avoir de problèmes.


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    • Marqué comme réponse Hussein demo vendredi 6 septembre 2019 10:52
    vendredi 6 septembre 2019 07:31
  • Bonjour,

    NAT + AD ==> Bof bof...

    Généralement, nous déconseillons de faire du NAT avec Active Directory.

    Il y a un peu de lecture ici :

    https://support.microsoft.com/fr-fr/help/978772/description-of-support-boundaries-for-active-directory-over-nat

    Quelle est votre architecture AD, combien de controleur de domaine avez vous ?

    Car pour joindre votre domaine, les client essaie de joindre un des DC et non un DC précis. Ce qui peut poser des soucis.

    Si votre besoin est de mettre à dispo l'authentification AD en DMZ, il y a d'autre méthode que le NAT. Notamment les RODC qui sont moins sensible et "qui peuvent être en DMZ" par exemple.

    Cordialement


    Benoit

    vendredi 6 septembre 2019 07:33
  • MERCI pour vos reactions rapides,

    au fait j'ai un DC central qui est derrière le NAT, pour une simple raison aménagement de ma salle serveur j’étais obligé de déplacer mon DC vers un autre site tout en gardant le service. 


    hussein demo

    vendredi 6 septembre 2019 08:19
  • Rien ne marche,

    Dit moi Sylvain, comment puis-je procéder pour ajouter une IP supplémentaire qui pointe vers mon DC?


    hussein demo

    vendredi 6 septembre 2019 10:53
  • Sur le serveur DNS de l'AD, clic droit sur votre zone DNS, créer un nouvel enregistrement A

    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    vendredi 6 septembre 2019 10:55
  • Rien ne marche, y a t-il pas un redicteur DNS dans ce sens ?

    hussein demo

    lundi 9 septembre 2019 08:22
  • Rien ne marche, y a t-il pas un redicteur DNS dans ce sens ?

    hussein demo

    Bonjour,

    Comme l'a indiqué Benoît, l'utilisation d'un AD derrière un NAT n'est pas recommandé. Voici d'ailleurs un article de Microsoft à ce sujet : https://support.microsoft.com/en-us/help/978772/description-of-support-boundaries-for-active-directory-over-nat

    Concernant votre problème, cela manque un peu de détails...

    Côté poste de travail, pouvez-vous effectuer les tests suivants :

    • nslookup domainead.tld  (doit retourner les enregistrements DNS du domaine)
    • ping domainead.tld  (doit retourner une des IP's - NATtée ou non - du contrôleur de domaine)
    • \\IP-NATée\NETLOGON (après authentification, doit faire apparaitre le partage NETLOGON)

    Merci de nous faire un retour avec ces éléments concrets (actions effectuées, messages d'erreur...)


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    lundi 9 septembre 2019 08:32
  • En complément, avez-vous bien autorisé tous les ports nécessaires au niveau de firewall pour que votre contrôleur de domaine soit accessible par les postes de travail ?
    https://serverfault.com/questions/565775/minimum-number-of-port-need-to-open-between-windows-client-domain-controller-o

    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    • Marqué comme réponse Hussein demo mardi 10 septembre 2019 08:55
    lundi 9 septembre 2019 08:47
  • Bonjour Sylvain, 

    le résultat sur les tests :

    - DNS request timed out

      server: unknown

      adress: 192.168 .... il me renvoie l'adresse DNS

    - Ping request could not find host mondomaine.com. Please check the name and try again

    - The specified network name is longer available.

    En complement, 

    un poste de travail sur le meme RX se connecte au domaine sans problème.

    mais plutôt tous les postes se trouvant devant le NAT pose problème 

    Merci. 


    hussein demo

    • Marqué comme réponse Hussein demo mardi 10 septembre 2019 08:55
    mardi 10 septembre 2019 08:55
  • Bonjour Sylvain, 

    le résultat sur les tests :

    - DNS request timed out

      server: unknown

      adress: 192.168 .... il me renvoie l'adresse DNS

    - Ping request could not find host mondomaine.com. Please check the name and try again

    - The specified network name is longer available.

    En complement, 

    un poste de travail sur le meme RX se connecte au domaine sans problème.

    mais plutôt tous les postes se trouvant devant le NAT pose problème 

    Merci. 


    hussein demo

    Cela ressemble clairement à un problème de pare-feu : vérifiez dans votre firewall que le trafic postes -> serveur est bien autorisé pour les protocoles/ports suivants :

    1. TCP & UDP port 88 for Kerberos Authentication
    2. TCP & UDP 389 for LDAP
    3. TCP & UDP 445 for SMB/CIFS/SMB2
    4. TCP and UDP port 464 for Kerberos Password Change
    5. TCP Port 3268 & 3269 for Global Catalog
    6. TCP and UDP port 53 for DNS
    7. TCP and UDP Dynamic - 49152 to 65535 ( Windows Server 2008 ) for DCOM, RPC, EPM

    Et comme il s'agit d'un NAT, assurez-vous que votre firewall redirige bien ces ports de manière symétrique (port 389 -> 389, port 445 -> 445).

    Si votre Firewall fait du filtrage applicatif, assurez-vous aussi qu'il n'interfère pas dans ces échanges (filtrage SSL par exemple).


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    mardi 10 septembre 2019 08:59
  • Bonjour Sylvain, 

    le résultat sur les tests :

    - DNS request timed out

      server: unknown

      adress: 192.168 .... il me renvoie l'adresse DNS

    - Ping request could not find host mondomaine.com. Please check the name and try again

    - The specified network name is longer available.

    En complement, 

    un poste de travail sur le meme RX se connecte au domaine sans problème.

    mais plutôt tous les postes se trouvant devant le NAT pose problème 

    Merci. 


    hussein demo

    Cela ressemble clairement à un problème de pare-feu : vérifiez dans votre firewall que le trafic postes -> serveur est bien autorisé pour les protocoles/ports suivants :

    1. TCP & UDP port 88 for Kerberos Authentication
    2. TCP & UDP 389 for LDAP
    3. TCP & UDP 445 for SMB/CIFS/SMB2
    4. TCP and UDP port 464 for Kerberos Password Change
    5. TCP Port 3268 & 3269 for Global Catalog
    6. TCP and UDP port 53 for DNS
    7. TCP and UDP Dynamic - 49152 to 65535 ( Windows Server 2008 ) for DCOM, RPC, EPM

    Et comme il s'agit d'un NAT, assurez-vous que votre firewall redirige bien ces ports de manière symétrique (port 389 -> 389, port 445 -> 445).

    Si votre Firewall fait du filtrage applicatif, assurez-vous aussi qu'il n'interfère pas dans ces échanges (filtrage SSL par exemple).


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    Les protocoles/ports dont vous parlez c'est au niveau du pare-feu windows 'serveur et poste'?

    et la redirection de manière symétrique se joue au niveau du firewall (équipement sur le réseau) dont on a configuré le NAT ?

    Besoin éclaircissement @Sylvain.

    Merci. 


    hussein demo

    mardi 10 septembre 2019 11:54
  • Il faut vérifier la communication complète : :

    [poste] ----> [Firewall/Routeur NAT ]  ----> [Serveur]

    Le pare-feu des postes doit laisser ces ports autorisés en sortie vers l'IP du serveur

    Le pare-feu du serveur doit laisser ces ports autorisés en entrée depuis les IP des postes

    Le "Firewall/routeur NAT" (l'équipement qui interconnecte le LAN des postes avec votre 2nde salle), soit autoriser l'accès des postes au serveur sur les ports en question.

    Le "Firewall/routeur NAT" doit rediriger les ports en question depuis l'interface où sont connectés les postes, vers l'interface où est connecté le serveur.

    Mais là, on est sur des compétences réseau, plus vraiment du Windows...


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    • Marqué comme réponse Hussein demo mardi 10 septembre 2019 15:22
    mardi 10 septembre 2019 12:01
  • Il faut vérifier la communication complète : :

    [poste] ----> [Firewall/Routeur NAT ]  ----> [Serveur]

    Le pare-feu des postes doit laisser ces ports autorisés en sortie vers l'IP du serveur

    Le pare-feu du serveur doit laisser ces ports autorisés en entrée depuis les IP des postes

    Le "Firewall/routeur NAT" (l'équipement qui interconnecte le LAN des postes avec votre 2nde salle), soit autoriser l'accès des postes au serveur sur les ports en question.

    Le "Firewall/routeur NAT" doit rediriger les ports en question depuis l'interface où sont connectés les postes, vers l'interface où est connecté le serveur.

    Mais là, on est sur des compétences réseau, plus vraiment du Windows...


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    Merci infiniment @Sylvain j'ai reussi avec ton aide. 

    hussein demo

    mardi 10 septembre 2019 15:20
  • Bonjour @Sylvain Je te reviens par rapport à ce sujet, j’avais pu faire fonctionner mon DNS grâce à tes directives quand bien même que c’est une architecture non conseiller par Microsoft. Je reviens une nième fois pour un souci concernant la réplication ; mon DC principal se réplique sans problème sur mes secondaires tandis que mes secondaires ne se répliquent pas sur mon principal donc j’ai une réplication unilatérale ce qui est bizarre. Au niveau de NTDS setting : pas de connexion (généré automatiquement) du coté DC principal de mes serveurs secondaires. En forçant la réplication j’ai une erreur DNS. Mais l’inverse marche correctement. Est-ce à cause de mon architecture que j’ai ce problème ou y a t-il quelque chose à revoir dans mes configurations ? Merci.

    hussein demo

    jeudi 19 septembre 2019 21:34
  • Bonjour,

    Là, on a un gros problème : alors que faire communiquer des postes de travail vers un DC NATté n'est pas recommandé, mais faisable, répliquer des contrôleurs de domaine au travers d'un NAT... ?!?

    Vous devriez arrêter immédiatement cette infrastructure réseau et passer sur un routage propre.

    En effet, si les postes vont bien tolérer le fait qu'une requête DNS retourne 2 plans d'adressage IP, cela va se gérer relativement correctement. Par contre, pour la réplication (et même s'il y a toujours des solutions), vous allez au devant de problèmes.

    Explication :

    • Pour se répliquer, les DC se basent sur la résolution DNS
    • Le DC1 (par exemple en 192.168.1.x) va demander l'IP du DC2 : il va recevoir comme réponse 192.168.3.x (IP réelle) et 192.168.4.x (IP NATtée) : 50% de chances pour qu'il essaye de contacter 192.168.3.x et qu'il n'y arrive pas puisqu'il ne peut joindre que l'IP NATTée.
    • Résultat : échec de réplication

    Solution (la seule et unique bonne solution, propre, et fonctionnelle avec tous les rôles serveur) :

    • Mettre en place une communication routée entre vos 2 salles, et abandonner le NAT
    • - OU - Mettre en place une communication niveau 2 entre vos 2 salles, et abandonner le NAT.

    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    WWW : http://snsv.consulting | Blog : http://sylvaincoudeville.fr

    "Aléatoire" et "Mystérieux" sont des qualificatifs inventés par l'Homme pour éviter de dire qu'il n'a pas trouvé la root cause du problème...

    vendredi 20 septembre 2019 06:09
  • Merci @Sylvain pour tes éclaircissements

    hussein demo

    vendredi 20 septembre 2019 06:35