Remapping du profil utilisateur apres jonction Entra : SID, registre, ACL

Quand un poste Windows passe de Hybrid Azure AD Join a Entra Join, le SID de l'utilisateur change. Windows associe chaque profil utilisateur a un SID specifique dans le registre. Si le registre n'est pas mis a jour, Windows cree un nouveau profil vide au lieu de charger le profil existant. Le remapping consiste a mettre a jour le registre et les ACL pour que le nouveau SID Entra pointe vers l'ancien profil. Cet article detaille chaque etape du processus.

Pourquoi Windows cree-t-il un nouveau profil apres la migration ?

Windows stocke l'association entre un SID et un profil dans la cle de registre HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Chaque sous-cle porte le nom d'un SID et contient le chemin du profil :

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
├── S-1-5-21-xxx-1234        ← ancien SID AD
│   └── ProfileImagePath = C:\Users\jean.dupont
├── S-1-5-18                 ← SYSTEM
└── S-1-5-19                 ← LOCAL SERVICE

Quand l'utilisateur se connecte avec son nouveau SID Entra (S-1-12-1-yyy-5678), Windows cherche une sous-cle correspondante dans ProfileList. Il n'en trouve pas — le SID est nouveau. Windows cree donc un nouveau profil dans C:\Users\jean.dupont.ENTRALIFT ou C:\Users\jean.dupont.000.

L'ancien profil complet est toujours sur le disque dans C:\Users\jean.dupont. Il suffit de dire a Windows que le nouveau SID doit utiliser ce profil. C'est le remapping.

Quelles sont les trois operations du remapping ?

Le remapping complet comprend trois operations, dans cet ordre :

1. Renommer la cle de registre ProfileList : pointer le nouveau SID vers l'ancien chemin de profil
2. Reconstruire les ACL NTFS : remplacer l'ancien SID par le nouveau dans les permissions de fichiers
3. Mettre a jour le fichier NTUSER.DAT : s'assurer que le registre utilisateur est accessible

Operation 1 — Renommer la cle ProfileList

$oldSid = "S-1-5-21-xxx-1234"    # SID AD (sauvegarde avant migration)
$newSid = "S-1-12-1-yyy-5678"    # SID Entra (detecte apres jonction)

$profileListPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList"

# Verifier que l'ancienne cle existe
$oldKey = Join-Path $profileListPath $oldSid
if (Test-Path $oldKey) {
    $profilePath = (Get-ItemProperty $oldKey).ProfileImagePath

    # Copier les valeurs vers une nouvelle cle avec le nouveau SID
    $newKey = Join-Path $profileListPath $newSid
    if (-not (Test-Path $newKey)) {
        Copy-Item -Path $oldKey -Destination $newKey
        Set-ItemProperty -Path $newKey -Name "ProfileImagePath" -Value $profilePath

        # Supprimer l'ancienne cle
        Remove-Item -Path $oldKey -Recurse

        Write-Host "ProfileList remappe : $oldSid -> $newSid -> $profilePath"
    }
}

Cette operation doit etre executee en tant que SYSTEM (ou depuis un compte admin local) car HKLM\SOFTWARE n'est pas modifiable par un utilisateur standard.

Operation 2 — Reconstruire les ACL NTFS

L'ancien SID est present dans les ACL du dossier de profil et de tous les sous-dossiers et fichiers. Il faut remplacer chaque reference a l'ancien SID par le nouveau.

$oldIdentity = New-Object System.Security.Principal.SecurityIdentifier($oldSid)
$newIdentity = New-Object System.Security.Principal.SecurityIdentifier($newSid)

# Remapper le owner et les ACE sur le dossier racine du profil
$profileDir = "C:\Users\jean.dupont"

# Prendre possession d'abord (en tant que SYSTEM/Admin)
takeown /F $profileDir /R /A /D O 2>$null

# Parcourir recursivement
Get-ChildItem -Path $profileDir -Recurse -Force -ErrorAction SilentlyContinue | ForEach-Object {
    try {
        $acl = Get-Acl $_.FullName
        $changed = $false
        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)
                $acl.RemoveAccessRule($ace) | Out-Null
                $acl.AddAccessRule($newAce)
                $changed = $true
            }
        }
        if ($acl.Owner -eq $oldIdentity.Value) {
            $acl.SetOwner($newIdentity)
            $changed = $true
        }
        if ($changed) { Set-Acl -Path $_.FullName -AclObject $acl }
    } catch {}
}

