Active Directory : Qu’est-ce que c’est ? Comment ça fonctionne ?

Active Directory est un service d’annuaire créé par Microsoft, au cœur de nombreuses infrastructures IT. Il permet une gestion centralisée, sécurisée et évolutive des ressources et des utilisateurs. Découvrez pourquoi cette solution est devenue incontournable, et le demeure encore aujourd’hui à l’ère du Cloud !

Il n’y a encore pas si longtemps, face à la complexité des infrastructures IT, les organisations étaient contraintes de naviguer à travers un labyrinthe complexe d’identités fragmentées, de ressources disparates, de politiques dispersées.

C’est en 1999 que Microsoft a tout changé avec une réponse aux défis croissants de la gestion des identités et des ressources au sein des entreprises. Une solution qui allait devenir un symbole de transformation, d’efficacité et de sécurité dans le monde de l’informatique, posant les bases d’un nouveau paradigme : Active Directory.

Active Directory : Qu’est-ce que c’est ?

Active Directory (AD) est un service d’annuaire développé par Microsoft pour Windows Server. Techniquement, il s’agit d’une base de données hiérarchique et distribuée qui stocke les objets du réseau : utilisateurs, ordinateurs, groupes, ressources. Avec ses services de domaine (Active Directory Domain Services, AD DS), AD relie les personnes aux ressources dont elles ont besoin et permet une gestion centralisée des identités, de l’authentification et de l’autorisation à l’échelle de l’organisation.

AD vs « un annuaire » en général : un annuaire au sens large se concentre sur le stockage et la consultation d’informations via des protocoles comme LDAP. Active Directory, lui, va plus loin : il intègre un modèle de sécurité (authentification Kerberos, contrôle d’accès), un moteur d’administration centralisée (stratégies de groupe, délégation), des mécanismes de réplication entre contrôleurs de domaine et un catalogue global pour la recherche, tout en s’intégrant nativement à l’écosystème Windows.

• Identité : référentiel unique des objets du SI et de leurs attributs, organisé de façon logique et hiérarchique.
• Authentification et autorisation : vérifie qui est l’utilisateur, puis détermine à quoi il peut accéder, avec prise en charge de l’authentification unique dans le domaine.
• Administration centralisée : stratégies de groupe (GPO), délégation des droits, politiques de mots de passe et paramètres de configuration appliqués à grande échelle.
• Intégration applicative : connexion avec des services Microsoft comme Exchange ou SharePoint et avec des applications tierces via des standards reconnus (LDAP, Kerberos, SAML, OAuth). Cela inclut des applications métier telles que les solutions CRM, un cas d’usage fréquent pour les développeurs full stack.
• Évolutivité et résilience : réplication entre contrôleurs de domaine, recherche trans-domaines via le catalogue global, adaptation aux PME comme aux grandes entreprises.
• Conformité et audit : journaux d’événements, contrôle d’accès et application cohérente des politiques pour répondre aux exigences réglementaires.

L’histoire et les origines d’Active Directory

Étroitement liée aux versions de Windows Server, l’histoire d’Active Directory commence avec Windows 2000 Server et se poursuit jusqu’aux éditions récentes de Windows Server 2025. En un quart de siècle, l’annuaire a évolué d’un socle sur site centré sur LDAP, Kerberos et DNS vers un pilier de l’identité hybride, intégré aux services cloud de Microsoft, avec Azure AD aujourd’hui baptisé Microsoft Entra ID. Voici les jalons qui permettent de comprendre cette trajectoire et de préparer les notions modernes d’hybridation et d’intégration Azure.

1. 1999, 2000 : lancement avec Windows 2000 Server. AD introduit un annuaire hiérarchique pour les utilisateurs, groupes, ordinateurs et ressources, les relations de confiance, les GPO et l’authentification Kerberos, adossés au DNS pour la découverte des services.
2. 2003 : maturité accrue avec Windows Server 2003. Améliorations de réplication, sécurité et niveaux fonctionnels de domaines et forêts, consolidation de la gestion des stratégies.
3. 2008 / 2008 R2 : cap sur la résilience et l’administration. Arrivée des contrôleurs de domaine en lecture seule (RODC) pour les sites distants, AD Recycle Bin pour restaurer des objets supprimés et AD Administrative Center pour une gestion modernisée.
4. 2012 / 2012 R2 : simplification et virtualisation. Déploiement et clonage de DC facilités, comptes de service gérés (gMSA), et premiers scénarios d’identité hybride avec la synchronisation vers le cloud qui aboutira à Azure AD Connect.
5. 2016 : renforcement de la sécurité. Introduction de mécanismes tels que la gestion des accès privilégiés (PAM) et les politiques/silos d’authentification pour mieux contenir les comptes à haut privilège, en cohérence avec les protections côté poste.
6. 2019 : durcissements et fiabilité. Évolutions focalisées sur la stabilité d’AD DS, l’interopérabilité et les bonnes pratiques de sécurité à l’échelle des forêts.
7. 2022 : sécurisation par défaut renforcée. Renforcement des protocoles et du durcissement Kerberos/Netlogon, intégration toujours plus fluide avec les services Azure pour les usages hybrides.
8. Aujourd’hui (Windows Server 2025 et ère cloud) : l’AD sur site reste le socle des environnements Windows, tandis que l’identité dans le cloud évolue avec Microsoft Entra ID (ex-Azure AD). Le couple AD DS + synchronisation offre une gestion unifiée des identités et des accès, du datacenter au SaaS, avec des scénarios SSO et MFA généralisés.

Quelles sont les principales fonctionnalités ?

Si la gestion d’identité est le cœur d’Active Directory, il offre une gamme de fonctionnalités bien plus étendue. Ses mécanismes d’authentification et d’autorisation permettent aux utilisateurs d’accéder aux ressources appropriées, en fonction de leurs identités et de leurs droits. Grâce aux politiques de groupe (Group Policies), les administrateurs peuvent également définir et gérer des paramètres de configuration pour les utilisateurs et les ordinateurs à travers une organisation. Ceci inclut des politiques de sécurité, des paramètres de réseau, des configurations de bureau et bien plus encore.

Afin d’assurer la cohérence des données à travers les contrôleurs de domaines, AD utilise des mécanismes de réplication qui synchronisent les informations de manière efficiente et fiable. En outre, des services web permettent l’intégration avec d’autres applications et services. Cela facilite la mise en place de solutions intégrées et interopérables. Toutes ces fonctionnalités font d’Active Directory une plateforme puissante et évolutive. C’est en les maîtrisant que les organisations peuvent tirer pleinement parti des avantages offerts.

En bref, Active Directory regroupe des fonctions clés, organisées par sous-thèmes actionnables :

• Gestion des identités et des accès (IAM) : création des comptes, appartenance aux groupes, délégation d’administration, authentification Kerberos et contrôle d’accès fin via ACL.
• Stratégies de groupe (GPO) : standardisation des postes et des serveurs, déploiement de configurations et de logiciels, durcissement sécurité et conformité.
• Accès et partage des ressources : impressions et partages de fichiers, permissions basées sur les groupes, SSO dans le domaine.
• Réplication et haute disponibilité : cohérence de l’annuaire entre contrôleurs de domaine, catalogue global pour des recherches rapides.
• Intégration et fédération : LDAP pour l’interopérabilité applicative, SAML/OAuth/OpenID Connect via AD FS pour le SSO web et partenaires.
• Audit et conformité : journaux d’événements, traçabilité des changements, application de politiques uniformes.

Quels sont les services AD (AD DS, AD CS, AD FS, AD LDS) ?

Service	Rôle	Cas d’usage courants
AD DS (Active Directory Domain Services)	Service de domaine et annuaire central : objets, authentification, autorisation, GPO, réplication.	Joindre des postes au domaine, SSO Kerberos sur le réseau interne, gestion des comptes et groupes.
AD CS (Active Directory Certificate Services)	Infrastructure de clés publiques : émission et gestion de certificats.	TLS interne, authentification par certificat, signature de code, Wi-Fi 802.1X.
AD FS (Active Directory Federation Services)	Fédération d’identités et SSO web pour applications externes.	Accès SSO à des applications SaaS/partenaires via SAML, OAuth ou OpenID Connect.
AD LDS (AD Lightweight Directory Services)	Annuaire applicatif sans domaine Windows.	Stocker des identités applicatives de façon isolée, schéma adapté à une application.

