MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Active Directory : résoudre l’impossibilité de joindre un ordinateur pré‑créé après les correctifs KB5020276/KB5028166

Active Directory : résoudre l’impossibilité de joindre un ordinateur pré‑créé après les correctifs KB5020276/KB5028166

Windows Server

Dans certains environnements Active Directory récents, joindre au domaine un poste dont l’objet ordinateur a été pré‑créé (pre‑staged) par un administrateur spécifique échoue pour ses collègues pourtant habilités. Cette analyse exhaustive explique pourquoi et détaille la méthode fiable pour rétablir la jonction multi‑opérateurs.

Sommaire

Pourquoi seul l’administrateur créateur parvient à joindre l’objet pré‑créé ?

Depuis le correctif KB5020276 (Netjoin : Domain‑Join Hardening Changes) publié en octobre 2022, Windows renforce la réutilisation des comptes ordinateurs existants :

  • Le client valide désormais que l’utilisateur effectuant la jonction détient explicitement les droits d’écriture appropriés sur l’objet.
  • Le processus tient compte du propriétaire (owner) de l’objet : par défaut, il s’agit du créateur. Aucun autre administrateur ne bénéficie automatiquement de droits complets si les ACL (Access Control Lists) ont été durcies.
  • Les mises à jour cumulatives ultérieures (KB5028166, KB5034125, etc.) ont poursuivi ce durcissement en ajustant les ACE (Access Control Entries) par défaut pour limiter les privilèges d’héritage.

Étape 1 – Vérifier la délégation de droits sur l’OU cible

Commencez par confirmer que le groupe ou le compte technique chargé des jonctions dispose des autorisations minimales sur l’OU où les objets ordinateurs sont créés.

Axe de vérificationPoints clésProcédure suggérée
Délégation de droitsLe compte doit posséder :
• Create Computer Objects
• Delete Computer Objects
• Reset Password
• (optionnel) Validated write to DNS host name & servicePrincipalName		Dans Active Directory Users and Computers (ADUC) :
Clic droit sur l’OU → Delegate Control → ajouter le groupe d’opérateurs.
Alternativement, exécutez :
dsacls "OU=Workstations,DC=contoso,DC=com" /S pour lister les ACE effectives.
Quota de jonctionsLes comptes non‑administrateurs sont limités à 10 jonctions par défaut.Via la console Group Policy Management (GPMC) :
Configuration ordinateur → Stratégies → Paramètres Windows → Paramètres de sécurité → Attribution des droits utilisateur → Add workstations to domain. Élargir la limite ou affecter le droit à un groupe.

Étape 2 – Contrôler la sécurité de l’objet ordinateur pré‑créé

1. Positionnement dans la bonne OU

Vérifiez que l’objet n’a pas été créé dans l’OU par défaut Computers, dépourvue de toute délégation personnalisée. Déplacez‑le si nécessaire.

2. ACL et attributs critiques

Ouvrez l’onglet Security de l’objet :

  • Attribuez au groupe d’opérateurs les droits Reset password et Write sur servicePrincipalName, dNSHostName, userAccountControl, unicodePwd.
  • Désactivez la case « Protect object from accidental deletion » qui ajoute des ACE Deny Delete.
  • Le cas échéant, transférez la propriété (Owner) de l’objet à Domain Admins ou à un groupe technique plutôt qu’au créateur individuel.

Étape 3 – Examiner les stratégies de groupe et la limitation des 10 jonctions

Le réglage MachineAccountQuota dans la partition CN=Directory Service,CN=Windows NT,CN=Services du domaine fixe la limite des jonctions par utilisateur standard. Vous pouvez :

  1. Éditer ce quota via ADSI Edit (valeur dword –1 pour illimité).
  2. Ou conférer le droit Add workstations to domain au groupe d’opérateurs dans une GPO.

Étape 4 – Analyser les journaux d’événements

L’échec de jonction affiche côté client une boîte de dialogue « Accès refusé » et consigne :

  • Événements ID 4097/4098 dans NetSetup.
  • Côté contrôleur de domaine, événements ID 5722 (échec d’établir une session sécurisée) ou 5805 (l’ordinateur n’a pas pu être lié).

Activez l’audit Directory Service Access (DS Access) puis consultez les événements 4662 pour identifier précisément l’ACE qui bloque l’opération.

Étape 5 – Impact concret des correctifs récents

