Freigeben über

Troubleshooting RODC's: Troubleshooting RODC location in the DMZ

  • Artikel

Consider the following scenario:

  • A NAP solution with a remediation zone (aka noncompliant network) for
    incoming clients
  • An RODC in the remediation zone subnet has been assigned to an AD site
    called 'RemediationSite'
  • The remediation subnet has been assigned to the RODC in the 'RemediationSite' site
  • Firewall rules prevent the incoming clients in the RemediationSite site from talking to any RWDC's

Typically, the NAP client is a laptop that was either shut down or hibernated while on the corporate LAN/WLAN and has then been brought up while on a home network and is attempting to establish a VPN connection into the corporate network.  At
some point, the NAP server may determine that the client needs to talk to a DC to apply Group Policy, authenticate, etc.

In this scenario, the incoming client may never be able to automatically discover the RODC.

The reason forthis is that the client doesn’t know in which site it is when it initially comes into the site RemediationSite, it must therefore eventually make a generic DNS query for the _msdcs.domain.com SRV record for a DC to talk to and the RODC by default doesn’t register any generic DNS information…it only registers site-specific DNS information.  DsGetDCName may therefore never return an RODC in the list of DC’s for the domain.

Note that the DCLocator function that DSGetDCName calls does however have a fallback to NetBIOS name resolution functionality (WINS and broadcasts) if no results are generated from DNS, if WINS is however not configured and broadcasts are blocked then that too will fail.

If the firewall rules however were to allow the client to talk to at least one RWDC, the client would get redirected to the RODC once the RWDC determines that the client is in the RODC’s site (both should at this point be in the non-compliant network).

 

But let's say you can’t/don’t want to change your firewall rules so we’re stuck in a Catch-22 scenario.  How can this be resolved?  Although an RODC in the non-compliant network may not be able to meet 100% of your DC needs, it is still possible to configure it to be discoverable by clients.

One possible method is to configure the RODC to register generic DNS records, but it does have some drawbacks that you need to be aware of.

  • The original reason for not registering generic DNS records is to ensure that only clients in the site the RODC is in talk to it.
    This is effectively the same principle as is described in the W2k3 Branch Office Guide where the W2k3 DC was configured to only register site-specific DNS records.
  • Not registering generic DNS records for RODC’s minimizes the risk of a users being manipulated into authenticating against a stolen RODC that has been brought online within the corporate network.

In short; IF the RODC needs to be discoverable from a generic DNS query, there is no alternative but to register generic DNS records for it.  It is however possible to minimize the security impact of registering the generic DNS records by modifying the
LDAPSrvPriority of the RODC in the remediation site to make sure other RO/RWDC’s will be preferred if available (See KB 306602 for details).

The DWORD registry entryRegisterSiteSpecificDnsRecordsOnly determines if the RODC will attempt to register generic DNS records.

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Value name: RegisterSiteSpecificDnsRecordsOnly

Value type: DWORD

RegisterSiteSpecificDnsRecordsOnly

This specifies to register site-specific and CName records only.
Default is TRUE (1) for RODC.

If it is set to FALSE (0), then RODC will try to register all types of DNS records including non-site specific records.

If this value is set, the RODC needs to be given the required permissions on the relevant DNS zones in order to be able to register all DNS records.

 

How to optimize the location of a domain controller or global catalog that resides outside of a client's sitehttp://support.microsoft.com/?id=306602

Windows Server 2003 Active Directory Branch Office Guide
http://www.microsoft.com/downloads/details.aspx?FamilyId=9353A4F6-A8A8-40BB-9FA7-3A95C9540112&displaylang=en

Planning the Placement of a NAP Remediation Serve
http://technet.microsoft.com/en-us/library/dd125378.aspx

Authentication fails when an external client tries to log on to a Windows Server 2008 server by using a read-only domain controller in a perimeter network
http://support.microsoft.com/kb/977510

Comments

  • Anonymous
    January 01, 2003
    Setting the registry key alone doesn't help - you'll need to use a script as joining via the GUI will always be looking for a RWDC, please read blogs.technet.com/.../troubleshooting-rodc-s-troubleshooting-domain-joins-against-rodc-s.aspx

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Check out the 'RODCs in the Perimeter Network' whitepaper on Technet: http://technet.microsoft.com/en-us/library/dd728030.aspx

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Your points are already covered in the article (apart from the link to support.microsoft.com/.../977510). I fully agree that LDAP pings from the client would be a preferable location method if your firewall admins can be persuaded.

  • Anonymous
    January 01, 2003
    Great to hear - thanks for the feedback

  • Anonymous
    November 24, 2009
    The comment has been removed

  • Anonymous
    November 24, 2009
    Actually that post that you are refering to was from some other unfortunate soul with the same problem :-( Yes, I installed the Hotfix.  Before I did I think that the script was finishing with an "Error: 87" and now has "Error: 1354".  The client server can see the RODC without any problems.  NSLookUp references it with no problem.   However, I noticed that when I run the script it attempts to traverse the firewall with UDP-389(LDAP). Here is the question that I posted on Technet: We rolled out a RODC to our Perimeter network.  There is a firewall between our perimeter network and our Corp Network.  We followed the steps per TechNet article:  http://technet.microsoft.com/en-us/library/dd728035(WS.10).aspx The problem we are having is trying to add machines via the suggested script.  We are trying to add a Windows 2003 server to the network from the Perimeter.  We WERE getting "Error: 87" until we applied hotfix: "WindowsServer2003-KB944043-v5-x86-ENU.exe".   Now that the hotfix has been applied we are now getting "Error: 1354"  Still unable to add the server to the Domain from the Perimeter network. Has anyone run into this issue?

  • Anonymous
    November 25, 2009
    The comment has been removed

  • Anonymous
    November 26, 2009
    The comment has been removed

  • Anonymous
    November 27, 2009
    Yep, the InfoSec team has approved it.  And we resolved the permissions issue to.  Though we added the RODC computer accounts to the ACL for the zone, we hadn't gone into the Adavanced Settings and set it to apply to all descendant objects too, this is why it wasn't creating them. Thanks for your help, greatly appreciated!

  • Anonymous
    October 18, 2011
    The comment has been removed

  • Anonymous
    April 10, 2013
    You should NEVER allow ANY RODC to publish domain wide SRV records as stated in the KB article "support.microsoft.com/.../977510". That can be a security problem! For the reasons see: social.technet.microsoft.com/.../df802a3c-6bbc-4b57-9ac9-3c1fb950a21b If the client DOES NOT know its AD site and you still want it to talk/use the RODC, allow the client to perform an LDAP Ping to RWDCs (no harm in that) so that the RWDCs tell the client in which AD site it is in. Based on that the client will contact the RODC. This does assume everything (sites, site links, etc) it is configured correctly! Regards, Jorge de Almeida Pinto [MVP-DS] jorgequestforknowledge.wordpress.com