active directory dns integration

Active Directory DNS Integration

White Paper

Abstract

This paper describes how Active Directory uses the Domain Name System (DNS) in conjunction with theWindows Domain Locator service for distributed computing environments. It discusses how the Adonis Serverintegrates into existing or new Active Directory deployments. DNS replication mechanisms are discussedincluding their pros and cons. Active Directory records and DNS labeling conventions are described in detail togive the reader a deeper understanding how the locator service works.

USE OF THIS DOCUMENT Publisher InformationAll rights reserved worldwide. No part of this publication may be reproduced,transmitted, transcribed, stored in a retrieval system, or translated into any humanor computer language in any form or by any means without the express writtenpermission of:

BlueCat Networks, Inc.9050 Yonge Street, Suite 401Richmond Hill, Ontario Canada L4C 9S6

Attention: General Manager

Telephone: 905-882-5691Fax: 905-882-5057E-mail: [email protected] Site: www.bluecatnetworks.com

This publication is provided as is without warranty of any kind, express or implied,including, but not limited to, the implied warranties of merchantability, fitness for aparticular purpose, or non-infringement.

All terms mentioned in this publication that are known to be trademarks or servicemarks are appropriately capitalized. BlueCat Networks cannot attest to theaccuracy of this information. Use of a term in this publication should not beregarded as affecting the validity of any trademark or service mark. Thetrademarks, service marks and logos (the "Trademarks") displayed are registeredand unregistered Trademarks of BlueCat Networks, Inc. and others. Users are notpermitted to use these Trademarks for any purpose without the prior writtenconsent of BlueCat Networks or the third party owning the Trademark.

CopyrightThis document and all information (in text, Graphical User Interface ("GUI"), videoand audio forms), images, icons, software, design, applications, calculators,models, projections and other elements available on or through this document arethe property of BlueCat Networks or its suppliers, and are protected by Canadianand international copyright, trademark, and other laws. Your use of this documentdoes not transfer to you any ownership or other rights or its content. Youacknowledge and understand that BlueCat Networks retains all rights notexpressly granted.

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.Actual implementation and configuration may vary. E. & O.E. i

No Professional AdviceThis document is for convenience and informational purposes only. Thisdocument is not intended to be a comprehensive or detailed statement concerningthe matters addressed; advice or recommendations, whether scientific orengineering in nature or otherwise; or an offer to sell or buy any product orservice. BlueCat Networks does not warrant or make any representationsregarding the use, validity, accuracy, or reliability of, or the results of the use of,this web site or any materials on this document or any web site referenced herein.This document is intended solely for the use of the recipient. It does not institute acomplete offering and is not to be reproduced or distributed to any other person.

Persons who receive this document agree that all information contained herein isexclusively the intellectual property of BlueCat Networks and will not reproduce,recreate or other use material herein, unless you have received expressed writtenconsent from BlueCat Networks.

© Copyright 2004 BlueCat Networks, Inc.

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.Actual implementation and configuration may vary. E. & O.E. ii

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.Actual implementation and configuration may vary. E. & O.E. iii

CONTENTS INTRODUCTION................................................................................................... 1

ACTIVE DIRECTORY AND DNS ......................................................................... 1

DYNAMIC DOMAIN CONTROLLER REGISTRATION........................................ 2

INTEGRATING THE ADONIS INTO ACTIVE DIRECTORY ................................ 4

DNS REPLICATION ............................................................................................. 5

ADVANTAGES OF ADONIS FOR ACTIVE DIRECTORY DNS SERVICES ........ 7

SUMMARY............................................................................................................ 9

ACTIVE DIRECTORY DNS RECORDS ............................................................... 9

SRV Records.................................................................................................. 9

A Records..................................................................................................... 11

CNAME Records .......................................................................................... 11

INTRODUCTION Windows® 2000 Server was a pivotal point for Microsoft in centralizing andconsolidating directory services. Active Directory® (AD) is based on well knownnetwork services such as Lightweight Directory Access Protocol (LDAP) andKerberos and utilizes DNS for its location mechanism. DNS has now grown tobecome not only the cornerstone of the Internet, but a crucial fabric to connectWindows clients with their Domain Controllers. This document will outline howActive Directory utilizes DNS and how the Adonis DNS Appliance integrates intothis environment. The integration of the Adonis Server can be performed easilywhile providing a robust, secure and highly maintainable DNS managementplatform.

