Mise en place d'un environnement d'intégration Active Directory
Pourquoi un environnement d’intégration ?
L'utilisation d'un environnement d'intégration est intéressant, voir indispensable pour de nombreuses opérations impliquant des modifications importantes de l'environnement Active Directory.
Certains de ces changements nécessitent d'être testés avant d'être déployés. Je pense, entre autre, à la mise en place de stratégie de groupe modifiant la sécurité (modification des stratégies de mot de passe, activation du SMB Signing,...) ou le réseau (mise en place d'IPSec, configuration de ports statique pour la réplication, ...)
D'autres modifications impactant directement l'Active Directory doivent être faite avec précaution en raison des risques qu'elles comportent. En particulier les extensions de schéma qui, si elles se déroulent mal, imposent la reconstruction de la forêt.
L'utilisation d'un environnement d'intégration permet plusieurs choses. Elle garantie l'absence d'impact sur l'environnement de production, donc d'indisponibilité. De plus, étant donné qu'il n'y a pas d'impératif de reprise d'activité, cela laisse le temps de mener les investigations pour déterminer l'origine exacte du problème et donc de le résoudre.
Comment construire son environnement d’intégration ?
Il y a deux méthodes permettant de construire un environnement d'intégration. Elles ont chacune leurs avantages et leurs inconvénients.
La première consiste à construire une nouvelle forêt avec le même contenu, la seconde à dupliquer la forêt existante. Bien entendue chacune de ces solutions peuvent exploiter la virtualisation de serveurs. Il faut cependant garder à l'esprit les recommandations concernant la virtualisation de contrôleurs de domaine.
(Voir l'article technique 888794 - Considerations when hosting Active Directory domain controller in virtual hosting environments)
Recommandations générales
En raison de la présence de doublons de noms Netbios (sur le nom de domaine, et éventuellement sur des noms de serveurs et/ou de station), il est recommandé d'utiliser deux réseaux différents pour isoler les deux environnements.
L'autre point, valable pour les deux solutions, est la pérennité de cet environnement. A moyen-long terme, il va forcément diverger de l'environnement de production. Il sera nécessaire, avant des tests d'opération sensible, de reconstruire l'environnement pour s'assurer qu'il est aussi proche que possible de la production.
Construction d’une nouvelle forêt
Pour éviter au maximum tout risque de confusion, il est intéressant de créer la forêt et les domaines avec une arborescence de nommage différent (nom DNS et Netbios). Cela permet de dissocier clairement les deux environnements et si les deux environnements venaient à être connectés, cela éviterait les problèmes de doublons de nom netbios. Cet environnement doit être créé par la même méthode que celui de production. Cela signifie même chemin d’installation (upgrade de 2000 à 2003 par exemple), et même ordre d’extension du schéma (pour reprendre les dépendances ou conflits d'attributs et de classes).
Une fois la structure de domaine créé, il faut importer les données. Les utilisateurs, ordinateurs, et groupes par un outil de migration (ADMT par exemple). Les GPOs peuvent être importées à l'aide de GPMC (via l'interface ou les scripts). La structure des OUs peut être reconstruite via export puis import par ldifde.exe.
Cette solution ne présente aucun risque pour l’environnement de production étant donné qu'il s'agit de domaines distincts. Il ne présente pas de risque de confusion (grace aux noms de domaines et de serveurs distincts). Il nécessite par contre un travail important pour sa mise en place : il faut rejouer l’évolution du domaine puis importer les données depuis l’autre environnement.
Cet environnement ne reflète donc pas exactement l'environnement de production.
Duplication de la forêt existante
Cette solution assure d’avoir une image à l’identique, mais le problème de divergence à partir de ce point existe toujours. Elle nécessite également aussi un travail de mise en place. Mais surtout, il existe un risque d’impact important voire critique sur l’environnement de production en raison de risque de réplication entre ces deux contextes en premier temps, et ensuite à cause des doublons de noms.
Pour construire un nouvel environnement à partir des données du domaine de production,
deux cas sont à envisager : l'utilisation d’un backup si un matériel identique existe, ou l'ajout puis l'isolation d’un DC. Dans les deux cas, il faut faire cette opération pour chacun des domaines de la forêt. Ces deux méthodes peuvent On peut mixer les deux méthodes. Dans ce cas, il faut commencer par ajouter les DCs et attendre la réplication de ces informations avant de faire les sauvegardes.
Utilisation d’une sauvegarde
Les étapes sont les suivantes. Il faut d'abord identifier une machine ayant le même hardware qu’un serveur de la production, ce serveur original doit également être serveur DNS, par contre, il est conseillé qu’il ne soit pas Catalog Global. Sur le serveur cible, installer le même système d'exploitation avec la même langue et le même niveau de service pack. Le laisser en groupe de travail et l’isoler du réseau de production.
Sur le serveur de production, faire une sauvegarde, au minimum de l'état du système. Ensuite restaurer cette image sur le nouveau serveur ne prenant soin de marquer le sysvol autoritaire, comme présenté dans la capture ci-dessous. Enfin, redémarrer le serveur.
![clip_image001[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/BlogFileStorage/blogs_technet/domaineetsecurite/WindowsLiveWriter/MiseenplacedunenvironnementdintgrationAc_CBDA/clip_image001%5B4%5D.jpg)
Ajout puis isolation d'un contrôleur de domaine
Il faut promouvoir une nouvelle machine en tant que contrôleur de domaine supplémentaire dans le domaine existant, ce nouveau DC peut être physique ou virtuel. Il faut ensuite y installer le service DNS afin qu'il récupère les partitions applicatives ForestDnsZones et DomainDnsZones.
Une fois la réplication terminée (et AD et DNS et Sysvol), le serveur doit être isolé (changement de réseau). Il faut ensuite purger le domaine des informations concernant ce serveur retiré.
Nettoyage du domaine de production
Cette opération n’est à faire que si le serveur a été créé par promotion, la méthode sauvegarde puis restauration ne créant pas de serveur mais en clonant un ne nécessite pas de nettoyer l'environnement de production.
Pour cela, il suffit de suivre les informations de l’article suivant pour supprimer toute référence au serveur isolé sur le domaine de production.
216498 - How to remove data in Active Directory after an unsuccessful domain controller demotion
Succinctement, cette opération consiste à
- · Supprimer l’objet NTDS Settings dans la partition configuration référençant le serveur isolé
- · Supprimer l’objet server dans la partition configuration référençant le serveur isolé
- · Supprimer l’objet computer dans la partition domaine référençant le serveur isolé
- · Supprimer les enregistrements DNS et WINS correspondant à ce serveur
Configuration de l’AD isolée
A ce stade, on doit avoir dans un réseau isolé un DC de chacun des domaines, ce serveur doit également être serveur DNS. Le domaine de production ne doit avoir aucune information concernant les serveurs isolés. Enfin les serveurs isolés ne doivent pas être en mesure de communiquer physiquement avec le reste du domaine.
Il faut tout d'abord modifier la configuration réseau des serveurs pour être client DNS d’eux-mêmes et la configuration du service DNS pour mettre à jour les redirecteurs et les délégations. Il faudra probablement aussi vérifier la configuration WINS.
Il faut enfin, sur ces serveurs, retirer toutes les références aux autres contrôleurs des domaines qui n'ont pas été isolés. Cela correspond à, dans la partition configuration, les Objets NTDS Settings et objets Servers, et dans les partitions domaines, les objets computers
Ces opérations de nettoyage sont décrites toujours dans le même article technique.
216498 - How to remove data in Active Directory after an unsuccessful domain controller demotion
Elles doivent être faites pour tous les DCs de la forêt excepté ceux isolés. Elles vont provoquer en même temps le transfert des rôles FSMO. Il est possible de transférer le rôle à l’avance via ntdsutl / roles / seize …, comme décrit dans l'article
255504 - Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller
A l'issue, il faut redémarrer le ou les serveurs isolés, puis activer le rôle Global Catalog sur au moins un serveur. Si un ou plusieurs des serveurs étaient Global Catalog, il faudra lui retirer le rôle puis le réactiver, pour s'assurer qu'il ne contient bien que des objets également présent sur les DCs isolés. Enfin vérifier la réplication des partitions entre les contrôleurs de domaine et la configuration du domaine et du réseau
Pour prévenir toute réplication entre l’environnement de test et de production, qui aurait un impact dramatique, il faut rendre impossible les authentifications entre les deux contextes. Pour cela, il faut réinitialiser 2 fois les mots de passe des comptes utiliser pour les authentifications entres DCs (le mot de passe du compte Krbtgt, des comptes machines, et de la relation d’approbation). Le détail de ces opérations se trouve dans le document
Best Practice Recommendation for Recovering your Active Directory Forest
En bref, modifier 2 fois le mot de passe du compte machine du serveur. Ce mot de passe est utilisé pour encrypter les TGS pour les SPNs que le compte machine publie
netdom resetpwd /server:<PDC> /userD:<administrator> /passwordD:*
Modifier 2 fois le mot de passe du compte KRBTGT. Ce mot de passe est utilisé pour encrypter les TGTs du domaine
Dans la console Active Directory Users and Computers , menu View / advanced features, clic-droit sur le compte désactivé KrbTgt dans le containeur user puis reset password.
Modifier le mot de passe des relations d’approbation, Implicites et explicites. Cette opération n‘est à faire qu’une seule fois
Sur le domaine parent
netdom trust <domaine parent> /domain:<domaine enfant> /resetOneSide /passwordT:example
/userO:administrator /passwordO:*
Sur le domaine enfant
netdom trust <domaine enfant> /domain:<domaine parent> /resetOneSide /passwordT:example
/userO:administrator /passwordO:*
Si de nouveaux DCs sont ajoutés, ils obtiendront les nouveaux mots de passe par réplication lors de leur promotion et pourront communiquer avec tout l'environnement isolé. Par sécurité, conservez tout de même les deux environnements isolés.
Liens utiles
Active Directory Migration Tool v3
ADMT v3 Migration Guide
Download Active Directory Migration Tool v3.0
Active Directory Migration Tool v3.1
Migrating and Restructuring Active Directory Domains Using ADMT v3.1
Download Active Directory Migration Tool version 3.1
Group Policy Management Console
Enterprise Management with the Group Policy Management Console
Download the GPMC with Service Pack 1 (SP1)
237677 - Using LDIFDE to import and export directory objects to Active Directory
139822 - How to Restore a Backup to Computer with Different Hardware
216498 - How to remove data in Active Directory after an unsuccessful domain controller demotion
Best Practice Recommendation for Recovering your Active Directory Forest
Running Domain Controllers in Virtual Server 2005
Cyrille de Pardieu
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Mots clés Technorati : Active Directory,Replication
Comments
- Anonymous
January 01, 2003
Cet article ne me semble pas insister suffisamment sur les risque d'un croisement des deux réseaux. La modification des mots de passe des DC n'est pas une solution pertinente. En effet pour effectuer cette opération les DC se doivent d'être en ligne. Si les DC des deux environnements se croisent ce sera comme vous le dite par ailleurs dramatique. En effet cela conduit à des USNRollback qu ne sont pas réglables aujourd'hui dans Windows sans exclure les DC impactés. Je vous suggère de remplacer dans les Recommandations Générales la phrase : " il est recommandé d'utiliser deux réseaux différents pour isoler les deux environnements" par " Vous devez prendre toutes les précautions pour que les deux réseaux ne se rencontre jamais en assurant un isolement physique total". Changer les mots de passes des DC et à mon avis, comme je vous le disais précédemment, une fausse solution puisque soit les DC ne sont pas connectés sur le même réseau et cette opération n'a alors pas de sens, soit ils le sont et le temps de faire cette opération on à tout corrompu. Votre article à quand même le mérite d'ouvrir le débat sur des problématiques qui restent largement ouvertes; mais il ne faudrait pas qu'il pose plus de problème qu'il ne se propose d'en régler.