Dans une entreprise équipée de Windows, il faut pouvoir reconnaître les utilisateurs, les ordinateurs et les ressources avant de leur accorder un accès. Active Directory répond précisément à ce besoin en centralisant les identités, les droits et une grande partie des règles réseau. Je vous explique son fonctionnement, ses composants, ses usages concrets et la différence avec Microsoft Entra ID.
L’essentiel à retenir sur Active Directory
- Active Directory Domain Services centralise les comptes, les ordinateurs, les groupes et les ressources d’un réseau Windows.
- Le contrôleur de domaine authentifie les utilisateurs et applique les règles de sécurité.
- Les stratégies de groupe permettent de configurer automatiquement les postes et les serveurs.
- DNS, Kerberos et LDAP sont des briques essentielles au bon fonctionnement de l’annuaire.
- Microsoft Entra ID gère principalement les identités cloud, tandis qu’Active Directory reste orienté réseau local.
Active Directory, c’est quoi au juste ?
Active Directory est le service d’annuaire de Microsoft intégré à Windows Server. Il enregistre les objets d’un réseau, comme les comptes utilisateurs, les postes, les serveurs, les imprimantes et les groupes, afin que l’entreprise puisse les identifier et contrôler leurs accès.
Concrètement, lorsqu’un salarié ouvre une session sur son ordinateur professionnel, Active Directory vérifie son identité et détermine ce qu’il est autorisé à utiliser. Il peut accéder à un dossier partagé, à une imprimante ou à une application sans que l’administrateur ait besoin de créer manuellement chaque droit sur chaque machine.
Je le présente souvent comme un répertoire centralisé associé à un système de contrôle. Le répertoire décrit les ressources disponibles, tandis que les règles indiquent qui peut les utiliser, depuis quel appareil et dans quelles conditions.
Active Directory Domain Services et les autres services AD
Quand on parle d’Active Directory, on désigne généralement Active Directory Domain Services, abrégé AD DS. C’est le composant chargé de l’annuaire, de l’authentification des utilisateurs et de l’organisation logique du réseau.
Microsoft propose aussi d’autres services portant le nom Active Directory. AD CS gère les certificats, AD FS la fédération d’identités et AD LDS fournit un annuaire plus léger pour certaines applications. Ces services peuvent fonctionner ensemble, mais ils ne remplacent pas le rôle central d’AD DS dans un domaine Windows.
Comment fonctionne un domaine Windows avec Active Directory
Le cœur du système est le contrôleur de domaine. Il s’agit d’un serveur Windows qui héberge une copie de l’annuaire et répond aux demandes d’authentification. Dans une infrastructure sérieuse, je recommande de prévoir au moins deux contrôleurs de domaine afin de limiter le risque de panne unique.
Les objets stockés dans l’annuaire
Active Directory organise les informations sous forme d’objets. Un utilisateur possède par exemple un nom, un identifiant, un service, des groupes d’appartenance et des autorisations. Un ordinateur peut être associé à un site, une unité organisationnelle et un ensemble de règles de configuration.
- Utilisateurs pour gérer les identités et les comptes de service.
- Groupes pour attribuer des droits à plusieurs personnes en une seule fois.
- Ordinateurs pour identifier les postes et serveurs joints au domaine.
- Unités d’organisation, ou OU, pour structurer les objets par service, site ou fonction.
- Imprimantes et ressources pour faciliter la publication et la recherche sur le réseau.
Cette organisation évite de gérer les permissions personne par personne. Par exemple, je peux créer un groupe « Comptabilité », lui donner accès à un dossier partagé, puis ajouter ou retirer les employés concernés. Le changement est plus rapide et surtout plus facile à auditer.
Le rôle indispensable du DNS
Active Directory dépend fortement du DNS, le service qui traduit les noms de machines en adresses réseau. Les postes clients utilisent notamment les enregistrements DNS pour trouver les contrôleurs de domaine et les services nécessaires à leur connexion.
Une erreur de DNS peut donc donner l’impression qu’Active Directory est en panne alors que l’annuaire fonctionne correctement. Dans la pratique, je vérifie toujours la configuration DNS avant d’accuser les stratégies de groupe ou les identifiants.
Authentification, LDAP et Kerberos
Lorsqu’un utilisateur ouvre une session, Active Directory s’appuie principalement sur Kerberos, un protocole d’authentification qui évite de transmettre directement le mot de passe sur le réseau. Le protocole LDAP permet, lui, de consulter et de modifier les informations de l’annuaire selon les autorisations définies.
Active Directory utilise également la réplication entre contrôleurs de domaine. Une modification effectuée sur un contrôleur est propagée aux autres, avec des mécanismes destinés à maintenir une vision cohérente de l’annuaire.
Ce que les équipes informatiques gèrent au quotidien
Active Directory ne sert pas uniquement à créer des comptes. Il devient réellement utile lorsqu’il automatise les tâches répétitives et impose une configuration cohérente sur l’ensemble du parc informatique.
Créer et administrer les identités
L’administrateur peut créer un compte, le rattacher à un service, l’ajouter à plusieurs groupes et définir les conditions de connexion. Lorsqu’un collaborateur quitte l’entreprise, la désactivation du compte coupe rapidement ses accès aux ressources du domaine.
Les groupes doivent toutefois être conçus avec méthode. Donner directement des permissions à chaque utilisateur produit vite un annuaire difficile à comprendre. Une structure fondée sur les rôles et les groupes métiers reste généralement plus propre et plus durable.
Appliquer des règles avec les stratégies de groupe
Les Group Policy Objects, ou GPO, permettent d’appliquer des paramètres à un ensemble d’utilisateurs ou d’ordinateurs. On peut imposer le verrouillage automatique de session, déployer une configuration réseau, interdire certains logiciels ou configurer des règles de sécurité.
Une GPO bien ciblée fait gagner beaucoup de temps. En revanche, une accumulation de règles mal documentées peut ralentir l’ouverture de session et provoquer des comportements difficiles à expliquer. Je conseille de conserver une documentation simple indiquant le but, la portée et le propriétaire de chaque stratégie.
Structurer les domaines, les sites et les unités d’organisation
Une unité d’organisation sert à regrouper des objets et à appliquer des règles adaptées. Elle peut représenter un service, une agence ou un type de matériel. Les sites Active Directory décrivent plutôt la localisation physique et la structure réseau, ce qui aide à optimiser l’authentification et la réplication.
La forêt représente le niveau logique le plus large. Elle peut contenir plusieurs domaines, mais une petite entreprise n’a généralement pas besoin d’une architecture complexe. Multiplier les domaines ou les forêts sans raison augmente la charge d’administration et rend les évolutions plus délicates.
Active Directory local, Entra ID ou environnement hybride
La confusion entre Active Directory et Microsoft Entra ID est fréquente, notamment depuis le changement de nom d’Azure Active Directory. Les deux solutions gèrent des identités, mais elles ne répondent pas exactement aux mêmes besoins.
| Critère | Active Directory Domain Services | Microsoft Entra ID |
|---|---|---|
| Hébergement | Serveurs locaux ou machines virtuelles gérées par l’entreprise | Service cloud administré par Microsoft |
| Usage principal | Domaines Windows, serveurs, fichiers, postes et applications internes | Microsoft 365, applications cloud et accès conditionnels |
| Protocoles courants | Kerberos, LDAP, DNS et stratégies de groupe | Protocoles d’identité modernes, authentification multifacteur et fédération |
| Gestion | Contrôleurs de domaine, sauvegardes, réplication et mises à jour à la charge de l’entreprise | Infrastructure sous-jacente gérée par Microsoft |
Entra ID ne remplace donc pas automatiquement Active Directory. Une entreprise qui utilise encore des partages SMB, des applications anciennes ou des GPO peut avoir besoin d’AD DS, même si elle exploite Microsoft 365 au quotidien.
Le modèle hybride relie les deux environnements. Les identités locales peuvent être synchronisées vers le cloud afin que les collaborateurs utilisent une identité cohérente pour les ressources internes et les services en ligne. Cette approche est souvent réaliste, mais elle ajoute une dépendance entre plusieurs systèmes qu’il faut surveiller.
Lire aussi : Intranet SharePoint - Comment bâtir un portail interne efficace ?
Et Microsoft Entra Domain Services ?
Microsoft Entra Domain Services fournit dans Azure certaines fonctions héritées d’un domaine Windows, notamment LDAP, Kerberos, NTLM et les stratégies de groupe. Il peut être utile pour héberger une application ancienne dans le cloud sans déployer soi-même des contrôleurs de domaine.
Ce service ne constitue pas une copie complète et administrable d’un Active Directory local. Il répond à un besoin précis de compatibilité. Je le considérerais donc comme une solution intermédiaire, pas comme le choix automatique pour toutes les infrastructures.
Les erreurs qui fragilisent un environnement Active Directory
Un annuaire mal entretenu devient rapidement une source de risques. Les comptes oubliés, les droits excessifs et les contrôleurs de domaine non surveillés peuvent faciliter une compromission ou compliquer une simple opération de support.
- Conserver les comptes inactifs au lieu de les désactiver après un départ ou une longue absence.
- Donner des droits d’administrateur à trop d’utilisateurs ou utiliser le même compte privilégié partout.
- Négliger les sauvegardes et la procédure de restauration de l’annuaire.
- Installer des contrôleurs de domaine sans stratégie DNS claire et documentée.
- Créer trop de GPO ou les appliquer à l’ensemble du parc sans phase de test.
- Oublier les comptes de service, souvent dotés de droits importants et rarement surveillés.
La sécurité passe aussi par la séparation des privilèges. Un compte utilisé pour lire ses e-mails ne devrait pas servir à administrer le domaine. L’authentification multifacteur, la limitation des comptes privilégiés et la surveillance des événements complètent utilement les contrôles natifs d’Active Directory.
Je conseille également de tester régulièrement une restauration. Une sauvegarde dont personne n’a vérifié la restauration n’est qu’une hypothèse. La continuité d’activité dépend autant de la procédure et de la documentation que de la présence des fichiers de sauvegarde.
Ce que je vérifierais avant de déployer Active Directory
Avant toute installation, je commencerais par cartographier les utilisateurs, les postes, les serveurs, les sites géographiques et les applications qui ont besoin d’une authentification Windows. Cette étape évite de construire une architecture compliquée pour répondre à un besoin qui pourrait être couvert plus simplement.
- Définir le périmètre du domaine et les ressources à protéger.
- Préparer le DNS et vérifier la résolution des noms sur les futurs clients.
- Prévoir la redondance avec plusieurs contrôleurs de domaine lorsque l’activité le justifie.
- Organiser les OU et les groupes selon les fonctions réelles de l’entreprise.
- Tester les GPO sur un groupe pilote avant leur déploiement général.
- Documenter les comptes privilégiés, les sauvegardes et la procédure de récupération.
Le bon choix dépend surtout de l’existant. Une petite structure qui utilise uniquement des applications cloud n’a pas forcément intérêt à gérer des serveurs Active Directory. À l’inverse, un réseau Windows avec des fichiers partagés, des applications métiers locales et des postes administrés par GPO bénéficiera encore fortement d’AD DS.
Le bon réflexe pour choisir entre local et cloud
Active Directory reste le socle logique d’un grand nombre de réseaux Windows. Il centralise les identités, simplifie les droits et automatise la configuration des postes, mais il exige une vraie discipline d’administration.
Pour décider entre Active Directory local, Microsoft Entra ID ou une architecture hybride, je regarderais d’abord les applications utilisées, les contraintes de sécurité, le niveau de dépendance au réseau interne et les compétences disponibles en interne. Le cloud n’efface pas les besoins d’identité : il change surtout l’endroit où ils sont gérés.
En résumé, comprendre Active Directory revient à comprendre qui peut accéder à quoi, depuis quel appareil et selon quelles règles. Une architecture simple, des privilèges limités et des sauvegardes testées feront généralement davantage la différence qu’une structure très sophistiquée.