ACTIVE DIRECTORY AND DNS Active Directory is an essential element of the Windows server architecture thatprovides a centrally managed directory service for distributed computingenvironments. The directory is a central authority for network security, resources,users and services. Active Directory is based upon the LDAP and uses securitybased on MIT's Kerberos project. AD was first available in Windows 2000 Server.

Microsoft chose to change its Windows Domain discovery process to use DNSinstead of its legacy discovery protocol. This acts like a boot strapping mechanismfor client systems to find the closest or most appropriate Domain Controller (DC).This information is stored in a series of DNS records specifying the followinginformation:

LDAP Servers

Kerberos Domain Controllers

Address of the Domain Controllers

Global Catalog Servers

Kerberos Password Change Servers

Before a client can connect to the Windows Domain, a suitable DC needs to befound. The Windows client contains a service called NetLogon which uses aDomain Controller locating algorithm to find the appropriate server. This algorithmworks in the following manner:

1. A List of DCs is obtained via a DNS query using the domain name, domain GUID and/or site name.

2. The locator will ping each controller in random order and use the weight-

ing factor discovered while getting the list of DCs. It will wait up to 1/10th

of a second for a reply from the DC. The pinging continues until all DCs have been tried or until a successful response has been received.

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.Actual implementation and configuration may vary. E. & O.E. 1

3. After a DC responds successfully to a ping, the results from the response are compared to the parameters required by the client. If this matches then the DC is used, otherwise pinging of other DCs resumes.

Figure 1: Locating an appropriate Domain Controller

DYNAMIC DOMAIN CONTROLLER REGISTRATION

Without the proper DNS information, a client cannot find out which server tocontact for authentication. Each Domain Controller registers and maintains it ownActive Directory DNS integration records which consist of several A (Address),CNAME (Canonical Name) and SRV (Service) records. These records are initiallyregistered by the DC's NetLogon service. This is performed via standard DNSzone transfer (AXFR), query and Dynamic DNS Update (RFC 2136) by the DC

Client Workstation

Domain Controller

Domain Controller

Adonis DNS

1. Query DNS for a list of Domain Controllers

2. Ping Domain Controllers remotely

3. Select Domain Controller that satisfies connection parameters


Figure 2: Registering Active Directory Records

When examining these records in the Microsoft DNS server, one is led to believethat this data must reside in sub zones of the parent domain. This is notnecessarily the case, since Dynamic DNS (DDNS) updates have no way ofcreating additional zones. The records are simply added as resource records withlabel separators (".") into the parent domain. Additionally one will notice thatseveral of the records contain underscore ("_") characters as part of the names.This technique is common practice used in Microsoft development tools and wasborrowed for the DNS naming technique for Active Directory. The following listcontains the naming conventions used in the records:

A registered DNS record can contain one or more of the above names to describea service that can be queried. For example, the following record locates an LDAPservice, on server1.bluecatnetworks.com, in the bluecatnetworks.com:

_ldap._tcp.bluecatnetworks.com SRV 0 0 389 server1.bluecatnetworks.com

DNS Label Description

_ldap LDAP service

_tcp Service uses TCP connections

udp Service uses UDP connections

_kerberos Record contains information about a Kerberos Key Distribution Center (KDC)

_msdcs Service is running on a Domain Controller

_kpasswd Kerberos Password Change service

_gc Global Catalog service

_sites Record contains information a specific site

dc Domain Controller (DC)

gc Global Catalog (GC)

Domain Controller

1. Perform transfer of Active Drectory zone

2. Send Dynamic Updates to add/update controller's records

3. Send updates to slave servers via Incremental Zone Transfer (IXFR)

Slave DNS Server

Slave DNS Server

Master DNS Server


An alternative form of this record that indicates that the LDAP service is on a DCwould have the following syntax:

_ldap._tcp.dc._msdcs.bluecatnetworks.com SRV 0 0 389 server1.bluecatnetworks.com

For a detailed list of these records see the "Active Directory DNS Records"section of this document.

INTEGRATING THE ADONIS INTO ACTIVE DIRECTORY

