Forum Discussion
Authenticating to a RoDC is unsuccessful
I have the requirement to create a segregated network for a group of my users. The network will contain 1 file server, an RoDC and a bunch of workstations.
The workstations have no connectivity to any RWDC, however the File Server and RODC do have and should always have connectivity as these are dependent on a local connection through a firewall and do not require a VPN or WAN link to be available.
Replication is working between my RWDC and the RoDC (confirmed by DNS updates and AD Group Changes are successfully replicated).
However, I am still unable to log in to a workstation on the same network as the RoDC.
Here are the facts that I know:
* On the workstation, Network Location Service is not detecting the Domain (Sets network to Private)
* Appropriate users and workstations have been added to the Password Replication Policy (though as I understand it this should not be required as the RODC has connectivity to the RWDC)
* Appropriate users and workstations have been "pre-populated"
* RODC is a Global Catalog
* IP Address for the workstation is issued via DHCP on the File Server, with DNS entry pointing to the RODC.
I don't understand why this is not working. Am I missing something?
- Thank you again Lain for your quick and thorough response.
I have now resolved the issue and I am feeling quite stupid about it. The workstations (both of them) I was testing with were configured for DirectAccess. As the NLS is not available on the network, it was trying to connect via Direct Access and hence using NRPT to resolve the domain name, additionally DirectAccess was not able to reach the Domain Controllers, and as it therefore failed to connect, it was causing the DNS issues.
I have removed the DirectAccess configuration for the workstation and things started working as expected.
I am going to mark this response as the best answer, but I do want you to know that it was in no small part due to your assistance. I would not have come to this conclusion without the hints you have provided and your guidance with troubleshooting. Sincerely, thank you very much, I was really struggling.
Without any specific diagnostic material to inform us, we're just guessing here.
Something that comes to mind is whether the clients and even the RODC itself have come to the conclusion that they're actually in the same site. There's numerous ways to check this but I find an easily-accessible one is running the following from PowerShell (administrative elevation not required.)
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite()Other sources of useful information would be from running dcdiag.exe on the RODC and checking the System event log on the clients for errors reported by the NETLOGON source, etc. There's obviously others, but any errors from these would help us provide more specific feedback.
Here's some literature that offers further insight into specific processes and how they behave in an RODC context, which may give you additional clues on what you might like to investigate next.
In-depth process reviews and important RODC DNS records:
- [MS-ADTS]: SRV Records | Microsoft Docs
- Appendix A: Read-Only Domain Controller (RODC) Technical Reference Topics | Microsoft Docs
More generalised impact articles not specifically related to authentication issues:
- How Operations in a Branch Site with an RODC Are Affected When the WAN Is Not Available | Microsoft Docs
- Planning for Application Compatibility with RODCs | Microsoft Docs
Cheers,
Lain
- Hi Lain,
Thanks for your reply, the links you provided confirm that what I am trying to achieve is not unusual, and confirm that my understanding of the RODC function is correct with the only potential issue is the dynamic update of DNS records which is a bridge I can cross in the future. This should not block authentication.
I should also mention that I have a Windows 2019 server in the perimeter network with the RODC that allows authentication and the NLA service correctly assigns the connection as DomainAuthenticated. However, at some point I had allowed this server to communicate directly with a RWDC (though communications are now blocked).
Running the powershell command you suggested returns a "Domain cannot be contacted" error on the workstation. Running it on the RODC (or other connected server) confirms the correct site.
If I do a lookup for my domain using NSLOOKUP (in either site), the RODC is not listed. Shouldn't it be listed here?Hi Brent,
Without knowing the explicit query you're running through nslookup, I'm not sure. I can only generalise and say if you're looking for SOA or NS records, then no, it won't be there.
RODCs do not create NS (and SOA) records, as described below. Queries for those are going to resolve back to a writable domain controller, but this is something of an aside to your authentication issue and isn't the cause of the "domain not found" - at least not on its own.
Plan DNS Servers for Branch Office Environments | Microsoft Docs
Again, without any actual errors from the clients or RODC to work with, or supporting configuration information from things like ipconfig /all, I'm guessing, but my gut feeling is that your RODC isn't happy about something.
Perhaps have a read of the following and see what the nltest.exe command within returns both from your RODC as well as the impacted clients.
RODC logs DNS event 4015 with error code 00002095 - Windows Server | Microsoft Docs
I'd say start with comprehensively assessing your RODC using things like dcdiag.exe and critical event logs before working backwards to the clients themselves, where things like NETLOGON and SCHANNEL events within the System log are going to be quite useful.
One DNS tip I'll toss out there as yet another guess is be careful of DNS search suffixes, if you're using them. I've seen issues with DNS client timeouts where they haven't been implemented efficiently.
Similarly, with your nslookup checks, ensure you're testing with and without a trailing period on the hostname, as that is often useful for tracking the impact of search suffixes.
For example, my domain is robertsonpayne.com. Running:
nslookup -type=SOA robertsonpayne.com.Will instruct the DNS client to avoid iterating through any search suffixes, resulting in a different (explicit and therefore more efficient) question being sent to the DNS server, where leaving off the final period does not (meaning all search suffixes are checked and devolved until they resolve.)
Cheers,
Lain
