How Domain controllers are located in windows

2

How do servers locate a domain controller in a Network?

One of the first major tasks a domain member computer has to do when it starts is to locate a domain controller. Generally, this task requires the use of a Domain Name System (DNS) server, which contains records for each domain controller in the domain, and the Locator, a remote procedure call to the computer’s local Netlogon service.

Starting Up

When the computer starts, its Netlogon service starts automatically (in the default configuration). Th is service implements the DsGetDcName application programming interface (API), which is used to locate a domain controller.

The computer  begins  by collecting  a number  of pieces of information that  will be used  to  locate a domain controller. This information includes the client’s local IP address, which is used to determine the client’s Active Directory site membership, the desired domain name, and a DNS server address.

Finding the Domain Controllers

Netlogon then queries the configured DNS server. Netlogon retrieves the service resource (SRV) records and host (A) records from DNS that correspond to the domain controllers for the desired domain. The general form for the queried SRV records is _service._protocol.domainname, where service is the domain service, protocol is the TCP/IP protocol, and domainname is the desired Active Directory fully qualified domain name (FQDN). For example, because Active Directory is a Lightweight Directory Access Protocol (LDAP)-compliant directory service,  clients query for  _ldap._tcp.domainname  (or  _ldap._tcp.dc._msdcs.domainname when  locating  the nearest domain controller).

Each domain controller in a domain will register its host name with the SRV record, so the client’s query results will be a list of domain controller host names. The client also retrieves the associated A records, providing the client with the IP address of every domain controller in the domain. The client then sends an LDAP search query,  via  the  User  Datagram  Protocol  (UDP),  to  each  domain  controller.  Each  domain  controller  then responds, indicating that it is operational. The Netlogon service caches all of this information so that finding a domain controller in the future won’t require a repeat of this initial process. Instead, the service can simply refer to its cache to find another domain controller.

Selecting a Domain Controller

After the client locates a domain controller, the client uses LDAP to access Active Directory on a domain controller, preferably one in the client’s own subnet. The domain contro ller uses the client’s IP address to identify the client’s Active Directory site. If the domain controller is not in the closest site, then the domain controller returns the name of the client’s site, and the client tries to find a domain controller in tha t site by querying DNS. If the client has already attempted to find a domain controller in that site, then the client will continue using the current, nonoptima domain controller. Once the client finds a domain controller it likes, it caches that domain controller’s information, and the client will continue to use that domain controller for future contacts (unless the domain controller becomes unavailable).

For more details on troubleshooting please refer below KB article

http://support.microsoft.com/kb/247811

 

For more article updates, videos and posters join our official page in Facebook

Facebook Page: https://www.facebook.com/ServerGeeks

Web Site: https://servergeeks.wordpress.com/

Video Channel: https://www.youtube.com/user/Habibmvp

 

Advertisements

Dependency of Active Directory on DNS

1

DNS Records that are required for proper functionality of Active Directory

 

We know that DNS servers serves more than resolving Name to IP and IP into Name. It is core protocol or you can say daddy of all protocols over a network.

In this article I have tried to visualize and explain all the core records of DNS without which Active Directory cannot function properly.

Here are the list of all core SRV, A and C-Name records that are used by Active Directory and Domain clients.

Please Note: The Red marked records in below table are used by Non-SRV-Aware Clients

 

Mnemonic Type DNS Record Requirements
  1. PDC
SRV _ldap._tcp.pdc._msdcs.<DnsDomainName> One per domain
  1. GC
SRV _ldap._tcp.gc._msdcs.<DnsForestName> At least one per forest
  1. KDC
SRV _kerberos._tcp.dc._msdcs.<DnsDomainName> At least one per domain
  1. DC
SRV _ldap._tcp.dc._msdcs.<DnsDomainName> At least one per domain
A <DomainControllerFQDN> One per domain controller (domain controllers that have multiple IP addresses can have more than one A resource record)
  1. GcIpAddress
A gc._msdcs.<DnsForestName> At least one per forest
  1. DsaCname
CNAME <DsaGUID>._msdcs.<DnsForestName> One per domain controller

 

