Active Directory DNS Integration
White Paper
Abstract
This paper describes how Active Directory uses the Domain Name System (DNS) in conjunction with the Windows Domain Locator service for distributed computing environments. It discusses how the Adonis Server integrates into existing or new Active Directory deployments. DNS replication mechanisms are discussed including their pros and cons. Active Directory records and DNS labeling conventions are described in detail to give the reader a deeper understanding how the locator service works. USE OF THIS DOCUMENT Publisher Information All rights reserved worldwide. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any human or computer language in any form or by any means without the express written permission of:
BlueCat Networks, Inc. 9050 Yonge Street, Suite 401 Richmond Hill, Ontario Canada L4C 9S6
Attention: General Manager
Telephone: 905-882-5691 Fax: 905-882-5057 E-mail: [email protected] Web 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 a particular purpose, or non-infringement.
All terms mentioned in this publication that are known to be trademarks or service marks are appropriately capitalized. BlueCat Networks cannot attest to the accuracy of this information. Use of a term in this publication should not be regarded as affecting the validity of any trademark or service mark. The trademarks, service marks and logos (the "Trademarks") displayed are registered and unregistered Trademarks of BlueCat Networks, Inc. and others. Users are not permitted to use these Trademarks for any purpose without the prior written consent of BlueCat Networks or the third party owning the Trademark.
Copyright This document and all information (in text, Graphical User Interface ("GUI"), video and audio forms), images, icons, software, design, applications, calculators, models, projections and other elements available on or through this document are the property of BlueCat Networks or its suppliers, and are protected by Canadian and international copyright, trademark, and other laws. Your use of this document does not transfer to you any ownership or other rights or its content. You acknowledge and understand that BlueCat Networks retains all rights not expressly 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 Advice This document is for convenience and informational purposes only. This document is not intended to be a comprehensive or detailed statement concerning the matters addressed; advice or recommendations, whether scientific or engineering in nature or otherwise; or an offer to sell or buy any product or service. BlueCat Networks does not warrant or make any representations regarding 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 a complete offering and is not to be reproduced or distributed to any other person.
Persons who receive this document agree that all information contained herein is exclusively the intellectual property of BlueCat Networks and will not reproduce, recreate or other use material herein, unless you have received expressed written consent 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 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
© 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 INTRODUCTION Windows® 2000 Server was a pivotal point for Microsoft in centralizing and consolidating directory services. Active Directory® (AD) is based on well known network services such as Lightweight Directory Access Protocol (LDAP) and Kerberos and utilizes DNS for its location mechanism. DNS has now grown to become not only the cornerstone of the Internet, but a crucial fabric to connect Windows clients with their Domain Controllers. This document will outline how Active Directory utilizes DNS and how the Adonis DNS Appliance integrates into this environment. The integration of the Adonis Server can be performed easily while providing a robust, secure and highly maintainable DNS management platform.
ACTIVE DIRECTORY AND DNS Active Directory is an essential element of the Windows server architecture that provides a centrally managed directory service for distributed computing environments. The directory is a central authority for network security, resources, users and services. Active Directory is based upon the LDAP and uses security based on MIT's Kerberos project. AD was first available in Windows 2000 Server.
Microsoft chose to change its Windows Domain discovery process to use DNS instead of its legacy discovery protocol. This acts like a boot strapping mechanism for client systems to find the closest or most appropriate Domain Controller (DC). This information is stored in a series of DNS records specifying the following information:
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 be found. The Windows client contains a service called NetLogon which uses a Domain Controller locating algorithm to find the appropriate server. This algorithm works 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.
Adonis DNS
1. Query DNS for a list of Domain Controllers
Domain Controller 2. Ping Domain Controllers remotely
Client Workstation 3. Select Domain Controller that satisfies connection parameters Domain Controller
Figure 1: Locating an appropriate Domain Controller
DYNAMIC DOMAIN Without the proper DNS information, a client cannot find out which server to CONTROLLER REGISTRATION contact for authentication. Each Domain Controller registers and maintains it own Active Directory DNS integration records which consist of several A (Address), CNAME (Canonical Name) and SRV (Service) records. These records are initially registered by the DC's NetLogon service. This is performed via standard DNS zone transfer (AXFR), query and Dynamic DNS Update (RFC 2136) by the DC
© 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. 2 Slave DNS Server
Slave DNS Server
Master DNS Server
1. Perform transfer of Active Drectory zone 3. Send updates to slave servers via Incremental Zone Transfer (IXFR)
2. Send Dynamic Updates to add/update controller's records
Domain Controller Figure 2: Registering Active Directory Records
When examining these records in the Microsoft DNS server, one is led to believe that this data must reside in sub zones of the parent domain. This is not necessarily the case, since Dynamic DNS (DDNS) updates have no way of creating additional zones. The records are simply added as resource records with label separators (".") into the parent domain. Additionally one will notice that several of the records contain underscore ("_") characters as part of the names. This technique is common practice used in Microsoft development tools and was borrowed for the DNS naming technique for Active Directory. The following list contains the naming conventions used in the records:
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)
A registered DNS record can contain one or more of the above names to describe a service that can be queried. For example, the following record locates an LDAP service, on server1.bluecatnetworks.com, in the bluecatnetworks.com:
_ldap._tcp.bluecatnetworks.com SRV 0 0 389 server1.bluecatnetworks.com
© 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. 3 An alternative form of this record that indicates that the LDAP service is on a DC would 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 The Adonis DNS Appliance can be easily integrated into the Active Directory INTO ACTIVE DIRECTORY environment. The simplest way to perform this operation is use the "Active Directory Wizard" for each zone that requires AD integration. The wizard asks for the IP addresses of each Domain Controller that will register their records. Once complete, the configuration is deployed and the Active Directory servers are informed that their primary DNS server is now an Adonis DNS Appliance. Once this has been performed, the DC will register their records and client machines will use this information to gain access to the AD domain.
To manually perform the integration without the assistance of the Wizard involves a 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 few minutes to an hour for the DCs to register their records. This time interval is dependent on the DC's registration settings and can be changed to suit an organization' needs. Domain Controllers will usually inspect their records after the interval has expired. After the DCs have registered their records, a simple refresh of the master server's configuration will reveal the Active Directory records.
© 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. 4 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, organizations use DHCP servers that can perform the registration directly with the DNS server and is a more secure method. However, if desired, clients can still register themselves directly with the DNS server by allowing those specific clients to make dynamic updates.
DNS REPLICATION There are two schools of thought about DNS record replication. Master-Slave, the current industry standard outlined in RFC 1034 and 1035, states that a secondary zone (slave) will replicate its contents from a primary (master) zone on a given internal. This was enhanced by the DNS Notify mechanism (RFC 1996) that allowed 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 and forward updates to their masters. The master-slave architecture works on Windows, UNIX® and other operating systems and is the recommended method for managing DNS. The following table lists some of the pros and cons of a Master-Slave replication system:
Master-Slave Pros Cons
Industry standard method for maintaining Must update the master server to make zone data changes on other servers
Master always contains most up-to-date If a slave is updated, a small delay will information exist before update is propagated
Central repository for zone data Requires latest version of BIND software
Does not require other services to to take advantage of update-forwarding replicate data
© 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. 5 Slave DNS Server
Slave DNS Server
Master DNS Server
Send updates to slave servers
Update locator records
Domain Controllers Figure 4: Active Directory Master-Slave Architecture
When Microsoft introduced Active Directory with Windows 2000, it changed its DNS implementation. The changes included the ability to allow special characters in DNS labels and to store the entire DNS configuration inside the Active Directory. Because Active Directory had its own replication scheme, a different DNS architecture known as Master-Master was developed. The recommended Microsoft architecture for Active Directory specifies that the DNS servers should reside on the domain controller, thus eliminating the need to perform zone transfers. 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 data Microsoft-only implementations
Editing the DNS on one zone replicates to Zone serial numbers can be inconsistent all others in SOA data
Saves bandwidth and processing power Non-standard Architecture
by using existing LDAP replication Not favored in heterogeneous environments
Relies on LDAP for replication
LDAP replication may not be acceptable for external zone data
© 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. 6 MS DNS Server
MS DNS Server
Active Directory
MS DNS Server
Update zone data
Update locator records
Domain Controller Figure 5: Active Directory Master-Master Architecture
The Adonis DNS Appliance uses the BIND 9.x name server software. Therefore all architectures are Master-Slave based. If this technique becomes more widely accepted with other vendors, future releases of the Adonis DNS Appliance may contain a Master-Master replication system.
ADVANTAGES OF ADONIS FOR Although every version of Windows Server ships with the Microsoft DNS service, ACTIVE DIRECTORY DNS many network administrators do use a non-Microsoft implementation of DNS. A SERVICES non-Microsoft DNS-based solution like the Adonis DNS Appliance integrates well into an Active Directory Environment.
1. Interoperability with existing DNS architecture The 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 Migration Existing 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.
© 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. 7 3. Superior Configuration Management The 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 Deployment Changes 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 Security DNS 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 is centered on the LDAP service. DNS plays an important role in providing the information used by the Windows Domain locator service to connect and
© 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. 8 authenticate with Active Directory. The Adonis DNS Appliance provides features that allow easy integration with Active Directory while providing BIND-based DNS services throughout an organization. Existing DNS configurations that utilize BIND can rest assured that the migration to the Adonis DNS Appliance will yield a compatible, reliable and dependable DNS solution.
For more information about the Adonis DNS Appliance, visit the BlueCat Networks website at http://www.bluecatnetworks.com
ACTIVE DIRECTORY DNS The following section contains a list of Active Directory specific records that are RECORDS registered by the NetLogon service.
SRV Records
_ldap._tcp.
_ldap._tcp.
_ldap._tcp.dc._msdcs.
_ldap._tcp.
_ldap._tcp.pdc._msdcs.
_ldap._tcp.gc._msdcs.
_ldap._tcp.
© 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. 9 Example: _ldap._tcp.richmondhill._sites.gc._msdcs.bluecatnetworks.com
_gc._tcp.
_gc._tcp.
_ldap._tcp.
_kerberos._tcp.
_kerberos._udp.
_kerberos._tcp.
_kerberos._tcp.
_kpasswd._tcp.
© 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. 10 Example: _kpasswd._tcp.bluecatnetworks.com
_kpasswd._udp.
A Records
gc._msdcs.
CNAME Records
© 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. 11