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

 

Advertisements

Tools to Troubleshoot DC issues

2


Tools to Troubleshoot DC issues

DCDIAG

DCDIAG analyzes the state of domain controllers in a forest or enterprise and reports any problems to help in troubleshooting.

  1. Preparing to install or migrate to Exchange new version
  2. Checking FSMO roles.
  3. Troubleshooting Group Policy.
  4. Investigating Active Directory not replicating frssysvol error.
  5. Running down Kerberos authentication problems.
  6. Resetting the Directory Service Administrator’s password.
  7. Fixing servers Service Principle Name (SPN) error.
  8. Other DC issues

Example: dcdiag.exe /V /D /C /E > c:\dcdiag.log

DCDIAG tool article http://technet.microsoft.com/en-us/library/cc731968(v=ws.10).aspx

REPADMIN

Repadmin.exe is a Microsoft Windows 2000 Resource Kit tool that is available in the Support Tools folder on the Windows 2000 CD-ROM. It is a command-line interface to Active Directory replication. This tool provides a powerful interface into the inner workings of Active Directory replication, and is useful for troubleshooting Active Directory replication problems.

Example: repadmin.exe /showrepl dc* /verbose /all /intersite > c:\repl.txt

RepAdmin tool article http://technet.microsoft.com/en-us/library/cc770963(v=ws.10).aspx

NETDIAG

This command-line diagnostic tool helps to isolate networking and connectivity problems by performing a series of tests to determine the state of your network client. These tests and the key network status information they expose give network administrators and support personnel a more direct means of identifying and isolating network problems. Moreover, because this tool does not require parameters or switches to be specified, support personnel and network administrators can focus on analyzing the output rather than on training users how to use the tool.

  1. Installing Exchange and you wish to check that you can connect to other servers.
  2. Checking VPN network tunnels on the WAN.
  3. DNS problems.  Computers cannot ‘see’ their domain controller on the LAN.
  4. A quick check on hotfixes.
  5. Check the Network Card Bindings from the command prompt.
  6. You are having problems with IPSEC.
  7. Winsock corruption, wrong version incompatibilities.
  8. NetDiag checks that Domain Controllers are all able to ‘speak’ LDAP.

 

Example: netdiag.exe /v > c:\netdiag.log

Note: This command need to be run on each DC of the domain.

NetDiag tool article http://technet.microsoft.com/en-us/library/cc731434(v=ws.10).aspx

Moving Active Directory Database and Logs

2


AD Scenario- Move Active Directory Database and Logs

An Active Directory database is installed on the C volume of a domain controller.

You need to move the Active Directory database to a new volume. What should you do?

A. Copy the ntds.dit file to the new volume by using the ROBOCOPY command.

B. Move the ntds.dit file to the new volume by using Windows Explorer.

C. Move the ntds.dit file to the new volume by running the Move-item command in Microsoft Windows

PowerShell.

D. Move the ntds.dit file to the new volume by using the Files option in the Ntdsutil utility.

Correct Answer: D

Explanation:

Step -1

Start the server in Directory Services Restore Mode

Windows Server 2003/2008 Directory Service opens its files in exclusive mode. This means that the files cannot be managed while the server is operating as a domain controller. To perform any files movement related activities using ntdsutil, we need to start the server in Directory Services Restore Mode.

To start the server in Directory Services Restore mode, follow these steps:

  • Restart the computer.
  • After the BIOS information is displayed, press F8.
  • Use the DOWN ARROW to select Directory Services Restore Mode, and then press ENTER.


  • Log on with your local administrative account and password. (Not Domain Administrative account)

Note:
using service control (SC.exe) you can verify quickly ntds services are running or stopped. In command prompt type SC query ntds

Step -2

How to Move Active Directory Database and Logs

You can move the Ntds.dit data file to a new folder. If you do so, the registry is updated so that Directory Service uses the new location when you restart the server. 

To move the data file to another folder, follow these steps:

  • Click Start, click Run, type ntdsutil in the Open box, and then press ENTER.


  • At the Ntdsutil command prompt, type activate instance ntds, and then press ENTER.


  • At the Ntdsutil command prompt, type files, and then press ENTER.


  • At the file maintenance command prompt, type move DB to <new location> (where new location is an existing folder that you have created for this purpose), and then press ENTER.

    In this case, the new location for database is C:\AD\Database


    • Now to move logs , at the file maintenance command prompt, type move logs to <new location> (where new location is an existing folder that you have created for this purpose), and then press ENTER. In our case, the new location for database is C:\AD\Logs


  • To quit file maintenance, type quit. Again to Ntdsutil, type quit to close the prompt
  • Restart the computer. AD database and Logs are moved successfully to new location.

For more details please read below article

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

Note: When to move NTDS.dit and Logs to a different location

  • You run out of disk space and want to move it away from the system disk
  • You want the DB to run on a faster/more reliable hard disk (other than the system disk)
  • You experience performance issues and want to seperate the DB from the core OS hard disk
  • You fat-fingered the correct location of the DB file when running dcpromo to bring the DC up