Dans certaines situations, il peut être souhaitable de masquer un contrôleur de domaine Active Directory (un DC pour « Domain Controller » en anglais).
L’idée est d‘empêcher les clients de le découvrir et ou de s’y inscrire dynamiquement.
C’est le cas typiquement dans le cadre d’une suppression définitive d’un DC. Il faut, par exemple, avant tout s’assurer qu’il n’y ait aucune adhérence entre le DC et certaines applications. Ces dernières peuvent être tout simplement mal configurées.
Donc, le fait de masquer un contrôleur de domaine permet facilement l’analyse et l’aide à la décision. Les éventuels trafics réseaux sont facilement identifiable dès lors que le DC est isolé.
Bref, le concept est pratique et applicable afin d’apporter des réponses à différents scenarii, à condition toutefois d’être rigoureux.
Les scenarii possibles
Ils sont divers :
- Déploiement,
- Suppression,
- Qualification,
- Campagne de patchs,
- PCA ou PSI avec l’idée de centrer de façon nominale les requêtes clientes Active Directory durant la production normale.
Cas concret et notre REX
La dernière situation, en date qui nous était exposée, concernait justement ce besoin d’un contrôleur de domaine sur un site de secours.
Notre compréhension était que ce contrôleur de domaine devait être opérationnel et fonctionnel, mais décorrélé des clients Active Directory en production.
En définitive, l’objectif était ainsi d’éliminer les adhérences avec la production tout en fournissant des services Active Directory cohérents aux équipements techniques logés sur le site de secours.
Il est quelque part question de masquer un contrôleur de domaine, mais dit-on : « … Un expert, c’est une opinion. Deux experts, c’est la contradiction. Trois experts, c’est la confusion … » 😊
Les débats d’experts
C’est toujours drôle quand les experts ne sont pas d’accords entre eux, surtout quand la raison n’est pas technique.
Il y a ceux qui suggèrent des vm Active Directory dormantes. En somme, l’idée est de restaurer cycliquement un contrôleur de domaine, tout en l’isolant au sens niveau 3 OSI. La production est donc copiée partiellement sur un site de secours isolé du reste.
De notre fenêtre, la restauration sur un site de secours vaut PRA. C’est purement et simplement de l’amateurisme selon nous 😂👌
Ce n’est pas sécuritaire et une telle approche ne rime à rien. En fin de compte, à part se tirer une balle dans le pied, nous n’y trouvons aucun intérêt pour personne ! De surcroît, nous trouvons cette approche des autres experts complètement débile.
Pourquoi ? Parce que restaurer un contrôleur de domaine nécessite un nettoyage en profondeur des objets stratégiques au sein de l’annuaire. Dans un environnement avec une plateforme Exchange, la reprise n’est pas possible non plus si l’Active Directory est soumis à un lag. C’est le cas dans ce scenario des autres experts.
D’autres experts prennent le relais et suggèrent alors qu’en cas de PRA on bascule tout vers Exchange online 😲🙈
Vouloir mener une transformation durant son PRA est juste une folie. Du jamais vu pour nous !
Quoi qu’il en soit, ces scenarii des autres experts sont de l’ordre du bullshit pour nous.
Toute action dans une infrastructure informatique nécessite une bonne connaissance des technologies, une vue globale et une bonne stratégie.
Pour nous, en tant qu’experts et porteurs du socle Active Directory, le seul moyen viable et élégant de gérer cette situation consiste à masquer un contrôleur de domaine situé sur le site de secours.
L’état de l’art pour masquer un contrôleur de domaine
La bonne façon de parvenir à masquer un contrôleur de domaine, il n’y en a pas trente-six, consiste à l’isoler logiquement. Cette isolation se fait à l’aide d’un site logique Active Directory sur lequel des contraintes par GPo sont appliquées.
Aucune action au niveau de la couche réseau (niveau 3 OSI) n’est nécessaire. Il n’y a aucun bidouillage pour être transparent.
Autrement, il est logique de ne pas couper la communication entre un site nominal et celui de secours.
La GPo consiste clairement à ne plus autoriser les enregistrements DNS dynamiques du contrôleur de domaine que nous souhaitons isoler. Il ne doit pas annoncer les services qu’il fournit.
Techniquement, il faut aller pour cela dans : Computer Configuration > Policies > Administrative Templates > System > Net Logon > DC Locator DNS Records et éditer l’entrée intitulée « Specify DC Locator DNS records not registered by the DCs »
En activant ce paramètre, vous pouvez définir exactement quels enregistrements DNS DC Locator ne devront plus être enregistrés par le service netnogon dans le DNS.
Une inhibition totale s’appuie sur les instructions suivantes : LdapIpAddress, Ldap, LdapAtSite, Pdc, Gc, GcAtSite, DcByGuid, GcIpAddress, Kdc, KdcAtSite, Dc, DcAtSite, Rfc1510Kdc, Rfc1510KdcAtSite, GenericGc, GenericGcAtSite, Rfc1510UdpKdc, Rfc1510Kpwd et Rfc1510UdpKpwd.
Notre recommandation est de maintenir les ’enregistrements A et CNAME (<DsaGuid>._msdcs.<DnsForestName>). Cela permet la réplication nominale du DC.
Autrement-dit, vous pouvez donc spécifier un ensemble d’instructions (des mnémoniques ou mnemonics en anglais) par rapport à l’enregistrement ou non d’un service.
Une fois cette isolation faite, il faut une configuration manuelle des applications pour exploiter les ressources et services fournis pas le DC isolé.
Ce cloisonnement ne remet nullement en cause les échanges entre contrôleurs de domaine, donc les réplications, ou encore les recherches des briques applicatives intégrées telles que la PKI, l’Exchange legacy, la fédération et cætera.
Point d’attention
N’est pas expert Active Directory qui veut.
Active Directory enferme les identités d’une entreprise, il est donc au centre de l’infrastructure informatique. Sa sécurité et les bonnes pratiques priment avant tout.
Nous pensons sérieusement que pour certains « … être experts, c’est tout simplement l’art d’apprendre une science à des vétérans, tout en étant un débutant … ».
Avantage de NEO CONSULT’ IN
Nous avons toujours un avantage jusqu’ici : la vision à 360°. Nous maîtrisons les autres technologies (messagerie, infrastructure, PKI, sécurité et cætera) et continuons de parfaire notre maîtrise de l’Active Directory selon chaque situation qui nous est exposée.
Nos seules règles sont : l’état de l’art, la simplicité et la sécurité.
Pour le reste, rien ne nous impressionne non plus dans les situations où nous sommes les seuls à défendre l’état de l’art.
Synthèse
Une équation bien posée est toujours à moitié résolue, à condition toutefois de bien penser.
La réflexion est toujours de mise et il faut s’interdire toute improvisation lorsqu’il s’agit d’Active Directory.
Donc, masquer un contrôleur de domaine Active Directory se réalise avec une méthode bien particulière et précise. La clé de voûte est le DNS, à bien réfléchir c’est une évidence finalement !
Ce type d’opération ne peut être substitué par des actions superflues, e.g. en manipulant le réseau ou encore en rejouant avec la restauration.