RODC et coupure du RW‑DC : résoudre l’échec d’authentification locale dans Active Directory

Lorsqu’un site ne possède qu’un RODC, une maintenance du contrôleur de domaine principal peut bloquer l’authentification locale si la PRP et la réplication inter‑site ne sont pas correctement configurées. Ce guide explique les causes, la remise en service et les bonnes pratiques éprouvées.

Problème : échec de l’authentification locale quand le RW‑DC est indisponible

Un site distant dispose d’un Read‑Only Domain Controller (RODC) sans aucun lien de réplication inter‑site défini. Lors d’une coupure planifiée du contrôleur de domaine principal (read‑write DC ou RW‑DC) hébergé ailleurs, les postes n’ont plus pu ouvrir de session sur le réseau local. Après coup, une GPO a été créée pour autoriser la mise en cache des informations d’identification, et des comptes ont été ajoutés dans Allowed RODC Password Replication Group. Pourtant, une tentative de préremplissage retourne : “The account must first be added to the Allowed list for this read‑only domain controller”.

Vue d’ensemble

Par conception, un RODC lit l’annuaire mais n’écrit pas. Il peut cependant mettre en cache des hachages de mots de passe pour authentifier localement les utilisateurs et ordinateurs du site lorsque la liaison WAN vers un RW‑DC est coupée. Cette capacité est contrôlée par la Password Replication Policy (PRP) définie sur l’objet ordinateur du RODC dans Active Directory. Sans réplication des objets utilisateurs, groupes et PRP vers ce RODC, et sans cache préalablement rempli, aucune authentification locale ne peut réussir pendant l’indisponibilité du RW‑DC.

Comment fonctionne réellement la PRP

• Listes PRP : Allowed (attribut msDS-RevealOnDemandGroup) et Denied (attribut msDS-NeverRevealGroup) définissent qui peut (ou ne peut jamais) voir son mot de passe répliqué.
• État du cache : msDS-RevealedList répertorie les comptes dont le mot de passe est déjà mis en cache. Un compte autorisé mais non encore “révélé” nécessitera soit un pre‑populate, soit une première connexion pendant que le RW‑DC reste accessible.
• Deux conditions indispensables : l’objet du compte doit exister sur le RODC (réplication AD) et la PRP doit l’autoriser. À défaut, le RODC ne peut servir de KDC local et renvoie une erreur.

Symptômes typiques sur site distant

• Connexion interactive impossible, messages d’erreur d’authentification Kerberos/NTLM.
• Événements dans Directory‑Services‑RODC signalant des demandes de mot de passe non autorisées (ex. ID 1695) ou l’absence d’objet localement répliqué.
• Erreurs lors d’un pre‑populate : “account must first be added to the Allowed list…”.
• Résolution DNS partielle ou dégradée si le rôle DNS local n’est pas correctement configuré sur le RODC.

Analyse des causes probables

1. Absence de réplication des objets AD vers le RODC : aucune topologie inter‑site (site link/schedule) n’a été définie. Résultat : les nouveaux utilisateurs, groupes et changements d’appartenance (dont l’ajout au groupe Allowed RODC Password Replication Group) ne sont jamais copiés vers le RODC.
2. PRP mal appliquée : des comptes présents dans la liste Denied ou non encore visibles localement. Rappel : un compte peut être autorisé via un groupe, mais s’il appartient, même indirectement, à Denied RODC Password Replication Group, il sera bloqué.
3. Cache vide : sans préremplissage (pre‑populate) et sans première connexion pendant que le RW‑DC est disponible, le RODC n’a aucun hachage local et ne peut authentifier hors‑ligne.

Solutions et bonnes pratiques