The Adonis DNS Appliance can be easily integrated into the Active Directoryenvironment. The simplest way to perform this operation is use the "ActiveDirectory Wizard" for each zone that requires AD integration. The wizard asks forthe IP addresses of each Domain Controller that will register their records. Oncecomplete, the configuration is deployed and the Active Directory servers areinformed that their primary DNS server is now an Adonis DNS Appliance. Oncethis has been performed, the DC will register their records and client machines willuse this information to gain access to the AD domain.

To manually perform the integration without the assistance of the Wizard involvesa few simple steps.

1. Create an Access Control List (ACL) that will contain the addresses of all the Domain Controllers. Add this ACL to each DNS server.

2. For the master server, allow zone transfers

3. For each master zone, allow dynamic updates using the ACL

4. For each slave zone, allow update forwarding using the ACL. This will for-ward dynamic updates to the master zone.

Once the configuration has been deployed, it will take anywhere from a fewminutes to an hour for the DCs to register their records. This time interval isdependent on the DC's registration settings and can be changed to suit anorganization' needs. Domain Controllers will usually inspect their records after theinterval has expired. After the DCs have registered their records, a simple refreshof the master server's configuration will reveal the Active Directory records.


Figure 3: Adonis Management Console with Active Directory Records

Windows 2000 type networks also allow clients to register their own Address (A)and Pointer (PTR) records with their DNS server. In most cases, organizationsuse DHCP servers that can perform the registration directly with the DNS serverand is a more secure method. However, if desired, clients can still registerthemselves directly with the DNS server by allowing those specific clients to makedynamic updates.

DNS REPLICATION There are two schools of thought about DNS record replication. Master-Slave, thecurrent industry standard outlined in RFC 1034 and 1035, states that a secondaryzone (slave) will replicate its contents from a primary (master) zone on a giveninternal. This was enhanced by the DNS Notify mechanism (RFC 1996) thatallowed master servers to notify their slaves when their contents were changed.With the advent of Dynamic DNS (DDNS), incremental zone transfers (IXFR)were developed to make zone transfers faster and slaves can now accept andforward updates to their masters. The master-slave architecture works onWindows, UNIX® and other operating systems and is the recommended methodfor managing DNS. The following table lists some of the pros and cons of aMaster-Slave replication system:

Master-Slave

Pros Cons

Industry standard method for maintaining zone dataMaster always contains most up-to-date informationCentral repository for zone dataDoes not require other services to replicate data

Must update the master server to make changes on other serversIf a slave is updated, a small delay will exist before update is propagatedRequires latest version of BIND software to take advantage of update-forwarding


Figure 4: Active Directory Master-Slave Architecture

When Microsoft introduced Active Directory with Windows 2000, it changed itsDNS implementation. The changes included the ability to allow special charactersin DNS labels and to store the entire DNS configuration inside the ActiveDirectory. Because Active Directory had its own replication scheme, a differentDNS architecture known as Master-Master was developed. The recommendedMicrosoft architecture for Active Directory specifies that the DNS servers shouldreside on the domain controller, thus eliminating the need to perform zonetransfers. The following table looks at the pros and cons of the Master-Master

method of replication:

Master-Master

Pros Cons

Central repository for all zone dataEditing the DNS on one zone replicates to all othersSaves bandwidth and processing power by using existing LDAP replication

Microsoft-only implementationsZone serial numbers can be inconsistent in SOA dataNon-standard ArchitectureNot favored in heterogeneous environmentsRelies on LDAP for replicationLDAP replication may not be acceptable for external zone data

Domain Controllers

Slave DNS Server

Slave DNS Server

Master DNS Server

Update locator records

Send updates toslave servers


Figure 5: Active Directory Master-Master Architecture

The Adonis DNS Appliance uses the BIND 9.x name server software. Thereforeall architectures are Master-Slave based. If this technique becomes more widelyaccepted with other vendors, future releases of the Adonis DNS Appliance maycontain a Master-Master replication system.

ADVANTAGES OF ADONIS FOR ACTIVE DIRECTORY DNS SERVICES

Although every version of Windows Server ships with the Microsoft DNS service,many network administrators do use a non-Microsoft implementation of DNS. Anon-Microsoft DNS-based solution like the Adonis DNS Appliance integrates wellinto an Active Directory Environment.

1. Interoperability with existing DNS architectureThe Adonis Server is based upon ISC's BIND, the most widely used DNS ser-vice implementation, and used as the reference for DNS. Existing BIND archi-tectures can interoperate easily with the Adonis Server while maintaining a similar architecture.

