Conseils sur la conception d'Active Directory pour les serveurs multi-hôtes

J'ai été chargé par un client de proposer une conception Active Directory fonctionnelle pour un scénario avec les exigences suivantes (simplifiées, elles sont en fait bien pires):

• Il existe un sous-réseau pour les systèmes clients.
• Il existe un sous-réseau pour les systèmes de serveurs.
• Les deux réseaux ne sont pas connectés.
• Chaque serveur doit avoir deux cartes réseau, une sur le réseau des serveurs, l'autre sur le réseau des clients.
• Le trafic entre les clients et les serveurs ne doit circuler que sur le réseau des clients.
• Le trafic entre les serveurs ne doit circuler que sur le réseau des serveurs.
• Cela devrait également s'appliquer aux contrôleurs de domaine.

Inutile de dire que cela ne va pas très bien avec la façon dont Active Directory utilise DNS pour localiser les contrôleurs de domaine; toute approche possible conduirait à l'un des scénarios suivants:

• Les contrôleurs de domaine enregistrent leur adresse IP "côté client" dans le DNS du domaine; les clients parleront avec eux à l'aide de cette adresse, mais il en sera de même pour les serveurs et le trafic de réplication AD.
• Les contrôleurs de domaine enregistrent leur adresse IP "côté serveur" dans le DNS du domaine; les serveurs parleront avec eux en utilisant cette adresse et le trafic de réplication circulera sur ce réseau, mais les clients ne pourront pas les atteindre.
• Les contrôleurs de domaine enregistreront les deux adresses IP dans le DNS du domaine; c'est à quiconque de deviner ce que tout système fera pour les atteindre.

Bien sûr, ces exigences sont complètement folles et elles ne peuvent pas toutes être satisfaites en même temps, à moins d'utiliser des solutions folles comme le fractionnement du service DNS sur les deux réseaux et le remplissage manuel de ses enregistrements SRV (argh) ou la localisation des serveurs Les contrôleurs de domaine utilisant DNS et les clients localisent les contrôleurs de domaine utilisant WINS (double-argh).

La solution que j'ai trouvée consiste à avoir deux contrôleurs de domaine sur le réseau "serveurs" et deux contrôleurs de domaine sur celui "clients", définissant deux sites AD et franchissant la frontière entre les deux réseaux uniquement avec du trafic de réplication DC. Cela nécessitera toujours quelques modifications DNS, car chaque serveur aura toujours deux cartes réseau (à l'exception des deux contrôleurs de domaine côté serveur et des serveurs purement back-end), mais il a au moins quelques chances de fonctionner.

Un conseil, à part fuir le plus vite possible?

Permettez-moi de commencer par dire que je suis d'accord avec la plupart des autres - soit convaincre le client du contraire, soit fuir.

Cependant, compte tenu de vos exigences répertoriées (il y en a beaucoup non répertoriées), je peux penser (et partiellement testé) au moins au travail préparatoire pour y arriver.

Plusieurs aspects spécifiques doivent être pris en compte.

1. Réplication des services de domaine Active Directory
2. Processus de localisation DC des clients / serveurs membres
3. Résolution de noms et trafic pour les services non AD DS

Un et deux ont beaucoup en commun - en général, nous sommes au gré de Microsoft sur celui-ci et devons travailler dans les limites des processus AD DS de Microsoft.

Troisièmement, nous avons un peu d'espace pour travailler. Nous pouvons choisir les labels utilisés pour accéder aux services (fichiers, instances de base de données, etc.).

Voici ce que je propose:

Créez vos contrôleurs de domaine (DC)

• Probablement au moins deux.
• Chaque contrôleur de domaine aura deux cartes réseau, une dans chaque réseau IP / site AD DS - les appelant clt et srv pour l'instant.
• Seulement configurer une carte réseau dans chaque DC en ce moment dans le réseau srv.

Configurer correctement les sites et services AD

• site et sous-réseau srv
• site clt et sous-réseau
• décochez "Pont tous les liens de sites" dans Sites -> Transports intersites -> Cliquez avec le bouton droit sur "IP"
• supprimez le DEFAULTIPSITELINK s'il existe (ou si vous l'avez renommé) afin qu'aucun lien de site ne soit configuré. Notez que c'est l'inconnu pour moi - KCC déversera probablement des erreurs dans le journal des événements du service d'annuaire en disant que les deux sites (srv et clt) ne sont pas connectés à des intervalles variables. Cependant, la réplication se poursuivra entre les deux contrôleurs de domaine car ils peuvent se contacter en utilisant les adresses IP du même site.