Les mises à jour suivantes ont modifié le comportement :

  • KB5020276 (oct. 2022) : durcissement initial, ajoute un contrôle de propriété et restreint la réutilisation des comptes.
  • KB5028166 (juil. 2023) : renforce les vérifications de confiance et change certaines ACL par défaut, provoquant des échecs avec Samba/NT4 et des objets pré‑stagés.
  • KB5034125 (janv. 2024) : généralise le durcissement aux dernières branches Windows 10/11.

Pour valider l’hypothèse, isolez une machine de test, désinstallez le correctif via wusa /uninstall /kb:5028166, redémarrez et rejouez la jonction. Si elle réussit, adaptez les ACL plutôt que de supprimer définitivement la mise à jour, car celle‑ci corrige également des vulnérabilités de sécurité.

Procédure de dépannage complète

  1. Supprimez tout ACE explicite « Deny » ajouté par mégarde.
  2. Déplacez l’objet dans l’OU où la délégation est définie.
  3. Attribuez la propriété à un groupe au lieu d’un individu.
  4. Appliquez les droits décrits (Create/Delete/Reset/Write).
  5. Vérifiez la GPO pour lever la limite de 10 ordinateurs.
  6. Nettoyez le cache local côté client :
    ipconfig /flushdns & klist purge & nltest /sc_reset
  7. Rejouez la jonction avec Add‑Computer ou l’interface graphique.
  8. Si l’échec persiste, activez l’audit DS Access et analysez les événements 4662.

Checklist rapide

  • ✔️ Compte opérateur membre du groupe délégué
  • ✔️ Droits d’écriture SPN & DNS Hostname
  • ✔️ Objet dans la bonne OU
  • ✔️ Propriétaire adéquat
  • ✔️ Aucun ACE Deny résiduel
  • ✔️ Correctifs installés & comportement compris

Script PowerShell d’inventaire

Le fragment suivant liste les ACL non standard sur les comptes ordinateurs :

$ou = "OU=Workstations,DC=contoso,DC=com"
Get-ADComputer -SearchBase $ou -Filter * |
 ForEach-Object {
   $acl = Get-Acl $_.DistinguishedName
   [PSCustomObject]@{
     Computer = $_.Name
     NonInheritanceACE = ($acl.Access | Where-Object { -not $_.IsInherited }).Count
   }
 } | Export-Csv ".\\ComputerAclAudit.csv" -NoTypeInformation

Exploitez le CSV pour repérer les objets comportant encore des ACE héritées de l’administrateur créateur.

Bonnes pratiques pour éviter le problème à l’avenir

  • Automatiser le prestaging via un compte de service dédié dont les ACL sont calibrées et auditées.
  • Centraliser la délégation au niveau de l’OU, pas sur chaque objet.
  • Documenter les exceptions (machines nécessitant un positionnement particulier).
  • Mettre en place des tests de jonction réguliers dans un environnement de pré‑production avant le « Patch Tuesday ».
  • Suivre le cycle de vie des KB et lire les notes de version Netjoin.

FAQ

Le paramètre MachineAccountQuota suffit‑il à régler le problème ?

Non. Il supprime seulement la limite de 10 jonctions mais n’accorde pas les droits d’écriture nécessaires sur un objet pré‑stagé ni ne modifie la propriété de l’objet.

Utiliser netdom ou Add‑Computer change‑t‑il le comportement ?

Non. Ces commandes reposent sur les mêmes API Netjoin et sur les mêmes ACL AD que l’interface graphique.

Puis‑je cloner les ACL d’un objet qui fonctionne ?

Oui, via dsacls <DN> /S > good.acl puis dsacls <DN‑cible> /RestoreACL good.acl. Attention toutefois à l’owner et aux SID spécifiques.

Conclusion

Depuis le durcissement introduit par KB5020276, la jonction d’un ordinateur pré‑créé exige une vérification rigoureuse des ACL et de la propriété de l’objet. En appliquant la méthode pas‑à‑pas détaillée ci‑dessus — délégation correcte, contrôle des ACE, validation des stratégies de groupe et compréhension des correctifs récents — vous éliminerez l’erreur « Accès refusé » et garantirez une expérience de jonction homogène pour toute l’équipe IT.

Windows Server
Active Directory Windows Server Domain Join KB5020276 KB5028166
Sommaire