Action	Description	Commandes / outils utiles
Activer ou planifier la réplication AD inter‑site	Créer un Site Link dans Active Directory Sites and Services, définir un horaire, vérifier la connectivité (135, 389, 636, 3268, 3269, 53, 88, 445, 9389, RPC dynamiques).	repadmin /replsummary, repadmin /showrepl, nltest /dclist:domain.tld
Vérifier la PRP du RODC	Dans les propriétés du RODC → Password Replication Policy, confirmer que les comptes/groupes nécessaires sont en Allowed et absents de Denied.	ADUC ou PowerShell : Get-ADDomainControllerPasswordReplicationPolicy, repadmin /prp view <RODCName> allowed|denied|revealed
Pré‑remplir (cache) les mots de passe	Une fois autorisés et répliqués : clic droit sur le RODC → Prepopulate Passwords… ou en CLI pour pousser les hachages.	repadmin /rodcpwdrepl <RODCName> <User1> <User2> (après convergence).
Activer/paramétrer le cache d’identifiants hors‑ligne	Les clients Windows conservent déjà un cache (10 connexions récentes par défaut). Pour l’ajuster : GPO Interactive logon: Number of previous logons to cache…	gpupdate /force
Surveiller et tester	Tester la connexion d’un poste tant que le RW‑DC est encore opérationnel pour peupler le cache, puis simuler l’arrêt du RW‑DC.	nltest /dsgetsite, journaux d’événements, Directory‑Services‑RODC
Solutions de secours	Mettre en place un VPN site‑à‑site vers un RW‑DC ou promouvoir un second RODC local pour supprimer le point de défaillance unique.	—

Procédure de remédiation rapide

1. Créer/valider le Site Link : associer les sites HQ et Remote, définir l’horaire de réplication (idéalement 15 min), puis forcer une topologie : repadmin /kcc * repadmin /syncall /AeP repadmin /replsummary
2. Vérifier que l’objet utilisateur est présent sur le RODC : repadmin /showobjmeta <RODCName> "CN=Prénom Nom,OU=...,DC=domain,DC=tld" Si l’objet est absent, forcer la réplication du NC concerné (domain naming context) puis revérifier.
3. Contrôler la PRP : repadmin /prp view <RODCName> allowed repadmin /prp view <RODCName> denied S’assurer que le compte ou le groupe (ex. Utilisateurs‑Site‑Remote) est en Allowed et non dans Denied.
4. Pré‑remplir le cache : repadmin /rodcpwdrepl <RODCName> domain\user1 domain\user2 repadmin /prp view <RODCName> revealed Attendre la convergence et contrôler que les comptes apparaissent dans revealed.
5. Vérifier DNS et SRV : le RODC doit porter le rôle DNS et héberger les enregistrements SRV appropriés (GC/KDC). Les clients du site doivent pointer d’abord vers ce DNS local.
6. Tester en conditions réelles : déconnecter la liaison WAN (ou éteindre seulement le RW‑DC) puis ouvrir une session avec un compte prérempli et non administrateur.

Vérifications détaillées et diagnostics

Contrôle de la topologie et de la santé AD

repadmin /showrepl <RODCName> /errorsonly
repadmin /replsummary
dcdiag /v /c /e /f:dcdiag.txt
nltest /dclist:domain.tld
nltest /dsgetdc:domain.tld /force /site:<RemoteSite>

• Corriger toute alerte inbound/outbound replication sur le RODC.
• Vérifier la résolution DNS de _ldap._tcp.Site-Remote._sites.dc._msdcs.domain.tld.

Contrôle PRP depuis PowerShell

Import-Module ActiveDirectory

# Récupérer la PRP complète

Get-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-REMOTE" -Allowed
Get-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-REMOTE" -Denied

# Voir qui est déjà en cache

Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity "RODC-REMOTE" -RevealedAccounts

# Ajouter un groupe d'utilisateurs du site à Allowed (exécuter sur un RW‑DC)

Set-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-REMOTE" -AllowedList @{Add="CN=Utilisateurs-Site-Remote,OU=Groupes,DC=domain,DC=tld"}

Pourquoi le préremplissage échoue

• Objet non répliqué : le compte n’existe pas (encore) dans la base NTDS du RODC. Tant que la réplication AD n’a pas copié l’objet et ses appartenances, pre‑populate échoue.
• Conflit Allowed vs Denied : un utilisateur autorisé via un groupe peut rester bloqué s’il est (directement ou indirectement) membre de Denied.
• Horloge et Kerberos : dérive d’horloge > 5 min ⇒ tickets invalides. Le RODC doit être source NTP pour le site distant (ou relai fiable).

Configuration du cache d’identifiants côté poste

La stratégie Interactive logon: Number of previous logons to cache (in case domain controller is not available) se trouve dans : Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Une valeur 10–50 est courante pour des sites à connectivité intermittente.

DNS sur RODC

