Identités Windows : comptes locaux vs comptes de domaine

Axiome d'investigation DFIR

Le nom d’utilisateur n’est pas une identité. Deux comptes portant le libellé textuel Administrator ou Administrateur sur deux machines ou domaines distincts ne partagent absolument aucune autorité de sécurité ni aucun secret cryptographique.

Le fil conducteur de toute analyse forensique doit rigoureusement dissocier :

Identité → Authentification → Autorisation → Accès → Action

Concept

Dans l’écosystème Windows, une identité de sécurité (Security Principal) est une entité à laquelle le système d’exploitation peut attribuer des privilèges et des droits d’accès sur des objets sécurisables (fichiers, clés de registre, partages, processus).

Il existe une dichotomie fondamentale et étanche entre deux types d’identités :

1. Les comptes locaux : résidant exclusivement dans la base de données SAM (Security Account Manager) d’une machine physique ou virtuelle donnée.
2. Les comptes de domaine : résidant centralement dans la base de données de l’annuaire Active Directory (ntds.dit), hébergée et répliquée sur les contrôleurs de domaine (DC).

L’identité n’est jamais définie par le nom d’affichage (sAMAccountName), mais par un identifiant mathématique immuable : le SID (Security Identifier).

---

Pourquoi c’est important en DFIR

Lors de l’analyse d’une intrusion ou d’un incident de ransomware (ex. Akira, LockBit), les analystes commettent fréquemment l’erreur de corréler des ouvertures de session sur différentes machines en se basant sur le nom d’utilisateur :

• Faux sentiment de continuité : constater qu’un compte Administrator a ouvert une session sur le Serveur A puis sur le Serveur B ne prouve absolument pas qu’il s’agit du même compte ni de la même entité. Si le Serveur A utilise SERVER-A\Administrator et le Serveur B SERVER-B\Administrator, il s’agit de deux autorités de sécurité totalement disjointes, même si un mot de passe réutilisé a pu être exploité.
• Confusion de périmètre : la compromission d’un compte local à privilèges élevés n’accorde par défaut aucun droit sur le domaine, tandis que la compromission d’un compte de domaine peut immédiatement impacter l’ensemble du parc si ce dernier est présent dans les groupes administrateurs locaux via les GPO.
• Validation de l’autorité : un serveur standalone (hors domaine) ne sait pas ce qu’est un compte Active Directory sans mécanisme de fédération ou d’authentification applicative tierce.

---

Comment ça fonctionne

1. La base locale SAM (security account manager)

Sur chaque station de travail ou serveur Windows (y compris lorsqu’il est membre d’un domaine), la ruche de registre locale HKLM\SAM stocke les comptes locaux et les groupes de sécurité locaux.

• Autorité émettrice : la machine locale elle-même.
• Portée du hash : le hash NTLM est stocké localement et chiffré par la clé Syskey (ruche SYSTEM).
• Validation : lors d’une authentification locale, le sous-système de sécurité local (LSASS / MSV1_0) vérifie les informations d’authentification contre cette SAM.

2. L’annuaire central Active Directory (ntds.dit)

Sur un contrôleur de domaine, la SAM locale est désactivée au profit de la base de données relationnelle ESE ntds.dit (%SystemRoot%\NTDS\ntds.dit).

• Autorité émettrice : le contrôleur de domaine représentant le domaine Active Directory.
• Portée du hash : répliqué entre tous les contrôleurs de domaine de la partition de domaine.
• Validation : l’authentification est traitée via Kerberos (KDC / tickets TGT et TGS) ou via NTLM pass-through (Netlogon vers le DC).

Critère	Compte local (SAM)	Compte de domaine (Active Directory)
Emplacement du stockage	HKLM\SAM sur le disque local de l’hôte	ntds.dit sur les contrôleurs de domaine
Autorité de sécurité	La machine locale (COMPUTERNAME)	Le domaine Active Directory (DOMAINNAME)
Format du SID	S-1-5-21-<Machine_ID>-<RID>	S-1-5-21-<Domain_ID>-<RID>
Validité hors connexion	Permanente sur la machine hôte	Requiert un cache d’identifiants (Cached Credentials)
Gestion administrative	lusrmgr.msc ou commandes net user	Console ADUC (dsa.msc), PowerShell ActiveDirectory

---

Ce qui est possible

• Avoir des comptes de même nom dans plusieurs autorités : il peut exister un utilisateur Administrator sur la machine A, un utilisateur Administrator sur la machine B, et un utilisateur Administrator dans le domaine A et le domaine B.
• Utiliser un compte de domaine sur un poste joint : un poste joint au domaine contacte son DC via DNS/Kerberos pour valider le compte CORP\jdoe et lui générer un jeton d’accès local.
• Utiliser un compte local pour un accès réseau : comme nous le verrons en détail dans la fiche 20, un compte local peut être utilisé à travers le réseau (SMB, WinRM, RPC) vers la machine qui héberge sa propre SAM, sous réserve des règles réseau et des restrictions d’accès distant.
• Se connecter à une machine membre avec un compte local : joindre un ordinateur à un domaine ne supprime pas sa SAM locale. Le compte SERVER01\LocalAdmin continue d’exister et de fonctionner.

---

Ce qui n’est pas possible

