Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

Authentication fails when an external client tries to log on to a Windows Server 2008 server by using a read-only domain controller in a perimeter network


View products that this article applies to.

Symptoms

An external client tries to log on to a server that is running Windows Server 2008 in a perimeter network (also known as DMZ, Demilitarized Zone, and Screened Subnet). When the server tries to authenticate the external client by using a read-only domain controller (RODC) in the perimeter network, the authentication fails.

Note If the server is permitted to authenticate the external client by using an internal domain controller (DC), the authentication is successful.

↑ Back to the top


Cause

This issue occurs when the external client does not know which site it first enters in the perimeter network. When this occurs, the external client makes a generic Domain Name System (DNS) query for the _msdcs.domain.com SRV resource record for a DC to which the client can connect. By default, RODCs do not register any generic DNS information. Instead, RODCs only register site-specific DNS information. Therefore, the DsGetDCName function never returns an RODC in the list of DCs for the domain.

Note If no results are generated from the DNS query, the DCLocator function that is called by the DSGetDCName function falls back to NetBIOS name resolution functionality (WINS and broadcasts). However, if WINS is not configured and broadcasts are blocked, then this fallback mechanism also fails.

If the firewall rules let the external client connect to at least one read/write domain controller (RWDC), the external client is redirected to the RODC. This behavior occurs as soon as the RWDC determines that the external client is in the RODC's site.

Note When this occurs both computers should be in the perimeter network.

↑ Back to the top


Resolution

To resolve this issue, you must make the RODC discoverable from a generic DNS query.

Note You can minimize the security effect of registering the generic DNS records by changing the LDAPSrvPriority value of the RODC in the remediation site to make sure that other available read-only domain controllers or read/write domain controllers are preferred. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
306602 How to optimize the location of a domain controller or global catalog that resides outside of a client's site
To make the RODC discoverable, specify the RegisterSiteSpecificDnsRecordsOnly DWORD Value in the registry. This DWORD Value determines whether the RODC tries to register generic DNS records.
Registry location:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters
Value name:RegisterSiteSpecificDnsRecordsOnly
Value type:DWORD

RegisterSiteSpecificDnsRecordsOnly

This DWORD value specifies to register site-specific and alias (CName) records only. The default value for an RODC is 1 (TRUE). If you set this value to 0 (FALSE), the RODC tries to register all DNS records. This includes non-site specific records.

Note If you set this DWORD value to 0, you must grant the RODC the required write permission on the relevant DNS zones to be able to register all DNS records.

↑ Back to the top


More information

For more information about how to determine RODC locations in the perimeter network, visit the following Microsoft TechNet Blog site:

↑ Back to the top


Keywords: kbtshoot, kbexpertiseinter, kbsurveynew, kbprb, KB977510

↑ Back to the top

Article Info
Article ID : 977510
Revision : 2
Created on : 11/24/2009
Published on : 11/24/2009
Exists online : False
Views : 1015