Comment gerer les ACL NTFS lors d'une migration d'identite Windows ?

Lorsqu'un poste Windows change d'identite — passage d'un domaine Active Directory a Microsoft Entra ID — le SID (Security Identifier) de l'utilisateur change. Les ACL NTFS (Access Control Lists) qui protegent les fichiers et dossiers referencent l'ancien SID. Sans intervention, l'utilisateur perd l'acces a ses propres fichiers. Cet article explique le mecanisme des ACL NTFS, pourquoi elles posent probleme lors d'une migration d'identite, et comment les reconstruire correctement.

Qu'est-ce qu'un SID et pourquoi change-t-il lors d'une migration ?

Chaque compte utilisateur dans Windows est identifie par un SID (Security Identifier), une chaine unique de la forme S-1-5-21-xxxxxxxx-yyyyyyyy-zzzzzzzz-1234. Ce SID est l'identite reelle du compte — le nom d'utilisateur n'est qu'un alias lisible.

Un compte Active Directory a un SID attribue par le domaine AD (prefixe S-1-5-21-...). Un compte Entra ID a un SID different, attribue par Entra (prefixe S-1-12-1-...). Quand un poste migre de Hybrid Azure AD Join vers Entra Join, l'utilisateur se reconnecte avec un nouveau SID Entra.

Le systeme de fichiers NTFS ne connait pas les noms d'utilisateur. Il ne connait que les SID. Chaque fichier et dossier porte une ACL qui liste les SID autorises et leurs permissions. Apres migration, l'ancien SID AD est present dans les ACL mais n'est plus reconnu — Windows l'affiche comme un SID orphelin (un identifiant numerique sans nom associe).

Que se passe-t-il sans reconstruction des ACL ?

Sans reconstruction, plusieurs problemes surviennent :

Perte d'acces au profil utilisateur. Le dossier C:\Users\nom et tout son contenu (Bureau, Documents, AppData) ont des ACL qui referencent l'ancien SID AD. L'utilisateur connecte avec son nouveau SID Entra ne peut pas lire ni ecrire dans son propre profil. Windows peut creer un nouveau profil vide a la place.

Fichiers inaccessibles. Les fichiers crees par l'utilisateur heritent des ACL du dossier parent. Si l'ancien SID est le seul autorise, les fichiers sont inaccessibles avec le nouveau compte.

Applications qui echouent. Certaines applications stockent des donnees dans AppData ou dans des dossiers proteges. Si les ACL bloquent l'acces, l'application plante ou perd sa configuration.

NTUSER.DAT verrouille. Le fichier de registre utilisateur (C:\Users\nom\NTUSER.DAT) porte aussi des ACL. S'il n'est pas accessible, le profil ne se charge pas du tout.

Comment sont structurees les ACL NTFS ?

Chaque fichier ou dossier NTFS a un Security Descriptor compose de :

• Owner : le SID du proprietaire
• DACL (Discretionary ACL) : la liste des ACE (Access Control Entries) qui definissent qui peut faire quoi
• SACL (System ACL) : les regles d'audit (moins critique pour la migration)

Chaque ACE contient :

• Un SID (qui)
• Des droits (lecture, ecriture, execution, controle total...)
• Un type (Allow ou Deny)
• Des flags d'heritage (s'applique aux sous-dossiers, aux fichiers, etc.)

Exemple de structure ACL sur un dossier de profil C:\Users\jean.dupont :

SID	Droits	Type
S-1-5-21-xxx-1234 (jean.dupont AD)	Full Control	Allow
S-1-5-18 (SYSTEM)	Full Control	Allow
S-1-5-32-544 (Administrators)	Full Control	Allow

Apres migration, le SID S-1-5-21-xxx-1234 n'existe plus. Il faut le remplacer par le nouveau SID Entra S-1-12-1-yyy-5678.

Comment reconstruire les ACL apres une migration ?

La reconstruction se fait en trois etapes : identification des SID, remplacement dans les ACL, et verification.

Etape 1 — Identifier l'ancien et le nouveau SID

# Ancien SID (sauvegarde avant migration)
# A collecter AVANT la disjonction AD
$oldSid = (New-Object System.Security.Principal.NTAccount("DOMAINE\jean.dupont")).Translate(
    [System.Security.Principal.SecurityIdentifier]).Value

# Nouveau SID (apres jonction Entra et premier logon)
$newSid = (Get-WmiObject Win32_UserProfile | Where-Object {
    $_.LocalPath -eq "C:\Users\jean.dupont"
}).SID

Il est indispensable de sauvegarder l'ancien SID avant la disjonction AD, car une fois le poste sorti du domaine, le SID AD n'est plus resolvable.

Etape 2 — Remplacer le SID dans les ACL

