Troubleshooting RODC's: Troubleshooting domain joins against RODC's

Windows Server 2008

So, the first question…do you need to deploy the RODC compatibility pack on your XP/2003 clients if you want to deploy RODC's? 

For domain joins (and password changes) against an RODC the answer is most definitely yes.

 

One of the most important changes implemented in the compack is how the client calls the DsGetDCName function which is a critical part of how the client locates a suitable DC. 

Without the change, DsGetDCName is called with the DS_WRITABLE_REQUIRED flag in most cases where a DC is needed. This was based on backwards compatibility with NT 4 where you knew that no BDC’s would be writable and any writable DC in a mixed mode domain would be an AD DC (since the NT 4 PDC is the first DC in the domain that is upgraded).
 

The behavior of DsGetDCName after you’ve installed the compack is that in most cases the DS_DIRECTORY_SERVICE_REQUIRED flag will be used instead of the DS_WRITABLE_REQUIRED flag when it is called (unless you actually specifically want or need a writeable DC).

 

 

The signifigance of this is that RODC’s will never be returned from a call to DsGetDCName with the DS_WRITABLE_REQUIRED flag whereas it will if DS_DIRECTORY_SERVICE_REQUIRED is passed since the only requirement with that flag is that the DC be a W2k or later DC.

  

Joining the client to the domain from the GUI will always looks for a full RWDC, the only way to join against an RODC is to script the operation.

 Installing the compack introduces a new flag for the NetJoinDomain function that must be used when scripting domain joins against an RODC, NETSETUP_JOIN_READONLY.

 

 

When using the NETSETUP_JOIN_READONLY flag to script a domain join operation, the following needs to be in place:

-          The computer account(s) being joined must have been precreated on a RWDC and replicated down to the RODC

-          The password for the computer account(s) must be allowed to replicate down to the RODC being used

 

- The password for the computer account(s) must be prepopulated on the DC's

 

- The RODC that you want to join against must be specified within the script (the RODC is undiscoverable during the domain join)

 

If the prepopulation of the password is skipped, the initial join will fail with a ERROR_NO_TRUST_SAM_ACCOUNT (1787) error as the password isn't present on the RODC at the time of the join. Running the script a second time within a few seconds will however succeed as the RODC will have chained the authentication up to a RWDC and then replicated in the password locally.

 

In a VBScript, the part where you call NetJoinDomain with the NETSETUP_JOIN_READONLY flag against an RODC could look something like this:

 

 

 

Const NETSETUP_JOIN_DOMAIN = 1

Const NETSETUP_MACHINE_PWD_PASSED = 128

Const NETSETUP_JOIN_READONLY = 2048

 

Set objNetwork = CreateObject("WScript.Network")

strComputer = objNetwork.ComputerName

Set objComputer = GetObject("winmgmts:{impersonationLevel=Impersonate}!\" & strComputer & "rootcimv2:Win32_ComputerSystem.Name='" & strComputer & "'")

ReturnValue = objComputer.JoinDomainOrWorkGroup("domain.com/myRODC.domain.com", "computername$", NULL, NULL, NETSETUP_JOIN_DOMAIN + NETSETUP_JOIN_READONLY + NETSETUP_MACHINE_PWD_PASSED)

wscript.echo "Join returned: "&ReturnValue This incidentally works against both RWDC's and RODC's, the difference being that this is not creating the account or setting any SPN for the computer account when called (which is what you get when calling JoinDomainOrWorkgroup without the NETSETUP_JOIN_READONLY flag).

 

 

 

Note that AllowNT4Crypto does not need to be set on the RODC being used (‘Allow cryptographic algorithms compatible with Windows NT 4.0’ Group Policy), this is another change that comes with the RODC client compatibility pack. Note that strong encryption during the join process is also enforced with the client pack installed.

 

 

Further details: 

      

Description of the Windows Server 2008 read-only domain controller compatibility pack for Windows Server 2003 clients and for Windows XP clients
http://support.microsoft.com/kb/944043

When a Windows NT 4.0-based computer tries to use the NETLOGON service to establish a security channel to a Windows Server 2008-based domain controller, the operation may fail
http://support.microsoft.com/kb/942564

DsGetDcName Function
http://msdn.microsoft.com/en-us/library/ms675983.aspx

NetJoinDomain Function
http://msdn.microsoft.com/en-us/library/aa370433(VS.85).aspx