2. Quick MigrationExisting BIND-based configurations can be quickly imported and deployed to Adonis Servers. Current Windows DNS implementations (NT 4.0, 2000 and 2003) can be imported via BlueCat Networks' DNS extraction tool. Current Microsoft DNS management application requires low level scripting or manual import via zone transfers to migrate from BIND to Windows DNS. The Adonis Server will perform additional data checking on the imported data to isolate and assist in resolution of issues before they are deployment.

Domain Controller

MS DNS Server

Update locator records

Update zone data

MS DNS Server

MS DNS Server

Active Directory


3. Superior Configuration ManagementThe Adonis Server contains an elegant and easy to use interface for manipu-lating DNS configurations and record data. Powerful features found in most applications include multi-level undo/redo, cut/copy/paste and data checking functionality that is absent from the Microsoft DNS application.

4. Controlled DeploymentChanges are not visible on the DNS server until the user has deployed the configuration. The current implementation of the Microsoft DNS application applies the changes to the DNS server as they are made. This can create issues for applications when simple typos are introduced into a configuration because records can be cached for a defined duration. This can lead to net-work application/service outages and stability issues. This issue is com-pounded by the fact that some applications do not respect DNS Time to Live (TTL) values and will hold onto an invalid date until restarted.

5. Improved SecurityDNS security is often overlooked for private networks because an internal network is seen as secure and separate from the outside world. The real problem lies in the sheer volume of exploits in the Windows operating system that plague network administrators. Worms unload their payloads that attack internal systems and replicate while bringing a network to its knees. The SQL Slammer worm that exploited a known vulnerability in the Microsoft Data Engine (MSDE) attacked available root servers by generating bogus queries. These queries resulted in a large number of ICMP packets being sent out and eventually brought the root servers off line. Many organizations also found their own internal DNS servers being attacked in a similar manner. The Ado-nis DNS Appliance contains an integrated firewall, IP packet spoofing and a hardened Linux operating system that resists these types of attacks.

6. Total Cost of Ownership (TCO)The total cost of the Adonis DNS Appliance is considerably lower than that of a Microsoft DNS server solution. With the volume of Windows updates, vul-nerabilities, scheduled maintenance and simplistic management, surrounding the Windows solution, the Adonis solution offers a lower cost of total owner-ship, even in the first year of deployment. For more detailed information about the total cost of ownership, see the BlueCat Networks document on the Ado-nis Server's Return on Investment (ROI).

SUMMARY Active Directory is the back bone of the Windows Server architecture and iscentered on the LDAP service. DNS plays an important role in providing theinformation used by the Windows Domain locator service to connect and


authenticate with Active Directory. The Adonis DNS Appliance provides featuresthat allow easy integration with Active Directory while providing BIND-based DNSservices throughout an organization. Existing DNS configurations that utilize BINDcan rest assured that the migration to the Adonis DNS Appliance will yield acompatible, reliable and dependable DNS solution.

For more information about the Adonis DNS Appliance, visit the BlueCatNetworks website at http://www.bluecatnetworks.com

ACTIVE DIRECTORY DNS RECORDS

The following section contains a list of Active Directory specific records that areregistered by the NetLogon service.

SRV Records

_ldap._tcp.<DomainName>SRV record that identifies an LDAP server in the domain named by <DomainName>.The LDAP server is not necessarily a DC. This record is registered by all DomainControllers.

Example: _ldap._tcp.bluecatnetworks.com

_ldap._tcp.<SiteName>._sites.<DomainName>Allows a client to find an LDAP server in the domain named by <DomainName>. Thisrecord is registered by all Domain Controllers.

Example: _ldap._tcp.richmondhill.bluecatnetworks.com

_ldap._tcp.dc._msdcs.<DomainName>Used by clients to locate a DC in the domain named by <DomainName>. This record isregistered by all Domain Controllers.

Example: _ldap._tcp.dc._msdcs.bluecatnetworks.com

_ldap._tcp.<SiteName>._sites.dc._msdcs.<DomainName>Allows a client to locate a DC for the given site and domain named by <SiteName>and <DomainName> respectively.

Example: _ldap.tcp.richmondhill._sites.dc._msdcs.bluecatnetworks.com

_ldap._tcp.pdc._msdcs.<DomainName>Allows a client to locate the Primary Domain Controller (PDC) for a domain named by<DomainName>. This record is only registered by the PDC of the domain.

