On a tous déjà vécu ce moment un peu gênant. Tout marche. Les users se connectent. Les partages répondent. Les GPO passent. Et puis, un mardi matin, c’est le drame. Un compte admin utilisé à 03 h 12, un DC qui réplique mal depuis des jours, un certificat qui a expiré, ou un stagiaire (innocent) qui a mis « tout le monde : contrôle total » sur un dossier critique.
Active Directory, c’est comme une chaudière. Tant que ça chauffe, personne ne regarde. Sauf que… quand ça casse, tu aurais aimé regarder un peu avant.
Du coup, voilà une routine simple, réaliste, à faire chaque mois. Pas un audit ISO de 300 pages. Juste 10 contrôles qui attrapent 80 % des soucis avant qu’ils ne deviennent des incidents. Et si tu es en BTS SIO option SISR, c’est exactement le genre d’habitudes qui te fait passer de « j’applique un tuto » à « je gère un SI ».
Au passage, si tu veux des labs et des fiches plus pratiques côté Windows Server, GPO, AD CS, supervision, pense à garder BTS SIO2 SISR Tech Lab dans tes favoris : https://sio1blog.blogspot.com/ (c’est typiquement le genre de site où tu reviens quand tu es en révision E4 ou E5… ou quand tu es en prod et que tu stresses).
1) Audit des comptes à privilèges (admin) et des groupes sensibles
Objectif : savoir qui peut tout casser, et si c’est justifié.
Groupes à vérifier à minima :
- Domain Admins
- Enterprise Admins
- Schema Admins
- Administrators (BUILTIN)
- Account Operators, Server Operators, Backup Operators
- DNSAdmins
- Group Policy Creator Owners
- Protected Users (si tu l’utilises)
À contrôler :
- membres inattendus (comptes de prestataires, comptes de service, anciens admins)
- comptes admin utilisés comme comptes du quotidien (mauvaise pratique classique)
- comptes admin inactifs mais toujours membres
- appartenance imbriquée (groupes dans groupes, effet « poupée russe »)
Commandes utiles (PowerShell) : powershell Get-ADGroupMember "Domain Admins" -Recursive | Select Name,SamAccountName,ObjectClass Get-ADUser -Filter * -SearchBase "CN=Users,DC=mondomaine,DC=local" -Properties LastLogonDate | Sort LastLogonDate | Select -First 20 Name,LastLogonDate
Si tu dois retenir une règle simple : un admin a un compte dédié, séparé. Et ce compte n’a pas de boîte mail, pas Teams, pas navigation Web. Oui c’est pénible. Oui ça sauve des domaines.
2) Audit des comptes inactifs et des comptes « oubliés »
Objectif : réduire la surface d’attaque. Un compte qui ne sert plus, c’est un cadeau.
À sortir chaque mois :
- comptes utilisateurs inactifs depuis 30, 60, 90 jours (selon politique)
- comptes désactivés depuis longtemps mais jamais supprimés
- comptes de service qui n’ont pas de propriétaire identifié
- comptes « test », « admin2 », « temp », « stagiaire2022 »… bref tu vois l’idée
Exemples : powershell
Search-ADAccount -UsersOnly -AccountInactive -TimeSpan 90.00:00:00 | Select Name,SamAccountName
Search-ADAccount -AccountDisabled -UsersOnly | Select Name,SamAccountName
Bon réflexe : déplacer dans une OU « Quarantaine », désactiver, attendre X jours, puis supprimer si conforme. Et documenter. Toujours.
3) Audit des mots de passe : politiques, exceptions, et comptes « sans expiration »
Objectif : détecter les contournements et les mauvaises surprises.
Points à vérifier :
- la stratégie de mot de passe (GPO) : longueur, complexité, historique, âge min et max
- les Fine-Grained Password Policies (FGPP) si tu en as
- comptes avec « Password never expires »
- comptes avec « User cannot change password » (parfois justifié, souvent non)
- comptes dont le mot de passe n’a pas été changé depuis… longtemps
Commandes : powershell Get-ADDefaultDomainPasswordPolicy
Get-ADUser -Filter 'PasswordNeverExpires -eq $true' -Properties PasswordNeverExpires | Select Name,SamAccountName
Get-ADUser -Filter * -Properties PasswordLastSet | Sort PasswordLastSet | Select -First 30 Name,PasswordLastSet
Petit rappel qui pique un peu : les comptes de service classiques + mots de passe qui n’expirent jamais, c’est une des portes d’entrée les plus fréquentes. Si tu peux migrer vers gMSA, fais-le. Même progressivement.
4) Audit des verrous de compte (account lockout) et des tentatives suspectes
Objectif : repérer les attaques par force brute, les scripts cassés, ou les postes infectés.
Ce que tu cherches :
- pics de lockout sur une période
- un même compte verrouillé depuis plusieurs machines
- lockout d’un compte admin (alerte rouge)
- tentatives répétées sur des comptes inexistants (énumération)
Côté événements Windows (sur DC) :
- 4740 : compte verrouillé
- 4625 : échec de connexion
- 4624 : connexion réussie (utile en corrélation)
Tu peux faire simple : filtre dans l’observateur d’événements, ou centraliser dans un SIEM si tu as.
PowerShell (rapide, brut) : powershell Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740; StartTime=(Get-Date).AddDays(-30)} | Select TimeCreated, @{n="Compte";e={$.Properties[0].Value}}, @{n="Machine";e={$.Properties[1].Value}} | Sort TimeCreated -Descending | Select -First 50
5) Audit de la réplication AD et de l’état des contrôleurs de domaine
Objectif : éviter les domaines « split brain », les objets fantômes, ou les GPO qui ne s’appliquent plus partout.
À vérifier chaque mois :
repadmin /replsummary: erreurs, latencerepadmin /showrepl: partenaires en échec- état DNS des DC, enregistrements SRV
- services essentiels (NTDS, DNS, KDC, Netlogon)
- espace disque (un DC plein, c’est rarement élégant)
Commandes incontournables : cmd repadmin /replsummary repadmin /showrepl * dcdiag /e /c /v
Si tu vois des erreurs de réplication qui traînent depuis 15 jours, ne te raconte pas d’histoire. Ça ne va pas « se réparer tout seul ». Ça finit toujours par te tomber dessus au pire moment.
6) Audit DNS AD intégré : zones, délégations, enregistrements douteux
Objectif : AD dépend de DNS. Si DNS est bancal, tout devient bancal.
À contrôler :
- zones AD intégrées présentes sur tous les DC DNS attendus
- vieillissement et scavenging (attention, à activer avec méthode)
- enregistrements SRV manquants pour _ldap, _kerberos, etc.
- serveurs DNS configurés sur les clients et serveurs (pas de DNS externe en primaire)
- délégations et forwarders (vers où partent les requêtes)
Tests utiles : cmd nslookup -type=SRV _ldap._tcp.dc._msdcs.mondomaine.local nltest /dsgetdc:mondomaine.local
Un classique : une machine (ou pire, un serveur) qui pointe sur 8.8.8.8 « parce que Internet marche mieux ». Et ensuite tu as des erreurs de jonction au domaine, de GPO, de Kerberos. Normal.
7) Audit des GPO : liens, priorités, héritage, et paramètres risqués
Objectif : s’assurer que tes stratégies font ce que tu penses qu’elles font.
Chaque mois, tu peux vérifier :
- GPO non liées (souvent oubliées)
- GPO liées mais vides (ou quasi)
- doublons (mêmes réglages à plusieurs endroits)
- liens sur des OUs critiques, ordre de liaison
- blocage d’héritage et « Enforced » utilisés à tort
- paramètres de sécurité dangereux
Paramètres GPO à surveiller (exemples) :
- ouverture RDP large (tout le monde)
- désactivation pare-feu Windows
- LAPS absent (ou mal configuré)
- droits utilisateurs : « Log on as a service », « Debug programs », etc.
- ajout de comptes dans Administrateurs local via GPP (préférences) sans filtrage
Outils :
gpmc.msc- rapport HTML d’une GPO
gpresult /hcôté poste pour vérifier l’application réelle
Astuce utile : export mensuel des GPO (sauvegarde). Si quelqu’un casse une stratégie, tu es content d’avoir un point de retour. powershell Backup-Gpo -All -Path "D:\Backup\GPO$(Get-Date -Format yyyy-MM)"
8) Audit des délégations, ACL, et permissions anormales dans l’annuaire
Objectif : repérer les escalades de privilèges « silencieuses ».
Ce que tu cherches :
- délégations sur des OUs sensibles (helpdesk, RH, serveurs)
- droits d’écriture sur des attributs critiques
- permissions sur les objets GPO (édition par des groupes non prévus)
- AdminSDHolder et objets protégés (cohérence)
C’est souvent là que se cache le vrai risque. Pas dans « Domain Admins » visible. Mais dans une délégation sur une OU qui permet de réinitialiser le mot de passe d’un compte qui, lui, est dans un groupe puissant.
Outils possibles :
- ADUC (onglet sécurité, affichage avancé)
dsacls- outils d’audit ACL (BloodHound en mode audit, Purple Knight, PingCastle, selon contexte)
Commande indicative : cmd dsacls "OU=Serveurs,DC=mondomaine,DC=local"
9) Audit Kerberos : comptes avec SPN, délégations Kerberos, et AS-REP roastables
Objectif : attraper des configurations qui facilitent les attaques classiques.
À vérifier :
- comptes utilisateurs avec SPN (souvent mauvais signe, sauf besoin réel)
- comptes de service avec SPN et mot de passe faible ou ancien (risque Kerberoasting)
- délégation Kerberos (unconstrained, constrained)
- comptes « AS-REP roastables » (pas de préauth Kerberos)
Exemples PowerShell : powershell
Get-ADUser -Filter * -Properties ServicePrincipalName | Where-Object {$_.ServicePrincipalName -ne $null} | Select Name,SamAccountName,ServicePrincipalName
Get-ADUser -LDAPFilter "(&(objectCategory=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))" | Select Name,SamAccountName
Si tu découvres des SPN sur des comptes utilisateurs « normaux », tu creuses. Ce n’est pas automatiquement une faille, mais c’est une zone rouge.
10) Audit journaux et alerting minimum : admin logon, modifications critiques, et sauvegardes
Objectif : être capable de répondre à « qui a fait quoi, quand »… et restaurer.
Même sans SIEM, tu peux mettre en place un minimum :
- Audits activés (Advanced Audit Policy) sur DC
- Revue mensuelle des événements clés
Alertes à configurer
- Ajout à Domain Admins (4728, 4732, 4756 selon groupes)
- Création de compte (4720) et activation (4722)
- Reset mot de passe (4724)
- Suppression de compte (4726)
- Modification GPO (5136 côté AD, et journaux GPO selon config)
- Logons admin (4624 avec type, poste source)
Et surtout, la question qui fâche : tes sauvegardes AD existent, elles sont testées, et tu sais restaurer ?
Sauvegardes à prévoir
- System State sur au moins un DC
- Sauvegarde des GPO (déjà mentionné)
- Sauvegarde des scripts de logon, SYSVOL, etc.
- Test de restauration (au moins trimestriel, mensuel si possible)
Une sauvegarde non testée, c'est une théorie. Pas une sauvegarde.
Une routine mensuelle simple (checklist à copier)
Si tu veux faire ça en 60 à 120 minutes, sans te perdre :
- Groupes sensibles : membres, comptes admin dédiés
- Comptes inactifs : désactiver, mettre en quarantaine, nettoyer
- Politique mots de passe : exceptions, « never expires », PasswordLastSet
- Lockout et échecs : 4740, 4625, corrélation simple
- Réplication : repadmin, dcdiag, services DC
- DNS : SRV, zones AD intégrées, config clients
- GPO : GPO orphelines, paramètres risqués, backup
- ACL AD : délégations et droits bizarres sur OU et GPO
- Kerberos : SPN, délégations, AS-REP
- Logs et sauvegardes : événements critiques, System State, test
Tu peux en faire une fiche d'exploitation. Ou même un mini projet de supervision pour ton dossier E5, franchement.
Outils utiles (sans te ruiner)
Quelques outils que tu peux utiliser en audit mensuel, selon ton contexte :
- Outils natifs :
[dcdiag](https://learn.microsoft.com/fr-fr/windows-server/administration/windows-commands/dcdiag),repadmin,gpresult, GPMC, Observateur d’événements - PowerShell AD : extraction, tri, comparaison mensuelle
- PingCastle (audit AD, très pédagogique)
- Purple Knight (reporting orienté durcissement)
- BloodHound (en audit, pour visualiser chemins d’attaque, à manier avec cadre)
- Windows Admin Center (selon versions et setup)
Et si tu veux des pas à pas orientés « apprentissage BTS SIO SISR », avec un ton plus lab et moins « cabinet d’audit », j’en mets régulièrement sur BTS SIO2 SISR Tech Lab : https://sio1blog.blogspot.com/. Ça te fera gagner du temps, surtout sur GPO, AD DS, DNS, et la partie sécu basique qui tombe souvent en questions.
Conclusion : active directory, ça s’entretient… ou ça se subit
Le truc, c’est que ces audits mensuels ne sont pas là pour faire joli. Ils te donnent de la visibilité. Et la visibilité, en infra, c’est quasiment tout.
Tu n’as pas besoin d’être parfait. Tu as besoin d’être régulier. Un petit rythme, des exports, une checklist, et deux ou trois alertes bien placées. Et tu passes de « j’espère que ça tient » à « je sais ce qui se passe ».
Si tu veux, je peux aussi te proposer une version « modèle de rapport mensuel » (une page), ou un script PowerShell qui sort un résumé des points 1 à 5. À publier ensuite sur ton espace de veille ou à intégrer dans un lab.
Questions fréquemment posées
Pourquoi est-il important de réaliser un audit régulier des comptes à privilèges dans Active Directory ?
Réaliser un audit régulier des comptes à privilèges permet de savoir qui a le pouvoir de modifier ou casser le système, et si ces accès sont justifiés. Cela aide à détecter les membres inattendus, les comptes admin utilisés quotidiennement (mauvaise pratique), les comptes inactifs toujours membres, et l'imbrication complexe des groupes. Cette vigilance prévient les incidents graves liés à la sécurité du domaine.
Quels groupes sensibles faut-il contrôler lors d'un audit des comptes privilégiés dans Active Directory ?
Les groupes sensibles à vérifier au minimum sont : Domain Admins, Enterprise Admins, Schema Admins, Administrators (BUILTIN), Account Operators, Server Operators, Backup Operators, DNSAdmins, Group Policy Creator Owners et Protected Users (si utilisés). Ces groupes détiennent des droits élevés pouvant impacter la sécurité globale du domaine.
Comment gérer les comptes inactifs ou oubliés pour réduire la surface d'attaque dans Active Directory ?
Il est recommandé de lister chaque mois les comptes utilisateurs inactifs depuis 30, 60 ou 90 jours selon la politique interne, les comptes désactivés mais non supprimés, ainsi que les comptes de service sans propriétaire identifié et les comptes temporaires ou tests. Une bonne pratique consiste à déplacer ces comptes dans une Unité d'Organisation 'Quarantaine', les désactiver puis les supprimer après un délai conforme en documentant toutes les actions.
Quels contrôles effectuer sur la politique de mots de passe dans Active Directory ?
Il faut vérifier la stratégie globale via GPO : longueur minimale, complexité requise, historique des mots de passe, âge minimal et maximal. Contrôler aussi les Fine-Grained Password Policies si elles existent. Identifier les comptes avec l'option 'Password never expires', ceux qui ne peuvent pas changer leur mot de passe et ceux dont le mot de passe n'a pas été changé depuis longtemps. Ces contrôles permettent d'éviter des failles majeures liées aux mots de passe faibles ou statiques.
Pourquoi est-il déconseillé d'utiliser un compte admin comme compte du quotidien ?
Utiliser un compte administrateur pour ses activités courantes augmente considérablement le risque d'exposition aux attaques car ce compte a des droits étendus. Il doit être dédié uniquement aux tâches d'administration et ne pas être utilisé pour la messagerie électronique, Teams ou la navigation web. Cette séparation protège le domaine contre des compromissions accidentelles ou malveillantes.
Quelles sont les bonnes pratiques pour sécuriser les comptes de service dans Active Directory ?
Les comptes de service classiques avec mots de passe qui n'expirent jamais constituent souvent une porte d'entrée pour les attaquants. Il est conseillé de migrer progressivement vers des Managed Service Accounts (gMSA) qui gèrent automatiquement leurs mots de passe. Cela réduit le risque lié aux mots de passe statiques et améliore la sécurité globale du système.
0 Commentaires