Apr 26 2022 06:23 PM
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?
Apr 27 2022 09:39 PM - edited Apr 27 2022 09:40 PM
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
Apr 28 2022 08:50 PM
Apr 28 2022 09:39 PM
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
Apr 28 2022 09:46 PM
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
May 01 2022 09:19 PM
May 01 2022 09:29 PM
Starting with a quick answer to the last question first in relation to logging directly onto the RODC: it's the same process as logging onto a client as the RODC - prior to caching the credential for the first time - does not have any user credentials locally.
So, it still has go through precisely the same process of talking to a writable domain controller and pulling down the credentials to cache (via the single object replication request and assuming it's eligible for doing so via the password replication policy) before doing the "normal" thing thereafter of only needing to check itself for subsequent logons.
That being the case, my gut feeling at this stage is that your successful logon is going to be because the RODC is communicating reliably with the other writable domain controllers, where something is still amiss from the client perspective.
I'll have a proper read of the full details in a bit and see if that jogs anything in my memory, too.
Cheers,
Lain
May 02 2022 12:48 AM
Okay, so I've done some more homework but it left me with a great area around the non service discovery-related DNS records, for which I can't find documentation as clear as that for service location records (which I linked previously). As such, I figured it'd be faster just to knock up an RODC quickly.
The short version is that it is indeed as I said before (in relation to the MS doco, of couse), which is you do not get an NS or SOA record for an RODC, only for the writables.
I didn't speak to A or PTR records but here's another "short version": Both exist for the host but not the domain/forest name, which directly contradicts the old TechNet post you've linked above.
Here's a quick screenshot showing the writable (testdc01.robertsonpayne.net) and the RODC (rodc01.robertsonpayne.net) where you can see - as per the MS article in DNS service location records - that the RODC only features within the site discovery scopes, not the wider domain/forest scopes.
With respect to marrying up the subnet definition (192.168.2.0/24) from the first command and the ipconfig from the second (192.168.200.0/24), they aren't the same subnet associations. But then, I know you obfuscated the details so I'm not sure if that's an oversight or not. Just figured it was worth a quick mention.
If they don't match then that would result in the clients trying to talk across the site, but as I say, it may be just an issue in this post.
I'd make sure that:
The /dnsgetdc variation could prove interesting from the client as you might get nothing back or possibly a writable domain controller via automatic site coverage (though you shouldn't.) This test specifically relates to which domain controllers have registered service location records specifically within the ****Isolation site in DNS.
If you do get more than just your RODC back in the dnsgetdc variation, then that's going to be one issue (or the issue.)
Cheers,
Lain
May 02 2022 09:37 PM
May 02 2022 10:37 PM
No worries.
First, are the clients able to reach both UDP 53 and TCP 53 of the RODC as well as writable domain controller you just opened up access to?
If it's only UDP 53 and not TCP 53, you will run into issues with queries that have results sets larger than 512 bytes, as the Windows DNS client will cut over to TCP 53 and re-issue the query by default in such circumstances.
I only mention that as an aside though, as for the explicit host query for "pdc.domain.local", that shouldn't/wouldn't have been big enough.
Given your member server is passing all the tests, I'm more suspect on the workstation side of things, specifically, what questions they're asking.
Putting the quick check from above aside then, can you run the following for me from an impacted workstation within a PowerShell console? Administrator rights are not required.
Get-DnsClientGlobalSetting;
nslookup -type=ALL domain.local. <IP-of-pdc.domain.local>
nslookup pdc.domain.local. <IP-of-pdc.domain.local>
nslookup rodc.domain.local. <IP-of-pdc.domain.local>
I'm curious to know what resolves and what does not. I've also mentioned search suffixes before, and the command on line 1 will show any that are configured. Here's an example of the output from line 1.
Here's example output for line 5 (which asks for all matching record types, making the bottom part of the results a bit busy, but useful) using my own test environment:
You should see your "pdc.domain.local" in the results, all things being equal. PS: I don't need to see these results, it's just something for you to check given you said "pdc.domain.local" isn't resolving from the clients even when talking directly to "pdc.domain.local".
Be sure to include the trailing period after each hostname as show on lines 3, 5 and 7. This is important as it instructs the DNS client to not append any client search suffixes.
So, if we let the IPv4 address of your "pdc.domain.local" = 192.168.1.1, then an example using line 3 from above would look like:
nslookup domain.local. 192.168.1.1
You can also use the -debug switch on nslookup to see what impact devolution is having (though this requires leaving the trailing period out.) For example, slightly changing line 3 from above to the following will show if the initial question is actually for domain.local or something else based on any search suffixes.
nslookup -debug domain.local 192.168.1.1
Cheers,
Lain
May 02 2022 11:00 PM
SolutionMay 02 2022 11:05 PM - edited May 02 2022 11:07 PM
No worries! It's always a relief when you find a solution, and there aren't any silly ones.
You wont be the last person to be caught out by name resolution policies, and as of Server 2016, there's now also DNS Server policies to add into the mix of "things you can't see that are undermining you." Lots of fun to be had troubleshooting DNS in this day and age.
Cheers,
Lain
May 02 2022 11:00 PM
Solution