Example: _ldap._tcp.pdc._mscdcs.bluecatnetworks.com

_ldap._tcp.gc._msdcs.<DomainName>Allows a client to find the Global Catalog (GC) server for the forest named by<ForestName>. Only the DC for the GC will register this record.

Example: _ldap._tcp.gc._msdcs.bluecatnetworks.com

_ldap._tcp.<SiteName>._sites.gc._msdcs.<ForestName>Allows a client to find a GC for the forest named by <ForestName>. Only an LDAPserver responsible for the GC will register this record.


http://www.bluecatnetworks.com

Example: _ldap._tcp.richmondhill._sites.gc._msdcs.bluecatnetworks.com

_gc._tcp.<ForestName>Allows a client to locate a GC for the forest named by <ForestName>. Only an LDAPserver responsible for the GC will register this record. The LDAP server is notnecessarily a DC.

Example: _gc._tcp.bluecatnetworks.com

_gc._tcp.<SiteName>._sites.<ForestName>Allows a client to find a GC for the site and forest named by <SiteName> and<ForestName> respectively. Only an LDAP server responsible for the GC will registerthis record.

Example: _gc._tcp.richmondhill._sites.bluecatnetworks.com

_ldap._tcp.<DomainGuid>.domains._msdcs.< ForestName>Used by clients to find a DC given the domain guid of <DomainGuid> in the forestnamed by <ForestName>. This lookup can used to resolve the DC if the domain namehas changed. This record is used infrequently and will not work if the <ForestName>has been changed.

Example: _ldap._tcp.01693484-b5c4-4b31-8608-80e77ccc78b8.domains._msdcs.bluecatnetworks.com

_kerberos._tcp.<DomainName>Allows a client to find a Kerberos Key Distribution Center (KDC) for the domain namedby <DomainName>. This record will be registered by all DCs providing the Kerberosservice. This service is RFC-1510 compliant with Kerberos 5 KDC. The server is notnecessarily a DC.

Example: _kerberos._tcp.bluecatnetworks.com

_kerberos._udp.<DomainName>Allows a client to find a Kerberos Key Distribution Center (KDC) for the domain namedby <DomainName>. This record will be registered by all DCs providing the Kerberosservice. This service is RFC-1510 compliant with Kerberos 5 KDC. The server is notnecessarily a DC. This service supports UDP.

Example: _kerberos._tcp.bluecatnetworks.com

_kerberos._tcp.<SiteName>._sites.<DomainName>Allows a client to locate a server running the Kerberos KDC for a site and domainnamed by <SiteName> and <DomainName> respectively. The server is notnecessarily a DC.

Example: _kerberos._tcp.richmondhill._sites.bluecatnetworks.com

_kerberos._tcp.<SiteName>._sites.dc._msdcs.<DomainName>Used by clients to locate the DC running a Kerberos KDC for the site and domainnamed by <SiteName> and <DomainName> respectively.

Example:_kerberos._tcp.richmondhill._sites.dc._msdcs.bluecatnetworks.com

_kpasswd._tcp.<DomainName>Allows a client to find a Kerberos Password Change Server for the domain named by<DomainName>. The server is not necessarily a DC. All DC running the KerberosKDC will register this record.


Example: _kpasswd._tcp.bluecatnetworks.com

_kpasswd._udp.<DomainName>Allows a client to find a Kerberos Password Change Server for the domain named by<DomainName>. The server is not necessarily a DC. All DC running the KerberosKDC will register this record.

Example: _kpasswd._udp.bluecatnetworks.com

A Records

<ServerName>.<DomainName>The server name named by <ServerName> is registered in the domain named by<DomainName>. This record is used by referral lookups to SRV and CNAME records.

Example: dc1.bluecatnetworks.com

gc._msdcs.<ForestName>Allows a client to find a GC for a given forest named by <ForestName>. This record isused by referral from SRV records.

Example: gc._msdcs.bluecatnetworks.com

CNAME Records

<DSAGuid>._msdcs.<ForestName>Allows a client to locate any DC in the forest named by <ForestName> by the GUID ofthe MSFT-DSA (Directory Services) object.

Example: 01693484-b5c4-4b31-8608-80e77ccc78b8._msdcs.bluecatnetworks.com


active directory dns integration

Documents