• Un compte local ne peut pas s’authentifier auprès de l’Active Directory : SERVER01\LocalAdmin n’existe pas pour les DC et ne peut obtenir aucun ticket Kerberos pour accéder aux ressources du domaine.
• Un compte local d’une machine a ne peut pas être reconnu nativement par une machine b : si la machine B n’a pas exactement le même mot de passe pour un compte local homonyme, l’authentification NTLM échouera systématiquement.
• Deux contrôleurs de domaine ne possèdent pas de comptes locaux d’utilisateurs distincts : la promotion d’un serveur en DC neutralise la SAM locale opérationnelle au profit de l’annuaire unifié ntds.dit (à l’exception du mode DSRM).

---

Confusions fréquentes

Les pièges classiques en analyse forensique

1. Confondre WORKGROUP et compte local : lorsqu’un log Windows affiche Workstation\admin, certains analystes pensent que la machine n’est pas dans un domaine. Une machine membre d’un domaine possède toujours sa SAM locale.
2. Associer le privilège au nom : renommer le compte Administrator de domaine en CompteService ne lui retire aucun privilège car son SID se termine toujours par le RID 500 (voir Fiche 02 : SID, RID and Windows Identity).
3. Supposer qu’un trust donne accès aux comptes locaux : les relations d’approbation d’Active Directory ne concernent que les comptes de domaine. Un trust ne peut en aucun cas relier deux SAM locales.

---

Exemple concret

Imaginons une entreprise disposant d’un domaine PROD.CORP (SID de domaine : S-1-5-21-111111111-222222222-333333333) et d’un serveur de fichiers membre FS01 (SID de machine : S-1-5-21-777777777-888888888-999999999).

Lors d’une tentative d’ouverture de session sur FS01 :

• Si l’attaquant saisit l’identifiant Administrator sans préfixe, le protocole de négociation tente d’abord de résoudre l’autorité locale FS01\Administrator (SID : S-1-5-21-777777777-888888888-999999999-500).
• Si l’attaquant spécifie PROD\Administrator, la requête est routée vers le KDC du domaine pour authentifier l’administrateur du domaine (SID : S-1-5-21-111111111-222222222-333333333-500).

Ces deux comptes ont des hashs NTLM différents, des clés Kerberos différentes et des droits d’accès initiaux totalement distincts.

---

Artefacts / traces

Dans les journaux d’événements Windows (Security.evtx), l’ouverture de session (Event ID 4624) fournit les preuves matérielles décisives :

EventID: 4624
SubjectUserSid: S-1-5-18 (SYSTEM)
TargetUserSid: S-1-5-21-777777777-888888888-999999999-500
TargetUserName: Administrator
TargetDomainName: FS01                  <-- Preuve irréfutable : compte LOCAL SAM
LogonType: 3                             <-- Connexion Réseau (SMB/RPC)
AuthenticationPackageName: NTLM
PackageName: NTLM V2

Si le compte était un compte du domaine, le champ contiendrait :

TargetUserSid: S-1-5-21-111111111-222222222-333333333-500
TargetUserName: Administrator
TargetDomainName: PROD                  <-- Preuve irréfutable : compte de DOMAINE
AuthenticationPackageName: Kerberos

---

Méthodes d’investigation

1. Extraction de la ruche SAM hors ligne :

   # Extraire les comptes locaux et leurs SIDs depuis une image forensique
   reg.exe save HKLM\SAM sam.save
   reg.exe save HKLM\SYSTEM system.save
   # Analyse avec impacket-secretsdump ou regipy
   secretsdump.py -sam sam.save -system system.save LOCAL

2. Identification en ligne via PowerShell :

   # Lister les comptes locaux réels et leurs SIDs
   Get-LocalUser | Select-Object Name, SID, Enabled, LastLogon
   
   # Vérifier le domaine auquel la machine est jointe
   (Get-CimInstance Win32_ComputerSystem).Domain

3. Analyse des journaux security.evtx :
   • Filtrer sur l’Event ID 4624 (Succès de connexion) et 4625 (Échec de connexion).
   • Comparer systématiquement TargetDomainName avec le nom netbios local de la machine (COMPUTERNAME). Si TargetDomainName == COMPUTERNAME, l’authentification est locale (SAM).

---

Outils

• Outils d’investigation : hayabusa, Chainsaw, LogParser, KAPE (collecte SAM / NTDS / Security.evtx).
• Outils d’inspection : wmic useraccount get name,sid, Get-LocalUser, Impacket secretsdump.
• Offensifs (à détecter) : netExec (nxc smb <target> -u Administrator -p ... --local-auth), Mimikatz (lsadump::sam).

---

Points clés à retenir

1. Le nom est une étiquette cosmétique, le SID est l’identité juridique de sécurité.
2. Une machine membre d’un domaine conserve toujours sa base locale SAM.
3. Pour prouver l’autorité d’un compte dans un log, comparez le TargetDomainName OU le préfixe de domaine du SID avec le SID local de la machine.
4. Les relations d’approbation (trusts) n’ont aucune prise sur les comptes locaux.

---

Références

• Microsoft Learn: Security Identifiers (SIDs)
• Fiche 02 : SID, RID and Windows identity
• Fiche 04 : local administrator vs domain administrator
• Fiche 20 : local accounts on domain-joined machines
• Active Directory fundamentals