Comment securiser une migration d'identite Windows : compte admin local, moindre privilege et audit
Une migration de postes de Hybrid Azure AD vers Entra ID modifie l'identite de la machine et de l'utilisateur. Pendant la transition, le poste passe par un etat intermediaire ou ni l'ancien domaine AD ni le nouveau tenant Entra ne le gerent pleinement. C'est une fenetre de risque. Cet article couvre les trois piliers de securite d'une migration d'identite : le compte administrateur local de secours, le principe de moindre privilege, et l'audit des operations.
Pourquoi la migration cree-t-elle une fenetre de risque ?
Entre la disjonction du domaine AD et la jonction Entra ID, le poste est en etat Workgroup. Pendant cette fenetre :
- Le poste n'est plus gere par les GPO Active Directory
- Les politiques Intune ne sont pas encore appliquees (l'inscription MDM se fait apres la jonction Entra)
- Le Conditional Access d'Entra ID ne protege pas encore les acces depuis ce poste
- Si la jonction Entra echoue, le poste reste sans gestion d'identite centralisee
Cette fenetre dure generalement quelques minutes (le temps d'un redemarrage et de l'application du PPKG). Mais en cas d'echec, elle peut durer indefiniment si personne n'intervient. D'ou l'importance d'un compte admin local de secours et d'un suivi en temps reel.
Comment configurer un compte administrateur local de secours ?
Le compte admin local de secours est le filet de securite de la migration. Il permet de se connecter au poste meme si :
- La jonction Entra echoue
- Le profil utilisateur ne se charge pas
- Le poste est coupe du reseau
Creation du compte
Le compte doit etre cree avant la disjonction du domaine (Phase 1), pendant que le poste est encore gere :
# Nom du compte admin de secours
$adminUser = "MigAdmin"
# Generer un mot de passe aleatoire (16 caracteres, complexe)
Add-Type -AssemblyName System.Web
$password = [System.Web.Security.Membership]::GeneratePassword(16, 4)
# Creer le compte
$securePassword = ConvertTo-SecureString $password -AsPlainText -Force
New-LocalUser -Name $adminUser -Password $securePassword -PasswordNeverExpires -AccountNeverExpires
Add-LocalGroupMember -Group "Administrators" -Member $adminUser
# Le mot de passe doit etre stocke de maniere securisee
# NE PAS le stocker en clair dans un fichier local
Stockage securise du mot de passe
Le mot de passe du compte de secours doit etre :
- Genere aleatoirement par poste (pas un mot de passe unique pour tous les postes)
- Chiffre avant d'etre envoye a un serveur central
- Consultable par l'administrateur depuis un dashboard securise
- Jamais stocke en clair sur le disque du poste, dans un fichier CSV, ou dans un email
# Exemple : chiffrement du mot de passe avec AES-256 avant envoi
$key = [System.Convert]::FromBase64String($env:ENCRYPTION_KEY)
$iv = [System.Security.Cryptography.Aes]::Create().IV
$aes = [System.Security.Cryptography.Aes]::Create()
$aes.Key = $key
$aes.IV = $iv
$encryptor = $aes.CreateEncryptor()
$passwordBytes = [System.Text.Encoding]::UTF8.GetBytes($password)
$encryptedBytes = $encryptor.TransformFinalBlock($passwordBytes, 0, $passwordBytes.Length)
$encryptedPassword = [Convert]::ToBase64String($iv + $encryptedBytes)
# Envoyer $encryptedPassword au serveur de pilotage via HTTPS
Suppression post-migration
Une fois la migration validee (poste Entra Joined, profil intact, politiques Intune appliquees), le compte de secours doit etre supprime ou desactive :
# Supprimer le compte de secours apres validation
Remove-LocalUser -Name "MigAdmin"
Alternativement, conservez le compte et gerez-le via Windows LAPS (Local Administrator Password Solution) pour Entra ID. LAPS fait tourner automatiquement le mot de passe du compte admin local et le stocke dans Entra de maniere securisee.
Comment appliquer le moindre privilege pendant la migration ?
Le moindre privilege limite les degats en cas de compromission d'un compte utilise pendant la migration.
Compte de service AD pour la disjonction
Le compte qui execute Remove-Computer ne doit pas etre un Domain Admin. Les droits necessaires sont uniquement :
| Droit | Objet | Portee |
|---|---|---|
WriteProperty sur userAccountControl |
Objets Computer | OU des machines a migrer |
WriteProperty sur dNSHostName |
Objets Computer | OU des machines a migrer |
WriteProperty sur servicePrincipalName |
Objets Computer | OU des machines a migrer |
DeleteChild (objets Computer) |
OU | OU des machines a migrer |
Reset Password (extended right) |
Objets Computer | OU des machines a migrer |
Delegez ces droits uniquement sur l'OU qui contient les machines a migrer, pas sur le domaine entier.
# Script de delegation (a executer par un Domain Admin, une seule fois)
$ou = "OU=PostesMigration,DC=domaine,DC=local"
$svcAccount = "DOMAINE\svc_migration"
dsacls $ou /G "$svcAccount`:CCDC;computer" /I:T
dsacls $ou /G "$svcAccount`:WP;userAccountControl;computer" /I:S
dsacls $ou /G "$svcAccount`:WP;dNSHostName;computer" /I:S
dsacls $ou /G "$svcAccount`:WP;servicePrincipalName;computer" /I:S
dsacls $ou /G "$svcAccount`:CA;Reset Password;computer" /I:S
Compte du Bulk Enrollment Token
Le compte utilise pour generer le Bulk Enrollment Token dans le PPKG doit avoir le droit d'inscrire des devices dans Entra, mais pas d'autres privileges. Creez un compte de service dedie (ex: svc-enrollment@tenant.onmicrosoft.com) avec uniquement le role Cloud Device Administrator ou le droit d'inscription en masse.
Agent de migration sur le poste
L'agent de migration s'execute en tant que SYSTEM sur le poste. C'est necessaire pour modifier le registre, disjoindre du domaine, et remapper les ACL. Mais l'agent ne doit pas avoir d'acces reseau excessif. Limitez ses communications aux endpoints strictement necessaires :
- Le serveur de pilotage (pour reporter l'etat et recevoir les commandes)
- Les services Microsoft Entra (pour la jonction)
- Aucun acces a d'autres serveurs internes
Comment auditer les operations de migration ?
L'audit permet de retracer chaque operation en cas de probleme ou d'incident de securite.
Ce qu'il faut logger
Chaque etape de la migration doit etre tracee avec un timestamp et un identifiant machine :
| Evenement | Donnees a logger |
|---|---|
| Debut de la Phase 1 | Machine ID, hostname, utilisateur connecte, SID AD |
| Disjonction reussie | Timestamp, resultat de Remove-Computer |
| Creation du compte admin local | Nom du compte (pas le mot de passe) |
| Debut de la Phase 2 | Timestamp |
| Application du PPKG | Resultat (succes/echec), code d'erreur eventuel |
| Jonction Entra reussie | Nouveau Device ID, timestamp |
| Remapping du profil | Ancien SID, nouveau SID, nombre de fichiers remappe |
| Migration terminee | Timestamp, duree totale |
Ou stocker les logs
- Localement : fichier log sur le poste (
C:\EntraLift\migration.log) pour le diagnostic en cas de perte de connectivite - Serveur central : envoi en temps reel au serveur de pilotage via HTTPS pour le suivi dans le dashboard
- Event Log Windows : ecriture dans un journal d'evenements dedie pour l'integration avec les outils SIEM
# Ecrire dans le journal d'evenements Windows
$source = "EntraLift-Migration"
if (-not [System.Diagnostics.EventLog]::SourceExists($source)) {
New-EventLog -LogName Application -Source $source
}
Write-EventLog -LogName Application -Source $source -EntryType Information `
-EventId 1000 -Message "Migration Phase 1 terminee pour $env:COMPUTERNAME"
Retention et revue
Conservez les logs de migration pendant au moins 90 jours apres la fin de la campagne de migration. Cela couvre la periode ou les utilisateurs peuvent encore rencontrer des problemes lies a la migration. Passez en revue les logs des machines en echec apres chaque vague.
FAQ
Faut-il un compte admin local sur chaque poste ou un compte generique ?
Un mot de passe unique par poste. Si un seul mot de passe est utilise pour tous les postes et qu'il fuite, tous les postes sont compromis. Generez un mot de passe aleatoire par machine, stocke de maniere chiffree sur le serveur de pilotage.
Windows LAPS remplace-t-il le compte de secours ?
Windows LAPS gere le mot de passe du compte admin local apres la jonction Entra. Pendant la migration (entre la disjonction AD et la jonction Entra), LAPS ne fonctionne pas encore car le poste n'est pas encore dans Entra. Le compte de secours cree par le script de migration couvre cette fenetre. Apres la migration, vous pouvez basculer vers LAPS pour la gestion continue.
Comment detecter si un compte de secours n'a pas ete supprime apres la migration ?
Deployez un script de remediation via Intune (Devices > Scripts and remediations > Remediations) qui detecte la presence du compte de secours et le supprime si la migration est terminee depuis plus de 7 jours. Alternativement, configurez Windows LAPS pour prendre en charge le compte.
EntraLift cree automatiquement un compte admin local de secours sur chaque poste avant la migration, avec un mot de passe unique genere aleatoirement et chiffre. Le mot de passe est consultable dans le dashboard. Le compte peut etre supprime automatiquement apres validation de la migration.
Commentaires (0)
Laisser un commentaire