LDAP (Lightweight Directory Access Protocol) est un protocole standard ouvert, basé sur TCP/IP, conçu pour accéder et maintenir des services d’annuaire distribués sur un réseau IP.
Il est "léger", en référence à son prédécesseur complexe, le protocole DAP (Directory Access Protocol) de la norme X.500.
- Protocole d'interrogation et de modification d'annuaires.
- Fonctionne sur TCP/IP :
- Port
tcp/389 : LDAP standard (non chiffré) ou LDAP avec StartTLS (la connexion démarre non chiffrée puis est sécurisée via l'opération StartTLS).
- Port
tcp/636 : LDAPS (LDAP over SSL/TLS - la connexion est chiffrée dès le départ).
L'utilisation de StartTLS ou LDAPS est essentielle pour la sécurité.
- Le standard LDAP définit une architecture normalisée reposant sur quatre piliers fondamentaux :
- la structuration stricte des données (Modèle d'Information)
- leur organisation hiérarchique unique dans l'arbre (Modèle de Nommage)
- les opérations standardisées pour interagir avec l'annuaire (Modèle Fonctionnel)
- et enfin les mécanismes d'authentification et de contrôle d'accès (Modèle de Sécurité)
- Développé initialement en 1993 (Université du Michigan) comme alternative simple à DAP.
- La version majeure et actuelle est LDAPv3, définie par l'IETF (RFC 4510 et suivantes), qui a standardisé le protocole et ajouté des fonctionnalités clés comme l'extensibilité, la sécurité (TLS) et l'internationalisation.
L'annuaire n'est pas une table plate, mais une structure hiérarchique.
- Arbre : L'annuaire est organisé comme un système de fichiers ou un arbre généalogique inversé. On appelle cette structure le DIT.
- Entrée : Chaque noeud de l'arbre est une entrée (un objet). On y trouve notamment (types de noeuds) :
- La Racine (Root) : Le point de départ)
- Les Branches (Containers) : Les subdivisions
- Les Feuilles (Leaf Objects) : Les objets finaux
- Identification unique (DN) : Chaque entrée possède un Distinguished Name (DN) unique qui trace son chemin complet depuis la racine.
Une entrée n'est qu'un conteneur identifié par son DN. Son contenu réel est défini par ses attributs.
- Entrée = Ensemble d'attributs.
- Nature de l'attribut :
- Défini par son Nom (ex:
sn pour Surname) et son OID (identifiant numérique unique).
- Contient une ou plusieurs valeurs.
- Précision importante : Contrairement au SQL, le multi-value est natif (ex:
mail peut contenir pro@test.com ET perso@test.com pour la même personne).
- Absence de NULL : Si un attribut n'a pas de valeur, il n'existe tout simplement pas dans l'entrée. On ne stocke pas de champ vide.
Le schéma est le jeu de règles strict qui régit le DIT. Sans schéma, l'annuaire n'est qu'un vrac de données. Il assure l'intégrité et l'interopérabilité.
Chaque attribut est défini dans le schéma par :
- Son OID : Son identité unique mondiale (ex:
2.5.4.4 pour sn : surname / Nom de famille).
- Sa Syntaxe : Le format (ou type) normalisé de la donnée. Voici les plus courantes :
- Unicode String : Chaîne de texte classique (ex: description).
- Integer : Nombre entier (ex: logonCount).
- Generalized Time : Date et heure normalisée (ex: whenCreated).
- Distinguished Name (DN) : Lien vers un autre objet (ex: manager, memberOf).
- Octet String : Donnée binaire (ex: userCertificate, objectSID).
- Boolean : Vrai/Faux.
- Ses Matching Rules (Règles de correspondance) : Comment l'annuaire doit comparer les données :
- Equality Match : Est-ce que "Jean" = "jean" ? (Case sensitivity).
- Ordering Match : Comment trier (alphabétique ou numérique ?).
- Substring Match : Peut-on chercher
*ean* ?
- Single vs Multi-valued : L'attribut autorise-t-il plusieurs valeurs ?
Les objectClasses regroupent des attributs pour former des entités cohérentes. Elles fonctionnent par Héritage (tout part de la classe racine top).
Il existe trois types de classes d'objets :
- ABSTRACT (Abstraite) : Ne peut pas être instanciée seule, sert de modèle (ex:
top, person).
- STRUCTURAL (Structurelle) : Définit ce que l'objet EST réellement. Une entrée doit avoir une (et généralement une seule chaîne) classe structurelle (ex:
inetOrgPerson, organizationalUnit).
- AUXILIARY (Auxiliaire) : Définit des caractéristiques supplémentaires que l'objet A. On peut les "greffer" sur un objet structurel pour étendre ses fonctions (ex: ajouter des attributs liés à une application spécifique sur un utilisateur).
Pour chaque objectClass, le schéma définit :
- MUST (Obligatoire) : Les attributs indispensables. L'objet ne peut être créé sans eux (ex:
cn et sn pour une person).
- MAY (Optionnel) : Les attributs autorisés mais facultatifs (ex:
telephoneNumber, description).
C'est le format standard utilisé pour importer ou exporter des données textuelles dans n'importe quel annuaire LDAP.
Exemple :
# Définition de l'entrée par son DN (l'adresse unique dans l'arbre)
dn: uid=jdupont,ou=comptabilite,dc=mon-entreprise,dc=com
# --- LES CLASSES (Le "TYPE" de l'objet) ---
# On voit ici l'héritage : on empile les classes de la plus générale à la plus précise
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
# --- LES ATTRIBUTS (Le "CONTENU") ---
# 1. Attributs OBLIGATOIRES (MUST) imposés par les classes ci-dessus
# 'sn' (Surname) et 'cn' (Common Name) viennent de la classe 'person'
sn: Dupont
cn: Jean Dupont
# 2. Attributs OPTIONNELS (MAY) mais standards
# 'title' vient de 'organizationalPerson'
title: Chef Comptable
# 3. Illustration du MULTI-VALUE
# L'attribut 'mail' peut apparaître plusieurs fois pour la même entrée.
# Pas besoin de créer 'mail1', 'mail2' comme en SQL.
mail: jean.dupont@mon-entreprise.com
mail: j.dupont@perso.fr
# 4. Attribut spécifique à la classe structurelle 'inetOrgPerson'
uid: jdupont
- Client se connecte au serveur LDAP (port 389 ou 636).
- Communication asynchrone possible (le client peut envoyer plusieurs requêtes sans attendre les réponses).
Bind : Authentification et spécification de la version du protocole.
Search : Recherche et récupération d'entrées/attributs.
Compare : Vérifie si une entrée a un attribut avec une valeur spécifique.
Add : Ajoute une nouvelle entrée.
Delete : Supprime une entrée.
Modify : Modifie les attributs d'une entrée existante.
ModifyDN : Renomme ou déplace une entrée (change son DN/RDN).
Unbind : Ferme la connexion.
Abandon : Annule une opération en cours.
Extended Operation : Pour des opérations non standardisées.
StartTLS : Opération pour négocier une connexion TLS sur le port standard (389) après l'établissement initial de la connexion TCP. À différencier avec LDAPS (port 636) où TLS est établi avant toute communication LDAP.
- Méthodes de
Bind :
- Anonyme : Accès très limité (souvent lecture seule sur des informations publiques). À éviter pour les opérations sensibles.
- Simple : Nom d'utilisateur (DN) et mot de passe (envoyé en clair si la connexion n'est pas protégée par TLS !). Requiert impérativement LDAPS ou StartTLS.
- SASL (Simple Authentication and Security Layer) : Framework permettant des mécanismes d'authentification plus robustes (ex: Kerberos, GSSAPI, EXTERNAL pour authentification basée sur certificat client TLS).
- Sécurité Essentielle :
- Toujours utiliser LDAPS ou StartTLS pour protéger les identifiants et les données en transit.
- Configurer des Listes de Contrôle d'Accès (ACLs) précises sur le serveur LDAP pour définir qui (quel DN, groupe, ou type d'accès) a le droit de lire ou modifier quelles parties de l'annuaire (DIT) et quels attributs. Le principe du moindre privilège doit s'appliquer.
- Utiliser des comptes de service dédiés avec des mots de passe forts pour les applications se liant à l'annuaire.
- Structure typique (et simple) avec
dc à la racine, puis des ou pour l'organisation.
Cet exemple peut notamment représenter dans un domaine Active Directory, un utilisateur Jean, attaché au domaine exemple.fr et qui appartient à l'OU personnes.
Sous Active Directory, l'objet utilisateur est identifié par son Common Name (cn) et non pas son login Windows (SAMAccountName).
SAMAccountName est l'attribut pour le login utilisateur Windows, alors que le standard LDAP prévoit que ce soit l'attribut uid. Souvent les deux sont alignés pour éviter toute ambiguïté.
- Outre Active Directory (qui est un service d'annuaire utilisant LDAP), d'autres serveurs LDAP existent :
- OpenLDAP : Implémentation open-source très répandue et mature.
- 389 Directory Server : Autre implémentation open-source robuste (utilisée par Red Hat).
- Oracle Unified Directory (OUD), Microsoft Active Directory Lightweight Directory Services (AD LDS), etc.
Dans un environnement d'entreprise, un seul serveur LDAP suffit rarement. Lorsque l'annuaire devient trop volumineux ou géographique étendu, on doit le découper : c'est l'Architecture Distribuée (ou Partitionnement).
Mais si les données sont éparpillées sur plusieurs serveurs, comment retrouver une information ? C'est là qu'interviennent les Referrals et le Chaînage.
Au lieu de copier tout l'annuaire partout (Réplication), on découpe l'arbre (DIT) en morceaux logiques hébergés par des serveurs différents.
- Le Principe : Chaque serveur est responsable d'une sous-branche spécifique de l'arbre, appelée Naming Context.
- Exemple géographique :
- Serveur A (Paris) héberge :
ou=france,dc=entreprise,dc=com
- Serveur B (New York) héberge :
ou=usa,dc=entreprise,dc=com
- Le Rôle du "Glue Record" : Le Serveur A sait que la branche "usa" existe, mais il ne contient pas les données. Il possède un pointeur (une référence) indiquant : "Pour tout ce qui concerne
ou=usa, voir le Serveur B".
Lorsqu'un client interroge le Serveur A pour trouver un utilisateur situé aux USA (donc sur le Serveur B), deux scénarios sont possibles selon la configuration.
Le serveur agit comme un agent d'accueil.
- Le client demande "Donne-moi l'utilisateur John aux USA".
- Le Serveur A répond : "Je ne l'ai pas. Mais je sais qui l'a : va voir le Serveur B à cette adresse (ldap://serveur-b)".
- C'est au Client de se débrouiller pour contacter le Serveur B et refaire sa demande.
Analogie : Vous demandez un document à l'accueil. L'hôte vous dit : "Ce n'est pas ici, c'est au bureau 204 au 2ème étage, allez-y vous-même."
Avantage : Charge serveur réduite (il ne fait que rediriger).
Inconvénient : Le client LDAP doit être "intelligent" (savoir gérer les redirections).
sequenceDiagram
participant C as Client LDAP
participant S1 as Serveur A (France)
participant S2 as Serveur B (USA)
C->>S1: Recherche (uid=John, ou=usa)
S1-->>C: RÉPONSE: Referral (ldap://serveur-b)
Note right of C: Le client reçoit l'adresse<br/>et doit rejouer la requête
C->>S2: Recherche (uid=John, ou=usa)
S2-->>C: RÉPONSE: Entrée trouvée (John)
Le serveur agit comme un proxy.
- Le client demande "Donne-moi l'utilisateur John aux USA".
- Le Serveur A voit qu'il ne l'a pas. Il contacte lui-même le Serveur B.
- Le Serveur B répond au Serveur A.
- Le Serveur A transmet la réponse finale au Client.
- Pour le client, tout est transparent, il a l'impression que le Serveur A possédait la donnée.
Analogie : Vous demandez un document à l'accueil. L'hôte vous dit : "Bougez pas, je vais le chercher pour vous au 2ème étage" et revient avec le document.
Avantage : Transparent pour le client (pas besoin de logique complexe).
Inconvénient : Plus lourd pour le Serveur A qui doit gérer les connexions inter-serveurs.
sequenceDiagram
participant C as Client LDAP
participant S1 as Serveur A (France)
participant S2 as Serveur B (USA)
C->>S1: Recherche (uid=John, ou=usa)
Note right of S1: SA voit que c'est chez SB<br/>et y va lui-même
S1->>S2: Recherche (uid=John, ou=usa)
S2-->>S1: Entrée trouvée (John)
S1-->>C: RÉPONSE: Entrée trouvée (John)
- Avantage : Centralisation et standardisation de l'information.
- Usages :
- Authentification centralisée pour systèmes (Linux/Unix via PAM/NSS), applications web, VPN, Wi-Fi (RADIUS via LDAP), etc.
- Carnet d'adresses centralisé (pour clients mail, applications).
- Stockage de configuration pour certaines applications ou services.
- Autorisation : Stockage des appartenances aux groupes utilisées par d'autres systèmes pour contrôler les accès.
- Base de l'annuaire Active Directory.
- Se fait via l'opération
Bind du protocole LDAP.
- Implémentation par Microsoft des services d'annuaire pour les environnements Windows Server. Nom complet : Active Directory Domain Services (AD DS).
- Système centralisé pour gérer utilisateurs, ordinateurs, sécurité, stratégies, et ressources.
- AD DS utilise LDAPv3 comme l'un de ses principaux protocoles d'accès pour interroger et modifier l'annuaire. Les outils d'administration AD et de nombreuses applications tierces communiquent avec les DC via LDAP.
- Cependant, pour l'authentification native des utilisateurs et ordinateurs Windows au sein du domaine, AD DS utilise principalement Kerberos (UDP/TCP 88). Kerberos offre une authentification plus sécurisée (basée sur des tickets chiffrés) et le Single Sign-On (SSO).
- AD étend le schéma LDAP standard avec des objets et attributs spécifiques à Windows.
¶ Domaine
- Unité administrative et de réplication de base. Regroupement logique de ressources (utilisateurs, ordinateurs...) partageant la même base de données d'annuaire et les mêmes politiques de sécurité. Limite d'authentification.
- Ensemble d'un ou plusieurs domaines AD partageant
- un schéma commun,
- une configuration commune,
- un Catalogue Global
- Limite de sécurité ultime : les approbations ne dépassent généralement pas la forêt.
- Les domaines d'une forêt ont des relations d'approbation transitives bidirectionnelles automatiques.
¶ Nom de domaine vs Nom NetBIOS
- AD utilise des noms de domaine DNS (ex:
entreprise.local, ad.societe.com).
- Le nom NetBIOS est un nom plus court (15 caractères max), hérité pour la compatibilité descendante.
- Un serveur Catalogue Global (GC) est un Contrôleur de Domaine qui héberge :
- Une copie complète et accessible en écriture de tous les objets de son propre domaine.
- Une copie partielle et en lecture seule de tous les objets de tous les autres domaines de la forêt. La copie partielle contient un sous-ensemble d'attributs jugés utiles pour les recherches (définis dans le schéma comme étant répliqués dans le GC).
- Rôles Clés du GC :
- Permettre des recherches rapides d'objets dans toute la forêt sans avoir à contacter un DC de chaque domaine.
- Résoudre les Noms Principaux d'Utilisateur (UPN - user@domain.com) lors de l'ouverture de session, surtout si l'utilisateur appartient à un domaine différent de celui de la machine.
- Fournir l'information d'appartenance aux groupes universels lors de l'ouverture de session.
Il est recommandé d'avoir au moins un GC par site physique pour optimiser les recherches et les ouvertures de session inter-domaines.
- Concept permettant de mapper la topologie physique du réseau (réseaux locaux bien connectés séparés par des liens WAN plus lents ou coûteux) à la structure logique d'AD.
- Site AD : Représente une zone du réseau où la connectivité est considérée comme rapide et fiable (typiquement un LAN ou un ensemble de LANs très bien connectés). Un site est défini par un ou plusieurs sous-réseaux IP.
- Liens de Sites : Connectent les sites AD entre eux. On leur associe un coût (reflétant la bande passante/latence) et une fréquence de réplication.
- Utilité :
- Contrôler et optimiser le trafic de réplication AD : La réplication entre DCs d'un même site (intra-site) est fréquente et non compressée. La réplication entre sites (inter-site) est moins fréquente (selon le planning du lien), compressée, et suit la topologie définie par les liens et leurs coûts (via le KCC).
- Localisation des services par les clients : Les postes clients et serveurs membres utilisent les informations de site pour trouver le contrôleur de domaine (et le GC) le plus "proche" sur le réseau pour s'authentifier et traiter les requêtes, réduisant la latence et l'utilisation des liens WAN.
¶ Contrôleur de Domaine (DC)
- Serveur Windows qui héberge le rôle AD DS (Active Directory Domain Services)
- Il héberge notamment une copie (réplique) de la base de données AD (
ntds.dit) pour son domaine.
- Il authentifie les ouvertures de session, applique les stratégies de groupe.
C'est l'acte de transformer un serveur Windows standard (sur lequel le rôle AD DS a été préalablement installé) en Contrôleur de Domaine opérationnel. Cela crée l'instance de la base de données (NTDS.DIT), le dossier partagé SYSVOL (pour les GPO), et inscrit le serveur dans la topologie de réplication.
- Les vérifications préalables (Avant de lancer la promotion) :
- Nom du Serveur : Doit être définitif. Renommer un DC après coup est complexe et risqué.
- Adresse IP : Doit impérativement être FIXE (Statique). Un DC ne doit jamais changer d'IP (sinon le DNS casse).
- DNS : Le serveur pointe-t-il vers un DNS valide (lui-même ou un autre DC existant) ?
- Compte Admin : Avez-vous les droits ? (Enterprise Admin pour ajouter un domaine, Schema Admin pour une nouvelle forêt).
- Contrôles & Actions (pendant l'installation, ou en paramètres de la commande) :
- Choix Topologique : "Nouvelle forêt" vs "Nouveau domaine" vs "Ajouter un DC à un domaine existant".
- Options de Rôle : Serveur DNS ? Catalogue Global (GC) ? (Recommandé : Oui aux deux).
- Mot de passe DSRM : Définition d'un mot de passe de secours (Mode restauration). Note : Ce n'est pas le mot de passe Admin du domaine, c'est un code de survie.
DSRM (Directory Services Restore Mode) est un mode de démarrage de secours où les services AD sont arrêtés pour permettre la maintenance ou la restauration de la base de données. Il nécessite un mot de passe administrateur spécifique ("Administrator DSRM Password"), défini lors de la promotion, qui est différent du mot de passe Administrateur du Domaine.
C'est l'acte de retirer la fonction de Contrôleur de Domaine. Le serveur supprime sa copie locale de la base de données AD, arrête la réplication, et redevient un "Serveur Membre" (ou autonome). Il garde son OS et ses logiciels, mais perd son "titre".
- Les vérifications critiques (Le système vous bloquera si...) :
- Rôles FSMO : Le serveur détient-il des rôles maîtres ? Si oui, l'assistant tentera de les transférer à un autre DC. Il est possible également (et plutôt recommandé) de procéder à ce transfert manuellement.
- Dernier DC ? Est-ce le tout dernier DC du domaine ?
- OUI : Vous détruisez définitivement le domaine.
- NON : Le domaine continue de vivre sur les autres.
- Dépendances : Est-ce le seul serveur DNS ou Catalogue Global du site ? (Risque de couper l'accès aux utilisateurs locaux).
- Contrôles & Actions (Pendant l'assistant) :
- Nouveau mot de passe Admin Local : Comme la base de données AD va être supprimée, le compte "Administrateur du Domaine" ne sera plus utilisable en local. Vous devez définir un mot de passe pour le compte Administrateur local (SAM locale) pour pouvoir vous reconnecter après le redémarrage.
- Mise à jour Métadonnées : Le serveur signale aux autres DC qu'il part, pour qu'ils arrêtent d'essayer de répliquer avec lui.
Si un contrôleur de domaine meurt physiquement (disque dur HS, carte mère grillée) et ne peut pas être rallumé, on ne peut pas lancer l'assistant de rétrogradation classique. Dans ce cas, le serveur est considéré comme "fantôme" par les autres. Les autres DC essaient toujours de le contacter pour répliquer, ce qui crée des erreurs. Il faut alors effectuer une rétrogradation forcée (manuelle) depuis un autre serveur pour mettre à jour l'annuaire.
- Mécanisme de synchronisation des bases AD entre les DCs d'un même domaine (et pour le GC/Schéma/Configuration entre tous les DCs de la forêt).
- Modèle multi-maître : Les modifications peuvent être faites sur n'importe quel DC (sauf pour certaines opérations gérées par les FSMO).
- Réplication Intra-site : Fréquente (quelques secondes/minutes), utilise la notification de changement, non compressée. Topologie en anneau généralement, avec des connexions supplémentaires pour la redondance.
- Réplication Inter-site : Moins fréquente (par défaut toutes les 3 heures, configurable), basée sur un planning, compressée pour économiser la bande passante WAN.
- KCC (Knowledge Consistency Checker) : Service tournant sur chaque DC qui génère automatiquement la topologie de réplication (objets
connection dans AD) en se basant sur les Sites et Liens de Sites définis par l'administrateur.
- PDC (Primary Domain Controller) : C'était le "chef" absolu du domaine. Il détenait la seule copie de la base de données en écriture. Si vous vouliez changer un mot de passe ou créer un utilisateur, cela devait obligatoirement se faire sur le PDC.
- BDC (Backup Domain Controller) : C'étaient des assistants en lecture seule. Ils recevaient une copie des données du PDC pour authentifier les utilisateurs (valider le login), mais on ne pouvait rien modifier dessus. Si le PDC tombait en panne, le réseau était "figé" (plus de modifications possibles) jusqu'à ce qu'un BDC soit promu manuellement.
C'est un concept de Windows NT4 devenu obsolète, car Active Directory utilise un modèle multi-maître.
Bien que le rôle strict de PDC ait disparu, un rôle FSMO nommé Émulateur PDC a été créé pour gérer certaines tâches critiques qui ne peuvent pas être gérées par tout le monde en même temps (voir plus bas).
- AD DS (Active Directory Domain Services) : Service fondamental assurant la gestion des identités et des accès.
- DNS (Domain Name System) : Prérequis absolu. Active Directory s'appuie entièrement sur le DNS pour la résolution de noms et la localisation des services (via enregistrements SRV). Pas de DNS = Pas d'AD.
- Zones DNS intégrées (Active Directory-Integrated Zones) :
- Principe : La base de données DNS est stockée dans les partitions de l'annuaire AD plutôt que dans un fichier .dns local.
- Avantages clés :
- Réplication Multi-Maître : Les modifications DNS peuvent être faites sur n'importe quel DC/DNS et sont répliquées automatiquement.
- Sécurité : Active l'option "Mises à jour dynamiques sécurisées uniquement" (seuls les membres du domaine peuvent modifier leurs enregistrements).
- Résilience : Si un serveur tombe, les données DNS sont préservées sur les autres nœuds AD.
C'est dans une sous-zone DNS spécifique nommée _msdcs.mondomaine.com que l'on retrouve les enregistrements SRV qui permettent de localiser le PDC Emulator, le Global Catalog ou les serveurs Kerberos.
FSMO signifie Flexible Single Master Operations. En français, on traduit souvent cela par "Maîtres d'Opérations".
Il s'agit de cinq rôles uniques pour gérer certaines opérations critiques et éviter les conflits dans un modèle multi-maître.
- Single Master : Pour ces 5 tâches précises, un seul contrôleur de domaine a le droit de valider les changements. Les autres doivent lui demander la permission.
- Flexible : Ce rôle n'est pas collé au serveur à vie. On peut le transférer manuellement vers un autre serveur (par exemple si on change de machine).
- Au niveau de la Forêt :
- Contrôleur de Schéma : Seul DC autorisé à modifier le schéma AD.
- Maître d'Opérations des Noms de Domaine : Gère l'ajout/suppression de domaines dans la forêt.
Placement suggéré : Souvent placés ensemble sur un DC bien sécurisé, potentiellement pas un GC, voire virtualisé. Pour une sécurité extrême, il peut être mis hors ligne (air gapped) sauf besoin de modification.
- Au niveau du Domaine :
- Émulateur PDC : Point de référence pour la synchronisation horaire (source NTP faisant autorité pour le domaine), reçoit les changements de mot de passe en priorité (réplication urgente), gère le verrouillage de compte. Il est aussi le serveur cible par défaut lorsqu'on édite les GPO (Group Policy Objects). C'est souvent lui qui "souffre le plus" en termes de charge CPU.
- Maître RID (Relative ID) : Alloue des blocs d'identifiants relatifs (RID) uniques à chaque DC pour qu'ils puissent créer des objets (utilisateurs, groupes, ordinateurs) avec un SID (Security IDentifier) unique dans le domaine (SID = SID du domaine + RID).
- Maître d'Infrastructure : Responsable de la mise à jour des références d'objets inter-domaines (ex: appartenance d'un utilisateur d'un domaine A à un groupe d'un domaine B). Met à jour les objets "fantômes". Ne doit pas être placé sur un serveur GC, sauf si tous les DCs du domaine sont aussi des GC.
Placement suggéré : PDCe et RID Master sont souvent placés ensemble sur un DC performant et bien connecté dans le domaine. Infrastructure Master sur un DC non-GC bien connecté aux GC d'autres domaines si applicable.
- Représentent les entités gérées dans l'annuaire.
- Conteneur intra-domaine pour organiser les objets (utilisateurs, groupes, ordinateurs, autres OUs).
- Facilite l'administration (délégation de contrôle) et l'application ciblée des Stratégies de Groupe (GPO).
- Collections d'objets (utilisateurs, ordinateurs, autres groupes).
- Types :
- Sécurité : Possèdent un SID, peuvent être utilisés pour attribuer des permissions sur des ressources et pour filtrer l'application des GPO.
- Distribution : Utilisés principalement comme listes de diffusion email, ne possèdent pas de SID.
- Étendues (pour les groupes de sécurité) :
- Domaine Local : Membres de n'importe où dans la forêt + domaines approuvés. Permissions applicables uniquement aux ressources du même domaine que le groupe.
- Global : Membres uniquement du même domaine que le groupe. Utilisable pour attribuer des permissions partout dans la forêt + domaines approuvés.
- Universel : Membres de n'importe quel domaine de la forêt. Utilisable pour attribuer des permissions partout dans la forêt. Nécessite un GC pour résoudre l'appartenance. L'appartenance est répliquée sur tous les GC, attention à l'impact sur la réplication si les changements sont fréquents.
| Type de Groupe |
Membres (Provenance / Qui ?) |
Portée des Droits (Où l'utiliser ?) |
Usage Type (Bonnes pratiques) |
| Domaine Local |
De n'importe quel domaine (Forêt/Externe). |
Uniquement dans le même domaine. |
Gestion des accès : Appliqué sur les ressources (dossiers, imprimantes) pour porter les permissions (ACL). |
| Global |
Uniquement du même domaine. |
Partout dans la forêt. |
Gestion des personnes : Regroupe les utilisateurs par rôle ou service (ex: Comptables, RH). |
| Universel |
De n'importe quel domaine (Forêt). |
Partout dans la forêt. |
Consolidation : Regroupe des groupes Globaux provenant de différents domaines (ex: "Tous les managers du groupe"). |
AG(U)DLP est une méthode d'imbrication (nesting) qui sépare "Qui je suis" (mon métier, mon rôle) de "Ce à quoi j'ai droit" (la ressource).
Le principe est de ne jamais donner de droits (Permissions) directement à un utilisateur, ni directement à un groupe métier. On crée une chaîne logique.
- A (Accounts) : Ce sont les utilisateurs (ex: Jean, Marie).
- G (Global Groups) : Ce sont les Rôles Métiers. Ils répondent à la question : "Quel est leur département ou leur fonction ?". Exemple :
GG_Comptabilité, GG_RH, GG_Stagiaires.
On met les Utilisateurs (A) dans ces groupes (G).
- DL (Domain Local Groups) : Ce sont les Accès aux Ressources. Ils répondent à la question : "À quoi faut-il accéder et comment ?". Exemple :
DL_Dossier_Factures_Lecture, DL_Imprimante_RH_Imprimer.
C'est ici que l'imbrication se fait : on met le groupe Global (G) dans le groupe Local de Domaine (DL).
- P (Permissions) : C'est le droit technique (NTFS). On applique la permission "Lecture" ou "Modifier" sur le dossier uniquement au groupe DL.
Imaginez que Jean est comptable et doit modifier des fichiers dans le dossier Factures.
- A (Account) : Vous avez le compte
Jean.
- G (Global) : Vous ajoutez Jean au groupe
GG_Comptables.
- DL (Domain Local) : Vous avez un groupe technique nommé
DL_Factures_Modif.
- Liaison G -> DL : Vous ajoutez le groupe
GG_Comptables comme membre de DL_Factures_Modif.
- P (Permission) : Sur le dossier
C:\Factures, vous donnez les droits NTFS "Modifier" au groupe DL_Factures_Modif.
Pourquoi ne pas juste mettre Jean directement dans le dossier ?
- Gestion facile des arrivées/départs : Si
Jean change de métier et va aux RH, vous le retirez juste de GG_Comptables et le mettez dans GG_RH. Il perd automatiquement ses accès aux factures et gagne ceux des RH. Vous n'avez pas besoin de fouiller les serveurs de fichiers pour changer les droits dossier par dossier.
- Visibilité immédiate : En regardant les membres du groupe
DL_Factures_Modif, vous ne voyez pas une longue liste de noms, mais des services (Compta, Direction, ...) : c'est beaucoup plus lisible pour un auditeur.
- Performance (Token Size) : Cette structure optimise la façon dont Windows calcule les droits à la connexion (le jeton d'accès).
Le U (Universel) sert uniquement si vous avez plusieurs domaines (une forêt avec des filiales).
Pour reprendre l'exemple :
- Si vous avez un domaine France et un domaine Belgique.
- Les comptables français (
GG_Compta_FR) et belges (GG_Compta_BE) doivent tous accéder au même serveur au siège.
- On crée un groupe Universel
GU_Comptables_Monde.
- On y met les deux groupes globaux.
- Ensuite, c'est ce groupe Universel qu'on ajoute dans le DL.
GPO signifie Group Policy Object (ou en français : Objet de Stratégie de Groupe).
C'est l'un des outils les plus puissants d'Active Directory.
Il s'agit d'ensembles de paramètres de configuration (sécurité, logiciels, scripts, préférences...) appliqués selon deux sections :
- Configuration Ordinateur : S'applique à la machine elle-même (au démarrage de Windows), quel que soit l'utilisateur qui se connecte.
- Exemple : Paramètres du Pare-feu, mises à jour Windows Update, installation de logiciels système, ...
- Configuration Utilisateur : S'applique à la personne (au moment du login).
- Exemple : Fond d'écran, raccourcis sur le bureau, restriction d'accès au disque C:, ...
Malgré leur nom ("Group" Policy), on n'applique généralement pas une GPO sur un groupe de sécurité, mais sur des conteneurs. L'ordre d'application est vital pour savoir qui gagne en cas de conflit, LSDOU :
- Local (La machine elle-même)
- Site (Le site géographique AD)
- Domaine
- OU (Unité d'Organisation) - C'est la dernière appliquée, donc celle qui a le dernier mot.
C'est pour cela que l'on range les utilisateurs et ordinateurs dans des OUs : pour leur appliquer des GPO spécifiques (ex: GPO "Compta" pour le service comptabilité).
Où sont-elles stockées ?
- La version logique (le lien, la version) est stockée dans la base de données AD (
NTDS.DIT).
- Les fichiers réels (les scripts, les modèles administratifs) sont stockés dans le dossier partagé
SYSVOL sur les contrôleurs de domaine.
- Les paramètres définis à un niveau supérieur (Site, Domaine, OU Parente) se propagent automatiquement aux niveaux inférieurs.
- L'application suit l'ordre LSDOU (Local > Site > Domaine > OU). En cas de paramètres contradictoires, la GPO la plus proche de l'objet (la dernière appliquée) l'emporte.
- Exemple : Une GPO sur l'OU écrase une GPO du Domaine.
- Cible : Se configure sur une Unité d'Organisation (OU).
- Effet : Empêche l'application de toutes les GPO provenant des niveaux supérieurs. L'OU devient hermétique et n'applique que les GPO liées directement à elle-même.
- Cible : Se configure sur le lien de la GPO.
- Effet : Donne la priorité absolue à cette GPO. Elle outrepasse le "Blocage d'héritage" (elle s'applique même si l'OU bloque). Elle écrase systématiquement tout paramètre contradictoire défini à un niveau inférieur (inverse la règle de conflit par défaut).
Erreur courante : confondre l'option "lien activé" et "appliqué (enforced)". Cette dernière option est très rarement activée et peut rendre complexe le débogage des GPO. (alors que la première est quant à elle très rarement désactivée);
- Suite d'outils à installer sur un poste client Windows (ou un serveur membre) pour gérer à distance les serveurs et rôles Windows, y compris AD DS.
- Inclut :
- Consoles MMC (.msc) : Utilisateurs et ordinateurs AD (
dsa.msc), Sites et services AD (dssite.msc), Domaines et approbations AD (domain.msc), Gestion des stratégies de groupe (gpmc.msc), Gestion DNS (dnsmgmt.msc), etc.
- Modules PowerShell : Des ensembles de commandes (cmdlets) pour administrer AD via la ligne de commande ou des scripts.
- Le module
ActiveDirectory pour PowerShell est l'outil de choix pour l'administration moderne d'AD.
- Permet l'automatisation des tâches répétitives, la gestion en masse (création/modification d'utilisateurs, groupes...), l'interrogation complexe de l'annuaire, et la gestion fine des permissions.
- Offre des capacités allant bien au-delà des consoles graphiques pour de nombreuses tâches avancées.
- AD étant le cœur de l'infrastructure Windows, sa sécurité est primordiale.
- Modèle d'Administration à Plusieurs Niveaux (Tier Model) : Séparer les comptes d'administration en niveaux
- Tier 0 : Contrôle de l'identité - DCs, ADFS, PKI
- Tier 1 : Serveurs d'entreprise
- Tier 2 : Postes de travail.
Un compte d'un niveau inférieur ne doit jamais pouvoir se connecter ou administrer un système d'un niveau supérieur.
- Principe du Moindre Privilège : N'accorder que les permissions strictement nécessaires aux utilisateurs et aux comptes de service pour accomplir leurs tâches. Utiliser la délégation de contrôle au niveau des OUs.
- Sécurisation des Contrôleurs de Domaine :
- Sécurité physique et de l'hyperviseur (si virtualisés).
- Limiter les rôles et logiciels installés sur les DCs.
- Utiliser des pare-feux pour restreindre les flux réseaux vers/depuis les DCs.
- Ne pas naviguer sur Internet ou consulter ses emails depuis un DC.
- Surveillance et Audit : Configurer et surveiller les journaux d'événements de sécurité (échecs/succès d'ouverture de session, modifications de groupes sensibles, etc.). Utiliser des outils SIEM ou des solutions spécialisées de surveillance AD.
- Gestion des Mots de Passe : Appliquer des politiques de mot de passe robustes (longueur, complexité, historique). Utiliser les Stratégies de Mot de Passe Affinées (Fine-Grained Password Policies - FGPP) pour appliquer des politiques différentes à des groupes spécifiques (ex: comptes admin vs utilisateurs standard).
- Contrôleurs de Domaine en Lecture Seule (RODC) : Déployer des RODC dans des sites physiquement moins sécurisés (ex: succursales). Ils hébergent une copie en lecture seule de l'annuaire (sauf pour certains secrets) et ne répliquent pas les modifications sortantes, réduisant la surface d'attaque.
Bien que l'Active Directory soit présenté comme une hiérarchie logique (Forêt, Domaines, OU), il repose physiquement sur des fichiers et une structure de base de données précise stockée sur chaque Contrôleur de Domaine.
Lors de la promotion d'un serveur en Contrôleur de Domaine, deux éléments critiques sont créés sur le disque dur :
À l'intérieur du fichier NTDS.DIT, les données ne sont pas mélangées. Elles sont segmentées en Partitions (ou Naming Contexts). Cela permet d'optimiser la réplication (certaines partitions sont répliquées dans toute la forêt, d'autres juste dans le domaine).
| Partition |
Contenu |
Réplication |
| Schéma |
Les définitions des classes et attributs. |
Toute la Forêt |
| Configuration |
La structure physique (Sites, Sous-réseaux, Topologie). |
Toute la Forêt |
| Domaine |
Les objets réels (Utilisateurs, Ordinateurs, Groupes). |
Domaine uniquement |
| Application |
Données spécifiques (ex: Zones DNS intégrées à AD). |
Configurable (souvent Forêt ou Domaine) |
Avant l'avènement massif du Cloud public, Microsoft a introduit AD FS pour répondre à la limite principale du protocole LDAP/Kerberos : il ne fonctionne pas bien sur Internet.
- Problème : Kerberos et LDAP sont conçus pour un réseau interne (LAN). On ne peut pas ouvrir ces ports sur Internet pour se connecter à une application SaaS (ex: Salesforce, Google Workspace) avec son compte Active Directory.
- Solution AD FS : C'est un service qui agit comme un tiers de confiance. Il permet d'étendre l'identité de l'entreprise vers le Web.
Contrairement à LDAP qui valide un mot de passe, AD FS fonctionne par Fédération d'identité.
- L'utilisateur tente d'accéder à une application Web externe.
- L'application redirige l'utilisateur vers le serveur AD FS de l'entreprise.
- L'utilisateur s'authentifie sur AD FS (via ses identifiants AD classiques).
- Si l'authentification réussit, AD FS ne donne pas le mot de passe à l'application. Il génère un Jeton (Token) signé (format SAML ou OIDC).
- Ce jeton contient des Revendications (Claims) : ce sont des informations extraites de l'AD (ex: Email, Nom, Rôle).
- L'application reçoit le jeton, vérifie la signature, et laisse entrer l'utilisateur.
Aujourd'hui, Microsoft Entra ID (Azure AD) remplace souvent AD FS car il intègre ces fonctions de fédération directement dans le Cloud. Cependant, AD FS reste utilisé par les entreprises qui souhaitent garder une souveraineté totale sur l'authentification sans dépendre du Cloud pour la validation des accès.
- Microsoft Entra ID (anciennement Azure Active Directory ou Azure AD) est le service d'identité et d'annuaire basé sur le cloud de Microsoft.
- Il est distinct d'Active Directory Domain Services (AD DS) qui est conçu pour les réseaux locaux (on-premises).
- Les organisations utilisent souvent les deux. Microsoft Entra Connect Sync (anciennement Azure AD Connect) est l'outil permettant de synchroniser les objets identité (utilisateurs, groupes) de l'AD DS local vers Microsoft Entra ID.
- Permet des scénarios d'identité hybride, offrant une expérience utilisateur cohérente (ex: même identifiant/mot de passe pour les ressources locales et cloud - via la synchronisation de hachage de mot de passe ou l'authentification directe).
- Entra ID est le service d'identité principal pour Microsoft 365, Azure, et des milliers d'autres applications SaaS (Software as a Service).
- Gère l'authentification et l'autorisation pour les applications cloud et mobiles.
- Utilise des protocoles d'authentification modernes comme OAuth 2.0, OpenID Connect (OIDC), SAML 2.0.
- Prend en charge l'Authentification Multi-Facteurs (MFA), l'Accès Conditionnel (Conditional Access), la gestion des appareils (jonction Entra, jonction Hybride Entra).
- Structure : Entra ID a une structure "plate", sans OUs ni GPOs comme AD DS. La gestion se fait via des groupes et des politiques ciblées.
- Protocoles : Principalement HTTP/S (OAuth, OIDC, SAML) vs Kerberos/LDAP pour AD DS.
- Focus : Entra ID est axé sur l'accès des utilisateurs aux applications, tandis qu'AD DS est axé sur la gestion des utilisateurs, ordinateurs et serveurs au sein d'un réseau local.
- Ce n'est pas un remplacement direct d'AD DS pour la gestion de serveurs et postes locaux, mais plutôt un complément essentiel dans les environnements modernes hybrides ou cloud-only.