Le remplacement doit etre fait recursivement sur tout le profil utilisateur. Voici l'approche PowerShell :

function Replace-AclSid {
    param(
        [string]$Path,
        [string]$OldSid,
        [string]$NewSid,
        [switch]$Recurse
    )
    $oldIdentity = New-Object System.Security.Principal.SecurityIdentifier($OldSid)
    $newIdentity = New-Object System.Security.Principal.SecurityIdentifier($NewSid)

    $items = @($Path)
    if ($Recurse) {
        $items += Get-ChildItem -Path $Path -Recurse -Force -ErrorAction SilentlyContinue |
                  Select-Object -ExpandProperty FullName
    }

    foreach ($item in $items) {
        try {
            $acl = Get-Acl -Path $item
            $modified = $false

            # Remplacer le owner si c'est l'ancien SID
            if ($acl.Owner -eq $OldSid -or $acl.Owner -eq $oldIdentity.Value) {
                $acl.SetOwner($newIdentity)
                $modified = $true
            }

            # Remplacer dans les ACE
            $newRules = @()
            foreach ($ace in $acl.Access) {
                if ($ace.IdentityReference.Value -eq $oldIdentity.Value) {
                    $newAce = New-Object System.Security.AccessControl.FileSystemAccessRule(
                        $newIdentity, $ace.FileSystemRights, $ace.InheritanceFlags,
                        $ace.PropagationFlags, $ace.AccessControlType)
                    $newRules += @{ Remove = $ace; Add = $newAce }
                    $modified = $true
                }
            }

            if ($modified) {
                foreach ($r in $newRules) {
                    $acl.RemoveAccessRule($r.Remove) | Out-Null
                    $acl.AddAccessRule($r.Add)
                }
                Set-Acl -Path $item -AclObject $acl
            }
        } catch {
            # Certains fichiers systeme sont proteges — ignorer
        }
    }
}

# Usage
Replace-AclSid -Path "C:\Users\jean.dupont" -OldSid "S-1-5-21-xxx-1234" -NewSid "S-1-12-1-yyy-5678" -Recurse

Etape 3 — Verifier

Apres le remplacement, verifiez que l'utilisateur a bien acces a son profil :

# Verifier le owner du dossier profil
(Get-Acl "C:\Users\jean.dupont").Owner

# Verifier les ACL
Get-Acl "C:\Users\jean.dupont" | Format-List

# Verifier l'acces effectif
icacls "C:\Users\jean.dupont"

Quand effectuer la reconstruction des ACL ?

Le timing est critique. La reconstruction doit se faire apres la jonction Entra (pour connaitre le nouveau SID) mais avant le premier logon de l'utilisateur (pour qu'il retrouve son profil intact).

En pratique, l'operation se fait en tant que SYSTEM ou avec le compte admin local de secours, pendant la phase de redemarrage post-jonction, avant que l'utilisateur ne se connecte.

Si le remapping est fait apres que l'utilisateur s'est connecte, Windows a deja cree un nouveau profil temporaire. Il faut alors supprimer ce profil temporaire, effectuer le remapping, et demander a l'utilisateur de se reconnecter.

Pour le processus complet de remapping du profil (registre + ACL), consultez Remapping du profil utilisateur apres jonction Entra : SID, registre, ACL.

FAQ

Le SID History peut-il eviter la reconstruction des ACL ?

Le SID History est un mecanisme Active Directory qui permet a un compte d'heriter des acces d'un ancien SID. Cependant, le SID History est un attribut AD — il n'existe pas dans Entra ID pour les comptes cloud-native. Il n'est donc pas utilisable dans le contexte d'une migration vers Entra Join.

Faut-il reconstruire les ACL sur les partages reseau aussi ?

Si l'utilisateur accede a des partages reseau (file servers), les ACL de ces partages referencent l'ancien SID AD. Deux options : soit le serveur de fichiers migre egalement vers des ACL basees sur le nouveau SID, soit vous utilisez les groupes Entra (qui restent synchronises via Azure AD Connect) pour gerer les permissions sur les partages.

Combien de temps prend la reconstruction des ACL d'un profil ?

La duree depend du nombre de fichiers. Pour un profil standard (10 000 a 50 000 fichiers), la reconstruction prend entre 30 secondes et 3 minutes. Pour un profil volumineux (200 000+ fichiers, par exemple avec un cache OneDrive important), cela peut atteindre 10 minutes. Le facteur limitant est la vitesse du disque (SSD vs HDD).

---

EntraLift automatise la reconstruction des ACL NTFS pendant la migration. L'ancien SID est sauvegarde avant la disjonction, le nouveau SID est detecte automatiquement apres la jonction Entra, et le remapping est effectue recursivement avant le premier logon utilisateur.