Sunday, August 27, 2006 10:18 PM
Jorge
Incorrect userAccountControl Attribute value causes error when running DCDIAG or during promotion of a server to a DC
There exist two issues/errors that can occur from the same cause, namely an incorrect set "userAccountControl" attribute value on a computer account.
For more information about the "userAccountControl" attribute see: http://support.microsoft.com/?id=305144
These are the default "userAccountControl" attribute values for the certain objects:
- Typical user : 0x200 (512)
- Domain controller : 0x82000 (532480)
- Workstation/server: 0x1000 (4096)
SCENARIO 1:
When running DCDIAG on a DC with a correct "userAccountControl" attribute value, something like the following will be reported:
Starting test: MachineAccount
Checking machine account for DC ROOTDC001 on DC ROOTDC001.
* SPN found :LDAP/rootdc001.ADCORP.LAN/ADCORP.LAN
* SPN found :LDAP/rootdc001.ADCORP.LAN
* SPN found :LDAP/ROOTDC001
* SPN found :LDAP/rootdc001.ADCORP.LAN/ADCORP
* SPN found :LDAP/ffb47c4c-ff0f-480d-854d-59e0ef0c5b11._msdcs.ADCORP.LAN
* SPN found :E3514235-4B06-11D1-AB04-00C04FC2DCD2/ffb47c4c-ff0f-480d-854d-59e0ef0c5b11/ADCORP.LAN
* SPN found :HOST/rootdc001.ADCORP.LAN/ADCORP.LAN
* SPN found :HOST/rootdc001.ADCORP.LAN
* SPN found :HOST/ROOTDC001
* SPN found :HOST/rootdc001.ADCORP.LAN/ADCORP
* SPN found :GC/rootdc001.ADCORP.LAN/ADCORP.LAN
......................... ROOTDC001 passed test MachineAccount
When viewed with LDP, the "userAccountControl" attribute value for a normal DC computer account should be:
1> userAccountControl: 0x82000 = ( UF_SERVER_TRUST_ACCOUNT | UF_TRUSTED_FOR_DELEGATION );
When running DCDIAG on a DC with a incorrect "userAccountControl" attribute value, something like the following will be reported:
Starting test: MachineAccount
Checking machine account for DC ROOTDC001 on DC ROOTDC001.
Warning: Attribute userAccountControl of ROOTDC001 is: 0x82020 = ( UF_PASSWD_NOTREQD | UF_SERVER_TRUST_ACCOUNT | UF_TRUSTED_FOR_DELEGATION )
Typical setting for a DC is 0x82000 = ( UF_SERVER_TRUST_ACCOUNT | UF_TRUSTED_FOR_DELEGATION )
This may be affecting replication?
* SPN found :LDAP/rootdc001.ADCORP.LAN/ADCORP.LAN
* SPN found :LDAP/rootdc001.ADCORP.LAN
* SPN found :LDAP/ROOTDC001
* SPN found :LDAP/rootdc001.ADCORP.LAN/ADCORP
* SPN found :LDAP/ffb47c4c-ff0f-480d-854d-59e0ef0c5b11._msdcs.ADCORP.LAN
* SPN found :E3514235-4B06-11D1-AB04-00C04FC2DCD2/ffb47c4c-ff0f-480d-854d-59e0ef0c5b11/ADCORP.LAN
* SPN found :HOST/rootdc001.ADCORP.LAN/ADCORP.LAN
* SPN found :HOST/rootdc001.ADCORP.LAN
* SPN found :HOST/ROOTDC001
* SPN found :HOST/rootdc001.ADCORP.LAN/ADCORP
* SPN found :GC/rootdc001.ADCORP.LAN/ADCORP.LAN
......................... ROOTDC001 passed test MachineAccount
When viewed with LDP, the "userAccountControl" attribute value for the DC computer account :
1> userAccountControl: 0x82020 = ( UF_PASSWD_NOTREQD | UF_SERVER_TRUST_ACCOUNT | UF_TRUSTED_FOR_DELEGATION );
SCENARIO 2:
When joining a server to a domain you can create the computer account during the join/promotion action OR you can pre-create the computer account using Active Directory Users and Computers and then join/promote. The latter can also occur when a server has been migrated from another domain. As part of the migration of the server the computer account is pre-created by the migration tool (e.g. ADMT) and after that server is migrated from one domain to the other!
When viewed with LDP, the "userAccountControl" attribute value for a normal server computer account should be:
1> userAccountControl: 0x1000 = ( UF_WORKSTATION_TRUST_ACCOUNT );
When viewed with LDP, the "userAccountControl" attribute value for the server computer account is:
1> userAccountControl: 0x1020 = ( UF_PASSWD_NOTREQD | UF_WORKSTATION_TRUST_ACCOUNT );
In the latter case, when promoting the server to a DC, for which a pre-created computer account was created, the following error might appear:
The operation failed because: The Active Directory Installation Wizard was unable to convert the computer account COMPUTER_NAME$ to a domain controller account. "Access is denied."
For both scenarios, the cause is an incorrect "userAccountControl" attribute value and the solution is to reset it to a correct value.
To restore the default "userAccountControl" attribute value for the computer account you can either use LDP or ADSIEDIT.MSC. Here I will explain how to change it with ADSIEDIT.MSC.
When using ADSIEDIT.MSC:
- From the command-line start ADSIEDIT.MSC
- Connect to the domain NC
- Navigate to the OU or container that contains the computer account of the server for which the "userAccountControl" attribute value must be changed
- Right click on the computer account of the server for which the "userAccountControl" attribute value must be changed and retrieve the properties
- Scroll down to the "userAccountControl" attribute
- You should see some value: <some DECIMAL value>
- If the server already is a DC change the value to: 532480
After this, if you use LDP you should see:
1> userAccountControl: 0x82000 = ( UF_SERVER_TRUST_ACCOUNT | UF_TRUSTED_FOR_DELEGATION ); - If the server is not a DC and was being promoted to a DC, change the value to: 4096
After this, if you use LDP you should see:
1> userAccountControl: 0x1000 = ( UF_WORKSTATION_TRUST_ACCOUNT );
Cheers,
Jorge
------------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
------------------------------------------------------------------------------------------------