Consider the following scenario:
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. Atsome 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.
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 theLDAPSrvPriority 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 entry RegisterSiteSpecificDnsRecordsOnly determines if the RODC will attempt to register generic DNS records.
Value name: RegisterSiteSpecificDnsRecordsOnlyValue type: DWORD
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 Guidehttp://www.microsoft.com/downloads/details.aspx?FamilyId=9353A4F6-A8A8-40BB-9FA7-3A95C9540112&displaylang=en
Planning the Placement of a NAP Remediation Servehttp://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 networkhttp://support.microsoft.com/kb/977510
Check out the 'RODCs in the Perimeter Network' whitepaper on Technet:
We are still getting "Error 1354" trying to join a Windows 2003 Server(SP2) to the RODC.
When you say "no alternative but to register generic DNS records for it", what are the exact steps? The KB article seems to say "NOT" to do it. I'm confused.
You originally posted the "error 1354" question to the entry http://blogs.technet.com/instan/archive/2008/08/13/troubleshooting-rodc-s-troubleshooting-domain-joins-against-rodc-s.aspx - but you didn't provide any details there.
You need to confirm you have installed the RODC-compatibility pack on the joining client (the W2k3 server in this case) - otherwise the joining client will always ask for a RWDC.
The error message you're getting back sounds suspicously like the RODC-compatibility pack isn't installed on the W2k3 server.
The joining client (W2k3 server, XP or Vista) needs to be able to locate the DC you´re joining against.
This will occur through the dclocator function and either a DNS query or a NetBIOS broadcast.
The alternative is to script it and specify which DC you're joining against.
If NetBIOS broadcast isn't returning the DC to the client then a generic DNS query will be the only method for the client to locate a DC when it doesn't know which site is in - RODC's however don't register generic DNS records by default so they will never be returned by a generic DNS query unless you configure it to register generic DNS records.
This is not normally required - the reasons for not registering generic DNS records are listed in the W2k3 Branch Office guide.
The point with having no alternative but to register generic records is that in some configurations this will be necessary for the client to be able to locate the RODC.
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?
Is it possible to clarify the process for configuring security for the zone and validating that the generic records have been created successfully?
I've flipped the reg key on the RODC, but haven't been able to resolve my issue. It doesn't look like any records have been added to DNS nor are there any logs indicating if anything was even tried.
The script on that Technet article says the following:
"In this section, you will find instructions and a sample script that can be used to domain join a Windows Server 2008, Windows Server 2008 R2 or Windows Vista SP 1 machine to a perimeter network."
Joining XP and W2k3 clients via an RODC using scrpting is definitely possible - but *this* particular script is explicitly saying which OS's it supports so there's no guarantee that it will work without modification on legacy systems (although Vista RTM/SP2 and Win7 are not in the list either).
I haven't tested this particular script but I've tested the sample bit from the other RODC blog entry I referred to.
One thing concerning the scripts are that they require a lot of prerequisites (like precreating the computer accounts and setting the password of the account, etc.) and you must also specify the /readonly switch on the command line.
What is the exact syntax of the command line you're entering?
If you look at the Netlogon.dns file on the RODC after setting the key then it should show exactly what records the RODC wants to register. If that doesn't contain generic DNS records then I would suggest running a Procmon trace while starting the Netlogon service to confirm your registry change is being read.
However, why do you think registering the generic records will address your issue? Did you run a network trace that shows the client failing to locate the RODC?
Thanks, netlogon.dns definitely shows all the records that should be created but aren't.
We were seeing dropped packets on our firewall of the member servers trying to hit the RWDC, those servers were getting NETLOGON 5719 errors during interactive logon with non-cached accounts. Your article was the first glimmer of hope after days of investigations (Thank you!).
I know this resolves the issue as I manually created all these records in the lab and everything started working brilliantly. However, I'm extremely hesitant to do any manual changes to _msdcs in a production environment. I'd much prefer the DNS servers manage this themselves.
Opening a call with Professional Support to hopefully resolve this, I still have a feeling I was just doing the security incorrectly.
Well, if you've confirmed registering the records manually in your testlab resolves the issue then it sounds reasonable that the same should apply in the production environment.
RODC's by default do not have permissions to create DNS records on the _msdcs zone (RWDC's have this permissions through the Enterprise Domain Controllers group).
A Network trace from Netlogon starting should confirm if you're hitting an Access Denied on the _msdcs zone.
The primary reason for the RODC's not having write permissions on the _msdcs zone is security - to prevent a compromised RODC from modifying data that could potentially redirect other clients to a compromised DC.
So, from a security perspective it would be better to register them manually using the values from the netlogon.dns file while from an admin perspective yuo want it to do this automatically.
If you want to enable the RODC to handle this automatically then the RODC would need to be allowed to create the records by modifying permissions on the _msdcs zone (Create all child objects should probably be enough to limit it to only being able to create new records and not mess with the other DC's records) - but you need to carefully weigh the security implications against the admin convenience and determine which one has a higher priority for your specific scenario.
...and please test this thoroughly in a lab as you have been doing :)
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!
Great to hear - thanks for the feedback
Hi! I enable the registry key beacuse i will join my dmz machine into RODC. However when i try to join a Server, when i insert the username and password for Domain Admin (i have one domain with 2 site, lan and dmz) the machines doesn't join. I see on the Firewall that the Server want to connect on the lan domain contollers. How can i join a server on the DMZ Site on the RODC? I need to use the priority of the SRV Record?
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
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:
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!
Jorge de Almeida Pinto [MVP-DS]
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.