Tandis que la « forêt » perdure systématiquement en tant qu’entité globale, en interne, votre forêt Windows peut être tout à fait malléable au fil du temps. De nouveaux domaines, DC, sites et liens de site peuvent être créés et supprimés dans le cadre de tests, de
Domaines, DC, sites et liens de site orphelins
démonstrations, de projets spéciaux ou pour d’autres raisons. Par conséquent, toutes les forêts Windows, à moins de bénéficier d’une gestion hors pair, sont émaillées d’objets orphelins.
Les domaines et contrôleurs de domaine constituent l’exemple le plus évident de ce type de situation, car les informaticiens bien intentionnés connectent des domaines de test ou d’évaluation au domaine de production. Même si le fait de conserver ces domaines ne provoque généralement pas de défaillances douloureuses, leur présence en tant qu’orphelins peut saturer le journal des événements (Event Log) avec des erreurs inutiles et compliquer la mise hors service de domaines. Si vous avez des domaines et contrôleurs de domaine orphelins dans votre forêt, envisagez de les supprimer par l’utilisation combinée de NTDSUTIL, d’ADSIEDIT (nécessaire pour les forêts très anciennes) et de la console de gestionnaire DNS.
Les objets orphelins les plus insidieux sont les sites supplémentaires et les liens de sites. A mesure que l’entreprise se développe, de nouveaux sites sont aussi ajoutés fréquemment dans la console Sites et services Active Directory (Active Directory Sites and Services). Le problème de ces ajouts manuels tient au fait qu’ils ne sont pas toujours supprimés systématiquement lors de la mise hors service de sites supplémentaires.
Les liens de sites créés manuellement peuvent aussi poser problème. Ces liens ont généralement été créés pour une des deux raisons suivantes : premièrement, des informaticiens bien intentionnés les ont créés il y a longtemps et ont ensuite oublié qu’ils n’étaient plus pertinents à mesure que la structure de sites a évolué. Ces liens doivent maintenant être réévalués et, si possible, supprimés.
La deuxième raison est liée à une limitation de longue date du vérificateur de cohérence des données (KCC, Knowledge Consistency Checker) d’AD, un service qui crée et gère automatiquement les liens de sites. Par le passé, KCC rencontrait des problèmes dès que le nombre de sites dépassait un certain seuil, d’où la nécessité pour les structures AD plus volumineuses de créer et gérer manuellement la structure de liens de sites. Même si cet ancien problème a été résolu, de nombreux domaines continuent aujourd’hui de fonctionner avec des liens de sites créés manuellement. Ces liens peuvent compliquer l’administration automatisée de KCC et engendrer des échecs de réplication ou d’autres erreurs difficiles à résoudre. Nombre de ses connexions manuelles sont des vestiges de l’époque ou des MCSE fraîchement émoulus éprouvaient le besoin de mettre à profit leurs nouvelles compétences en « personnalisant » les domaines. Si vous rencontrez une de ses situations avec votre domaine, envisagez d’examiner encore une fois les paramètres de sites, afin de vérifier qu’ils sont à jour par rapport à la structure actuelle de l’entreprise.
Téléchargez cette ressource

État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.