À noter : d’autres services existent selon les besoins, par exemple AD RMS pour la protection des informations.

À quoi servent les stratégies de groupe (GPO) ?

Les GPO appliquent automatiquement des paramètres de configuration et des règles de sécurité à des utilisateurs, ordinateurs, OU ou sites. Elles réduisent les écarts de configuration, renforcent la sécurité et accélèrent les déploiements.

Exemple : pour un service financier, une GPO peut imposer le chiffrement du disque, verrouiller la session après 5 minutes, déployer le proxy d’entreprise et bloquer les périphériques USB.

• Standardiser les postes : pare-feu, navigateurs, mises à jour, imprimantes.
• Renforcer la sécurité : politiques de mots de passe, restrictions locales, durcissement des services.
• Automatiser l’IT : déploiement de logiciels, scripts d’ouverture/fermeture de session, mappage de lecteurs.
• Assurer la conformité : appliquer des baselines et tracer les changements.

Comment AD centralise-t-il identités, accès et ressources ?

AD orchestre le cycle de vie des identités, l’authentification et l’autorisation, puis l’accès aux ressources partagées, le tout sous une administration centralisée et traçable.

1. Provisioning : création du compte, affectation aux OU, ajout aux groupes selon le rôle.
2. Joindre les appareils : intégration des postes au domaine pour hériter des GPO et politiques.
3. Authentification : connexion sécurisée (Kerberos) au domaine.
4. Autorisation : accès accordé par appartenance aux groupes et ACL sur fichiers, partages, applis.
5. Exploitation et contrôle : déploiements et configurations via GPO, supervision, audits.
6. Changements et fin de vie : mobilité interne gérée par les groupes, puis désactivation et retrait des accès.

Comprendre les concepts clés d’Active Directory

Active Directory (AD) repose sur un annuaire LDAP hiérarchique qui organise des objets et applique des règles d’authentification et d’autorisation. Pour administrer efficacement un annuaire d’entreprise, il faut maîtriser ses objets, la logique des groupes et portées, la hiérarchie domaines-arbres-forêts et la façon dont les Unités d’organisation structurent la délégation.

Cette section synthétise les notions les plus recherchées afin d’éclairer la gestion quotidienne des identités, des permissions et de la gouvernance d’AD.

Quels sont les objets AD et quel est le rôle du schéma ?

Dans AD, tout est objet stocké dans l’annuaire: utilisateurs, ordinateurs, groupes, contacts, imprimantes, partages, mais aussi conteneurs et unités d’organisation (OU). Chaque objet appartient à une classe et porte des attributs décrits par le schéma de la forêt. Le schéma définit les classes disponibles, leurs attributs et les règles d’utilisation. Il se réplique dans toute la forêt et toute extension du schéma est sensible, car globale et irréversible en pratique.

