Votre audit exige de désactiver le compte « Administrator » intégré d’Active Directory sur un environnement à un seul contrôleur de domaine. Voici la stratégie la plus sûre : ne pas désactiver dans ce contexte, mais renommer le compte intégré, le durcir, et utiliser au quotidien un autre compte administrateur.
Sommaire
Vue d’ensemble de la question
Dans un domaine Active Directory (AD), le compte Administrator est créé par défaut et porte un identifiant de sécurité réservé (RID 500). Il possède des droits étendus qui en font une cible privilégiée pour les attaquants. Un audit peut demander sa désactivation par mesure de réduction de surface d’attaque. Cependant, dans un environnement ne comportant qu’un seul contrôleur de domaine (DC), la désactivation peut augmenter le risque opérationnel : si le compte de secours ou la chaîne d’administration est rompue, vous pouvez vous verrouiller hors du domaine.
Réponse & solution
- Techniquement possible de désactiver le compte intégré, mais très risqué avec un seul DC (risque d’exclusion, perte de « porte d’urgence »).
- La mesure la plus sûre dans ce contexte : renommer le compte intégré, restreindre ses usages, auditer ses connexions, et administrer au quotidien avec des comptes nominatifs et/ou un compte de break‑glass stocké en lieu sûr.
Pourquoi le compte intégré est spécial ?
- RID 500 : même renommé, l’objet conserve son identifiant (le SID du domaine se termine par
-500), ce qui permet de l’identifier aux yeux d’un attaquant expérimenté. - Privilèges étendus : membre implicite/explicite des groupes les plus sensibles (Domain Admins, etc.), et souvent protégé par le mécanisme AdminSDHolder/SDProp.
- Ciblage opportuniste : de nombreux outils d’attaque testent d’abord « Administrator ». Le simple renommage casse une partie des attaques triviales et des scripts « grand public ».
Option A — Désactiver le compte intégré (à éviter avec un seul DC)
Étape 1 — Créer et tester un compte admin équivalent
- Créer un nouveau compte membre de Domain Admins (et Enterprise/Schema Admins si la forêt le justifie).
- Tester toutes les opérations critiques : ouverture de session sur le DC, ADUC (dsa.msc), GPMC, Centre d’administration AD, PowerShell (
ActiveDirectory), tâches de sauvegarde/restauration, etc.
Étape 2 — Sécuriser ce nouveau compte
- Mot de passe robuste, coffre-fort, PAW (poste d’administration dédié), MFA si disponible.
- Limiter explicitement ses surfaces de connexion (RDP/SMB) par GPO et pare‑feu.
Étape 3 — Désactiver « Administrator »
Console : Active Directory Users and Computers → conteneur Users → Administrator → Propriétés → cocher Le compte est désactivé.
PowerShell :
Import-Module ActiveDirectory
$admin = Get-ADUser -Filter 'SID -like "*-500"'
Disable-ADAccount -Identity $admin
Étape 4 — Surveiller & documenter
- Activer l’audit et alerter sur les événements clés (voir tableau ci‑dessous).
- Maintenir une procédure de reprise : sauvegarde System State du DC, mots de passe DSRM, média de restauration, procédure d’escalade.
Important : avec un unique DC, cette option est déconseillée. Une erreur ou une panne au mauvais moment peut bloquer toute administration.
Option B — Renommer le compte intégré (recommandé ici)
Objectif : réduire l’exposition et garder une « porte d’urgence » contrôlée.
Étape 1 — Renommer proprement
Console : clic droit Administrator → Renommer → définir un Nom complet, un sAMAccountName (par ex. Adm-Root) et, si souhaité, un UPN.
PowerShell :
Import-Module ActiveDirectory
$domain = (Get-ADDomain).DNSRoot
$admin = Get-ADUser -Filter 'SID -like "*-500"' -Properties SamAccountName,UserPrincipalName,DistinguishedName
$NewCn = 'Adm-Root' # Nom (CN) lisible dans l'annuaire
$NewSam = 'Adm-Root' # sAMAccountName (logon DOMAINE\Adm-Root)
$NewUpn = "{0}@{1}" -f $NewSam, $domain
Rename-ADObject -Identity \$admin.DistinguishedName -NewName \$NewCn
Set-ADUser -Identity \$admin -SamAccountName \$NewSam -UserPrincipalName \$NewUpn Étape 2 — Comprendre la portée du renommage
- Le compte garde sa SID d’origine (RID 500) : il reste détectable par un attaquant chevronné.
- Le renommage réduit les attaques opportunistes (scripts basiques, tentatives massives ciblant « Administrator ») mais ne remplace pas les autres contrôles.
Étape 3 — Durcir le compte renommé
- Limiter les usages : refuser l’accès RDP et l’accès réseau, n’autoriser que la console en cas d’urgence, si votre procédure le permet.
Paramètres GPO suggérés :
| Chemin GPO | Paramètre | Action recommandée |
|---|---|---|
| Configuration ordinateur → Paramètres Windows → Paramètres de sécurité → Stratégies locales → Attribution des droits utilisateur | Deny log on through Remote Desktop Services | Ajouter le compte RID‑500 renommé |
| Idem | Deny access to this computer from the network | Ajouter le compte RID‑500 (si compatible avec vos opérations de secours) |
| Propriétés du compte (onglet Compte) | Account is sensitive and cannot be delegated | Cocher |
| Configuration ordinateur → Stratégies → Paramètres Windows → Paramètres de sécurité → Options de sécurité | Interactive logon: Message text for users attempting to log on | Message d’avertissement (bannières légales) |
Étape 4 — Créer un compte admin opérationnel distinct
- Utilisez un compte admin nominatif (membre de Domain Admins) pour la gestion courante, protégé par MFA/PAW.
- Conservez un compte de secours (break‑glass) : mot de passe stocké hors ligne, coffre-fort, sealed, testé périodiquement.
Étape 5 — Vérifier les dépendances
Rechercher et remplacer toute référence explicite à DOMAINE\Administrator (services, tâches planifiées, scripts, jobs) :
# Services Windows exécutés en DOMAINE\Administrator
Get-WmiObject Win32_Service |
Where-Object { $_.StartName -match 'DOMAINE\\Administrator' } |
Select-Object Name, StartName
# Variante moderne
Get-CimInstance Win32\_Service |
Where-Object { $\_.StartName -match 'DOMAINE\Administrator' } |
Select-Object Name, StartName
# Tâches planifiées (serveurs modernes)
Get-ScheduledTask | ForEach-Object {
\$p = (Get-ScheduledTaskInfo \$*.TaskName -TaskPath \$*.TaskPath -ErrorAction SilentlyContinue)
\[PSCustomObject]@{
Task = "\$(\$*.TaskPath)\$(\$*.TaskName)"
RunAs = \$*.Principal.UserId
}
} | Where-Object { \$*.RunAs -match 'DOMAINE\Administrator' }
# Tâches planifiées (méthode universelle)
schtasks /query /v /fo CSV |
ConvertFrom-Csv |
Where-Object { $\_.'Run As User' -match 'DOMAINE\Administrator' } |
Select-Object TaskName, 'Run As User' Tableau de décision : désactiver vs renommer
| Critère | Désactiver | Renommer (recommandé) |
|---|---|---|
| Réduction des attaques opportunistes | Élevée (compte inutilisable) | Bonne (nom inattendu) |
| Risque opérationnel (unique DC) | Élevé (perte de porte d’urgence) | Faible à modéré (porte d’urgence conservée) |
| Complexité de mise en œuvre | Moyenne | Faible |
| Impact sur scripts/services hérités | Faible à moyen | Moyen (si « Administrator » est codé en dur) |
| Visibilité par attaquants chevronnés | Nulle (compte désactivé) | Persistante via RID 500 |
Journalisation et alerting : quels événements surveiller ?
| ID d’événement | Source | Signification / Usage |
|---|---|---|
| 4624 | Sécurité | Ouverture de session réussie (filtrer par SID du compte RID‑500) |
| 4625 | Sécurité | Ouverture de session échouée (détecter du brute‑force ciblant « Administrator ») |
| 4722 | Sécurité | Compte activé |
| 4725 | Sécurité | Compte désactivé |
| 4738 | Sécurité | Propriétés du compte modifiées |
| 4781 | Sécurité | Nom du compte modifié (utile lors du renommage) |
| 4740 | Sécurité | Compte verrouillé (utile pour d’autres comptes admins nominatif) |
Procédure guidée (runbook) : renommage sécurisé + durcissement
- Pré‑requis : sauvegarde récente du System State du DC, accès console, mots de passe DSRM disponibles et testés.
- Créer/valider un compte admin nominatif et un compte de secours (break‑glass) ; tester les connexions et tâches critiques.
- Renommer le compte intégré (CN + sAMAccountName + UPN) avec PowerShell ou ADUC.
- Durcir par GPO (refus RDP/SMB, délégation interdite, restrictions d’ouverture de session à des hôtes d’administration).
- Audit : créer des règles de corrélation (SIEM) sur 4624/4625/4722/4725/4738/4781 pour la SID RID‑500.
- Remédiation des dépendances : migrer services/tâches/scripts vers un compte de service ou gMSA, jamais le compte RID‑500.
- Décoy (optionnel) : recréer un utilisateur leurre nommé « Administrator », désactivé, sans privilèges, pour détecter toute tentative de connexion opportuniste.
- Documentation : enregistrer le nouveau nom, l’UPN, l’emplacement, les GPO associées, les procédures de récupération.
# Exemple de script PowerShell "tout-en-un" (renommage + durcissement minimum)
Import-Module ActiveDirectory
$domain = (Get-ADDomain).DNSRoot
$admin = Get-ADUser -Filter 'SID -like "*-500"' -Properties SamAccountName,UserPrincipalName,DistinguishedName,Enabled
$NewCn = 'Adm-Root'
$NewSam = 'Adm-Root'
$NewUpn = "{0}@{1}" -f $NewSam, $domain
# 1) Renommer l'objet et mettre à jour les identifiants de connexion
Rename-ADObject -Identity $admin.DistinguishedName -NewName $NewCn
Set-ADUser -Identity $admin -SamAccountName $NewSam -UserPrincipalName $NewUpn
# 2) Marquer le compte comme "sensible & non déléguable"
Set-ADUser -Identity $admin -AccountNotDelegated $true
# 3) (Option) Créer un utilisateur "leurre" nommé Administrator, désactivé
New-ADUser -Name 'Administrator' -SamAccountName 'Administrator' -Enabled $false -AccountPassword (ConvertTo-SecureString 'MotDePasse-Long-Unique!' -AsPlainText -Force) -PassThru |
Set-ADUser -Description 'Honeytoken: alerte si utilisé'
Bonnes pratiques complémentaires
- Principe du moindre privilège : préférer des comptes de service dédiés (ou gMSA) aux services plutôt que d’utiliser des comptes admins.
- Tiering AD : séparer les postes/serveurs Tier 0 (contrôleurs de domaine), Tier 1 (serveurs) et Tier 2 (postes), avec des comptes dédiés par couche.
- Rotation régulière des mots de passe très privilégiés ; contrôler les emplacements où ils sont saisis (PAW, bastions).
- DSRM : s’assurer que le mot de passe DSRM est connu et testé ; si nécessaire, synchroniser/mettre à jour via
ntdsutil "set dsrm password". - Surveillance continue : implémenter des alertes en quasi‑temps réel sur la SID
*-500et sur des connexions interactives ou réseau non prévues.
Checklist opérationnelle
| Élément | À faire | Statut |
|---|---|---|
| Sauvegarde System State du DC | Vérifier la restauration testée en labo | |
| Compte admin nominatif | Créé, MFA/PAW, droits testés | |
| Compte break‑glass | Stockage hors ligne, test trimestriel | |
| Renommage RID‑500 | CN, sAMAccountName, UPN mis à jour | |
| Durcissement GPO | Deny RDP / Deny network / Non déléguable | |
| Audit/Alerting | 4624/4625/4722/4725/4738/4781 filtrés sur SID | |
| Dépendances | Services/Tâches/Scripts migrés vers comptes dédiés | |
| Honeytoken (facultatif) | Créer « Administrator » désactivé + alerte | |
| Documentation | Procédures & cartographie à jour |
FAQ rapide
Peut‑on supprimer le compte intégré ?
Non. Le compte intégré ne peut pas être supprimé ; on peut seulement le renommer ou le désactiver.
Le renommage suffit‑il ?
Non, il doit être complété par un durcissement (GPO, restrictions d’ouverture de session), un audit ciblé, et l’usage quotidien de comptes nominatif (et de service) à privilèges précisément mesurés.
Que faire si des scripts utilisent « DOMAINE\Administrator » ?
Identifiez‑les via les commandes proposées, remplacez par des comptes de service dédiés et révoquez l’usage du RID‑500 dans toute automatisation.
Et si je n’ai qu’un seul DC ?
C’est exactement le cas risqué : évitez la désactivation. Renommez, durcissez, surveillez, et préparez une stratégie de reprise. À moyen terme, envisagez de déployer un second DC pour réduire les points uniques de défaillance.
Conclusion
- La désactivation du compte intégré est possible mais non conseillée avec un seul contrôleur de domaine.
- La voie prudente et conforme consiste à renommer le compte intégré (RID 500), restreindre ses usages via GPO, auditer ses activités, et administrer au quotidien avec un autre compte admin robuste.
Annexes – commandes utiles
Vérifier rapidement l’état du compte RID‑500
Import-Module ActiveDirectory
Get-ADUser -Filter 'SID -like "*-500"' -Properties Enabled,SamAccountName,UserPrincipalName,DistinguishedName |
Select-Object Enabled,SamAccountName,UserPrincipalName,DistinguishedName
Restreindre l’ouverture de session à une liste de hôtes (ex. PAW)
# Autoriser l'ouverture de session uniquement sur un groupe d'ordinateurs d'administration
$admin = Get-ADUser -Filter 'SID -like "*-500"'
Set-ADUser -Identity $admin -LogonWorkstations 'PAW01,PAW02'
Remarque : à utiliser uniquement si vos procédures de secours le tolèrent. Sinon, préférez les restrictions GPO « Deny log on … ».
Mettre à jour le mot de passe DSRM
# Sur le DC, exécuter en élévation
ntdsutil "set dsrm password" "reset password on server %COMPUTERNAME%" quit quit
Créer un rapport CSV des services/tâches héritant de DOMAINE\Administrator
$domain = (Get-ADDomain).NetBIOSName
$pattern = [regex]::Escape("$domain\Administrator")
\$svc = Get-CimInstance Win32\_Service |
Where-Object { $\_.StartName -match \$pattern } |
Select-Object Name, StartName
\$tsk = schtasks /query /v /fo CSV |
ConvertFrom-Csv |
Where-Object { \$*.'Run As User' -match \$pattern } |
Select-Object TaskName, @{n='RunAs';e={\$*.'Run As User'}}
\$svc | Export-Csv .\Services\_Administrator.csv -NoTypeInformation -Encoding UTF8
\$tsk | Export-Csv .\Tasks\_Administrator.csv -NoTypeInformation -Encoding UTF8 Mémo d’audit
- Décision : Renommer le compte intégré (RID 500), ne pas le désactiver tant qu’il n’existe qu’un seul DC.
- Contrôles : GPO de refus RDP/SMB, non‑délégation, restrictions d’ouverture de session, journalisation ciblée.
- Opérationnel : comptes nominatif et de secours, procédures testées, documentation à jour, surveillance continue.
En synthèse : renommer et durcir le compte intégré, éliminer ses usages opérationnels, et gouverner les privilèges via des comptes dédiés — c’est la meilleure voie pour satisfaire l’audit sans risquer l’exclusion du domaine.