Active Directory Authentication

Repost

The DC Locator Process, The Logon Process, Controlling Which DC Responds in an AD Site, and SRV Records

Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003 Microsoft Certified Trainer Microsoft MVP: Directory Services Active Directory, Exchange and Windows Infrastructure Engineer

Original Compilation: 4/2009 Posted/Published 1/3/2009 Updated 10/28/2011

Note: This is a compilation of data from various resources. I hope you find it helpful.

Controlling which DC responds in a Site

This section is to understand how to change the Netlogon Registry Data to control SRV weights and priorities, that are referenced in the links above. Be careful when implementing these changes. It MUST be documented so if another DC in the site were to go down, users may experience a delay or worse, an inability to logon, and if the changes made were forgotten, it will be extremely difficult to troubleshoot.

To find out which DC logged you in: echo %logonserver%

You can also test which DCs are nearest to your workstation in your site (copy nltest.exe from the DC to the workstation's system32 folder): nltest /sc_query:YourDomainName.com

To find the GC your workstation used (copy nltest.exe from the DC to the workstation's system32 folder): nltest /dgsgetdc:your_domain_name.com /GC

This is performed altering the default weight and/or priority settings that get registered in the SRV records. The changes are made in the specific DC's netlogon registry entry. I would suggest to change all your DCs in a Site for more finite control. The reason is it controlled in the netlogon registry entry, is because the netlogon service is the component that registers a DC's data into their respective SRV folders.

When changing them, keep in mind a client will attempt to contact a server with the lowest priority first. If there are more than one server with the same priority, DNS load balancing is used when selecting the target server. If the weights are changed with the same priority, then a server is chosen based a percentage by dividing the weigth by the sum of all weights of all DCs in an AD Site.

Let's say you have 3 DCs: DC01, DC02 and DC03. Weights are assigned as follows: DC01 = 10 DC02 = 20 DC03 = 30

In this example: DC01 will be contacted 1 out of every 6 times (10/(30+20+10)) DC02 will be contacted 2 out of every 6 times (10/30(20/(30+20+10))) DC03 will be contacted 3 out of every 6 times (10/20(30/(30+20+10)))

You can use nslookup to find the SRV weights: nslookup q=srv _ldap._tcp.dc01._msdcs.domain.com

Then verify the correct SRV records were created based on the registry changes you made: How to verify that SRV DNS records have been created for a domain controller: http://support.microsoft.com/kb/816587

The CSEs (client side extensions) is what chooses a DC in this order:

1.A DC in its own AD Site based on the client's IP address and subnet its in. 2.If more than one DC in the same Site to choose from in the same IP subnet, Round Robin prevails 3.If more than one DC in the same AD Site but one of the DCs are in the same subnet and the other is not, then Subnet Priortization prevails to choose the DC in its own subnet. 4.If more than one DC in the same AD Site but both of the DCs are in different IP subnets than the client, and the two DCs are in the same subnet, then Round Robin will prevail to choose one of the DCs in that same subnet. 5.If more than one DC in the same AD Site but both of the DCs are in different IP subnets than the client, then Subnet Priortization will prevail to choose one of the subnets that a closest match based on the network bits (see this for more info on subnet priortization and bit selection: Technet Thread - DNS issue : DHCP relay + VLANs + multiple AD Sites (Heavily discusses subnet priortization and subnet bits) http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/ea03c013-7484-4a24-96be-d95219b69b3f/

Good discussion on DC locator process and how the client handles AD Sites, when a DC goes down, and when a client moves between sites. Thread Question: "how to control sequence of domain controllers a client computer logging on" http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/77bc547f-4d0d-4a0c-b463-359b1c771a81/

AutoSiteCoverage Domain controllers cover, that is, provide services to, the site in which they reside and to other sites listed in the value of the SiteCoverage entry. In addition, when the value of AutoSiteCoverage is 1, the system can add sites that do not have domain controllers to this domain controller's coverage area. http://technet.microsoft.com/en-us/library/cc939530.aspx

AD Site Coverage: Reg entry: Specifies a list of sites in which this domain controller registers itself. These sites are in addition to the site in which the domain controller resides and the sites listed in the value of the AutoSiteCoverage entry. http://technet.microsoft.com/en-us/library/cc937924.aspx

SRV Resource Records

The above section described how to control which DC responds. The reason it works is based on SRV records. Therefore, I thought to provide information regarding SRV records that are associated with this process. This section describes the SRV records used by Active Directory. The following is a quote, however I did not quote the whole article, just what is pertinent to logon and DC locations.

This section was quoted from: SRV Resource Records http://technet.microsoft.com/en-us/library/cc961719.aspx

When a Windows 2000 or Windows 2003 domain controller starts up, the Net Logon service uses dynamic updates to register SRV resource records in the DNS database, as described in an Internet Engineering Task Force draft that defines "A DNS RR for specifying the location of services (DNS SRV)." For more information about this draft, see the Internet Engineering Task Force (IETF) link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Follow the links to Internet Drafts, and then use a keyword search.

The SRV record is used to map the name of a service (in this case, the LDAP service) to the DNS computer name of a server that offers that service. In a Windows 2000 network, an LDAP resource record locates a domain controller.

A workstation that is logging on to a Windows 2000 domain queries DNS for SRV records in the general form: _Service._Protocol.DnsDomainName

Active Directory servers offer the LDAP service over the TCP protocol; therefore, clients find an LDAP server by querying DNS for a record of the form: _ldap._tcp.DnsDomainName

Note: The service and protocol strings require an underscore (_) prefix to prevent potential collisions with existing names in the namespace.

_msdcs Subdomain There are possible implementations of LDAP servers other than Windows 2000–based domain controllers. There are also possible implementations of LDAP directory services that employ Global Catalog servers but are not servers that are running Windows 2000. To facilitate locating Windows 2000–based domain controllers, in addition to the standard _Service._Protocol.DnsDomainName format, the Net Logon service registers SRV records that identify the well-known server-type pseudonyms "dc" (domain controller), "gc" (Global Catalog), "pdc" (primary domain controller), and "domains" (globally unique identifier, or GUID) as prefixes in the _msdcs subdomain. This Microsoft-specific subdomain allows location of domain controllers that have Windows 2000–specific roles in the domain or forest, as well as the location by GUID when a domain has been renamed. To accommodate locating domain controllers by server type or by GUID (abbreviated "dctype"), Windows 2000–based domain controllers register SRV records in the following form: _Service._Protocol.DcType._msdcs.DnsDomainName

The addition of the _msdcs subdomain means that two sets of DNS names can be used to find an LDAP server: DnsDomainName is used to find an LDAP server or Kerberos server that is running TCP (or, in the case of a Kerberos server, either TCP or the User Datagram Protocol [UDP]), and the subdomain _msdcs.DnsDomainName is used to find an LDAP server that is running TCP and also functioning in a particular Windows 2000 role. The name "_msdcs" is reserved for locating domain controllers. The single keyword "_msdcs" was chosen to avoid cluttering the DNS namespace unnecessarily. Other constant, well-known names (pdc, dc, and gc) were kept short to avoid exceeding the maximum length of DnsDomainName.

SRV Records Registered by Net Logon

The list that follows provides the definitions of the names associated with registered SRV records. It also describes the lookup criteria supported by each record and the checks performed by Netlogon as each record is registered. Text in bold type denotes constant record components; text in italic type denotes variable names.

In the descriptions of registered SRV records, DnsDomainName refers to the DNS domain name that is used during creation of the domain controller when the domain tree is joined or created (that is, while the computer is running the Active Directory Installation Wizard). DnsForestName refers to the DNS domain name of the forest root domain.

The following is a list of the owner names of the SRV records that are registered by Net Logon. An owner name is the name of the DNS node to which the resource record pertains.

_ldap._tcp.DnsDomainName. Allows a client to locate a server that is running the LDAP service in the domain named by DnsDomainName. The server is not necessarily a domain controller — that is, the only assumption that can be made about the server is that it supports the LDAP application programming interface (API). All Windows 2000 Server–based domain controllers register this SRV record (for example, _ldap._tcp.reskit.com.). _ldap._tcp.SiteName._sites.DnsDomainName.

Allows a client to locate a server that is running the LDAP service in the domain named in DnsDomainName in the site named by SiteName. SiteName is the relative distinguished name of the site object that is stored in the Configuration container in Active Directory. The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers register this SRV record (for example, _ldap._tcp.charlotte._sites.reskit.com.).

_ldap._tcp.dc._msdcs.DnsDomainName. Allows a client to locate a domain controller (dc) of the domain named by DnsDomainName. All Windows 2000 Server–based domain controllers register this SRV record.

_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName. Allows a client to locate a domain controller for the domain named by DnsDomainName and in the site named by SiteName. All Windows 2000 Server–based domain controllers register this SRV record.

_ldap._tcp.pdc._msdcs.DnsDomainName. Allows a client to locate the server that is acting as the primary domain controller (also known as a "PDC") in the mixed-mode domain named in DnsDomainName. Only the PDC emulator master of the domain (the Windows 2000–based domain controller that advertises itself as the primary domain controller to computers that need a primary domain controller) registers this SRV record.

_ldap._tcp.gc._msdcs.DnsForestName. Allows a client to locate a Global Catalog (gc) server for this forest. Only domain controllers that are functioning as Global Catalog servers for the forest named in DnsForestName register this SRV record (for example, _ldap._tcp.gc._msdcs.reskit.com.).

_ldap._tcp.SiteName._sites.gc._msdcs.DnsForestName. Allows a client to locate a Global Catalog (gc) server for this forest in the site named in SiteName. Only domain controllers that are serving as Global Catalog servers for the forest named in DnsForestName register this SRV record (for example, _ldap._tcp.charlotte._sites.gc._msdcs.reskit.com.).

_gc._tcp.DnsForestName. Allows a client to locate a Global Catalog (gc) server for this domain. The server is not necessarily a domain controller. Only a server that is running the LDAP service and functioning as the Global Catalog server for the forest named in DnsForestName registers this SRV record (for example, _gc._tcp.reskit.com.).

Note: In Windows 2000, a Global Catalog server is a domain controller. Other non-Windows 2000 implementations of directory services can also register servers as Global Catalog servers.

_gc._tcp.SiteName._sites.DnsForestName. Allows a client to locate a Global Catalog (gc) server for this forest in the site named in SiteName. The server is not necessarily a domain controller. Only a server that is running the LDAP service and functioning as the Global Catalog server for the forest named in DnsForestName registers this SRV record (for example, _gc._tcp.charlotte._sites.reskit.com.).

_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName. Allows a client to locate a domain controller in a domain on the basis of its GUID. A GUID is a 128-bit number that is automatically generated for referencing objects in Active Directory — in this case, the domain object. This operation is expected to be infrequent; it occurs only when the DnsDomainName of the domain has changed, the DnsForestName is known, and DnsForestName has not also been renamed (for example, _ldap._tcp.4f904480-7c78-11cf-b057-00aa006b4f8f.domains._msdcs.reskit.com.). All domain controllers register this SRV record.

_kerberos._tcp.DnsDomainName. Allows a client to locate a server that is running the Kerberos KDC service for the domain that is named in DnsDomainName. The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

_kerberos._udp.DnsDomainName. Same as _kerberos._tcp.DnsDomainName, except that UDP is implied.

_kerberos._tcp.SiteName._sites.DnsDomainName. Allows a client to locate a server that is running the Kerberos KDC service for the domain that is named in DnsDomainName and is also in the site named in SiteName. The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

_kerberos._tcp.dc._msdcs.DnsDomainName. Allows a client to locate a domain controller that is running the Windows 2000 implementation of the Kerberos KDC service for the domain named in DnsDomainName. All Windows 2000 Server–based domain controllers that are running the KDC service (that is, that implement a public key extension to the Kerberos v5 protocol Authentication Service Exchange subprotocol) register this SRV record.

_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName. Allows a client to locate a domain controller that is running the Windows 2000 implementation of the Kerberos KDC service for the domain that is named in DnsDomainName and that is also in the site named in SiteName. All Windows 2000 Server–based domain controllers that are running the KDC service (that is, that implement a public key extension to the Kerberos protocol Authentication Service Exchange subprotocol) register this SRV record.

_kpasswd._tcp.DnsDomainName. Allows a client to locate a Kerberos Password Change server for the domain. All servers that provide the Kerberos Password Change service (which includes all Windows 2000–based domain controllers) register this name. This server at least conforms to "Kerberos Change Password Protocol." (For more information about this draft, see the Microsoft Platform SDK link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Use a keyword search to locate the draft.) The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

_kpasswd._udp.DnsDomainName. Same as _kpasswd._tcp.DnsDomainName, except that UDP is implied. If multiple domain controllers have the same criteria, multiple records exist with the same owner name. A client that is looking for a domain controller with specific criteria would receive all the applicable records from the DNS server. The client would pick one of the returned records to select a domain controller, as described in "A DNS RR for specifying the location of services (DNS SRV)." For more information about this draft, see the Internet Engineering Task Force (IETF) link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Follow the links to Internet Drafts, and then use a keyword search. For information about the Kerberos v5 authentication protocol and Kerberos subprotocol extensions, see "Authentication" in this book.

Host Records for Non-SRV-Aware Clients Net Logon registers the following DNS A records for the use of LDAP clients that do not support DNS SRV records (that is, that are "non-SRV-aware"). The Locator does not use these records.

The following owner names of A (host) records are registered by Net Logon:

DnsDomainName. Allows a non-SRV-aware client to locate any domain controller in the domain by looking up an A record. A name in this form is returned to the LDAP client through an LDAP referral. (For more information about LDAP referrals, see "LDAP Referrals" later in this chapter.) A non-SRV-aware client looks up the name; an SRV-aware client looks up the appropriate SRV resource record.

gc._msdcs.DnsForestName. Allows a non-SRV-aware client to locate any Global Catalog server in the forest by looking up an A record. A name in this form is returned to the LDAP client through an LDAP referral. A non-SRV-aware client looks up this name; an SRV-aware client looks up the appropriate SRV resource record. Netlogon also registers a DNS CNAME (alias) record for use by Active Directory replication. The Locator does not use this record.

The owner name of the CNAME record is: DsaGuid._msdcs.DnsForestName. Allows a client to locate any domain controller in the forest by looking up an A record. The only information that is known about the domain controller is the GUID of the directory system agent (also known as the "DSA") object for the domain controller and the name of the forest in which the domain controller is located. This record is used to facilitate renaming a domain controller.

Other SRV Record Content

The following information is also included in an SRV record: Priority The priority of the server. Clients attempt to contact the server with the lowest priority. Weight A load-balancing mechanism that is used when selecting a target host from those that have the same priority. Clients randomly choose SRV records that specify target hosts to be contacted, with probability proportional to the weight.

Port Number The port where the server is listening for this service.

Target The fully qualified domain name of the host computer.

The following example illustrates the combined information that is contained in A resource records and SRV resource records. A domain controller named Phoenix in the domain reskit.com has an IP address of 157.55.81.157. It registers the following A records and SRV records with DNS: phoenix.reskit.com A 157.55.81.157 _ldap._tcp.reskit.com SRV 0 0 389 phoenix.reskit.com _kerberos._tcp.reskit.com SRV 0 0 88 phoenix.reskit.com _ldap._tcp.dc._msdcs.reskit.com SRV 0 0 389 phoenix.reskit.com _kerberos._tcp.dc._msdcs.reskit.com SRV 0 0 88 phoenix.reskit.com.

When the appropriate SRV records and A records are in place, a DNS lookup of _ldap._tcp.dc._msdcs.reskit.com returns the names and addresses of all domain controllers in the domain. For more information about A records, SRV records, DNS, and dynamic updates, see "Introduction to DNS" and "Windows 2000 DNS" in the TCP/IP Core Networking Guide.

If the DCs are in a truly configured "Site", then to change the priority and weights, you must change the registry entries under the Netlogon key. Once changed, then it will register that info into DNS.

Windows Vista/2008 and Windows 7/2008 R2 Updated Features with DC Locator Improvements

Windows Vista and newer, allows auto-rediscovery if their original logon server is no longer available:

If a Windows 2000 or XP client is are already authenticated by a DC, in order for it to use another DC, they would have to log off and logon again, or reboot to re-authenticate with other DC. This has been augmented with Windows Vista. 2008 with GPO and other options, such as forcing DC rediscover by running:

nltest /dsgetdc:<FQDN Domain Name> /force

How does Windows Server 2008 resolve Domain Controller Load Balancing problems http://www.windowsnetworking.com/kbase/WindowsTips/WindowsServer2008/AdminTips/ActiveDirectory/HowdoesWindowsServer2008resolvesDomainControllerLoadBalancingproblems.html

Windows 2008 R2 DC Locator improvements:

Enabling Clients to Locate the Next Closest Domain Controller, Updated: December 29, 2009 - Applies To: Windows Server 2008, Windows Server 2008 R2 http://technet.microsoft.com/en-us/library/cc733142%28WS.10%29.aspx

Enable Site Costed Referrals on [Windows 2008 & 2008 R2] Domain Controllers by Qasim Zaidi - Published on 4/29/2010 "SiteCostedReferrals is enabled by default in 2008 DCs. http://gallery.technet.microsoft.com/scriptcenter/a4605fb3-2a19-4f5d-a0fe-38336f15ba1a

Good discussion on DC locator process and AD Sites: Thread Question: "how to control sequence of domain controllers a client computer logging on" http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/77bc547f-4d0d-4a0c-b463-359b1c771a81/

How does Windows Server 2008 resolve Domain Controller Load Balancing problems? http://www.windowsnetworking.com/kbase/WindowsTips/WindowsServer2008/AdminTips/ActiveDirectory/HowdoesWindowsServer2008resolvesDomainControllerLoadBalancingproblems.html

The following was quoted from the above link: "The DC Locator Service has been re-designed in Windows Server 2008 to include a new mechanism. When a client computer finds a preferred domain controller, it sticks to this domain controller unless that domain controller stops responding or the client computer is restarted. This is generally called Domain Controller Stickiness. If you take this domain controller offline for maintenance purpose or it goes down, the clients that were connected to it will look for another domain controller to shift their connections to new domain controller. But when the domain controller comes online again, these connections are not shifted back because client computers do not refresh themselves to check to see if domain controller is back again. This can cause load-balancing issues because client computers remain connected to same domain controller.

Windows Server 2008 includes a new Group Policy setting for client computers. If a domain controller goes down and whenever the DC Locator Service invokes itself to execute the DcGetDCName API call, it retrieves a domain controller name from its cache. It checks to see if this cached entry is expired. If it is expired, it discards this domain controller and tries to search a new domain controller for the client."

The domain controller locator cannot find an appropriate domain controller on a computer that is running Windows XP or Windows Server 2003

(This is based on a reg entry that ..."After you install the hotfix, the DNS locator client in Windows XP and in Windows Server 2003 updates its domain controller cache after a default interval.

The DNS locator client tries to rediscover a suitable domain controller. The life cycle of a cached entry is controlled by the value of the ForceRediscoveryInterval registry entry."

Workaround: Method 1 Some client computers periodically retrieve the domain controller name by using the DS_FORCE_REDISCOVERY flag to call the DsGetDcName function. Determine which client computers do this. Then, deploy a script to these client computers.

Method 2 Update the cache on each client. To do this, run the following command at a command prompt: nltest /dsgetdc:DomainName /force

The domain controller locator cannot find an appropriate domain controller on a computer that is running Windows XP or Windows Server 2003 http://support.microsoft.com/kb/939252

Sharepoint's People Picker and DC/GC Access

This has been brought up time to time, and I thought I would provide my notes on this.

Sharepoint People Picker and choosing a Global Catalog: http://marc-antho-etc.net/blog/post/SharePoint-People-Picker-and-Active-Directory-Part-1.aspx

SharePoint People Picker and Active Directory http://sharepoint-talk.blogspot.com/2011/09/sharepoint-people-picker-and-active.html

Sharepoint using People Picker in a Resource Forest Model Forcing the picker to use a specific GC: "However we can point SharePoint explicitly to a particular GC that is located in the site locally where the SharePoint box is located. This can be done through the following commandline: Stsadm -o setproperty -pn peoplepicker-searchadforests -pv "forest:GCSERVER.DOMAIN.INTRANET" -url http://URLofWebApplication

This would ensure that we don't keep bouncing between different DCs/GCs for individual lookups of different forests but go directly to the only GC which responds back with list of users." http://www.networksteve.com/enterprise/topic.php/Sharepoint_using_People_Picker_in_a_Resource_Forest_Model/?TopicId=4512&Posts=4

I hope you've found this blog useful. If you have any comments or corrections, please let me know.

Reference

http://msmvps.com/blogs/acefekay/archive/2010/01/03/the-dc-locator-process-the-logon-process-controlling-which-dc-responds-in-an-ad-site-and-srv-records.aspx

Active Directory Authentication

Views

Contents

Repost

Sharepoint's People Picker and DC/GC Access

Related Links and Resources

Reference

Navigation menu

Navigation

Search

Tools

Personal tools