• Objets courants:
  • User: identité d’une personne, utilisée pour l’authentification.
  • Computer: compte machine joint au domaine, cible des GPO.
  • Group: ensemble de comptes pour gérer des droits à grande échelle.
  • Contact: fiche d’information sans authentification.
  • OU: conteneur logique pour organiser, déléguer et appliquer des GPO.
  • sAMAccountName et userPrincipalName pour l’identifiant.
  • memberOf et member pour l’appartenance aux groupes.
  • objectGUID et objectSID pour l’unicité et la sécurité.
  • lastLogonTimestamp pour l’activité d’un compte.
  • operatingSystem pour les objets ordinateurs.

  Impact du schéma: il conditionne ce que l’on peut créer et stocker. On l’étend pour introduire de nouvelles applications ou attributs, après tests et validation de gouvernance, car la modification touche tous les domaines de la forêt.

  Groupes de sécurité vs distribution: quelles différences et quelles portées ?

  Les groupes de sécurité servent à attribuer des permissions aux ressources. Les groupes de distribution servent à la messagerie et ne portent pas de droits d’accès. Les deux types existent avec trois portées: locale au domaine, globale et universelle, qui déterminent où le groupe peut être utilisé et quels membres il peut contenir.

  Type	Portée	Usages typiques
  Sécurité	Locale au domaine	Attribuer des ACL sur des ressources de ce domaine. Peut contenir des membres de n’importe quel domaine de la forêt.
  Sécurité	Globale	Regrouper des comptes d’un même domaine. À imbriquer dans des groupes locaux pour attribuer les droits.
  Sécurité	Universelle	Regrouper des comptes et groupes de plusieurs domaines. Pratique pour des accès communs inter-domaines.
  Distribution	Locale au domaine	Listes de diffusion limitées au domaine, sans permissions.
  Distribution	Globale	Listes de diffusion par entité ou service dans un domaine.
  Distribution	Universelle	Listes de diffusion trans-domaines, pour communications à l’échelle de la forêt.

  Comparaison et bonne pratique: utilisez des groupes de sécurité pour les accès, des groupes de distribution pour la messagerie. Modélisez les droits avec l’approche imbriquée recommandée: Comptes → Groupes globaux → Groupes locaux de domaine → Permissions (AGDLP). À l’échelle de plusieurs domaines, utilisez des groupes universels lorsque la réplication et les besoins d’accès le justifient.

  Domaines, arbres, forêts et relations d’approbation: comment s’articulent-ils ?

  AD s’organise en domaines rassemblés en arbres qui partagent un espace de noms, et en forêts qui partagent schéma et configuration. Le domaine représente une unité d’administration et de réplication. La forêt constitue la véritable limite de sécurité: les interactions entre forêts exigent des relations d’approbation explicites.

  • Domaine: base d’administration, partage une base d’annuaire et des stratégies communes.
  • Arbre: ensemble de domaines qui partagent un espace de noms continu.
  • Forêt: ensemble d’arbres qui partagent schéma, configuration et catalogue global.
  • Approvals/Trusts:
    • Intra-forêt: entre domaines d’une même forêt, transitives et bidirectionnelles par défaut.
    • Inter-forêts: approbations de forêt (unidirectionnelles ou bidirectionnelles) pour autoriser l’authentification entre forêts.
    • External: approbations vers un domaine hors forêt lorsque la confiance de forêt n’est pas possible.
    • Shortcut: optimisent la résolution entre domaines éloignés dans la même forêt.
    • Realm: vers des environnements Kerberos non AD.
    Se former au développement logiciel

    La compréhension de ces relations est essentielle pour planifier les périmètres de sécurité, les flux d’authentification et la délégation d’administration.

    Qu’est-ce qu’une Unité d’organisation (OU) et la délégation de droits ?

    Une OU est un conteneur logique au sein d’un domaine. Elle sert à structurer les objets, cibler des GPO et appliquer des Listes de contrôle d’accès (ACL) pour une délégation administrative granulaire. Avec l’assistant de délégation, on confie par exemple au support de niveau 1 la réinitialisation de mots de passe dans une OU donnée, sans octroyer de privilèges étendus ailleurs.

    • Bonnes pratiques:
      • Modéliser les OU selon la réalité opérationnelle: par services, sites ou populations administrées.
      • Éviter des OU par personne. Utiliser des groupes pour l’attribution des droits.
      • Limiter la profondeur de la hiérarchie pour garder une application des GPO lisible.
      • Documenter la délégation: qui peut faire quoi, où, et avec quel groupe.
      • Tester les GPO et les délégations sur une OU pilote avant déploiement global.
      • Auditer régulièrement les ACL d’OU et l’appartenance aux groupes délégués.

      Cas concret: une entreprise multi-sites crée des OU par agence (Paris, Lyon, Lille) et par service (Finance, RH, IT). Les techniciens locaux sont membres d’un groupe “Helpdesk-Lyon” délégué sur l’OU “Lyon” avec droits de réinitialisation de mots de passe et d’ajout d’ordinateurs au domaine. Les GPO de sécurité poste client s’appliquent aux OU des ordinateurs par site, tandis que les GPO métier s’appliquent aux OU des utilisateurs. Un audit programmé vérifie chaque trimestre que la délégation et les GPO restent conformes.

      Une architecture divisée entre structure physique et logique

      Pour bien appréhender le fonctionnement et la mise en œuvre d’Active Directory, comprendre son architecture est très utile. Elle se décompose en plusieurs parties. En termes de structure physique, les contrôleurs de domaine sont des serveurs Windows Server exécutant le rôle AD DS (Active Directory Domain Services). Ils contiennent une copie de la base de données AD et gèrent les requêtes et modifications pour les objets d’AD dans leur domaine ou leur forêt.

      Les données entre les contrôleurs de domaine sont synchronisées grâce à la réplication pour garantir la disponibilité et la résilience, et il existe différents types de réplicas. Par exemple, les réplicas de lecture permettent de déléguer certaines opérations sans affecter la base de données principale.

      Concernant la structure logique, AD est organisé de façon hiérarchique pour déterminer les relations de confiance, les limites d’administration et les schémas d’attribution des noms. Ce sont les domaines, les arbres et les forêts qui composent cette hiérarchie. En outre, AD s’intègre étroitement avec d’autres services et protocoles comme DNS (Domain Name System) pour la résolution des noms, Kerberos pour l’authentification et d’autres services Windows pour une gestion unifiée.

      En un coup d’œil : la couche physique vise la proximité réseau, la disponibilité et la réplication entre serveurs, tandis que la couche logique organise la sécurité, la délégation et les stratégies.

      Couche	Composants principaux	Périmètre	Objectifs clés
      Physique	Contrôleurs de domaine (DC), RODC, serveurs de catalogue global, sites AD	Datacenters et sites distants	Disponibilité, proximité réseau, réplication, résilience
      Logique	Domaines, arbres, forêts, OU, groupes, GPO	Frontières d’administration et de sécurité	Délégation, politiques, nomenclature et confiances

      Contrôleurs de domaine (DC) et rôles FSMO: qui fait quoi ?

      Les DC authentifient les utilisateurs, appliquent les GPO et répliquent l’annuaire. Dans les sites peu sécurisés, un RODC (Read-Only Domain Controller) limite l’exposition en gardant une copie en lecture seule. Un catalogue global accélère les recherches inter-domaines en stockant un sous-ensemble d’attributs pour tous les objets de la forêt.

      Formation Microsoft Azure : DP-203 ou AZ-104 certifiante

      Certains rôles critiques restent détenus par un seul DC à la fois, appelés rôles FSMO (Flexible Single Master Operations) :

      • Maître RID : alloue des pools d’identifiants relatifs aux DC du domaine pour générer des SID uniques lors de la création d’objets.
      • Émulateur PDC : point central pour la compatibilité héritée, les verrouillages de compte, la priorité de mise à jour des mots de passe et la référence de temps.
      • Maître d’infrastructure : met à jour les références d’objets entre domaines au sein du même domaine.
      • Maître de schéma : autorité unique pour modifier le schéma de la forêt.
      • Maître d’attribution de noms de domaine : gère l’ajout et la suppression de domaines ou de partitions d’application dans la forêt.

      Sites AD et topologie: comment optimiser la réplication ?

      Un site AD regroupe des sous-réseaux IP à faible latence. La réplication intra-site est déclenchée par notification de changement et non compressée, alors que la réplication inter-sites est planifiée, compressée et suit une topologie basée sur des liens de site et des coûts. Le KCC calcule automatiquement une topologie robuste, en nommant des serveurs passerelles si nécessaire.

      • Modéliser chaque emplacement réseau avec ses sous-réseaux et créer un site par zone de faible latence.
      • Définir des liens inter-sites avec des coûts reflétant la bande passante, puis ajuster la planification selon les fenêtres de trafic.
      • Prévoir au moins 2 DC par site quand c’est possible, et des RODC sur les sites peu sécurisés.
      • Éviter les pontages superflus de liens, surveiller la convergence et les arriérés de réplication.

      Réplication, SYSVOL et DFSR: que faut-il savoir ?

      La réplication AD s’appuie sur le moteur DRS et des numéros de séquence de mise à jour pour converger vers un état cohérent. Les conflits sont rares et traités automatiquement grâce à des métadonnées de versionnement et des horodatages.

      SYSVOL contient les GPO et les scripts de connexion, démarrage et arrêt. Sa réplication utilise aujourd’hui DFSR, plus résilient et efficace que FRS, avec compression, mise en file d’attente et reprise. Des incohérences SYSVOL se traduisent souvent par des GPO non appliquées, d’où l’importance de surveiller la santé de DFSR.

      • Vérifier régulièrement la santé de DFSR et les journaux d’événements.
      • Limiter la taille et le nombre de fichiers dans SYSVOL, éviter d’y stocker des binaires volumineux.
      • Contrôler la latence inter-sites pour anticiper l’impact sur l’application des GPO.

      Que contient la base de données NTDS.dit ?

      Le fichier NTDS.dit stocke l’annuaire. Il est segmenté en partitions et optimisé par des index pour accélérer les recherches. Le catalogue global conserve un sous-ensemble d’attributs de toute la forêt pour les recherches trans-domaines.

      • Partition Schéma : définitions de classes et d’attributs, communes à la forêt.
      • Partition Configuration : topologie, sites, services et liens.
      • Partition Domaine : objets de votre domaine (utilisateurs, groupes, ordinateurs).
      • Partitions d’application : données spécifiques, par exemple DNS intégré à AD (ForestDnsZones, DomainDnsZones).

      Ajouter des index ciblés améliore des requêtes fréquentes, mais accroît la taille et la charge de réplication. Il convient de mesurer l’impact avant d’étendre le schéma ou d’indexer de nouveaux attributs.

      Quels ports réseau AD doivent être ouverts ?

      Port	Protocole	Service / Finalité
      53	TCP/UDP	DNS, localisation des DC
      88	TCP/UDP	Kerberos, authentification
      389	TCP/UDP	LDAP, annuaire
      636	TCP	LDAPS, LDAP chiffré
      445	TCP	SMB, partage SYSVOL/NETLOGON et GPO
      135	TCP	RPC Endpoint Mapper
      49152, 65535	TCP	RPC dynamiques (réplication AD, Netlogon, WMI)
      3268 / 3269	TCP	Catalogue global LDAP / LDAP sur SSL
      123	UDP	Service de temps Windows (NTP)

      • Ouvrir la plage RPC dynamique côté DC et serveurs qui dialoguent avec AD, ou la restreindre de manière cohérente si une politique l’exige.
      • Le trafic GPO dépend de SMB et de la santé de SYSVOL : un blocage 445 ou une réplication en échec provoquera des pannes d’authentification ou de stratégie.
      • Limiter NetBIOS hérité (137, 139) aux cas nécessaires et privilégier DNS moderne.
      Comprendre l’architecture d’Active Directory

      Quels protocoles et mécanismes d’authentification utilise AD ?

      Active Directory Domain Services s’appuie sur un socle de protocoles standard pour fournir authentification, autorisation et découverte des services. Dans un domaine Windows, Kerberos est le mécanisme d’authentification par défaut, LDAP/LDAPS sert à interroger et modifier l’annuaire, NTLM subsiste pour des besoins de compatibilité, et DNS est indispensable à la localisation des contrôleurs de domaine et du catalogue global. Comprendre leur rôle aide à sécuriser les intégrations applicatives et les postes clients.

      • LDAP/LDAPS : lecture et mise à jour des objets de l’annuaire, authentification au moyen d’un bind, sécurisation via TLS.
      • Kerberos : authentification par tickets entre clients, contrôleur de domaine et services, basée sur les SPN.
      • NTLM : mécanisme hérité utilisé en dernier recours pour la compatibilité ou lorsque Kerberos n’est pas possible.
      • DNS : résolution des noms et enregistrements SRV pour découvrir contrôleurs de domaine, catalogue global et services AD.

      LDAP/LDAPS: à quoi ça sert dans AD ?

      LDAP (Lightweight Directory Access Protocol) est le langage client-serveur utilisé pour interroger et modifier les données d’Active Directory. Un client se connecte au service d’annuaire d’un contrôleur de domaine et effectue un bind pour s’authentifier, puis lit ou met à jour des attributs d’objets (utilisateurs, ordinateurs, groupes, OU, etc.).

      • Usages typiques : recherche d’utilisateurs et de groupes, validation d’appartenance, provisioning applicatif, synchronisation d’attributs, gestion des ACL.
      • Bind simple vs SASL : le bind simple transmet un mot de passe, à utiliser uniquement avec chiffrement. Le bind SASL intègre Kerberos via GSSAPI ou SPNEGO et permet la délégation d’identité côté application.
      • Sécurisation : chiffrer les sessions avec LDAPS sur 636 ou StartTLS sur 389, activer la signature LDAP et la liaison de canal (channel binding), restreindre l’anonymat et appliquer le moindre privilège sur les comptes de service.

      Exemple concret : une application interne exécute une requête LDAP pour vérifier si alice appartient au groupe Finance. Elle se connecte en SASL Kerberos, négocie StartTLS, puis lit l’attribut memberOf de l’objet utilisateur. L’opération et les identifiants circulent chiffrés.

      Kerberos: comment fonctionnent tickets et SPN ?

      Kerberos est le protocole d’authentification par défaut d’AD. Il repose sur des tickets délivrés par le contrôleur de domaine jouant le rôle de KDC (Key Distribution Center) et sur des SPN (Service Principal Names) qui identifient de manière unique les services côté serveur.

      1. Obtention du TGT : au logon, le client envoie une requête d’authentification au KDC. S’il est validé, il reçoit un TGT (Ticket Granting Ticket) utilisable pendant sa durée de vie.
      2. Demande de ticket de service : quand l’utilisateur accède à une application, il présente son TGT au KDC pour obtenir un ticket de service (TGS) ciblant le SPN du service demandé.
      3. Accès au service : le client présente le TGS au service. L’authentification est mutuelle et n’expose pas de mot de passe sur le réseau.
      4. Délégation : un service peut se faire déléguer l’identité de l’utilisateur pour appeler un autre service, selon la configuration de délégation.
      • SPN : chaque service AD doit publier un SPN correct (ex. HTTP/app.societe.fr lié au compte de service). Un SPN erroné provoque une bascule en NTLM.
      • Délégation non contrainte : le service peut se déléguer vers n’importe quel service. Fonctionnelle mais risquée, à éviter.
      • Délégation contrainte : le compte de service ne peut se déléguer que vers une liste de SPN autorisés. Recommandée en production.
      • Délégation contrainte basée sur les ressources (RBCD) : autorisation définie côté ressource cible, utile en environnements distribués.
      • Implications sécurité : durcir les comptes de service (mots de passe robustes, idéalement gMSA), surveiller les SPN et les requêtes anormales pour limiter les attaques de type Kerberoasting.

      NTLM: dans quels cas reste-t-il utilisé ?

      NTLM est un mécanisme d’authentification plus ancien, conservé pour la compatibilité. Il peut encore apparaître quand Kerberos n’est pas disponible ou mal configuré, par exemple dans des workgroups, avec des applications héritées, en accès local, lors de problèmes de DNS ou de SPN, ou dans certains scénarios inter-forêts sans relation d’approbation.

      Conséquences principales : absence d’authentification mutuelle et surface d’attaque accrue (pass-the-hash, NTLM relay). L’objectif d’un domaine moderne est de réduire l’usage de NTLM au strict minimum et de privilégier Kerberos.

      • Auditer puis restreindre NTLM via les stratégies de sécurité de domaine, interdire LM et NTLMv1, n’autoriser que NTLMv2 si nécessaire.
      • Corriger Kerberos pour éviter les bascules: SPN exacts, synchronisation NTP, DNS interne opérationnel.
      • Durcir SMB et HTTP : activer la signature SMB, Extended Protection for Authentication, et protéger contre les relais NTLM.
      • Migrer les applications vers Kerberos ou vers une identité moderne et utiliser des gMSA pour les comptes de service.
      • Limiter les privilèges locaux et déployer une solution de gestion des mots de passe d’administrateur local.

      DNS: pourquoi est-il critique pour AD ?

      AD s’intègre étroitement avec DNS pour permettre la découverte des contrôleurs de domaine, du catalogue global et des services d’annuaire. Les zones DNS intégrées à AD répliquent avec les contrôleurs de domaine et acceptent des mises à jour dynamiques sécurisées. Sans un DNS interne fiable, authentification, jonction au domaine, GPO et réplication tombent en panne.

      • Enregistrements SRV essentiels : _ldap._tcp.dc._msdcs.<domaine>, _kerberos._tcp.<domaine>, _gc._tcp.<forêt>, variantes _sites pour l’affinité de site.
      • Zone _msdcs : contient les références des contrôleurs de domaine et les GUID utilisés par la réplication.
      • Dépendances : localisation du contrôleur de domaine lors du logon, découverte du catalogue global, application des GPO, réplication AD DS et résolution des SPN.
      • Bonnes pratiques : utiliser le DNS interne AD pour la zone du domaine, activer les mises à jour dynamiques sécurisées, nettoyer les enregistrements obsolètes et éviter les résolveurs publics pour les suffixes internes.
      Approfondir l’authentification dans Active Directory

      Comment AD s’intègre-t-il avec d’autres technologies ?

      

      Active Directory ne fonctionne pas en silo. Il s’intègre aux applications et services via des standards d’identité pour offrir SSO, fédération et gestion unifiée des accès. En complément de la version sur site, Azure AD (aujourd’hui Microsoft Entra ID) facilite l’accès aux applications cloud, avec authentification moderne et politiques de sécurité centralisées.

      Concrètement, LDAP sert surtout aux applications historiques qui interrogent l’annuaire AD DS, tandis que SAML 2.0 et OAuth 2.0/OpenID Connect portent le SSO moderne pour les applications web, mobiles et SaaS. Le choix du protocole dépend du contexte projet, des capacités de l’application et du niveau de sécurité attendu.

      • SSO interne Windows : authentification transparente aux applications intégrées au domaine via Kerberos et politiques de groupe.
      • SSO cloud et SaaS : fédération SAML ou OpenID Connect avec Microsoft Entra ID pour Office 365, CRM, ITSM et apps métiers.
      • Applications legacy : contrôle d’accès et annuaire via LDAP contre AD DS, sans refonte applicative.
      • Partenaires/B2B : fédération d’identités avec des fournisseurs externes pour partager des applications en toute sécurité.
      • Environnements hybrides : synchronisation d’identités et stratégies d’accès cohérentes entre site et cloud.

      Comment intégrer des applications via LDAP ou SAML/OAuth ?

      Protocole	Cas d’usage	Avantages
      LDAP	Applications sur site existantes qui valident les utilisateurs et lisent les groupes directement dans AD DS.	Intégration simple côté intranet, exploitation des attributs AD, moindre impact sur des apps non modernisées.
      SAML 2.0	SSO navigateur pour applications web et SaaS.	Fédération sans mot de passe dans l’app, échanges signés, interopérabilité large avec les IdP.
      OAuth 2.0 + OpenID Connect	Applications web et mobiles modernes, API et microservices.	Tokens d’accès et d’identité, MFA et Conditional Access côté IdP, expérience SSO fluide multi-device.

      Bon réflexe projet : conserver LDAP pour les applications legacy qui ne supportent pas la fédération, et privilégier SAML ou OpenID Connect via un fournisseur d’identité comme Microsoft Entra ID pour toutes les applications modernes ou SaaS. Documentez les attributs échangés, mappez les groupes ou rôles, et prévoyez des tests de non-régression.

      ADFS et SSO : quand les utiliser ?

      AD FS apporte de la fédération et du SSO en s’appuyant sur votre AD sur site. C’est pertinent lorsque des exigences techniques ou réglementaires imposent de garder l’authentification chez vous ou lorsque des applications ne supportent que certains protocoles compatibles AD FS. À l’inverse, un IdP SaaS comme Microsoft Entra ID couvre la majorité des usages SSO modernes avec moins d’infrastructure à maintenir.

      • AD FS : avantages : contrôle local de l’authentification, compatibilité avec des apps exigeant une fédération sur site, intégration fine avec AD DS.
      • AD FS : limites : serveurs à opérer (haute disponibilité, mises à jour, certificats, publication), coûts d’exploitation et de sécurité plus élevés.
      • IdP SaaS : avantages : déploiement rapide, MFA et politiques d’accès conditionnel, catalogue d’apps SaaS, moindre complexité d’infrastructure.
      • IdP SaaS : limites : dépendance à la connectivité internet, licences selon fonctionnalités, adaptation nécessaire pour quelques applications très spécifiques.

      En pratique, la plupart des organisations choisissent l’IdP cloud par défaut et réservent AD FS à des cas d’exception liés à des contraintes techniques ou contractuelles, avec un plan de modernisation progressif vers SAML ou OpenID Connect.

      Comment relier AD à Microsoft 365 et aux services SaaS ?

      La connexion d’AD aux services cloud combine synchronisation d’identités et SSO. Azure AD Connect (désormais Microsoft Entra Connect) aligne utilisateurs et groupes entre AD DS et Microsoft Entra ID pour Microsoft 365 et les applications SaaS, puis l’IdP fournit SAML/OpenID Connect, MFA et Conditional Access. Le provisioning applicatif peut être automatisé via SCIM et l’attribution par groupes.

      1. Choisir le modèle d’identité : cloud uniquement, synchronisé avec Password Hash Sync ou Pass-Through Authentication, ou fédéré.
      2. Préparer AD : nettoyer les doublons, définir un suffixe UPN routable, valider les attributs clés (UPN, sourceAnchor).
      3. Installer Entra Connect : configurer la portée de synchronisation, activer si besoin le SSO transparent.
      4. Sécuriser l’IdP : activer MFA, Conditional Access, comptes d’urgence, journaux et alertes.
      5. Intégrer les applications : choisir SAML ou OpenID Connect, mapper les claims, tester et piloter les mises en production.
      6. Automatiser le provisioning : connecter SCIM quand disponible, utiliser l’attribution par groupes et des workflows d’entrée/sortie.
      7. Exploiter et superviser : surveiller la santé de la synchro, les connexions et les anomalies, documenter et former le support.

      Comment sécuriser Active Directory face aux menaces actuelles ?

      Active Directory concentre l’authentification, l’autorisation et les configurations du parc, il est donc une cible prioritaire. Pour passer d’un « zoom » théorique à un plan opérationnel, structurez votre démarche autour de trois piliers complémentaires.

      • Prévenir les vecteurs d’attaque les plus courants (connaître les techniques, leurs prérequis et points de blocage).
      • Durcir l’environnement et appliquer le moindre privilège (séparation des tâches, gestion des comptes à hauts privilèges, postes d’administration dédiés).
      • Surveiller et réagir (journaux, événements clés, intégration SIEM, alertes et remédiations guidées).
      Maîtriser la sécurité dans Active Directory

      Quelles sont les attaques courantes (Kerberoasting, Pass-the-Hash, escalade) ?

      • Kerberoasting: un compte authentifié demande des tickets de service Kerberos (TGS) pour des SPN publiés, puis tente de casser hors ligne le secret du compte de service. Prérequis techniques: présence de SPN sur des comptes de service, secrets faibles ou non renouvelés, absence de contrôle sur les requêtes TGS volumineuses.
      • Pass-the-Hash: réutilisation du hachage NTLM d’un compte pour s’authentifier sans connaître le mot de passe. Prérequis: capacité à extraire des secrets sur un poste compromis (accès LSASS, absence de protection des informations d’identification), réutilisation de mots de passe locaux, NTLM non restreint.
      • Escalade de privilèges: exploitation de délégations et ACL trop larges, GPO mal configurées, groupes à privilèges surchargés, délégation Kerberos non contrainte, chemins d’attaque liés aux appartenances et aux droits hérités. Prérequis: premier point d’appui dans le domaine, visibilité sur les relations objets et groupes.

      La réduction de surface passe par des secrets robustes et tournants, la segmentation des privilèges, la suppression des délégations risquées et l’audit régulier des groupes et ACL. Les politiques de mot de passe et l’authentification multi-facteurs renforcent la résistance initiale, tandis que les journaux d’événements d’AD permettent de détecter requêtes Kerberos anormales, créations de comptes et modifications non planifiées.

      Comment appliquer le moindre privilège et gérer les comptes à hauts privilèges (PAM/PAW) ?

      Le moindre privilège s’appuie sur la séparation des tâches et des périmètres d’administration. Les comptes à hauts privilèges doivent être rares, dédiés à l’administration et utilisés depuis des postes d’administration sécurisés. Des solutions de gestion des accès à privilèges (PAM) et des postes d’administration dédiés (PAW) limitent l’exposition des secrets et réduisent les déplacements latéraux.

      • Mettre en place une stratification des niveaux d’administration (Tier 0 pour AD/DC, Tier 1 pour serveurs, Tier 2 pour postes) et interdire les connexions croisées.
      • Utiliser des comptes d’administration dédiés par usage (bureautique vs admin), jamais réutilisés pour la navigation web ou la messagerie.
      • Imposer l’authentification multi-facteurs sur tous les comptes à privilèges et restreindre « Log on locally/Remote logon » aux seuls PAW.
      • Réduire et contrôler l’appartenance aux groupes Domain Admins, Enterprise Admins, Backup Operators; auditer régulièrement AdminSDHolder et les ACL critiques.
      • Limiter la délégation Kerberos, marquer les comptes sensibles « Sensitive and cannot be delegated », désactiver la délégation non contrainte.
      • Mettre en œuvre du privilège à la demande (just-in-time) et des approbations temporisées pour les élévations.

      Comment sécuriser les comptes et services (MSA/gMSA, SPN) ?

      Les comptes de service sont souvent la clef des attaques Kerberos. Les Managed Service Accounts (MSA) et Group Managed Service Accounts (gMSA) automatisent la rotation des secrets et réduisent les erreurs humaines. Une hygiène stricte des SPN limite l’exposition et simplifie la détection.

      • Standardiser l’usage de gMSA pour les services applicatifs et planifier une rotation automatique et fréquente des secrets.
      • Éviter tout service exécuté avec des comptes Domain Admins; attribuer uniquement les droits nécessaires au service.
      • Inventorier et nettoyer les SPN: supprimer ceux qui sont orphelins ou obsolètes, regrouper par rôle et propriétaire.
      • Activer les chiffrages Kerberos modernes sur les comptes de service, interdire les algorithmes hérités quand c’est possible.
      • Interdire la pré-authentification désactivée sur les comptes utilisateurs et services.
      • Marquer les comptes d’admins et de service critiques « Account is sensitive and cannot be delegated ».
      Découvrir le métier de Microsoft Azure : DP-203 ou AZ-104

      Quelles GPO et durcissements pour protéger DC et postes ?

      • Gestion des locaux admins: déployer Windows LAPS pour des mots de passe d’administrateur local uniques, forts et tournants.
      • Protection des identifiants: activer Credential Guard et Remote Credential Guard, protéger LSASS (RunAsPPL), interdire le cache d’identifiants sur les PAW.
      • Durcissement réseau: désactiver SMBv1, imposer la signature SMB, restreindre NTLM et activer l’audit, imposer LDAP signing et channel binding.
      • Chiffrement et démarrage sécurisé: chiffrer les volumes systèmes (BitLocker) et protéger le firmware; interdire les périphériques amovibles sur DC.
      • Réduction de surface sur DC: limiter les rôles installés, désactiver le service Print Spooler et les services non essentiels, filtrer l’administration distante.
      • Contrôle d’exécution: appliquer AppLocker ou Windows Defender Application Control sur postes d’admin et serveurs sensibles.
      • Politiques de mots de passe: mettre en place des politiques fines (FGPP) adaptées aux comptes à privilèges et de service.
      • Audit avancé: activer l’audit « Directory Service Changes », « Logon/Logoff », « Object Access », « Policy Change » et journaliser vers un collecteur central.

      Ces paramètres GPO réduisent l’exploitation des hachages et tickets, renforcent l’authentification et rendent visibles les changements sensibles. Priorisez le durcissement des DC et des PAW, puis étendez progressivement à l’ensemble du parc.

      Monitoring et audit: quels journaux et événements suivre ?

      • Authentification Kerberos et NTLM: 4768/4769/4771/4770 (AS/TGS), 4776 (NTLM). Surveiller des pics de TGS, des échecs inhabituels, des usages NTLM persistants.
      • Connexions et privilèges: 4624/4625 (logons), 4648 (credentials explicites), 4672 (privilèges spéciaux attribués).
      • Modifications d’objets AD: 5136/5137/5139 (Directory Service), 4720/4726 (création/suppression d’utilisateurs), 4728/4729/4732/4733 (adhésions aux groupes), 4739/4719/4735/4737 (changements de stratégie et GPO).
      • Signaux d’attaque AD spécifiques: événements 4662 liés aux droits de réplication (replication-get-changes) indicateurs d’un DCSync; création de SPN inattendus; élévations sur comptes sensibles.
      • Infrastructure: journaux DNS et DFSR pour détecter détournements de résolution ou anomalies de réplication; intégration Sysmon sur hôtes critiques pour les processus et réseaux.

      Centralisez les journaux dans un SIEM, définissez des alertes temps réel sur les événements clés et basez-vous sur des profils de comportement: pics de requêtes TGS, ajouts soudains à Domain Admins, création de GPO non planifiée. Couplée à des alertes, cette visibilité permet une réponse rapide aux menaces et favorise la conformité avec les politiques de sécurité et d’audit évoquées plus haut.

      Comment assurer sauvegarde et reprise après sinistre (DR) ?

      Active Directory fait battre le cœur de l’authentification et des autorisations, mais la réplication n’est pas une sauvegarde. Un plan de reprise d’activité dédié à AD protège votre entreprise contre la suppression accidentelle d’objets, la corruption de la base NTDS, un ransomware ou la perte d’un contrôleur de domaine. L’objectif est clair : documenter, sauvegarder, tester, puis restaurer dans des délais compatibles avec vos RTO/RPO.

      • Définir des objectifs RPO/RTO réalistes et documentés pour AD, DNS et SYSVOL.
      • Appliquer la règle 3-2-1 (3 copies, 2 supports, 1 hors site/hors ligne), chiffrée et immuable.
      • Effectuer des sauvegardes cohérentes applicatives via VSS de l’état du système des contrôleurs de domaine, jamais un simple snapshot non applicatif.
      • Conserver au moins une sauvegarde valide plus récente que la durée de rétention des objets supprimés (tombstone/recycle bin), typiquement 180 jours selon votre forêt.
      • Documenter rôles FSMO, topologie de réplication, sites et sous-réseaux, mots de passe DSRM et procédures d’escalade.
      • Sauvegarder aussi les briques adjacentes : DNS, PKI AD CS, DHCP, scripts de connexion et GPO.
      • Tester régulièrement des restaurations et valider la santé AD avec dcdiag et repadmin.
      • Après incident, planifier la rotation du compte KRBTGT et la revue des délégations et GPO.
      Se former au développement logiciel

      Quoi sauvegarder et à quelle fréquence ?

      Priorité aux contrôleurs de domaine. Une sauvegarde État du système couvre la base NTDS.dit, le registre, les fichiers de démarrage, le catalogue global, SYSVOL (GPO, scripts) et, si présent, DNS intégré à AD. Complétez avec les exports et sauvegardes des services connexes. Exemple de calendrier minimal ci-dessous.

      Élément	Méthode recommandée	Fréquence minimale
      Contrôleurs de domaine (AD DS, NTDS.dit, catalogue global)	Sauvegarde État du système via VSS (Windows Server Backup ou solution compatible AD). Éviter la restauration de snapshots non applicatifs. En VM, vérifier la prise en charge GenerationID.	Quotidien incrémental + hebdomadaire complète
      SYSVOL, GPO, scripts de connexion	Inclus dans l’État du système. Export GPO dédié (Backup-GPO) pour versionner la configuration.	À chaque changement majeur + hebdomadaire
      DNS intégré à AD	Inclus dans l’État du système. Sinon, sauvegarde du service DNS et de sa zone.	Hebdomadaire + avant modifications
      Rôles FSMO, sites, sous-réseaux, liaisons	Inventaire et exports (PowerShell, repadmin, ntdsutil pour la liste des rôles). Documentation à jour.	Mensuel + avant changement d’architecture
      PKI AD CS (si déployée)	Sauvegarde de la base CA, des journaux et de la clé privée. Export des modèles et de la configuration.	Mensuel + après modification de la CA
      DHCP	Export de la configuration et sauvegarde serveur.	Hebdomadaire + avant modifications
      Azure AD Connect / synchronisation hybride	Export de la configuration et de la clé de chiffrement si utilisée.	Avant mise à jour/patch + trimestriel
      Mots de passe DSRM, runbooks et scripts d’automatisation	Stockage chiffré hors ligne, avec contrôle d’accès et audit.	À chaque mise à jour

      • Points d’attention : tester la restauration sur un clone isolé, chiffrer et rendre immuables les copies hors ligne, limiter les privilèges des comptes de sauvegarde, surveiller l’expiration et la réussite des jobs.
      • Rétention : conserver des points mensuels et trimestriels en plus du quotidien. Garder au moins un jeu dans la fenêtre de purge des objets supprimés de votre forêt.

      Restauration autoritative vs non autoritative : quand et comment ?

      Deux approches existent. La restauration non autoritative remet en service un DC depuis une sauvegarde de l’État du système puis laisse la réplication écraser les données restaurées avec la version la plus récente des autres DC. Elle est adaptée à une panne ou corruption locale d’un contrôleur de domaine. La restauration autoritative force, via ntdsutil, une ou plusieurs unités (objets, OU, GPO) à être considérées comme la référence. Elle s’emploie après des suppressions massives ou des modifications indésirables côté annuaire.

      1. Qualifier l’incident et le périmètre : objets supprimés, DC défaillant, SYSVOL incohérent. Vérifier RPO/RTO et choisir la stratégie.
      2. Restauration non autoritative d’un DC
         • Démarrer le serveur en Directory Services Restore Mode (DSRM).
         • Restaurer l’État du système depuis la sauvegarde la plus récente et redémarrer en mode normal.
         • Laisser la réplication converger, puis valider avec dcdiag et repadmin /replsummary.
      3. Restauration autoritative d’objets/OU/GPO
         • Restaurer l’État du système d’un DC en DSRM à une date comprise dans la fenêtre de rétention.
         • Lancer ntdsutil pour marquer les objets comme autoritatifs (authoritative restore d’un objet, d’un sous-arbre ou d’une GPO).
         • Redémarrer, forcer la réplication (repadmin /syncall) et contrôler les journaux.
      4. Cas particuliers
         • SYSVOL sous DFSR : appliquer la procédure de restauration autoritative/non autoritative DFSR adaptée.
         • Si le détenteur d’un rôle FSMO est perdu, reprendre le rôle sur un autre DC (ntdsutil ou PowerShell).
      5. Post-restauration : revue des GPO et délégations, rotation du compte KRBTGT si compromission suspectée, ré-enrôlement éventuel de machines affectées.

      Comment tester votre plan de reprise d’activité AD ?

      1. Exercice en environnement isolé : restaurer un DC en non autoritatif, valider l’ouverture de session, DNS et la réplication.
      2. Test de restauration autoritative : supprimer une OU et une GPO de test, restaurer avec ntdsutil, mesurer les délais et l’impact.
      3. Perte d’un site : simuler l’indisponibilité d’un DC d’agence, vérifier la continuité d’authentification et la redirection des clients.
      4. Reprise de rôles FSMO : scénariser la perte du détenteur, reprendre les rôles et vérifier les opérations dépendantes.
      5. Validation RPO/RTO : chronométrer sauvegarde, restauration, convergence de réplication, puis mettre à jour les objectifs si nécessaire.
      6. Audit de la documentation : runbooks, mots de passe DSRM, contacts d’escalade, localisation des supports hors ligne. Corriger les écarts.
      7. Fréquence : au minimum semestrielle et après tout changement majeur (mise à jour, ajout de site, refonte GPO).

      Conseil pratique : normaliser les procédures dans des runbooks pas-à-pas, prévoir des check-lists de validation technique, et conserver une copie hors ligne. Automatisez les exports GPO et les inventaires AD pour réduire le temps de reprise et fiabiliser les tests.

      Se former à la sauvegarde et au DR d’Active Directory

      Active Directory à l’heure du cloud Microsoft Azure

      

      À l’ère du cloud, l’identité devient le nouveau plan de contrôle. Les entreprises combinent AD DS sur site pour les workloads hérités et Azure AD renommé Microsoft Entra ID pour les applications SaaS et Azure. Avec Azure AD Connect, la synchronisation des identités unifie profils, groupes et accès pour une expérience cohérente et sécurisée.

      L’enjeu n’est plus de choisir entre on-prem et cloud, mais de bâtir une identité hybride qui concilie productivité, sécurité moderne et exigences de conformité, tout en clarifiant le rôle de chaque brique.

      AD on-prem vs Azure AD vs Azure AD Domain Services: quelles différences ?

      Solution	Rôle	Cas d’usage	Limites clés
      Active Directory Domain Services (AD DS) sur site	Annuaire d’entreprise sur Windows Server, protocoles LDAP, Kerberos et NTLM, jointure au domaine, GPO.	Postes Windows, serveurs, applications dépendantes d’une jointure AD et des GPO, réseaux internes.	Administration d’infrastructure requise, pas de SAML/OIDC natif, dépendance réseau, pas d’accès conditionnel cloud.
      Azure AD / Microsoft Entra ID	Fournisseur d’identité cloud pour Azure, Microsoft 365 et SaaS, standards OAuth 2.0, OpenID Connect et SAML.	SSO multi-cloud, B2B/B2C, accès à distance, gestion des appareils Azure AD Join, accès conditionnel et MFA.	Pas de LDAP ni GPO, pas de jointure AD classique, pas fait pour les applis qui exigent NTLM/Kerberos côté serveur.
      Azure AD Domain Services (AAD DS)	Domaine managé dans Azure exposant LDAP, Kerberos et NTLM sans déployer de contrôleurs de domaine.	Reprise d’applis héritées dans Azure qui exigent jointure au domaine ou LDAP, sans gérer AD DS soi-même.	Pas d’accès Domain Admin, pas d’extensions de schéma libres, pas de relations d’approbation, fonctionnalités limitées et non répliquées vers l’on-prem.

      En synthèse, AD DS reste la pierre angulaire des environnements locaux, Entra ID est le plan d’identité cloud et AAD DS sert de pont pour les applications legacy à migrer dans Azure.

      Azure AD Connect: quels modes de synchronisation (PHS, PTA, fédération) ?

      Azure AD Connect désormais Microsoft Entra Connect Sync aligne les identités entre AD DS et Entra ID. Côté authentification, trois modèles couvrent l’essentiel.

      Mode	Principe	Sécurité	Expérience utilisateur
      PHS Password Hash Synchronization	Synchronise dans le cloud un haché dérivé des mots de passe AD. Authentification réalisée dans Entra ID.	Hachés dérivés salés et chiffrés, pas de mot de passe en clair, bénéfice des contrôles cloud tels que Smart Lockout et détection de risques.	Haute résilience, aucune dépendance à l’AD on-prem pour se connecter, SSO possible avec Seamless SSO.
      PTA Pass-through Authentication	Agents sur site valident en temps réel les connexions contre AD via un canal sortant sécurisé.	Aucun haché stocké dans le cloud, chiffrement bout en bout. Dépendance à la connectivité et à la disponibilité des agents.	SSO possible avec Seamless SSO. En cas d’agents indisponibles, l’authentification échoue.
      Fédération AD FS ou IdP tiers	Redirection vers un service de fédération sur site qui émet le jeton.	Maîtrise locale des politiques et des certificats, mais surface d’attaque accrue et complexité opérationnelle.	SSO riche, compatibilité cartes à puce et exigences spécifiques. Forte dépendance à l’infrastructure fédérée.

      • Haute disponibilité et bascules
        – PHS: un serveur Entra Connect en mode staging prêt à prendre la main, supervision de la synchro et du password writeback si utilisé.
        – PTA: déployer au moins 3 agents sur site, mises à jour et surveillance régulières, bascule automatique entre agents.
        – Fédération: ferme AD FS redondée avec répartition de charge, deux proxies WAP, certificats suivis, plan de repli documenté vers PHS ou PTA, comptes de secours cloud.

      Remarque: pour des besoins de provisioning léger, Microsoft Entra Cloud Sync peut compléter ces approches, mais il ne remplace pas les modes d’authentification ci-dessus.

      Quels scénarios d’identité hybride mettre en place ?

      • Cloud-first PHS ou PTA, appareils Azure AD Join avec Intune, SSO aux applications SaaS. Critères: mobilité, réduction de l’empreinte on-prem, adoption rapide des contrôles cloud.
      • Staged migration synchronisation des identités, Hybrid Azure AD Join, retrait progressif d’AD FS, bascule vers PHS, puis migration d’applications. Critères: parc important, contraintes de change, coexistence nécessaire.
      • Resource forest conservation d’une forêt AD pour serveurs et applications héritées, Entra ID pour le SaaS. Critères: dépendances Kerberos ou GPO, contraintes réglementaires locales.
      • Lift-and-shift d’applications legacy vers Azure usage d’AAD DS pour fournir LDAP et jointure de domaine managés dans une VNet. Critères: réécriture applicative non envisageable à court terme.

      Cas concret: une entreprise multi-sites déjà sur Microsoft 365 remplace AD FS par PHS, active Seamless SSO, passe ses postes récents en Azure AD Join gérés dans Intune et garde AD DS pour fichiers et imprimantes. Une application RH exigeant LDAP est déplacée dans Azure et rattachée à AAD DS, en attendant sa modernisation.

      Quelles bonnes pratiques de sécurité cloud (MFA, Conditional Access) ?

      • MFA partout avec number matching et facteurs résistants au phishing, FIDO2 et Windows Hello for Business en priorité.
      • Accès conditionnel bloquer les protocoles hérités, exiger un appareil conforme ou hybride, évaluer risque utilisateur et session, utiliser les contextes d’authentification.
      • Protection des identités activer les politiques basées sur le risque et la Continuous Access Evaluation, alertes sur activités anormales.
      • Gouvernance des privilèges Privileged Identity Management en activation juste-à-temps avec approbation, revue d’accès périodique.
      • Hybride sécurisé Password Protection on-prem, SSPR avec writeback, durcissement des contrôleurs de domaine, postes d’administration sécurisés.
      • Comptes de secours cloud hors politiques, stockés et surveillés, tests de scénarios de repli.

      En pratique, commencez par un socle: bloquer l’authentification de base, imposer MFA à tous, créer une politique d’accès conditionnel qui exige appareil conforme ou hybride pour les données sensibles, et migrer de la fédération vers PHS pour bénéficier des protections natives d’Entra ID.

      Mettre en œuvre l’identité hybride avec Liora

      Quels outils d’administration et d’audit privilégier ?

      Pour l’exploitation quotidienne d’Active Directory, combinez les consoles MMC, PowerShell et les utilitaires de diagnostic, puis complétez par des outils d’inventaire et d’audit. L’objectif est d’administrer, dépanner et rendre compte efficacement, tout en s’appuyant sur les politiques de groupe, la réplication et les journaux d’événements déjà évoqués plus haut pour assurer la cohérence et la traçabilité des changements.

      • Consoles graphiques : ADUC, Centre d’administration Active Directory (ADAC), Sites et services AD, Domaines et approbations, GPMC.
      • Ligne de commande et diagnostic : dcdiag, repadmin, nltest, gpresult, Observateur d’événements.
      • Automatisation et reporting : PowerShell modules ActiveDirectory et GroupPolicy, exports CSV/HTML, scripts d’inventaire réguliers.
      • Surveillance et hybride : journaux de sécurité Windows, alertes SIEM, supervision de la réplication et, en environnement hybride, contrôle de la synchronisation avec Azure AD Connect.

      Quels outils natifs utiliser (ADUC, GPMC, PowerShell, dcdiag, repadmin) ?

      • ADUC (Active Directory Users and Computers) → création et désactivation de comptes, réinitialisation de mots de passe, gestion des appartenances aux groupes, déplacement d’objets et édition d’attributs courants.
      • GPMC (Group Policy Management Console) → création, liaison et sauvegarde de GPO, filtrage WMI, Modélisation et Résultats de stratégie pour le dépannage des paramètres effectivement appliqués.
      • PowerShell (module ActiveDirectory) → opérations en masse et reporting précis : inventaire des comptes inactifs, export des membres de groupes sensibles, vérification des SPN, mesure de la réplication (ex. Get-ADReplicationPartnerMetadata), génération de rapports CSV/HTML.
      • PowerShell (module GroupPolicy) → audit et documentation des GPO (Get-GPOReport), comparaison et sauvegarde automatisées.
      • dcdiag → contrôle de santé des contrôleurs de domaine, enregistrements DNS, services clés et tests ciblés par DC ou par site.
      • repadmin → vue d’ensemble de la topologie et des délais de réplication (replsummary), analyse des erreurs (showrepl) et synchronisation à la demande (syncall).
      • gpresult / rsop.msc → diagnostic fin des paramètres GPO appliqués à un poste ou un utilisateur pour résoudre les écarts de configuration.
      • Observateur d’événements → consultation des journaux de sécurité, Directory Services et DNS pour le suivi des modifications, des échecs d’ouverture de session et des alertes de sécurité.

      Pratique au quotidien : définissez une routine. Quotidien : surveiller les alertes critiques, l’état des DC et la synchronisation. Hebdomadaire : contrôler la réplication, l’état de SYSVOL et les échecs Kerberos anormaux. Mensuel : exporter des rapports de comptes inactifs, membres de groupes à privilèges et sauvegarder la configuration GPO. Testez régulièrement la restauration de l’état du système des DC.

      Comment évaluer l’exposition avec des outils d’inventaire/audit ?

      L’évaluation de l’exposition repose sur un inventaire fiable, l’audit des droits et la cartographie des chemins d’attaque. Les approches d’analyse de graphes représentent les relations entre comptes, groupes, ACL et délégations pour révéler des élévations de privilèges possibles. Complétez ces vues par des contrôles récurrents, afin de suivre l’évolution des privilèges, des configurations et de la surface d’attaque au fil du temps.

      • Comptes et identités : comptes inactifs depuis X jours, mots de passe qui n’expirent jamais, comptes sans préauthentification Kerberos, comptes de service avec SPN et mots de passe faibles, couverture gMSA/LAPS.
      • Groupes à privilèges : effectifs et héritages de Domain Admins, Enterprise Admins, Schema Admins, Administrators locaux via GPO, groupes imbriqués non documentés.
      • Délégations et ACL : permissions inhabituelles sur OU, GPO et conteneurs critiques, modifications d’AdminSDHolder, délégations Kerberos non contraintes ou trop larges.
      • Réplication et santé des DC : erreurs dcdiag/repadmin, retards de réplication, état de SYSVOL via DFSR, horodatages incohérents.
      • Postes et serveurs : versions d’OS obsolètes, protocoles faibles activés, configuration des GPO de durcissement et écarts constatés par gpresult.
      • Journaux et alertes : pics d’échecs d’ouverture de session, anomalies Kerberos, changements de membres dans les groupes à privilèges, suppression ou création massive d’objets.
      • Hybride : état de la synchronisation et alertes Azure AD Connect, cohérence des identités et des groupes entre environnements.

      Planifiez ces contrôles, centralisez les résultats, suivez des métriques simples : nombre de comptes inactifs traités, variation du nombre de membres de groupes privilégiés, temps moyen de réplication, taux de conformité des GPO critiques et volume d’alertes de sécurité résolues.

      Mettre en pratique l’administration et l’audit AD

      Conclusion : Active Directory, la clé d’une infrastructure IT solide, performante et sécurisée

      Depuis sa création par Microsoft, Active Directory s’est affirmé comme une pierre angulaire dans le paysage informatique moderne. Il centralise les identités, les accès et les politiques, tout en s’intégrant aux applications et aux services, sur site comme dans le cloud. En misant sur une architecture claire, des contrôles de sécurité robustes et une approche hybride grâce aux outils de synchronisation, AD demeure la référence pour bâtir une infrastructure fiable, performante et résiliente.

      • Structure et architecture : maîtrisez les concepts clés (domaines, OU, arbres, forêts) et l’architecture logique et physique (contrôleurs de domaine, réplication, DNS), sans oublier les rôles critiques comme le catalogue global.
      • Sécurité et conformité : appuyez-vous sur les mécanismes de sécurité d’AD et les GPO pour appliquer MFA, RBAC, politiques de mots de passe et audit, et faire respecter le principe du moindre privilège.
      • Hybride et cloud : combinez AD sur site avec le cloud via Azure AD Connect et l’intégration applicative afin d’offrir SSO et gouvernance unifiée des identités (Microsoft Entra ID, ex Azure AD).
      • Fonctionnalités essentielles : révisez l’authentification et l’autorisation, la délégation, la gestion par stratégies et la réplication pour une administration cohérente à l’échelle de l’entreprise.
      • Cadre et évolutions : replacez vos choix techniques dans l’histoire d’AD pour anticiper les nouveautés et aligner architecture, sécurité et opérations.

      Afin d’apprendre à maîtriser Active Directory, vous pouvez choisir Liora. Notre formation d’administrateur système, réseaux et cloud vous permettra d’apprendre à concevoir, mettre en œuvre, sécuriser, administrer, maintenir et surveiller les infrastructures. Vous découvrirez l’administration des systèmes tels que Windows et Linux, des réseaux comme WAN et LAN et des bases de données. Le programme couvre aussi les solutions de gestion des parcs informatiques, d’automatisation et de sécurité.

      Par ailleurs, ce cursus axé sur le Cloud couvre aussi les aspects tels que la virtualisation et les architectures hybrides. À la fin du parcours, vous pourrez recevoir une certification Cloud AWS et valider le titre « Administrateur d’infrastructures sécurisées » délivré par le Ministère du Travail. En parallèle, nous proposons aussi une formation permettant de maîtriser le cloud Azure en seulement 5 jours. Vous découvrirez les différents services proposés par la plateforme de Microsoft, et recevrez la certification AZ-900 !

      Toutes nos formations se complètent intégralement à distance, et notre organisme est éligible au CPF pour le financement. Découvrez dès maintenant Liora !

      Se former à Active Directory

      Vous savez tout sur Active Directory. Pour plus d’informations sur le même sujet, découvrez notre dossier complet sur Unix et notre dossier consacré au cloud Microsoft Azure.