Authenticating to a RoDC is unsuccessful

Silver Contributor

Apr 28, 2022

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:

More generalised impact articles not specifically related to authentication issues:

Cheers,

Lain

BrentStobbs
Brass Contributor
Apr 29, 2022
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?
- LainRobertson
  Silver Contributor
  Apr 29, 2022
  BrentStobbs
  
  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
- LainRobertson
  Silver Contributor
  Apr 29, 2022
  BrentStobbs
  
  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
  - BrentStobbs
    Brass Contributor
    May 02, 2022
    Hi Lain
    
    Thank you for your ongoing assistance with this. You assumption is correct. The RoDC has been put into it's own site with the appropriate subnet and IP Link configured.
    
    Replication between sites is working, as I can add/remove users to my administration group which allows logon to the DC, and this is accurately reflected after initiating a replication.
    
    I wondered if something went amiss when setting up the RoDC, so I Promo'd it down and then DCPromo'd it again, but still the same issue with the exception of the cached data has gone (which is a good thing for troubleshooting imo).
    
    When I run GetComputerSite() on my RoDC it correctly returns the site information (I have censored some information out with *s):
    
    Name : ***Isolation
    Domains : {}
    Subnets : {192.168.2.0/24}
    Servers : {******RODC.local.domain.com}
    AdjacentSites : {****-Corporate-Lan}
    SiteLinks : {***-Isolation}
    InterSiteTopologyGenerator :
    Options : None
    Location :
    BridgeheadServers : {*******RODC.local.domain.com}
    PreferredSmtpBridgeheadServers : {}
    PreferredRpcBridgeheadServers : {}
    IntraSiteReplicationSchedule :
    
    When I run this same command from the client workstation I get "The specified domain either does not exist or could not be contacted"
    
    IPCONFIG /ALL on my RoDC (IP Addresses have been changed from the real addresses):
    
    Connection-specific DNS Suffix . :
    Description . . . . . . . . . . . : Microsoft Network Adapter Multiplexor Driver
    Physical Address. . . . . . . . . : ********
    DHCP Enabled. . . . . . . . . . . : No
    Autoconfiguration Enabled . . . . : Yes
    Link-local IPv6 Address . . . . . : fe80::e5a5:b81d:9ebe:4303%4(Preferred)
    IPv4 Address. . . . . . . . . . . : 192.168.200.10(Preferred)
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . : 192.168.200.4
    DNS Servers . . . . . . . . . . . : ::1
    127.0.0.1
    192.168.100.10 (DC1 in Corporate Site)
    192.168.100.15 (DC2 in Corporate Site)
    
    IP Configuration on my client is set by DHCP with the a single DNS server being the RoDC.
    
    The NSLOOKUP command I ran was NSLOOKUP LOCAL.DOMAIN.COM. When run on the RoDC or Client Workstation this returns the correct IP addresses of all my RWDCs (of which I have 4 in 3 Sites), but not the RoDC.
    
    Based on this thread https://social.technet.microsoft.com/Forums/lync/en-US/22499c64-6016-4be5-8cb5-f538b49dd321/rodc-not-listed-under-nslookup?forum=winserverDS the RoDC should be listed here. I can confirm there is a PTR record for the RoDC in the Reverse Lookup Zone.
    
    Additionally if doing a lookup for _ldap._tcp.dc._msdcs.local.domain.com after setting the type to all, only the RWDCs are listed. The same results occur when running this on my primary DC or within the RoDCs site.
    
    The reason I'm fixated on this being the issue, is if a client workstation connects to the site while all connections to any RWDC are unavailable, the client still has to be able to query DNS to locate the RoDC before it can determine what site it is in and ask the appropriate DC (or RoDC) for authentication.
    
    Currently my workstations are not aware there is a connectable RoDC that can tell them what site they are in.
    
    I'm assuming that I am able to log on to the RoDC because it is knows it is a DC and doesn't need to go looking for one.
    
    Or am I barking up completely the wrong tree?

Forum Discussion

Authenticating to a RoDC is unsuccessful

Share

Resources