locked
AD/DNS dans environnement NAT RRS feed

  • Discussion générale

  • Bonjour à tous,

     

    Je sollicite la communauté sur un point d'architecture un peu délicat. Mon client désire effectuer un changement d'infrastructure réseau au sein de son entreprise et nous sollicite pour valider la partie système.

    Aujourd'hui, l'ensemble de son réseau est sur un plan d'adressage totalement privé en 10.x.x.x.

    Deux Datacenters hébergent les serveurs d'infrastructure type Contrôleurs de Domaine, DNS, Messagerie, Intranet, etc...

    Un site siège et 58 sites distants, de petite taille. Les sites distants hebergent chacun un serveur membre utilisé pour le DHCP, partage fichier... Les utilisateurs sur ces sites distants s'authentifient sur les DC aux Datacenters. Le siège, les Datacenters et les sites distants sont interconnectés par un réseau MPLS.

    Jusque là tout va bien, ca roule.

     

    Mais voila, faisant parti d'un grand groupe et on lui propose de bénéficier du nuage WAN du groupe pour interconnecter les sites distants aux Datacenters pour de multiple raisons (couts, vitesse, securité...). Or la condition est de changer le plan d'adressage des sites distants avec des adresses "publiques" réservée en 126.x.x.x (je ne connais pas exactement le nouveau plan). Les Datacenters resteront dans l'ancien plan d'adressage privé; NAT sera alors implémenté par des firewalls reliant les Datacenters au nouveau réseau WAN. Ces Firewalls maintiendront la table de translation, traduisant les adresses dites 'externes' (126.x.x.x) en adresses privés (10.x.x.x) afin que les serveurs hébergés aux Datacenters restent accessibles depuis les sites distants par l'intermédiaire de leurs adresses externes, le réseau 10.x.x.x devenant inconnu aux sites distants.

     

    Notre problèmatique, concernant le système, n'est pas sur les applications type web (intranet) ou Telnet car le NAT n'empechera pas l'accès à ces services; mais la problèmatique est dans l'infrastructure AD/DNS. Les serveurs DNS étant hébergé au Datacenters, un site distant effectuant une requete DNS, obtiendra une réponse indiquant une adresse privée (10.x.x.x) au lien de son equivalent NATé. Certains firewall type Cisco ou apparement Checkpoint semble disposer de mecanisme de translation DNS type DNS Doctoring, or j'aimerais pouvoir etre sure de ce type d'infrastucture dans un environnement Active Directory.

    Existe t-il un autre moyen pour natter les réponses DNS ?

    De plus, comment kerberos va t-il réagir à travers du NAT ? Est ce que les clients sur les sites distants vont-ils pouvoir s'authentifier en utilisant les adresses NAT (externes) des contrôleurs de domaine situés au sein des Datacenters ? je ne trouve aucune information sur le sujet à ce jour.

     

    Pour info, nous avons envisagé de recommander l'installation de Firewalls sur l'ensemble des sites distants permettant d'effectuer un NAT inverse et ainsi maintenir le plan d'adresse privé sur les sites distants et résoudre tous nos problèmes, n'ayant pas à toucher à l'infra système actuelle. Mais ceci est à exclur en raison du cout trop important d'installation de 58 FW !

     

    Qu'en pensez vous ? Est ce que quelqu'un a déjà validé une solution AD similaire dans un environnement NAT ? quels sont vos suggestions ?

     

    merci d'avance.

    jeudi 24 avril 2008 13:00

Toutes les réponses

  • Bonjour Anthony
    nous avons exactement la meme problematique.
    Aurais tu trouvé une solution ?
    Dans l'attente de ta réponse.

    Cordialement

    Didier Lourenco
    mercredi 11 février 2009 09:06
  •  

    Bonjour,

    il s'agit d'un cas intéressant qui mérite réflexion.
    Je dirai que pour le DNS, la configuration standard est un DNS interne qui forward les requêtes vers
    un DNS externe (requête NATée). Pour une requête directe par NAT tu as besoin d'un procédé type
    DNS Doctoring.

    Quant à kerberos, tu peux désactiver dans le ticket client (Ticket granting ticket TGT) l'utilisation
    de l'adresse IP source pour l'authentifcation. Tu peux le fairee sur le KDC.
    Une explication du (vraie) Kerberos ici :
    http://www.stanford.edu/services/kerberos/sysadmin/firewalls.html

    Ce sont des pistes à creuser...


    Joël
    mercredi 11 février 2009 17:16