Error 0x52E joining a domain: credentials rejected or missing OU rights

Fix it now

0x52E is Windows error 1326, which Microsoft publishes as “The user name or password is incorrect”. On a domain join it is often exactly that, and three near misses produce the same refusal: an unqualified account name, an account with no right to create an object in the organisational unit you named, and a clock too far out for Kerberos.

w32tm /query /status
nltest /dsgetdc:corp.example.com
Add-Computer -DomainName corp.example.com -OUPath "OU=Workstations,DC=corp,DC=example,DC=com" -Credential (Get-Credential) -Restart

1. Enter the account in a qualified form: admin@corp.example.com or CORP\admin. On a machine that is not yet a member, an unqualified name is looked up locally first.
2. Check the clock. Microsoft’s own domain controller security test treats a skew of 300 seconds or more between two machines as fatal to Kerberos, so an offset near that is enough to produce an instant rejection.
3. If the credentials are good, the problem is rights on the destination container. Delegate the right to create computer objects on that organisational unit and retry with -OUPath naming it.
4. If the failure follows one account rather than one machine, read the next article along: the machine account quota produces a different code but the same shape of complaint.

Add-Computer is a Windows PowerShell 5.1 cmdlet. In PowerShell 7 it will not be recognised, which reads like a different failure than it is.

If the object appears in the organisational unit you targeted and a domain user signs in, you are done. If not, the next section separates the failures that share this code.

Why it happens

The join API authenticates the credentials you supply against a domain controller, then uses that identity to create or take over a computer object. A wrong password fails at the first stage and produces 1326. On the domain controller’s Security log the same failure appears as event 4625 with a Status or Sub Status of 0xC000006A, which Microsoft’s own monitoring guidance reads as a user logon with a misspelled or bad password. If you can see that pair, the password really is wrong and nothing else in this article applies.

The second case is an account that authenticates perfectly and is not permitted to create an object where you asked. Because that happens inside the same call, the failure can surface as a credential rejection rather than as an access denial. The distinguishing test is whether the same credentials work against the domain controller for something else. If they do, the password is right and the problem is delegation.

The third is time. Kerberos rejects a ticket whose timestamp falls outside the tolerance, and the symptom is a rejection that arrives instantly however carefully you retype the password. Microsoft’s dcdiag /test:CheckSecurityError check, run with /ReplSource, tests exactly this: it verifies that the time skew between servers is less than 300 seconds for Kerberos, along with naming context permissions, SYSVOL and NETLOGON connectivity, and the “Access this computer from the network” privilege.

Two neighbouring codes are worth telling apart. 1385, ERROR_LOGON_TYPE_NOT_GRANTED, is published as “Logon failure: the user has not been granted the requested logon type at this computer” – the account is valid and is being refused a particular kind of logon. 1332, ERROR_NONE_MAPPED, is “No mapping between account names and security IDs was done”, which means the name could not be resolved to a security identifier at all: a deleted account, an untrusted domain, or a stale entry in an access control list.

Full reference

The codes, as Microsoft publishes them

Telling the three failures apart in two minutes

Delegation rather than Domain Admin

The right answer to “this account cannot create the object” is almost never to make the account more powerful. Microsoft documents that members of Administrators and Domain Administrators, and users with delegated permissions on containers to create and delete computer accounts, are exempt from the machine account quota. Delegating on the specific organisational unit where machines land gets you the same practical result as Domain Admin for joins, without giving a deployment account rights over everything else in the directory.

1. Open Active Directory Users and Computers and find the OU machines are built into.
2. Delegate control to the deployment account or group.
3. Grant the right to create computer objects in that folder, and to delete them if rebuilds are part of the job.
4. Test with one machine, joined with -OUPath naming that OU.
5. Document which accounts hold the delegation, so that the next person does not raise the machine account quota to work around a rights problem.

Time, and why it is worth checking early

Do not correct a domain-wide drift by setting the clock on a domain controller by hand. Time flows down the domain hierarchy, so a manually set DC ends up fighting it. Correct the source the hierarchy uses and let the rest follow.

Codes that arrive at the same dialog from somewhere else

• 8557 is the machine account quota refusal: the account has created as many computer objects as it is allowed. Different code, same complaint from the user.
• 8305 means an object with that name already exists in the directory, which is what a rebuild under an old name looks like.
• 1355 means the domain could not be contacted at all, which is a locator problem and not a credential one.
• 1722 means the RPC conversation never opened, so credentials were never evaluated.

Before you conclude the password is wrong

Read the failure on the domain controller rather than on the client. A Security log entry with a Status or Sub Status of 0xC000006A settles the question in one line, and Microsoft’s own guidance is to watch for a run of them against critical or service accounts. If there is no such entry, the domain controller never rejected a password, and whatever failed on the client happened before or after the authentication rather than during it.

Every code this article covers

Confirm the fix worked

1. The computer object appears in the organisational unit you targeted, not the default container.
2. A domain user signs in at the console of a machine with no cached credentials for them.
3. w32tm /query /status on the client shows a small offset against a domain time source.
4. No new event 4625 with Sub Status 0xC000006A appears on the domain controller for that account.
5. gpupdate /force completes on the joined machine.

Questions people ask about this