Pour une explication approfondie du fonctionnement des ACL NTFS et de leur reconstruction, consultez Gerer les ACL NTFS lors d'une migration d'identite Windows.

Operation 3 — NTUSER.DAT

Le fichier C:\Users\jean.dupont\NTUSER.DAT est le registre utilisateur (HKCU). Il porte ses propres ACL. Si l'ancien SID est le seul autorise, le nouveau compte ne peut pas charger le profil.

# S'assurer que le nouveau SID a Full Control sur NTUSER.DAT
$ntuserPath = Join-Path $profileDir "NTUSER.DAT"
$acl = Get-Acl $ntuserPath
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    $newIdentity, "FullControl", "Allow")
$acl.AddAccessRule($rule)
$acl.SetOwner($newIdentity)
Set-Acl -Path $ntuserPath -AclObject $acl

Le meme traitement s'applique a ntuser.dat.LOG1, ntuser.dat.LOG2, et UsrClass.dat (dans AppData\Local\Microsoft\Windows).

Quel est le bon timing pour le remapping ?

Le timing est critique. Voici la sequence correcte :

Phase 1 : Sauvegarder l'ancien SID → Disjoindre du domaine AD → Reboot
Phase 2 : Appliquer le PPKG → Jonction Entra → Reboot
Phase 3 : AVANT le logon utilisateur :
          1. Detecter le nouveau SID Entra
          2. Renommer la cle ProfileList
          3. Reconstruire les ACL
          4. Mettre a jour NTUSER.DAT
          → L'utilisateur se connecte → Profil intact

Si le remapping est effectue apres que l'utilisateur s'est connecte, Windows a deja cree un profil temporaire. Il faut alors :

1. Deconnecter l'utilisateur
2. Supprimer le profil temporaire (.000 ou .ENTRALIFT)
3. Effectuer le remapping
4. Reconnecter l'utilisateur

Comment detecter automatiquement le nouveau SID Entra ?

Apres la jonction Entra et le redemarrage, le nouveau SID n'est pas encore dans ProfileList (l'utilisateur ne s'est pas encore connecte). Mais il est visible dans le registre Entra du poste :

# Lire l'info de jonction Entra
$dsreg = dsregcmd /status
$userSid = ($dsreg | Select-String "UserSID").ToString().Split(":")[1].Trim()

Alternativement, si vous connaissez l'UPN de l'utilisateur, vous pouvez le resoudre apres jonction :

# Apres jonction Entra, l'utilisateur existe dans le store local
$account = New-Object System.Security.Principal.NTAccount("AzureAD\jean.dupont@domaine.com")
$newSid = $account.Translate([System.Security.Principal.SecurityIdentifier]).Value

FAQ

Le remapping fonctionne-t-il si l'utilisateur a un profil itinerant (roaming profile) ?

Les profils itinerants sont un mecanisme Active Directory. Apres la migration vers Entra Join, les profils itinerants ne sont plus charges depuis le serveur AD. Le profil local existant sur le poste est celui qui sera remappe. Si vous utilisez des profils itinerants, le contenu du profil est celui de la derniere synchronisation avant la migration.

Que se passe-t-il avec OneDrive Known Folder Move ?

Si OneDrive Known Folder Move (KFM) est active, les dossiers Bureau, Documents et Images sont rediriges vers OneDrive. Leur contenu est synchronise dans le cloud et ne depend pas du SID local. Le remapping des ACL reste necessaire pour les fichiers hors des dossiers rediriges (AppData, caches d'application, parametres locaux).

Peut-on tester le remapping sans migrer reellement ?

Oui, en laboratoire. Creez une VM en Hybrid Join, prenez un snapshot, migrez-la vers Entra Join, effectuez le remapping, verifiez le profil. Si le resultat est incorrect, restaurez le snapshot et ajustez les scripts. Cette approche est recommandee avant toute migration en production.

---

EntraLift automatise les trois operations de remapping — registre ProfileList, ACL NTFS, et NTUSER.DAT — en une seule passe, executee automatiquement entre la jonction Entra et le premier logon utilisateur. L'ancien SID est sauvegarde en Phase 1 et le nouveau est detecte automatiquement en Phase 2.