다음을 통해 공유

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

Comments

  • Anonymous
    January 01, 2003
    So you don't have a domain join issue and you don't have a computer account password change issue. What is the problem you're troubleshooting? (that has the Netlogon messages you describe). Incidentally, as there is no hit on NtpDcMatchResponse that I can find I suspect you're actually referring to NetpDcMatchResponse.  If that is the case then you may be looking at an issue with ADSI when used in combination with the Group Policy Preferences client where it specifically asks for a writable DC. There is a fix for ADSI and Gppref that is available for Windows 7 but that fix will not be backported to XP or W2k3 as both are in Extended Support. See support.microsoft.com/.../983531 for details on the Windows 7 fix.

  • Anonymous
    January 01, 2003
    If you're seeing that flag then it sounds like you're trying to join using the GUI, the GUI doesn't add the required NETSETUP_JOIN_READONLY flag during the join operation. I.e. XP and W2k3 clients can only join RODC's using a script where the NETSETUP_JOIN_READONLY flag is specified (and all the other prerequisites in the article are in place also).

  • Anonymous
    January 01, 2003
    Interesting....are you using the GUI or a script?  Do both behave the same?

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Then you don't have a domain join issue, my bet is the workstation is trying to change the machine account password.  Is it in the list of accounts allowed to replicate its password to the RODC?  If it is, do you see it in the list of accounts that have their passwords stored on it?

  • Anonymous
    January 01, 2003
    Are you attempting to join a Beta Win7/W2k8R2 machine or an RTM Win7/W2k8R2 against an RODC? If either is the case; do you get the same message when joining a Vista or W2k8 machine to the same domain?

  • Anonymous
    October 28, 2009
    When we run the VB script we get this error: ERROR_INVALID_DOMAIN_ROLE 1354 (0x54A) This operation is only allowed for the Primary Domain Controller of the domain. Do you know how we can fix this?

  • Anonymous
    August 18, 2010
    Brilliant article. :)

  • Anonymous
    January 25, 2011
    Thanks for the article this is exact the problem we have with our XP Clients. I installed the compack but still the clients have the DS_WRITABLE_REQUIRED flag. What else can we do to let the clients get the DS_DIRECTORY_SERVICE_REQUIRED flag. Thanks, Giovanni

  • Anonymous
    January 25, 2011
    Actually i see the flag in the netlogon debug log. What happens is that a XP client tries to authenticate to the RODC, it finds the RODC but than in the log i see that the RODC isn't writable (of course) and the client then switches the authentication to a writable domain controller

  • Anonymous
    January 26, 2011
    The XP client was already joined to the domain and after that we implemented the RODC. When the XP client startups i see the following in the netlogon.log "NtpDcMatchResponse: DC3: Responder is not a writable server. 0x28fc" and then the clients sends a request to the writable DC I also see this in the log "DsGetDcName function called: Dom:(null) Acct:(null) Flags: FORCE DS WRITABLE BACKGROUND RET_NETBIOS"

  • Anonymous
    January 30, 2011
    Yes the workstation is in the list of accounts allowed to replicate its password to the RODC, and i also see it in the list of accounts that have their passwords stored on it.

  • Anonymous
    February 02, 2011
    The problem i'm troubleshooting is that machines do not authenticate to the right domain controller of their site when the machines startup. 15 minutes after the machine started the process of finding the best DC starts agian and then the machine authenticate to the RODC of the site. But I want it to authenticated to the RODC when it starts to and not only after 15 minutes And the error in the log is that the read only domain controller isn't writable (of course) DC4 is the RODC, 172.16.1.1 and 172.16.1.6 are writeable DC's I put a piece of the log here for you: (i have replaced our domainname with "domain") 02/02 18:04:00 [MISC] DsGetDcName function called: Dom:(null) Acct:(null) Flags: DS WRITABLE BACKGROUND RET_NETBIOS 02/02 18:04:00 [MAILSLOT] NetpDcPingListIp: domain.local.: Sent UDP ping to 192.168.66.1 02/02 18:04:00 [CRITICAL] NetpDcMatchResponse: DC4: domain.local.: Responder is not a writable server. 0x28fc 02/02 18:04:00 [CRITICAL] NetpDcGetNameIp: domain.local.: site specific SRV records done. 02/02 18:04:00 [MAILSLOT] NetpDcPingListIp: domain.local.: Sent UDP ping to 192.168.34.2 02/02 18:04:01 [MAILSLOT] NetpDcPingListIp: domain.local.: Sent UDP ping to 172.16.1.1 02/02 18:04:01 [MISC] DsGetDcName function returns 0: Dom:(null) Acct:(null) Flags: DS WRITABLE BACKGROUND RET_NETBIOS 02/02 18:04:01 [MISC] DsGetDcName function called: Dom:(null) Acct:(null) Flags: FORCE DS WRITABLE BACKGROUND RET_NETBIOS 02/02 18:04:01 [MAILSLOT] NetpDcPingListIp: domain.local.: Sent UDP ping to 192.168.66.1 02/02 18:04:01 [CRITICAL] NetpDcMatchResponse: DC4: domain.local.: Responder is not a writable server. 0x28fc 02/02 18:04:02 [CRITICAL] NetpDcGetNameIp: domain.local.: site specific SRV records done. 02/02 18:04:02 [MAILSLOT] NetpDcPingListIp: domain.local.: Sent UDP ping to 172.16.1.6 02/02 18:04:02 [MISC] DsGetDcName function returns 0: Dom:(null) Acct:(null) Flags: FORCE DS WRITABLE BACKGROUND RET_NETBIOS 02/02 18:04:04 [MISC] DsGetDcName function called: Dom:(null) Acct:(null) Flags: BACKGROUND RET_DNS 02/02 18:04:04 [MISC] NetpDcGetName: domain.local. using cached information

  • Anonymous
    January 22, 2015
    Hey y'all, Mark, Tom and Lakshman are back for another mailbag. All of our NFL teams are out of the