Les services de domaine Active Directory (AD DS) sont devenus un composant central merveilleusement fiable, hautement évolutif et tolérant aux pannes de l'infrastructure informatique de votre entreprise. Il fonctionne généralement très bien sans nécessiter beaucoup d'attention. Mais l'administrateur d'AD DS doit fournir un travail supplémentaire pour faire passer le service d'un niveau de "bon fonctionnement au jour le jour" à un niveau de "fiabilité à toute épreuve lorsqu'une situation inhabituelle se présente". Lorsque cette situation inhabituelle se produit (remarquez que j'ai dit "quand" et non "si"), il existe un certain nombre de mauvaises configurations et de mauvaises pratiques qui exposent votre domaine ou votre forêt AD DS à un risque de perte de données, de défaillance du contrôleur de domaine (DC), voire de défaillance du domaine ou de la forêt. Certains de ces éléments peuvent sembler élémentaires, mais vous seriez étonné de savoir à quel point ils sont courants.
Lecture associée
Vous avez encore des DC Windows Server 2003. Windows Server 2003 était un excellent système d'exploitation en son temps... mais ce temps est révolu. Plus important encore, il s'agit d'un système d'exploitation vulnérable et non corrigeable. Pourquoi faire courir des risques à votre entreprise ? Passez à autre chose !
Tous vos DC et sauvegardes se trouvent sur un seul site physique. De nombreux problèmes peuvent survenir sur un seul site. C'est une bonne chose que vous ayez plus de DC, mais s'ils sont tous dans le même centre de données, votre forêt reste vulnérable à tout ce qui peut détruire ce centre de données. Il en va de même pour les sauvegardes de votre forêt. Il n'y a aucune excuse pour ne pas être préparé à une catastrophe naturelle à évolution lente comme l'ouragan Sandy sur la côte est des États-Unis. Mais j'ai aussi connu des incendies externes à évolution rapide qui ont causé des dommages importants à un centre de données et l'ont au moins rendu indisponible, s'il n'a pas été gravement endommagé. Moralité : recherchez tous les points de vulnérabilité dans votre environnement AD DS.
La corbeille n'est pas activée. Nous, administrateurs, avons tous poussé un soupir de soulagement lorsque la corbeille Active Directory est devenue disponible pour la première fois dans Windows Server 2008 R2. Il a toutefois fallu un certain temps avant que cet utilitaire de restauration d'objets si nécessaire ne soit largement utilisé, car il nécessite un niveau fonctionnel minimal de Windows Server 2008 R2 dans la forêt. Et pour y parvenir, il faut mettre à niveau tous les DC de la forêt à partir de versions plus anciennes, notamment Windows Server 2003. Étant donné qu'un nombre scandaleusement élevé d'organisations n'ont que récemment mis leurs DC Windows Server 2003 au repos bien mérité, beaucoup de ces entreprises n'ont pas non plus activé la corbeille. Vous savez qui vous êtes ; mettez-vous au travail !
Vous ne suivez pas les meilleures pratiques de virtualisation. Si vos DC sont antérieurs à Windows Server 2012, ils ne comprennent pas les environnements virtualisés. En particulier, ils récupèrent mal les restaurations basées sur l'image lorsque la base de données AD a été restaurée à un moment antérieur sans déclencheur. Assurez-vous que vous (et surtout vos administrateurs de virtualisation) suivez les meilleures pratiques de Microsoft pour la virtualisation d'AD DS.
Vous ne surveillez pas régulièrement l'état de santé du DC / DNS. L'une des raisons les plus courantes pour lesquelles Active Directory rencontre des problèmes est que personne n'y prête attention. Si vous êtes une petite organisation, je comprends que vous n'ayez pas les moyens de financer une solution de surveillance étendue (bien qu'il existe d'excellentes solutions gratuites pour les petites et moyennes entreprises, telles que SpiceWorks). Tout ce qu'il faut pour effectuer une surveillance de base est un script programmé qui exécute DCDIAG /s : /E et l'écrit dans un fichier. Consultez-le tous les matins. Si vous rencontrez des erreurs de réplication, par exemple, l'outil gratuit ADREPLSTATUS est là pour vous aider.
Vous exécutez plusieurs rôles sur un DC. L'exécution de plusieurs rôles sur un DC compromet à la fois la sécurité et la capacité de récupération. À l'ère des machines virtuelles faciles à créer, il n'y a aucune raison de ne pas disposer de serveurs dédiés à cette tâche.
Vous ne modifiez jamais les mots de passe de vos comptes de service. C'est un petit secret que la plupart des services informatiques ne veulent pas admettre : les comptes de service de bon nombre de leurs principaux services d'infrastructure n'ont pas été mis à jour depuis des années. Avant Windows Server 2008 R2, changer le mot de passe d'un compte de service signifiait entraîner une indisponibilité du service (par exemple, une base de données SQL Server dans une application commerciale multi-niveaux). Le mot de passe n'était donc jamais modifié. Dans une grande organisation que je connais, le mot de passe du compte de service SMS était connu par au moins trois générations d'administrateurs système ! Cette vulnérabilité a été corrigée, d'abord par les comptes de service gérés (MSA) dans Windows Server 2008 R2, puis par les MSA de groupe dans Windows Server 2012. Avez-vous fait quelque chose à ce sujet ?
Trop d'administrateurs. Voilà qui devrait vous empêcher de dormir. De très nombreuses organisations ont beaucoup trop de comptes administratifs parce que la personne qui a construit leur AD DS n'a pas pris le temps de mettre en place un modèle d'administration déléguée. Par conséquent, l'octroi de droits étendus est le moyen le plus rapide de fermer un ticket de service. C'est aussi le moyen le plus rapide que je connaisse pour que votre entreprise fasse la une du fil d'actualité de SC Magazine sur la sécurité, voire pire.
Ne vous faites pas d'illusions. Si votre environnement AD DS présente l'une de ces conditions, il vous incombe de montrer à la direction pourquoi la correction de ces problèmes doit être une priorité pour la sécurité de votre entreprise.
