Dans un petit réseau, chaque ordinateur peut parfaitement vivre sa vie dans son coin.
Chaque machine possède ses comptes locaux, ses mots de passe, ses partages, ses imprimantes et ses petites décisions administratives personnelles.
Puis l’entreprise grandit.
Il y a vingt postes.
Puis cinquante.
Puis trois cents.
Alice change de service, Bob quitte l’entreprise, le mot de passe Wi-Fi doit être renouvelé, cinquante ordinateurs doivent recevoir le même paramètre de sécurité et personne ne se rappelle pourquoi le compte local admin2 existe sur douze machines avec exactement le même mot de passe.
C’est généralement à ce moment que la centralisation cesse de ressembler à une obsession bureaucratique et commence à ressembler à une excellente idée.
Dans l’écosystème Microsoft, cette centralisation repose historiquement sur Active Directory Domain Services — AD DS.
Un domaine Active Directory permet de centraliser les identités, l’authentification, l’organisation des machines, une partie des autorisations et de nombreuses politiques de configuration.
En échange, le réseau développe quelques dépendances nouvelles.
Notamment envers DNS.
Beaucoup envers DNS.
Workgroup et domaine : deux philosophies très différentes
Un workgroup, ou groupe de travail, correspond au modèle décentralisé classique des petits réseaux Windows.
Chaque ordinateur administre essentiellement ses propres comptes.
Si Alice possède un compte sur :
PC-ALICEcela ne signifie pas automatiquement qu’elle possède le même compte sur :
PC-COMPTA
SERVEUR-FICHIERS
PC-BOBChaque machine possède sa propre base d’identités locales.
Dans un workgroup
On obtient donc typiquement :
- des comptes locaux indépendants ;
- des mots de passe pouvant différer d’une machine à l’autre ;
- des autorisations administrées localement ;
- des politiques de sécurité essentiellement locales ;
- peu de mécanismes centraux pour administrer un grand parc.
Pour trois ordinateurs familiaux, cela peut être parfaitement raisonnable.
Pour 800 postes répartis sur quatre sites, cela commence à ressembler à une expérience sociale dont personne n’a signé le formulaire de consentement.
Le domaine : une identité utilisable dans tout l’environnement
Dans un domaine Active Directory, les identités sont enregistrées dans un annuaire partagé par les contrôleurs de domaine.
Alice peut disposer d’un compte comme :
CONTOSO\aliceou sous forme UPN :
alice@corp.example.comCe compte peut ensuite être utilisé pour s’authentifier sur les machines et ressources autorisées du domaine.
On n’a plus besoin de créer manuellement :
alicesur cinquante serveurs différents.
Les serveurs peuvent reconnaître l’identité de domaine et utiliser ses groupes pour prendre leurs décisions d’autorisation.
Un domaine n’est pas « un serveur »
C’est une confusion très fréquente.
On entend parfois :
« Le serveur Active Directory est tombé. »
Techniquement, un domaine Active Directory correctement conçu ne devrait pas dépendre d’un unique serveur.
Il peut contenir plusieurs contrôleurs de domaine — Domain Controllers ou DC.
Par exemple :
DC01.corp.example.com
DC02.corp.example.comCes machines possèdent des copies répliquées de la partition d’annuaire correspondant à leur domaine.
Un client peut alors utiliser un contrôleur disponible et approprié.
Le domaine est un ensemble logique.
Le contrôleur de domaine est un serveur qui fournit les services du domaine.
Confondre les deux revient à confondre Internet avec le routeur situé sous votre télévision.
Active Directory ou Active Directory Domain Services ?
Dans le langage courant, on dit simplement :
Active Directory
ADMais le rôle Windows Server dont nous parlons précisément s’appelle :
Active Directory Domain Services
AD DSIl faut aussi éviter de confondre AD DS avec :
Microsoft Entra IDanciennement Azure Active Directory.
Les deux produits traitent des identités et peuvent être intégrés dans des architectures hybrides, mais leurs protocoles, leurs modèles et leurs usages ne sont pas identiques.
Ajouter le mot « Active » à plusieurs produits d’identité pendant vingt ans a constitué une stratégie de nomenclature dont nous récoltons encore les fruits.
Active Directory est un service d’annuaire
AD DS est un service d’annuaire hiérarchique distribué.
Il conserve des informations sur des objets comme :
- les utilisateurs ;
- les ordinateurs ;
- les groupes ;
- les contacts ;
- certains services ;
- des imprimantes publiées ;
- les stratégies et différents objets d’infrastructure.
Contrairement à une comparaison souvent faite, Active Directory n’est pas simplement une gigantesque base SQL relationnelle avec quelques utilisateurs dedans.
Son modèle est celui d’un annuaire hiérarchique.
Les objets
Chaque élément stocké dans AD est représenté par un objet.
Par exemple :
Alice Dupont
PC-ALICE
GG-Comptabilite
Imprimante-RDCUn objet possède différentes propriétés appelées attributs.
Pour un utilisateur, on peut rencontrer des informations comme :
- son nom ;
- son prénom ;
- son nom d’ouverture de session ;
- son adresse électronique ;
- son numéro de téléphone ;
- sa description ;
- ses appartenances à des groupes ;
- différentes informations de sécurité et d’état du compte.
Le mot de passe ne doit évidemment pas être imaginé comme un petit champ texte intitulé :
password = SuperSecret123que LDAP retournerait poliment à la première requête.
Active Directory conserve les informations nécessaires à l’authentification sous des formes protégées et soumises à des règles particulières.
Le schéma : le dictionnaire d’Active Directory
AD possède un schéma.
Il définit notamment :
- quelles classes d’objets peuvent exister ;
- quels attributs ces classes peuvent posséder ;
- leurs relations ;
- certaines contraintes associées.
Une classe :
usern’a donc pas été improvisée au moment où Alice a rejoint l’entreprise.
Le schéma définit ce qu’est un objet utilisateur et quelles informations peuvent lui être associées.
Le schéma décrit les types d’objets.
L’annuaire contient les instances réelles de ces objets.
La structure logique : forêt, domaine et OU
Active Directory possède plusieurs niveaux d’organisation.
Une représentation simplifiée ressemble à :
Forêt
└── Domaine
├── OU
│ ├── Utilisateurs
│ └── Ordinateurs
└── OU
├── Utilisateurs
└── OrdinateursLa forêt : le niveau supérieur
Une forêt Active Directory contient un ou plusieurs domaines partageant notamment :
- un schéma commun ;
- une configuration commune ;
- un catalogue global ;
- des relations d’approbation automatiques entre les domaines de la forêt.
Une petite entreprise peut parfaitement posséder :
une forêt
└── un domaineIl n’est absolument pas obligatoire de construire sept domaines parce que le schéma permet d’en avoir plusieurs.
L’architecture la plus simple répondant correctement au besoin possède une qualité administrative rare :
elle reste compréhensible six ans plus tard.
Le domaine
Un domaine représente notamment :
- une partition logique de l’annuaire ;
- un ensemble d’utilisateurs et d’ordinateurs ;
- une unité de réplication pour certaines données ;
- un espace d’administration et d’authentification.
Un domaine peut porter un nom DNS comme :
corp.example.comet également posséder un nom NetBIOS historique comme :
CORPOn obtient alors deux formes courantes d’identification :
CORP\aliceet :
alice@corp.example.comLes unités d’organisation — OU
Les Organizational Units permettent d’organiser les objets à l’intérieur d’un domaine.
Par exemple :
corp.example.com
├── OU=Utilisateurs
│ ├── OU=Comptabilite
│ ├── OU=RH
│ └── OU=Technique
└── OU=Ordinateurs
├── OU=Postes
└── OU=ServeursLes OU servent principalement à deux grandes choses :
- déléguer l’administration ;
- déterminer la portée de certaines stratégies de groupe.
Une OU n’est pas simplement un dossier décoratif servant à produire un joli arbre dans la console.
OU et groupe : ne les confondez pas
Une autre confusion très fréquente consiste à utiliser les OU comme si elles remplaçaient les groupes de sécurité.
Leurs rôles sont différents.
| Objet | Usage principal |
|---|---|
| OU | Organisation administrative, délégation, portée des GPO |
| Groupe | Regrouper des identités, notamment pour les autorisations |
Pour autoriser les comptables à accéder à :
\\FS01\Comptaon utilisera généralement un groupe de sécurité.
On ne donnera pas une permission NTFS à :
OU=Comptabilitesimplement parce que tous les comptables y sont rangés.
Les groupes : rendre les permissions administrables
Imaginons 80 utilisateurs devant accéder à un partage.
La mauvaise méthode :
Alice : Modify
Bob : Modify
Charles : Modify
...
78 autres lignesLa méthode beaucoup plus saine consiste à créer un groupe :
GG-Compta-Modificationpuis à lui attribuer la permission :
GG-Compta-Modification : ModifyLes utilisateurs sont ensuite ajoutés ou retirés du groupe.
L’autorisation du dossier ne change pas chaque fois que quelqu’un rejoint le service.
C’est cette logique qui permet à une infrastructure de survivre à son organigramme.
LDAP : parler avec l’annuaire
LDAP — Lightweight Directory Access Protocol est l’un des protocoles fondamentaux utilisés pour accéder aux informations d’annuaire.
Il permet notamment :
- de rechercher des objets ;
- de lire leurs attributs lorsque les permissions l’autorisent ;
- de créer ou modifier certains objets ;
- d’effectuer des opérations d’authentification ou de liaison selon le scénario.
LDAP n’est donc pas seulement :
« Le moteur de recherche d’Active Directory. »
Il constitue une véritable interface d’accès à l’annuaire.
Les Distinguished Names
Un objet possède notamment un Distinguished Name — DN qui indique sa position dans la hiérarchie.
Par exemple :
CN=Alice Dupont,OU=Comptabilite,OU=Utilisateurs,DC=corp,DC=example,DC=comOn peut le lire approximativement ainsi :
CN=Alice Dupont: l’objet ;OU=Comptabilite: son OU ;OU=Utilisateurs: l’OU parente ;DC=corp,DC=example,DC=com: le domaine DNS.
Une adresse qui aurait pu être courte.
LDAP avait d’autres projets.
LDAP, LDAPS et chiffrement
Le port LDAP traditionnel est :
TCP 389LDAP peut également être sécurisé à l’aide de TLS.
On rencontre notamment LDAPS sur :
TCP 636Il faut toutefois distinguer :
- le protocole LDAP ;
- l’authentification utilisée ;
- la protection ou le chiffrement de la session.
« Nous utilisons LDAP » ne répond donc pas encore à la question :
« Les échanges sont-ils correctement protégés ? »
Kerberos : l’authentification par tickets
Dans un domaine Windows moderne, Kerberos est le mécanisme d’authentification privilégié pour de nombreux scénarios.
Son principe évite d’envoyer votre mot de passe à chacun des services que vous souhaitez utiliser.
À la place, le système fonctionne avec des tickets cryptographiques.
Le KDC
Les contrôleurs de domaine fournissent notamment le rôle de :
Key Distribution Center
KDCKerberos distingue notamment :
- le service d’authentification ;
- le service d’émission de tickets ;
- les services réseau auxquels le client souhaite accéder.
Le TGT : votre premier ticket
Lorsqu’un utilisateur s’authentifie correctement, il peut obtenir un :
Ticket Granting Ticket
TGTCe ticket permet ensuite de demander d’autres tickets pour accéder aux services autorisés.
Par exemple, Alice veut accéder à :
\\FS01\ComptaLe mécanisme simplifié ressemble à :
Alice
↓
Contrôleur de domaine / KDC
↓
TGT
↓
Demande d'un ticket pour le service CIFS de FS01
↓
Ticket de service
↓
FS01Le serveur de fichiers peut vérifier le ticket sans avoir besoin que l’utilisateur lui transmette son mot de passe.
Une organisation nettement plus élégante que d’envoyer SuperSecret123! à chaque serveur du bâtiment.
Single Sign-On : pourquoi Alice n’entre pas son mot de passe partout
Kerberos contribue au fonctionnement du Single Sign-On.
Alice ouvre sa session Windows.
Puis elle accède à :
\\FS01\Comptasans ressaisir son mot de passe.
Elle ouvre ensuite une application interne compatible avec l’authentification intégrée.
Toujours pas de nouveau mot de passe.
Pour l’utilisateur, cela ressemble à :
« Windows sait qui je suis. »
Derrière, Kerberos vient de faire circuler assez de tickets pour remplir un petit carnet de transport.
Kerberos dépend fortement de l’heure
Les tickets possèdent des périodes de validité.
Une différence importante d’heure entre les machines peut donc casser l’authentification Kerberos.
D’où l’importance de la synchronisation temporelle dans un domaine.
Dans Active Directory, le temps suit une hiérarchie particulière, avec un rôle important joué par le contrôleur possédant le rôle PDC Emulator du domaine racine de forêt.
On découvre parfois ce principe après avoir passé une heure à examiner DNS, les SPN et les ACL avant de constater que le serveur croit être mardi prochain.
Et NTLM ?
Kerberos n’est pas le seul protocole d’authentification que Windows peut rencontrer.
NTLM existe toujours pour certains scénarios de compatibilité ou lorsque Kerberos ne peut pas être utilisé.
Mais dans un environnement Active Directory moderne correctement configuré, Kerberos est généralement préféré lorsqu’il est disponible.
Le fait qu’une authentification fonctionne n’implique donc pas automatiquement qu’elle utilise Kerberos.
Voir les tickets Kerberos
Sous Windows :
klistpermet d’examiner les tickets du contexte actuel.
C’est particulièrement utile lorsque quelqu’un assure :
« C’est forcément Kerberos. »
Le mot « forcément » constitue traditionnellement une excellente raison de vérifier.
DNS : l’infrastructure vitale d’Active Directory
DNS est fondamental dans AD DS.
Pas simplement parce qu’il traduit :
dc01.corp.example.comen :
192.168.10.10mais parce qu’Active Directory utilise également DNS pour publier et localiser ses services.
Les enregistrements SRV
Les contrôleurs de domaine publient notamment des enregistrements :
SRVpermettant aux clients de découvrir où se trouvent différents services.
On peut par exemple rencontrer :
_ldap._tcp.dc._msdcs.corp.example.comou des enregistrements concernant Kerberos.
Un client ne se contente donc pas de demander :
« Quelle est l’adresse IP de corp.example.com ? »
Il peut demander :
« Quels serveurs fournissent le service LDAP pour les contrôleurs de ce domaine ? »
Tester les enregistrements
Avec nslookup :
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.comOu avec PowerShell :
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example.comLe grand classique : mettre un DNS public sur les clients
Une machine membre d’un domaine doit normalement utiliser une infrastructure DNS capable de résoudre correctement les enregistrements Active Directory.
Configurer directement le poste avec :
8.8.8.8ou :
1.1.1.1comme DNS principal peut permettre de résoudre parfaitement :
www.wikipedia.orgtout en empêchant le poste de trouver :
_ldap._tcp.dc._msdcs.corp.example.comUn utilisateur peut alors conclure :
« Internet fonctionne, donc le DNS fonctionne. »
Phrase techniquement fascinante dans un domaine Active Directory.
Pourquoi DNS tombe souvent sous les accusations
Lorsqu’AD rencontre un problème, les symptômes peuvent apparaître très loin de DNS :
- ouverture de session lente ;
- impossibilité de joindre le domaine ;
- GPO non appliquées ;
- échec Kerberos ;
- serveur introuvable ;
- réplication défaillante ;
- services de domaine indisponibles.
Voilà pourquoi les administrateurs Active Directory répètent si souvent :
« Vérifie le DNS. »
Ce n’est pas toujours le DNS.
Mais il a suffisamment souvent été coupable pour acquérir cette réputation.
Comment un poste trouve-t-il un contrôleur de domaine ?
Windows utilise un mécanisme appelé couramment DC Locator.
De manière simplifiée :
- le poste connaît son domaine ;
- il interroge DNS pour trouver les contrôleurs correspondant au service recherché ;
- DNS retourne les enregistrements SRV appropriés ;
- le client vérifie la disponibilité des contrôleurs ;
- il choisit un DC approprié, notamment en tenant compte de la topologie Active Directory.
Trouver un contrôleur de domaine
Sous Windows :
nltest /dsgetdc:corp.example.comPour connaître le DC utilisé pour certaines opérations de session :
echo %LOGONSERVER%Ces deux commandes ne répondent pas exactement à la même question, mais sont très utiles au diagnostic.
Les sites Active Directory
Active Directory possède aussi une notion de site.
Un site représente normalement une partie bien connectée du réseau et est associé à des sous-réseaux IP.
Par exemple :
Site-Paris
10.10.0.0/16
Site-Lyon
10.20.0.0/16Cette information permet notamment :
- d’optimiser la réplication ;
- d’aider les clients à sélectionner des services proches ;
- de représenter la topologie physique du réseau indépendamment des OU.
Site et OU ne représentent pas la même chose
Une OU correspond essentiellement à une organisation administrative et logique.
Un site représente davantage la topologie réseau physique.
Alice peut être dans :
OU=Comptabilitetout en travaillant dans :
Site-LyonSon métier et son emplacement IP sont deux informations différentes.
Une distinction étonnamment saine venant d’un système capable de produire des DN de cent vingt caractères.
La réplication : plusieurs DC, un même annuaire
Les contrôleurs de domaine doivent maintenir leurs données suffisamment cohérentes.
Pour cela, Active Directory utilise un mécanisme de réplication.
Supposons que l’administrateur modifie Alice sur :
DC01Le changement est ensuite répliqué vers :
DC02
DC03
...Les contrôleurs de domaine inscriptibles fonctionnent largement selon un modèle multi-maître.
Cela signifie que plusieurs DC peuvent accepter différentes modifications de l’annuaire puis les répliquer.
Il n’existe donc plus le modèle général :
un maître unique
+
plusieurs copies passivesqui caractérisait les anciens domaines Windows NT.
PDC et BDC : le musée Windows NT
Sous Windows NT, un domaine possédait :
- un PDC — Primary Domain Controller ;
- des BDC — Backup Domain Controllers.
Le PDC possédait la copie maîtresse modifiable de la base.
Les BDC recevaient des copies.
Ce modèle a disparu avec Active Directory.
Les contrôleurs de domaine modernes inscriptibles sont largement des pairs capables de recevoir des changements.
Mais Windows a conservé une petite trace aristocratique de l’ancien régime.
Le PDC Emulator existe toujours
Active Directory possède un rôle nommé :
PDC EmulatorIl ne signifie pas que son détenteur est redevenu l’unique contrôleur primaire.
Il s’agit d’un des rôles FSMO — Flexible Single Master Operations.
Le PDC Emulator possède certaines responsabilités particulières, notamment autour :
- de la synchronisation temporelle ;
- de certaines opérations de mots de passe ;
- de compatibilités historiques ;
- de plusieurs fonctions administratives spécifiques.
Les DC sont donc largement égaux.
Certains ont simplement reçu des tâches supplémentaires et un badge.
Les cinq rôles FSMO
Active Directory possède cinq rôles FSMO.
Au niveau de la forêt
- Schema Master ;
- Domain Naming Master.
Dans chaque domaine
- RID Master ;
- PDC Emulator ;
- Infrastructure Master.
Ces rôles existent parce que certaines opérations seraient difficiles ou dangereuses à effectuer simultanément partout selon un modèle totalement multi-maître.
Voir les détenteurs des rôles
Une commande historique pratique :
netdom query fsmoPowerShell permet également d’obtenir ces informations avec les cmdlets Active Directory.
Le RID Master
Chaque objet de sécurité Windows reçoit un SID — Security Identifier.
Les contrôleurs de domaine utilisent des pools de RID — Relative Identifiers afin de créer des SID uniques pour les nouveaux objets de sécurité.
Le RID Master distribue ces pools aux DC.
Sans cela, laisser plusieurs serveurs inventer librement des identifiants uniques aurait fini par produire le même genre d’expérience que cinq services utilisant tous le numéro de ticket 42.
Le Schema Master
Le Schema Master contrôle les modifications du schéma de la forêt.
Modifier le schéma est une opération sérieuse.
Une extension peut être nécessaire pour certains logiciels.
Mais une modification incorrecte mérite davantage de préparation que :
« Ça a l’air bon, clique sur OK. »
Le Domain Naming Master
Ce rôle intervient notamment lors de certaines opérations liées à l’ajout ou à la suppression de domaines et de partitions dans la forêt.
Ce n’est normalement pas un rôle auquel un administrateur pense tous les matins.
Ce qui constitue généralement une excellente nouvelle.
L’Infrastructure Master
L’Infrastructure Master possède des responsabilités particulières concernant certaines références entre objets provenant de domaines différents.
Son importance pratique dépend notamment de l’architecture de la forêt et du placement du catalogue global.
RODC : le contrôleur qui ne prend pas toutes les décisions
Il existe également des :
Read-Only Domain Controllers
RODCUn RODC contient des copies en lecture seule de certaines partitions Active Directory.
Il est notamment utile dans certains sites où :
- la sécurité physique est limitée ;
- le personnel IT est absent ;
- on souhaite réduire les risques associés à un DC inscriptible.
Les RODC constituent donc une exception importante à la phrase :
« Tous les contrôleurs peuvent modifier l’annuaire. »
Non.
Les contrôleurs inscriptibles, oui.
Le contrôleur explicitement nommé Read-Only a manifestement négocié d’autres conditions de travail.
Le catalogue global
Dans une forêt possédant plusieurs domaines, certains contrôleurs peuvent fonctionner comme Global Catalog — GC.
Le catalogue global contient :
- une copie complète des objets du domaine du DC ;
- une copie partielle de certains attributs des objets provenant des autres domaines de la forêt.
Il permet notamment des recherches à l’échelle de la forêt et participe à certaines opérations d’authentification.
On pourrait le voir comme l’index général de la bibliothèque.
Il ne possède pas nécessairement chaque page de chaque livre, mais il sait suffisamment de choses pour vous aider à trouver ce que vous cherchez.
SYSVOL : l’autre élément qu’il vaut mieux ne pas oublier
Les contrôleurs de domaine ne répliquent pas uniquement la base d’annuaire.
Ils exposent également un partage important :
SYSVOLIl contient notamment une partie des données nécessaires aux stratégies de groupe et aux scripts associés.
Les GPO possèdent effectivement deux composantes :
- des informations stockées dans Active Directory ;
- des fichiers stockés dans SYSVOL.
La réplication doit donc maintenir la cohérence de ces éléments entre les DC.
GPO : administrer plusieurs machines sans visiter plusieurs bureaux
Les Group Policy Objects — GPO constituent l’un des grands avantages d’un domaine Windows.
Ils permettent de définir centralement de très nombreux paramètres pour les utilisateurs et les ordinateurs.
Par exemple :
- stratégies de sécurité ;
- pare-feu Windows ;
- paramètres du système ;
- restrictions utilisateur ;
- scripts de démarrage et de connexion ;
- redirection de certains dossiers ;
- préférences ;
- certains déploiements logiciels ;
- configuration de composants Windows.
L’administrateur modifie une politique centralement.
Les clients concernés la récupèrent et l’appliquent.
On évite ainsi la méthode historique :
« Prenez une chaise. Nous allons faire les 240 postes un par un. »
Où peut-on lier une GPO ?
Les GPO peuvent notamment être liées à :
- un site ;
- un domaine ;
- une OU.
On résume souvent l’ordre normal de traitement avec :
L → S → D → OUpour :
Local
Site
Domain
Organizational UnitDans une hiérarchie d’OU imbriquées, les GPO des parents sont normalement traitées avant celles des enfants.
Des mécanismes comme :
- l’héritage ;
- Enforced ;
- Block Inheritance ;
- le filtrage de sécurité ;
- les filtres WMI ;
peuvent ensuite influencer le résultat.
Le jour où six GPO configurent le même paramètre avec trois niveaux d’héritage, l’ordre de traitement cesse d’être une notion théorique.
Mettre tout le monde dans la même OU n’est pas une stratégie
Une architecture :
OU=ToutLeMondepossède l’avantage d’être rapide à créer.
Elle possède moins d’avantages une fois qu’il faut appliquer :
- une politique aux serveurs ;
- une autre aux postes ;
- une restriction aux machines publiques ;
- une délégation au support ;
- des paramètres spécifiques à la comptabilité.
Une structure d’OU doit refléter les besoins d’administration et de politique, pas nécessairement recopier à la virgule près l’organigramme RH.
Joindre une machine au domaine
Lorsqu’un ordinateur Windows rejoint un domaine, un objet ordinateur est créé ou utilisé dans Active Directory.
La machine établit ensuite une relation sécurisée avec le domaine.
Conceptuellement :
PC-ALICE
│
├── possède son identité machine
│
└── entretient une relation sécurisée avec le domaineCette identité machine est elle-même importante.
Un poste de domaine n’est donc pas simplement un ordinateur sur lequel Alice tape :
CORP\aliceau lieu de :
PC-ALICE\aliceLa machine elle-même est devenue membre de l’infrastructure d’identité.
Le compte ordinateur
Dans Active Directory, on trouve par exemple :
PC-ALICE$Le dollar final est utilisé dans certaines représentations du compte machine.
Comme un utilisateur, l’ordinateur possède une identité de sécurité et peut recevoir des autorisations ou des politiques.
Oui, votre PC est donc lui aussi un objet administratif doté d’une identité.
Il était déjà suffisamment difficile de gérer les utilisateurs.
Que se passe-t-il lorsqu’Alice ouvre sa session ?
De manière simplifiée :
- le poste connaît son domaine ;
- DNS lui permet de trouver des contrôleurs de domaine ;
- le client contacte un DC approprié ;
- Alice est authentifiée ;
- son identité et ses appartenances à des groupes sont déterminées ;
- Kerberos peut lui fournir ses premiers tickets ;
- les stratégies de groupe applicables sont déterminées ;
- Windows construit son environnement de session ;
- Alice accède ensuite aux ressources autorisées avec son identité de domaine.
Pour Alice :
mot de passe → Bureau WindowsPour l’infrastructure :
DNS, DC Locator, authentification, tickets, groupes, GPO, profils, scripts et plusieurs protocoles qui souhaitent tous que l’heure du système soit correcte.
Authentification et autorisation : deux problèmes différents
Active Directory permet notamment de savoir :
Qui êtes-vous ?
C’est l’authentification.
Une fois votre identité connue, une ressource doit encore déterminer :
Avez-vous le droit de faire cela ?
C’est l’autorisation.
Alice peut donc être parfaitement authentifiée par le domaine et recevoir ensuite :
Access is denied.en ouvrant :
\\FS01\DirectionActive Directory sait qui elle est.
C’est précisément pour cela que le serveur sait qu’elle ne devrait pas être là.
Les SID : le vrai identifiant de sécurité
Windows ne considère pas simplement :
alicecomme l’identité de sécurité fondamentale.
Les utilisateurs, groupes et ordinateurs possèdent des Security Identifiers — SID.
Conceptuellement :
S-1-5-21-...Le nom est essentiellement une représentation humaine.
Le SID est ce que les mécanismes de sécurité utilisent réellement.
C’est pourquoi supprimer un compte puis recréer un nouveau compte portant exactement le même nom ne recrée pas nécessairement la même identité vis-à-vis des anciennes ACL.
Alice est revenue.
Pour Windows, ce n’est juridiquement pas la même Alice.
Les relations d’approbation — Trusts
Active Directory permet d’établir des relations d’approbation entre domaines ou forêts.
Elles permettent à une infrastructure de reconnaître les identités provenant d’une autre limite administrative selon des règles définies.
Par exemple :
corp.example.com
⇅
partner.example.netUne relation d’approbation ne donne pas automatiquement accès à toutes les ressources.
Elle permet de faire confiance à l’authentification provenant de l’autre environnement selon la configuration.
Les ressources conservent leurs propres autorisations.
Faire confiance à l’identité de quelqu’un ne signifie pas lui donner les clés du bâtiment.
Pourquoi utiliser Active Directory ?
Centraliser les identités
Un utilisateur peut disposer d’une identité commune pour de nombreuses ressources.
Administrer les groupes
Les droits peuvent être attribués à des groupes plutôt qu’individuellement.
Appliquer des politiques
Les GPO permettent de gérer centralement de nombreux paramètres.
Déléguer l’administration
Le support peut, par exemple, recevoir le droit de réinitialiser certains mots de passe sans devenir administrateur du domaine entier.
Gérer un parc important
Plus le nombre de machines augmente, plus l’administration purement locale devient coûteuse.
Intégrer des services
De nombreuses applications peuvent utiliser Active Directory pour :
- l’authentification ;
- l’appartenance à des groupes ;
- LDAP ;
- Kerberos ;
- les certificats ou différents mécanismes d’intégration.
Active Directory n’est pas un logiciel de surveillance
L’article original mentionnait la possibilité de « savoir qui débranche le serveur ».
Active Directory facilite effectivement :
- l’identification des utilisateurs ;
- l’audit de nombreuses opérations ;
- l’application centralisée de politiques de journalisation ;
- la centralisation de certains événements avec d’autres outils.
Mais AD n’est pas à lui seul un système complet de supervision ou de SIEM.
Pour réellement surveiller une infrastructure, on s’appuie également sur :
- les journaux Windows ;
- l’audit de sécurité ;
- la supervision ;
- les outils de collecte d’événements ;
- éventuellement un SIEM.
Et pour savoir précisément qui a physiquement débranché le serveur à 17 h 59 :
Active Directory reste malheureusement moins efficace qu’une caméra correctement placée.
La haute disponibilité : pourquoi avoir plusieurs DC ?
Avec un seul contrôleur de domaine :
DC01
↓
panne
↓
journée intéressantePlusieurs services peuvent être affectés :
- authentification ;
- résolution DNS si le DNS repose également sur ce serveur ;
- modification de l’annuaire ;
- application de certaines politiques ;
- accès à différentes ressources.
Avoir plusieurs DC réduit cette dépendance.
Typiquement :
DC01
DC02sur des infrastructures correctement séparées lorsque cela est possible.
Deux DC ne remplacent cependant pas une sauvegarde Active Directory.
La réplication reproduit aussi très efficacement certaines erreurs administratives.
Supprimer le mauvais objet sur DC01 et attendre la réplication n’est pas une stratégie de conservation.
Réplication et sauvegarde ne sont pas synonymes
Supposons que vous supprimiez accidentellement :
OU=Comptabilitesur DC01.
La réplication peut parfaitement transmettre cette suppression à DC02.
DC02 n’est donc pas devenu une sauvegarde simplement parce qu’il possédait une deuxième copie cinq secondes plus tôt.
Une véritable stratégie Active Directory doit considérer :
- la redondance ;
- la sauvegarde ;
- les mécanismes de restauration ;
- la protection contre les suppressions accidentelles ;
- les procédures de reprise après sinistre.
Le compte Domain Admins n’est pas un compte utilisateur quotidien
Un des principes de sécurité les plus importants :
Les comptes hautement privilégiés ne devraient pas servir à lire les e-mails, naviguer sur Internet ou effectuer le travail bureautique quotidien.
Un administrateur peut par exemple posséder :
alicepour son travail normal et :
adm-alicepour certaines opérations administratives.
Utiliser Domain Admins pour ouvrir une pièce jointe reçue par e-mail revient à aller acheter du pain avec les clés du datacenter accrochées à la ceinture.
Le principe du moindre privilège
Un utilisateur devrait recevoir les droits nécessaires à son rôle, pas :
Domain Admin
Parce que sinon l'application ne fonctionne pasLorsqu’un logiciel réclame des privilèges excessifs, le bon réflexe consiste à comprendre :
- quelles ressources il utilise ;
- quelles ACL lui manquent ;
- quel service doit être exécuté sous quel compte ;
- quelle délégation précise est réellement nécessaire.
Donner tous les privilèges règle beaucoup de problèmes.
C’est également une méthode efficace pour en préparer de beaucoup plus grands.
Déléguer plutôt que distribuer Domain Admins
Les OU permettent notamment de déléguer certaines opérations.
On peut par exemple permettre au support :
- de réinitialiser les mots de passe des utilisateurs d’une OU ;
- de déverrouiller les comptes ;
- de gérer certains objets ordinateurs ;
sans lui donner le contrôle intégral de la forêt.
Une bonne délégation répond à :
« De quoi cette équipe a-t-elle besoin ? »
et non :
« Quel groupe d’administrateurs suffisamment puissant fera disparaître l’erreur ? »
Quelques outils indispensables
Utilisateurs et ordinateurs Active Directory
dsa.mscConsole historique permettant notamment de gérer :
- les utilisateurs ;
- les groupes ;
- les ordinateurs ;
- les OU.
Sites et services Active Directory
dssite.mscPour la topologie de sites et de réplication.
Domaines et approbations Active Directory
domain.mscGestion des stratégies de groupe
gpmc.mscDNS
dnsmgmt.mscLa console qu’il est préférable d’apprendre avant de décider que DNS est simplement « le truc qui transforme Google en IP ».
PowerShell et Active Directory
Le module Active Directory permet d’administrer l’annuaire avec PowerShell.
Par exemple :
Get-ADUser -Identity aliceRechercher plusieurs utilisateurs :
Get-ADUser -Filter *Afficher un groupe :
Get-ADGroup -Identity "GG-Comptabilite"Voir les contrôleurs de domaine :
Get-ADDomainController -Filter *Afficher les informations du domaine :
Get-ADDomainEt de la forêt :
Get-ADForestDiagnostiquer Active Directory sans cliquer partout au hasard
Lorsqu’un problème apparaît, quelques commandes permettent de déterminer quelle couche souffre réellement.
1. Vérifier la configuration IP
ipconfig /allRegardez particulièrement :
- l’adresse IP ;
- la passerelle ;
- les serveurs DNS ;
- le suffixe DNS.
2. Vérifier DNS
nslookup dc01.corp.example.comPuis les SRV :
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com3. Trouver un contrôleur de domaine
nltest /dsgetdc:corp.example.com4. Vérifier le canal sécurisé
Selon le contexte :
Test-ComputerSecureChannel -Verbose5. Examiner Kerberos
klist6. Vérifier les GPO appliquées
gpresult /rPour un rapport HTML :
gpresult /h C:\Temp\gpo.html7. Forcer une actualisation des politiques
gpupdate /forceCette commande est utile.
La lancer quinze fois de suite ne produit généralement pas quinze fois plus de stratégie de groupe.
DCDIAG : interroger la santé d’un contrôleur
Sur un contrôleur de domaine ou avec les outils appropriés :
dcdiagpermet d’effectuer différents tests portant sur les services du contrôleur.
Une version plus détaillée :
dcdiag /vREPADMIN : quand la réplication devient suspecte
Pour examiner la réplication :
repadmin /replsummaryPour davantage de détails :
repadmin /showreplUn domaine dans lequel :
repadmin /replsummaryaffiche une collection impressionnante d’erreurs rouges mérite probablement davantage d’attention qu’un redémarrage improvisé de l’imprimante.
Diagnostiquer une ouverture de session lente
Une ouverture de session lente peut notamment provenir de :
- DNS incorrect ;
- DC éloigné ou indisponible ;
- site Active Directory mal associé ;
- GPO lentes ;
- scripts de connexion ;
- lecteurs réseau indisponibles ;
- profils ;
- problèmes réseau ;
- authentification dégradée.
Commencer immédiatement par :
gpupdate /forcen’est donc pas toujours un diagnostic.
C’est parfois seulement une manière de demander au problème de recommencer devant vous.
« Le domaine est indisponible » : par quoi commencer ?
Sur le client :
DNS
ipconfig /all
nslookup corp.example.com
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.comContrôleur de domaine
nltest /dsgetdc:corp.example.comHorloge
w32tm /query /statusConnectivité
Selon le diagnostic :
Test-NetConnection dc01.corp.example.com -Port 53
Test-NetConnection dc01.corp.example.com -Port 88
Test-NetConnection dc01.corp.example.com -Port 389Le simple :
ping dc01est utile pour certaines questions.
Il ne prouve pas que LDAP, Kerberos, DNS ou RPC fonctionnent correctement.
ICMP n’est pas le représentant syndical de tous les autres protocoles.
Les principaux services et ports
Active Directory utilise plusieurs protocoles.
| Service | Port courant | Rôle |
|---|---|---|
| DNS | TCP/UDP 53 | Résolution et découverte des services |
| Kerberos | TCP/UDP 88 | Authentification |
| LDAP | TCP/UDP 389 selon usage | Accès à l’annuaire |
| LDAPS | TCP 636 | LDAP protégé par TLS |
| Global Catalog | TCP 3268 | Requêtes catalogue global |
| Global Catalog TLS | TCP 3269 | Catalogue global protégé par TLS |
| SMB | TCP 445 | SYSVOL et autres services SMB |
| RPC Endpoint Mapper | TCP 135 | Découverte RPC |
Ce tableau n’est pas une liste exhaustive de tous les flux nécessaires à AD DS.
Active Directory utilise également des ports RPC dynamiques et d’autres services selon les opérations.
Créer une règle pare-feu contenant uniquement :
53, 88, 389et considérer le sujet terminé peut donc produire des résultats artistiques.
Active Directory et le cloud
Les infrastructures modernes peuvent combiner :
- Active Directory Domain Services local ;
- Microsoft Entra ID ;
- services cloud ;
- identités synchronisées ;
- machines jointes au domaine, à Entra ID ou selon des modèles hybrides.
Il ne faut donc plus réduire toute identité Microsoft au choix :
Workgroup
ou
Active Directory localLe paysage est aujourd’hui plus large.
Mais AD DS reste extrêmement présent dans les infrastructures d’entreprise et demeure essentiel pour de nombreux systèmes Windows, applications historiques et services locaux.
Quelques idées reçues
« Il faut un domaine dès qu’il y a deux PC »
Non.
La centralisation doit répondre à un besoin réel.
« Active Directory est juste une base d’utilisateurs »
Non.
Il contient également ordinateurs, groupes, configuration, topologie, stratégies et de nombreuses informations d’infrastructure.
« Un domaine possède un serveur principal »
Pas dans le sens historique du PDC Windows NT.
Plusieurs DC inscriptibles peuvent accepter des modifications, même si certaines opérations particulières dépendent des rôles FSMO.
« DNS ne sert qu’à convertir un nom en adresse IP »
Dans AD, il permet également aux clients de découvrir les services du domaine grâce aux enregistrements SRV.
« LDAP authentifie tout »
LDAP est principalement un protocole d’accès à l’annuaire.
Kerberos joue un rôle central dans l’authentification Windows de domaine.
« Si j’ai deux DC, j’ai une sauvegarde »
Non.
Vous avez de la réplication et de la redondance.
Une suppression accidentelle peut également être répliquée.
« Domain Admin résout les problèmes de droits »
Il les masque souvent.
Ce n’est pas exactement la même chose.
Workgroup ou domaine ?
| Critère | Workgroup | Domaine Active Directory |
|---|---|---|
| Comptes | Locaux à chaque machine | Centralisés dans le domaine |
| Authentification | Locale | Contrôleurs de domaine |
| Politiques centralisées | Très limitées | GPO |
| Administration d’un grand parc | Difficile | Conçue pour cela |
| Groupes centralisés | Non | Oui |
| Délégation | Principalement locale | Fine via AD |
| Dépendance infrastructure | Faible | DNS, DC, réplication, etc. |
| Complexité | Faible | Plus importante |
| Échelle typique | Petit environnement | Organisation administrée centralement |
Les concepts à retenir
| Concept | Rôle |
|---|---|
| AD DS | Service d’annuaire de domaine Microsoft |
| Forêt | Niveau logique supérieur regroupant un ou plusieurs domaines |
| Domaine | Partition logique d’AD et espace d’identités |
| OU | Organisation, délégation et portée des GPO |
| Groupe | Regroupement d’identités, notamment pour les autorisations |
| DC | Contrôleur fournissant les services du domaine |
| LDAP | Accès et interrogation de l’annuaire |
| Kerberos | Authentification par tickets |
| DNS | Résolution des noms et localisation des services AD |
| GPO | Configuration centralisée des utilisateurs et ordinateurs |
| SYSVOL | Contient notamment une partie des GPO et scripts |
| Global Catalog | Recherche et données partielles à l’échelle de la forêt |
| Site | Représentation de la topologie réseau |
| FSMO | Rôles uniques pour certaines opérations particulières |
| SID | Identifiant de sécurité d’un principal Windows |
Une architecture minimale raisonnable
Pour une petite infrastructure d’entreprise, on peut imaginer :
Forêt : example.com
└── Domaine : corp.example.com
├── DC01
│ ├── AD DS
│ └── DNS
│
├── DC02
│ ├── AD DS
│ └── DNS
│
├── OU=Utilisateurs
│ ├── OU=Comptabilite
│ ├── OU=Direction
│ └── OU=Technique
│
└── OU=Ordinateurs
├── OU=Postes
└── OU=ServeursLes permissions sur les ressources sont ensuite attribuées à des groupes comme :
GG-Compta-Lecture
GG-Compta-Modification
GG-Serveurs-RDPet les GPO sont appliquées selon les besoins administratifs.
Cela constitue déjà une base infiniment plus saine que :
Administrators
└── Everyonepartout, stratégie également connue sous le nom de :
« On verra plus tard pour la sécurité. »
Bonnes pratiques essentielles
- Déployez plusieurs contrôleurs de domaine lorsque la disponibilité le justifie.
- Configurez correctement DNS et faites utiliser ce DNS aux membres du domaine.
- Utilisez des groupes pour attribuer les permissions.
- Concevez les OU pour la délégation et les GPO, pas uniquement pour reproduire l’organigramme.
- Limitez fortement l’utilisation des comptes Domain Admins et autres comptes privilégiés.
- Séparez si possible les comptes administratifs des comptes quotidiens.
- Maintenez la synchronisation temporelle.
- Surveillez la réplication avec les outils appropriés.
- Sauvegardez Active Directory : plusieurs DC ne constituent pas une sauvegarde.
- Documentez les rôles FSMO, DNS, sites, sous-réseaux et dépendances critiques.
- Évitez les modifications de schéma ou les délégations excessives sans comprendre leurs conséquences.
Conclusion : le contrôle centralisé devient surtout intéressant quand il est bien conçu
Un workgroup est simple parce que chaque machine administre essentiellement son petit royaume.
Cette simplicité fonctionne très bien à petite échelle.
Puis le réseau grandit.
Et ce qui ressemblait à de la liberté devient progressivement :
42 comptes locaux
17 mots de passe différents
9 lecteurs réseau configurés à la main
et un fichier nommé
budget_final_final_v3_revu_OK_bis.xlsxActive Directory répond à ce problème par la centralisation.
Il fournit :
- un annuaire distribué ;
- des identités communes ;
- des groupes ;
- des contrôleurs de domaine répliqués ;
- Kerberos pour l’authentification ;
- LDAP pour accéder à l’annuaire ;
- DNS pour localiser les services ;
- des OU pour organiser et déléguer ;
- des GPO pour administrer les postes ;
- et suffisamment de mécanismes complémentaires pour occuper une carrière entière.
Ce n’est donc pas vraiment une « dictature du réseau ».
C’est davantage un gouvernement central doté d’un annuaire, d’un service des passeports, d’un cadastre, d’un système fiscal et de plusieurs contrôleurs régionaux qui passent leur temps à se répliquer les dossiers.
Et contrairement au workgroup, lorsqu’Alice quitte l’entreprise, il suffit normalement de désactiver :
CORP\aliceplutôt que de partir à la chasse à son compte local sur trente-sept machines.
C’est moins romantique.
Mais à partir d’une certaine taille de réseau, l’ordre possède des qualités étonnamment séduisantes.