• Installer le rôle DNS sur le RODC et héberger des zones AD‑intégrées (Stubs ou Read‑only selon le design).
• Clients du site : DNS primaire = RODC; DNS secondaire = résolveur de secours atteignable via WAN/VPN.
• Contrôler l’enregistrement des SRV (KDC/GC/LDAP) pour le site : nslookup -type=SRV _kerberos._tcp.Site-Remote._sites.domain.tld.

Scripts d’automatisation — audit et mise en cache

Exemple : auditer la PRP, la présence des objets et préremplir pour tous les utilisateurs d’une OU donnée.

Import-Module ActiveDirectory

$RodcName    = "RODC-REMOTE"
$TargetOU    = "OU=Utilisateurs,OU=Remote,DC=domain,DC=tld"
$Users       = Get-ADUser -SearchBase $TargetOU -Filter * | Select-Object -Expand SamAccountName

# 1) Vérifier que l'OU est autorisée via un groupe d'agrégation (AGDLP)

$GroupAllowed = "CN=Utilisateurs-Site-Remote,OU=Groupes,DC=domain,DC=tld"
Set-ADDomainControllerPasswordReplicationPolicy -Identity $RodcName -AllowedList @{Add=$GroupAllowed}

# 2) Forcer une synchronisation globale (exécuter sur un RW-DC)

repadmin /syncall /AdeP

# 3) Préremplir les comptes (par lot raisonnable)

$BatchSize = 50
$Users | ForEach-Object -Begin {$batch=@()} -Process {
$batch += $_
if ($batch.Count -ge $BatchSize) {
$cmd = "repadmin /rodcpwdrepl $RodcName " + ($batch -join " ")
Write-Host $cmd
cmd /c $cmd
$batch=@()
}
} -End {
if ($batch.Count -gt 0) {
$cmd = "repadmin /rodcpwdrepl $RodcName " + ($batch -join " ")
Write-Host $cmd
cmd /c $cmd
}
}

Plan de test avant une maintenance RW‑DC

1. Jour J‑7 : créer/mettre à jour le groupe Utilisateurs‑Site‑Remote. L’y ajouter pour tous les comptes destinés au cache.
2. Jour J‑6 : valider la topologie inter‑site et la synchronisation (repadmin /replsummary = OK).
3. Jour J‑5 : pre‑populate pour l’échantillon pilote (10 utilisateurs). Vérifier revealed.
4. Jour J‑4 : étendre à tout le périmètre. Documenter la liste revealed exportée.
5. Jour J‑3 : tests réels : demander au site d’ouvrir une session pendant que le RW‑DC est en ligne.
6. Jour J‑2 : valider DNS, NTP, journaux RODC sans erreurs.
7. Jour J‑1 : gel des changements d’appartenance de groupes. Nouvelle passe repadmin /syncall /APeD.
8. Jour J : exécuter la maintenance. Mesurer le taux de connexion réussi à distance.

Erreurs fréquentes et parades

• Mettre des comptes sensibles en Allowed : par sécurité, les comptes intégrés Administrators / Domain Admins ne sont jamais mis en cache. Ne pas les déplacer en Allowed.
• Ignorer les groupes imbriqués : un utilisateur autorisé via un groupe peut rester bloqué si un autre groupe parent figure dans Denied.
• Rely on client cached logons uniquement : utile pour des laptops, mais insuffisant pour les services Windows (accès aux partages, scripts d’ouverture) qui requièrent un DC opérationnel.
• DNS externe uniquement : la simple résolution Internet ne suffit pas. Les enregistrements AD‑intégrés doivent être disponibles localement.

Architecture recommandée pour sites distants

• Deux RODC locaux : élimine le SPOF en cas de panne matérielle d’un RODC unique.
• VPN site‑à‑site stable vers un RW‑DC : permet le seeding du cache et des opérations d’administration.
• Conception AGDLP dédiée à la PRP : un groupe Utilisateurs‑Site‑Remote à placer en Allowed sur les RODC du site, et des groupes “jamais répliquer” en Denied.
• Surveillance proactive : alerter sur les événements PRP/RODC (ex. 1645, 1695), les échecs de réplication et la dérive NTP.

Check‑list de diagnostic rapide

