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.
11 Replies
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?Also, when run on the RODC, did the GetComputerSite() return its own site, or some other site?
I'm working under the assumption that the RODC has been put into its own site and the current subnets (particularly those the clients are on) have been assigned to that site. If that isn't the case, then that gets back to what I was fishing for earlier with that command, which is site discovery leading the clients to try and talk across the firewall.
Cheers,
Lain