Below I have mentioned the location of all these important records, with their properties and NSLOOKUP commands to verify if the record exists correctly or not. I have taken screenshot from a single domain lab, on default site i.e. my domain itself represent the forest. So results may vary if you explore these in big infrastructure.

 

 

In the records Properties window, you will notice below few fields:

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.

 

 

 

Host Records for SRV-Aware Clients

  1. PDC 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 registers this SRV record.

 

 

 

  1. GC 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.

 

 

  1. KDC Record – _kerberos._tcp.dc._msdcs.<DnsDomainName>

Allows a client to locate a domain controller that is running the Windows implementation of the Kerberos KDC service for the domain named in DnsDomainName . All Windows 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.

 

 

  1. DC Record – _ldap._tcp.dc._msdcs.<DnsDomainName>

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

 

 

  1. Domain FQDN A Record  – <DomainControllerFQDN>

This record helps to locate the domain controllers IP address in a domain.

 

Host Records for Non-SRV-Aware Clients

 

  1. GC IP Address – 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.

Net Logon also registers a DNS CNAME (alias) record for use by Active Directory replication The Locator does not use this record.

 

 

  1. DsaCname Record – <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.

 

To know more about SRV records in DNS , please refer to below article

http://technet.microsoft.com/en-us/library/cc961719.aspx

 

 

For more article updates, videos and posters join our official page in Facebook

Facebook Page: https://www.facebook.com/ServerGeeks

Web Site: https://servergeeks.wordpress.com/

Video Channel: https://www.youtube.com/user/Habibmvp

 

DNS Records

0

DNS Records Types

Entries for hostnames, IP addresses, and other information in the zone database are stored in records. Each host has at least one record in the DNS database that maps the hostname to the IP address.

The following table lists common resource records.

Record Type

Use

SOA (Start of

Authority)

The first record in any DNS database file is the SOA. It defines the general parameters for the DNS zone, and it is assigned to the DNS server hosting the primary copy of a zone. There is only one SOA record, and it is the first record in the zone database file. The SOA record includes parameters such as the authoritative server and the zone file serial number.

NS (name server)

The NS resource record identifies all name servers that can perform name resolution for the zone. Typically, there is an entry for the primary server and all secondary servers for the zone (all authoritative DNS servers).

A (host address)

The A record maps an IPv4 (32-bit) DNS host name to an IP address. This is the most common resource record type.

AAAA (quad-A)

The AAAA record maps an IPv6 (128-bit) DNS host name to an IP address.

MX (Mail

Exchanger)

The MX record identifies servers that can be used to deliver e-mail.

CNAME (canonical name)

The CNAME record provides alternate names (or aliases) to hosts that already have a host record. Using a single A record with multiple CNAME records means that when the IP address changes, only the one A record needs to be modified.

Common uses of a CNAME record include:

  • Adding the alias of www for Web servers. Users typically contact the Web server using a name like http://www.habib.com instead of using the actual server name.
  • Associating a server with the domain name itself. For example, create a CNAME record with a blank name to allow a specific host to be identified with the domain name (such as habib.com).
DNAME (Domain Alias)

The DNAME record provides alternate names (or aliases) to domains that already have a host record.

SRV (service locator)

The SRV record is used by Windows Server 2008 to register network services. This allows clients to find services (such as domain controllers) through DNS. Windows 2008 automatically creates these records as needed and during domain controller installation.

PTR (pointer)

In a reverse lookup zone, the PTR record maps an IP address to a host name (i.e. “points” to an A record). Where IPv4 PTR records are created in the in-addr.arpa namespace, reverse lookup zones for IPv6 addresses should be created in the ip6.arpa namespace.

(Note: When you manually create an A record, you can choose to create the corresponding PTR record at the same time. Creating the PTR record will fail if the reverse lookup zone does not exist.)

WINS and WINS-R resource records

Add these records to a zone when you want to allow DNS to use WINS resolution. The WINS resource record allows DNS queries that fail to resolve to be forwarded to the WINS servers in the WINS resource record. The WINS-R resource record allows the resolution of a reverse query that is not resolvable through DNS.