Configurer une zone supplémentaire dans AD DS Integrated DNS

• Si votre domaine AD DS est acme.local , créez une deuxième zone intégrée AD principale avec les mises à jour dynamiques activées, appelée clt.acme.local .

Configurez le deuxième NIC sur vos DC

• Ces NIC seront les NIC du réseau / site clt.
• Définissez leurs IP
• Voici la partie magique - Propriétés de l'adaptateur -> Propriétés IPv4 -> Avancé -> Onglet DNS -> Définissez le suffixe DNS pour cette connexion sur clt.acme.local -> cochez Enregistrer cette connexion ... -> Cochez Utiliser cette connexion Suffixe DNS ... -> OK tout au long.
• ipconfig / registerdns
• Ceci enregistrera l'IP clt NIC dans la zone clt.acme.local - fournissant une méthode pour nous de contrôler quel IP / réseau est utilisé plus tard.

Configurer les NIC des serveurs membres

• Les cartes réseau des serveurs membres dans le site clt doivent avoir leur suffixe DNS et leurs cases à cocher définies en conséquence, comme ci-dessus.
• Ces paramètres peuvent être utilisés avec statique et DHCP, peu importe.

Configurer le comportement du résolveur DNS [stub] dans les sites

• DC -> Configurer la carte réseau srv DC pour utiliser elle-même et d'autres IP NIC srv DC. Laissez DC clt NIC DNS vide (une adresse IP statique est cependant nécessaire). (Le serveur DNS DC écoutera toujours toutes les adresses IP par défaut).
• Serveurs membres -> Configurer la carte réseau srv du serveur membre pour utiliser les IP du site srv DC. Laissez le serveur membre clt NIC DNS vide (une adresse IP statique peut être utilisée).
• Clients / Stations de travail -> Configurer DNS (via DHCP ou statique) pour utiliser les IP NIC clt du DC.

Configurer les mappages / ressources de manière appropriée

• Lorsque les serveurs se parlent, assurez-vous d'utiliser .acme.local -> se résoudra en IP réseau srv.
• Lorsque les clients parlent aux serveurs, assurez-vous d'utiliser .clt.acme.local -> se résoudra en IP réseau clt.

De quoi je parle?

• La réplication AD DS se produira toujours car les contrôleurs de domaine peuvent se résoudre les uns les autres et se connecter les uns aux autres. La zone acme.local et _msdcs.acme.local ne contiendra que la réplication AD DS du DC srv NIC IP uniquement sur le réseau srv.
• Le processus de localisation DC pour les serveurs membres et les postes de travail fonctionnera - bien qu'il existe la possibilité de retards dans diverses parties des différents processus AD DS lorsque le site est inconnu, si plusieurs adresses IP DC sont retournées - elles seront essayées, échouées et passeront à autre chose jusqu'à ce qu'on travaille. Les effets sur DFS-N n'ont pas non plus été complètement évalués - mais continueront de fonctionner.
• Les services non AD DS fonctionneront correctement si vous utilisez les étiquettes .acme.local et .clt.acme.local susmentionnées, comme décrit.

Je n'ai pas complètement testé cela car c'est plutôt ridicule. Cependant, le point de cette réponse (wow, longue) est de commencer à évaluer si c'est possible ou non - pas si cela devrait être fait.

@Commentaires

@Massimo 1/2 Ne confondez pas plusieurs sites AD DS dans la zone acme.local, et donc les enregistrements SRV remplis par les contrôleurs de domaine dans ces sites dans la zone acme.local avec le besoin d'enregistrements SRV dans la zone clt.acme.local. Le suffixe DNS principal du client (et le domaine Windows auquel ils sont joints) sera toujours acme.local. Les postes clients / postes de travail n'ont qu'une seule carte réseau, le suffixe DNS principal dérivant probablement du DHCP, défini sur acme.local.

La zone clt.acme.local n'a pas besoin d'enregistrements SRV car elle ne sera pas utilisée dans le processus de localisation DC. Il est uniquement utilisé par les clients / postes de travail pour se connecter aux services non AD DS du serveur membre en utilisant les adresses IP du serveur membre dans le réseau clt. Les processus liés à AD DS (localisateur DC) n'utiliseront pas la zone clt.acme.local, mais les sites AD DS (et les sous-réseaux) dans la zone acme.local.