Question	Comment vérifier	Action si KO
Le site link existe‑t‑il et réplique‑t‑il ?	repadmin /replsummary, /showrepl	Créer/configurer le lien, ouvrir les ports, /syncall
L’utilisateur est‑il présent sur le RODC ?	repadmin /showobjmeta	Forcer la réplication du NC
La PRP autorise‑t‑elle ce compte ?	repadmin /prp view allowed/denied	Ajouter le groupe en Allowed, retirer de Denied
Le mot de passe est‑il déjà en cache ?	PRP → Advanced → Resultant Set ou ... -RevealedAccounts	Exécuter /rodcpwdrepl puis revérifier
DNS local opérationnel ?	Résolution SRV et nom du domaine, tests clients	Corriger rôle DNS, forwarders, clients
Horloge correcte ?	w32tm /query /status	Aligner sur une source NTP fiable

Cas d’école : pourquoi la GPO “cache d’identifiants” n’a pas suffi

La stratégie Interactive logon: Number of previous logons to cache améliore la résilience poste, mais ne remplace pas l’authentification AD pour les accès réseau, scripts, GPP, etc. Sans RODC fonctionnel (objets répliqués + PRP + cache PRP), on observe : partages inaccessibles, scripts non exécutés, politiques incomplètes. La GPO est un complément, pas une solution à elle seule.

Questions fréquentes

Q : Le message “The account must first be added to the Allowed list…” signifie‑t‑il que l’utilisateur n’est pas en Allowed ?
R : Pas forcément. Il peut l’être côté RW‑DC, mais le RODC n’a pas encore reçu la modification (pas de réplication) ou le compte n’existe pas sur ce RODC. Il faut d’abord corriger la topologie et synchroniser.

Q : Peut‑on autoriser tout le monde en Allowed ?
R : Techniquement oui, mais déconseillé. Utilisez un groupe spécifique au site. Maintenez Denied pour les comptes sensibles (Admins, KRBTGT, etc.).

Q : Le RODC peut‑il émettre des TGT pour des comptes non mis en cache ?
R : Non. Il doit contacter un RW‑DC pour ces comptes. Si la liaison est coupée, seule l’authentification des comptes déjà mis en cache peut réussir.

Q : Les comptes d’ordinateur doivent‑ils être mis en cache ?
R : Souvent oui pour les machines du site (services, GMSA selon le besoin). Appliquez le même principe : réplication des objets + PRP + préremplissage si nécessaire.

Bonnes pratiques de sécurité

• Principe du moindre privilège : ne mettez en cache que les comptes nécessaires au site.
• Pas de comptes à haut privilège en cache : laissez‑les en Denied.
• Journalisation : surveillez les événements PRP (ajouts, révélations, refus) et les accès LDAP/Kerberos.
• Plan de révocation : en cas de compromission du site, utilisez la fonctionnalité de réinitialisation des mots de passe mis en cache lors de la Demotion ou via les outils AD.

Résumé opérationnel

1. Établir une réplication inter‑site régulière afin que comptes, groupes et PRP soient présents sur le RODC.
2. Autoriser explicitement les comptes (ou un groupe d’utilisateurs du site) en Allowed, et supprimer tout conflit en Denied.
3. Pré‑remplir les mots de passe ou faire réaliser une première connexion pendant que le RW‑DC est disponible.
4. Tester hors connexion du RW‑DC et surveiller les journaux pour valider l’authentification locale.

Annexes — commandes utiles

# Topologie et réplication
repadmin /kcc *
repadmin /replsummary
repadmin /showrepl RODC-REMOTE /errorsonly
repadmin /syncall /APeD

# PRP

repadmin /prp view RODC-REMOTE allowed
repadmin /prp view RODC-REMOTE denied
repadmin /prp view RODC-REMOTE revealed
repadmin /rodcpwdrepl RODC-REMOTE domain\user1 domain\user2

# DNS, site et DC

nltest /dsgetsite
nltest /dclist:domain.tld
nslookup -type=SRV _kerberos._tcp.Site-Remote._sites.domain.tld

# Temps (Kerberos)

w32tm /query /status

# PowerShell (extraits)

Get-ADDomainController -Filter "IsReadOnly -eq '$true'"
Get-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-REMOTE" -Allowed
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity "RODC-REMOTE" -RevealedAccounts 

---

En appliquant ces étapes (réplication, PRP correcte, préremplissage, DNS/NTP fiables et tests réels), un site ne disposant que d’un RODC peut continuer à authentifier localement ses utilisateurs pendant une coupure planifiée ou imprévue du RW‑DC, sans sacrifier la sécurité.