Problem with Authintcation with RODC

Abdulhadi Eissa 0 Reputation points
2025-06-18T11:59:12.9+00:00

Hello,
We have 2 Domain controller in the HQ and one RODC in a site, and we are using VPN between the HQ and the site, I configured the RODC correctly, with all steps, but all computers at the site trying to authenticate with the HQ DC, and when VPN is down the authentication fail.

  • the DCs in the HQ: DC1:192.168.1.207 and DC2: 192.168.1.209

-I added all users in the site to the password replication policy

-The primary DNS address in the network card setting of the RODC is the ip of DC , and the secondary is the IP of RODC
-The DNS of computers in the site is the RODC IP, and it is working fine.

  • when execute this command ( nltest /dsgetdc:domain.local ) on the RODC it is showing:
    DC: \DC1.domain.local
    Address: \192.168.1.209
    Dom Guid: 5b4f43a8-f793-49d8-8867-d2a16544654a
    Dom Name: domain.local
    Forest Name: Domain.local
    Dc Site Name: HQ
    Our Site Name: Site1
    Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9 DS_10 0x20000

-nslookup showing only the writeable DCs:
Name: domain.local
Addresses: fd01::9cd3:d836:1e14:f961
192.168.1.207
192.168.1.209

  • This command ( nltest /dsgetsite ) in the site's computers, showing the correct site name: Site1

I tried a lot of troubleshooting but the problem still, please help me

Windows for business Windows Server User experience Other
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Chen Tran 955 Reputation points Independent Advisor
    2025-06-20T18:16:38.8033333+00:00

    Hello Abdulhadi,

    Thank you for posting question on Microsoft Windows forum!

    Based on your query of clients at a remote site are attempting to authenticate with Headquarters' Domain Controllers (DCs) instead of the local Read-Only Domain Controller (RODC), causing authentication failures when the VPN connection is down. This problem might lies in the Active Directory Sites and Services configuration. If the subnet of the remote site is not correctly defined and associated with the site, the DC locator process on the client computers will not be able to find the local RODC and will fall back to querying for any DC in the domain, leading them to the HQ DCs.

    Coupled with the output of the command nltest /dsgetdc:domain.local on the RODC pointing to a HQ DC. This might be an indicator that even the RODC itself, when performing a general domain controller discovery, is locating a writable DC in the main office. This strongly suggests that from the perspective of the DC locator process, the RODC doesn't see itself as the primary DC for its own site for general domain queries.

    The followings are some suggested troubleshooting steps for the issue.

    1.Verify and Correct Active Directory Sites and Services:

    • Open Active Directory Sites and Services: On a writable domain controller in your HQ, open the Active Directory Sites and Services administrative tool.
    • Check Subnet Definitions:
      • Expand the Subnets folder.
      • Ensure that the IP subnet for your remote site (Site1) is created. If not, right-click Subnets and select New Subnet.
      • Enter the network address and subnet mask for Site1.
      • In the Select a site object for this subnet list, choose Site1.
    • Verify Site Association:
      • If the subnet already exists, right-click it and select Properties.
      • Confirm that it is associated with Site1. If it's associated with the HQ site or is unassociated, this is the primary cause of your problem.
    • Check Site Links:
      • Ensure there is a site link connecting your HQ site and Site1. This is necessary for replication. Since your RODC was installed, a link likely exists, but it's good practice to verify its configuration and replication schedule.

    2.Correct DNS Configuration on the RODC:

    • The DNS client settings on your RODC should be optimized for its role.
    1. Primary DNS: The RODC should point to itself as the primary DNS server. This is a best practice for domain controllers.
    2. Secondary DNS: The secondary DNS server should be one of the writable DCs in the HQ. This provides a fallback for DNS resolution if the local DNS service on the RODC has an issue.
    • To change the DNS settings on the RODC:
    1. Open the Network Connections settings on your RODC.
    2. Go to the properties of the network adapter.
    3. Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.
    4. Set the Preferred DNS server to the RODC's own IP address or 127.0.0.1.
    5. Set the Alternate DNS server to the IP address of one of your HQ DCs (e.g., 192.168.1.207).

    3.Verify Password Replication Policy:

    • On a writable DC, open Active Directory Users and Computers.
    • Navigate to the Domain Controllers OU and find your RODC computer object.
    • Right-click the RODC object and select Properties.
    • Go to the Password Replication Policy tab.
    • Confirm that the user groups from Site1 are in the Allowed RODC Password Replication Group. Also, ensure they are not members of any group listed in the Denied list.

    Hope the above information is helpful!


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.