@Massimo 3

Il y aura des enregistrements SRV pour les sites AD DS clt et srv - juste qu'ils existeront dans la zone acme.local - voir la note ci-dessus. La zone clt.acme.local n'a pas besoin d'enregistrements SRV liés à DC.

Les clients pourront localiser une amende DC. Les serveurs DNS clients pointent vers les IP clt des contrôleurs de domaine.

Lorsque le processus de localisation DC sur le client démarre

• Si le client connaît son site, la question DNS sera _ldap._tcp. [Site] ._ sites.dc._msdcs.acme.local SRV. Cela retournera les DC spécifiques au site qui ont des enregistrements SRV enregistrés.
• Si le client ne connaît pas son site, la question DNS sera _ldap._tcp.dc._msdcs.acme.local SRV. Cela retournera tous les DC. Le client tentera de se lier au LDAP de DC jusqu'à ce qu'il en trouve un qui réponde. Lorsque le client en trouve un, il effectue une recherche de site pour déterminer le site du client et met le site en cache dans le registre afin que les futures instances du localisateur de DC se produisent plus rapidement.

@Massimo 4

Ugh, belle prise. D'après moi, il y a deux façons de contourner ce problème.

1. L'impact moindre (par rapport à 2 ci-dessous) est de créer une entrée dans le fichier hosts sur les clients / postes de travail pour dc1.acme.local et dc2.acme.local pointant vers les IP NIC clt des contrôleurs de domaine.

ou

2. Créez manuellement les enregistrements SRV nécessaires dans le fichier netlogon.dns sur chacun des contrôleurs de domaine. Cela aura probablement des conséquences sur le réseau du serveur. Les serveurs membres peuvent parfois communiquer avec les contrôleurs de domaine sur le réseau clt si celui-ci est configuré.

Dans l'ensemble, rien de tout cela n'est joli, mais ce n'est pas nécessairement l'objectif final. Peut-être que le client teste simplement vos côtelettes techniques. Placez-le sur leur table de conférence et dites-leur: "Ici, cela fonctionnera, mais je vous facture 4x mon tarif normal pour le configurer et le prendre en charge. Vous pouvez le réduire à 1,5 fois mon tarif normal - .5x charge PITA, en faisant [bonne solution]. "

Comme indiqué précédemment, ma recommandation est de convaincre du contraire ou de fuir. Mais c'est sûr un petit exercice amusant et ridicule. :)

Au final, j'ai opté pour la solution des deux sites:

• Deux DC pour le réseau "serveurs", deux DC pour le réseau "clients".
• Deux sites AD, un pour les réseaux "serveurs" et un pour les "clients".
• Les contrôleurs de domaine dans le réseau de "serveurs" n'auront qu'une carte réseau sur celle-ci (les clients ne vont pas leur parler du tout), donc c'est facile.
• Les contrôleurs de domaine dans la zone "clients" en auront deux, mais n'enregistreront dans le DNS que ceux côté client.
• Les serveurs parleront à leurs contrôleurs de domaine, les clients parleront aux leurs.

Bien sûr, cela signifie activer le trafic de réplication entre les deux réseaux; les contrôleurs de domaine dans le réseau "clients" auront toujours une carte réseau sur le réseau "serveurs", mais comme elle ne sera pas enregistrée dans le DNS, les contrôleurs de domaine dans ce réseau les contacteront en utilisant leurs adresses IP côté client; de sorte que la carte réseau sera en fait complètement inutile et que certains ports du pare-feu devront être ouverts. La seule autre option serait de falsifier les hostsfichiers des contrôleurs de domaine , mais espérons que cela puisse être évité.

Eh bien, je pense que c'est le mieux qui puisse être fait pour satisfaire autant d'exigences (folles) que possible.

Merci pour tous les conseils :-)

Tout d'abord, lorsque nous fournissons des services à nos clients, nous devons nous interroger sur leurs besoins. Permettre au client de comprendre que leur niveau de complexité n'est pas nécessaire.

• Quel était le nombre de clients?
• C'est tout le trafic interne?
• Quel est le niveau fonctionnel des domaines?
• Le protocole TLS est-il utilisé?

Utiliser la méthode KISS - Serait la création de deux VLAN "SVR" et "CLT" permettant SSL / TLS et l'appelant un jour ....