Dans ce tutoriel, on va voir comment supprimer un contrôleur de domaine Active Directory RODC, je ne vais pas rentrer dans le détail du fonctionnement d’un DC RODC ici.
Il y a quelques mois, suite à l’évolution de notre environnement, j’ai du décommissionner notre contrôleur de domaine RODC qui était placé en DMZ à deux fonctionnalités :
- Fournir une liaison LDAP au application en DMZ qui authentifiait les utilisateurs (pas le choix à cause du legacy)
- Serveur DNS pour la zone DMZ et d’autre VLAN « poubelle »
Au fur à mesure des évolutions dans applications dans le SI et la mise en place de nouveau service, ce contrôleur de domaine est devenu « obsolète » et inutile.
Pour la partie authentification, nous privilégions aujourd’hui des méthodes d’authentification modernes, principalement via Authentik ou ADFS, en utilisant OpenID Connect ou SAML selon la compatibilité des applications.
Pour les applications ne supportant pas ces protocoles et reposant encore sur LDAP, nous utilisons Authentik en tant que proxy LDAP. Cette approche est également appliquée aux applications situées sur le réseau LAN, ce qui permet d’éviter les connexions directes vers les contrôleurs de domaine et de renforcer la sécurité tout en centralisant l’authentification.
Pour la partie DNS, elle a été remplacée par une serveur AdGuard Home, qui sert également de serveur DoH pour les ordinateurs de l’entreprise quand ils sont à l’extérieure.
Sommaire
Vérifier l’utilisation du contrôleur de domaine (authentification et DNS)
Afin de pas couper l’accès à des services où rendre un segmenter de réseau (vlan) inutilisable car plus de serveur DNS, il faut anticiper cet arrêt.
La première étape a été de migrer les applications vers Authentik en utilisant le proxy LDAP.
Une fois cette migration effectuée, il est indispensable de vérifier que le contrôleur de domaine n’est plus sollicité pour l’authentification.
Cette vérification s’effectue via l’Observateur d’événements (Journal de sécurité) en filtrant les Event ID suivants :
- 4776 : validation d’identifiants NTLM par le contrôleur de domaine
- 4768 : demande de ticket Kerberos (TGT)
- 4769 : demande de ticket de service Kerberos (TGS)
Il est reste des évènement 4768 qui sont liés au contrôleur de domaine lui même, ce qui est normal.
La seconde étape va être de vérifier le serveur DNS, pour cela, il faut activer le journal de débogage, qui va permettre d’enregistrer les requêtes et d’identifier les ordinateurs qui utilisent ce serveur.
Laisser quelques minutes / heures passées puis vérifier le fichier de logs, sur la capture ci-dessous, on peut voir que le serveur traite toujours des requêtes DNS.
Depuis ces logs, il faut soit aller modifier la configuration IP des cartes réseaux ou modifier les étendues DHCP en fonction de votre configuration.
Cette phase d’observation ne fait pas en 10 minutes, en fonction de la taille de votre environnement compte une semaine à plusieurs mois.
Décommissions du contrôleur de domaine RODC
Avant de décommissionner, le serveur, ce que je vous conseille de faire c’est éteindre celui-ci et laisser passer quelques jours pour voir les éventuels problèmes.
Une fois que vous êtes sur que celui-ci n’est plus utilisé, passer au décommissionnement , le plus simple lancer l’assistant va être de lancer l’assistant de suppression de rôles, accessible depuis le gestionnaire de serveur.
En suivant l’assistant, quand vous allez vouloir valider la désinstallation du rôle Services ADCS, un message d’erreur va s’afficher ou vous pourrez lancer l’assistant de décommissions en cliquant sur Rétrograder le contrôleur de domaine.
Il ne vous reste plus qu’à suivre l’assistant.
Afin de garder un environnement Active Directory propre, il est préférable d’utiliser l’assistant qui va permettre de supprimer les liens du DC dans le domaine.
Conclusion
Vous savez maintenant comment décommissionner un contrôleur de domaine RODC en toute sécurité, en vérifiant en amont son utilisation pour l’authentification et le DNS, puis en procédant proprement à sa suppression dans Active Directory.
De mon côté, ce rôle est devenu largement secondaire, voire inutile en dehors de cas très spécifiques (sites isolés, environnements avec connectivité limitée ou contraintes de sécurité fortes). Aujourd’hui, avec la généralisation des liaisons fibre, des VPN/MPLS et l’essor du cloud (notamment avec Microsoft Azure), le besoin d’un RODC sur les sites distants est beaucoup moins fréquent qu’auparavant.
Par ailleurs, pour sécuriser les flux d’authentification des applications et des équipements périphériques (copieurs, applications legacy, etc.), je privilégie l’utilisation de Authentik en tant que proxy LDAP. Cette approche permet d’éviter les connexions directes vers les contrôleurs de domaine, de centraliser l’authentification et de s’orienter progressivement vers des méthodes d’authentification modernes comme OpenID Connect ou SAML.
Et vous, utilisez-vous encore des contrôleurs de domaine RODC dans votre infrastructure, ou ont-ils également perdu en pertinence avec l’évolution des architectures réseau et cloud ?
