HOW TO INTEGRATE ACTIVE DIRECTORY AND DNS Whitepaper
ii | BlueCat Networks Use of this document 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. 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 © 2011, BlueCat Networks Inc. All rights reserved worldwide. Publisher Information Published in Canada — 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. 4101 Yonge Street, Suite 502 Toronto, Ontario Canada M2P 1N6 Telephone: 416-646-8400 Fax: 416-225-4728 E-mail:
[email protected] Website: 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. 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 website or any materials on this document or any website 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.
How to Integrate Active Directory and DNS | iii
Executive Summary 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. AD utilizes DNS for its location mechanism. DNS has grown to become not only the cornerstone of the Internet, but a crucial fabric to connect Windows clients with their Domain Controllers. This document outlines how AD 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.
iv | BlueCat Networks
Contents Executive Summary �����������������������������������������������������������������������������������������������iii Active Directory and DNS��������������������������������������������������������������������������������������� 1 Dynamic DomainController Registration���������������������������������������������������������������� 1 Integrating Adonis into Active Directory���������������������������������������������������������������� 2 DNS Replication����������������������������������������������������������������������������������������������������� 3 Advantages Of Adonis For ActiveDirectory DNS Services���������������������������������������� 4 Interoperability with Existing DNS Architecture ���������������������������������4 Quick Migration�������������������������������������������������������������������������4 Superior Configuration Management�����������������������������������������������4 Controlled Deployment����������������������������������������������������������������4 Improved Security�����������������������������������������������������������������������5 Total Cost of Ownership (TCO)��������������������������������������������������������5 Summary��������������������������������������������������������������������������������������������������������������� 5 Active Directory DNS Records��������������������������������������������������������������������������������� 5 SRV Records������������������������������������������������������������������������������5 A Records��������������������������������������������������������������������������������������������������������������� 7 CNAME Records������������������������������������������������������������������������������������������������������ 7 About BlueCat Networks���������������������������������������������������������������������������������������� 8 BlueCat Networks White Papers����������������������������������������������������������������������������� 9
Slave DNS Server Master DNS Server
Domain Controller
2
How to Integrate Active Directory and Slave DNSDNS Server | 1 2
1 1 Update locator records
Active Directory and DNS
2 Send updates to slave servers
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. AD is based upon 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:
▪▪ ▪▪ ▪▪ ▪▪ ▪▪
Dynamic Domain Controller Registration
Without the proper DNS information, a client cannot discover which server to contact for authentication. Each Domain Controller registers and maintains its own Active Directory DNS integration records consisting 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 a standard DNS zone transfer (AXFR) and updated Dynamic DNS (DDNS) by the DC (RFC 2136).
Slave DNS Server
LDAP Servers Kerberos Domain Controllers Addresses of the Domain Controllers Global Catalog Servers Kerberos Password Change Servers
Master DNS Server
Domain Controller
3
Slave DNS Server 3
1 2
1 Perform transfer of Active Directory Zone 2 Send Dynamic Updates to add/update controller’s records
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 DC 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 Globally Unique Identifier (GUID) and/or site name. 2. The locator pings each controller in random order and uses the weighting factor discovered while getting the list of DCs. It waits up to one tenth of a second for a reply from the DC. The pinging continues until all controllers are tried or until a successful response is received. 3. After a DC responds successfully to a ping, the results from the response are compared to the parameters required by the client. If there is a match, then the DC is used. Otherwise, the pinging of other DCs resumes.
3 Send updates to slave via Incremental Zone Transfer (IXFR)
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’s zone file. 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 on a specific site
dc
Domain Controller (DC)
gc
Global Catalog (GC)
Slave DNS Server
Domain Controller
Master DNS Server
2
Slave DNS Server 2
1 1 Update locator records
2 Send updates to slave servers
A registered DNS record can contain one or more of the above names to describe a service that can be queried.
2 | BlueCat Networks For example, the following record locates an LDAP service, on server1.bluecatnetworks.com in bluecatnetworks.com: _ldap._tcp.bluecatnetworks.com SRV 0 0 389 server1.bluecatnetworks.com
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.
4. For each slave zone, allow update forwarding using the ACL. This forwards dynamic updates to the master zone. Once the configuration has been deployed, it takes 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 that can be changed to suit an organization’s requirements. Domain Controllers 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 in the Adonis Management Console reveals the Active Directory records. Windows 2000 type networks also enable clients to register their
Integrating Adonis into Active Directory
own Address (A) and Pointer (PTR) records with their local DNS
The Adonis DNS Appliance easily integrates into the Active Directory environment. The simplest way to perform this operation is to 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 is performed, the DC’s register their records and client machines, then use the information to gain access to the AD domain.
perform the registration directly on the DNS server, which is a
Manually performing the integration without the Wizard involves a few simple steps: 1. Create an Access Control List (ACL) that contains the addresses of all the Domain Controllers. Add this ACL to each DNS server. 2. For the master DNS server, allow zone transfers. 3. For each master zone, allow dynamic updates using the ACL.
server. In most cases, organizations use DHCP servers that can 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. In either case, an ACL should be used to secure these updates.
How to Integrate Active Directory and DNS | 3
DNS Replication There are two schools of thought about DNS record replication: Master — Slave and Master — Master. Master — Slave The current industry standard outlined in RFC 1034 and 1035, states that a secondary zone (slave) replicates its contents from a primary (master) zone on a given internal network. This was enhanced by the DNS Notify mechanism (RFC 1996) that lets master servers notify their slaves when their contents have changed. With the advent of Dynamic DNS (DDNS), faster incremental zone transfers (IXFR) were developed. Slave servers could then accept and forward updates to their respective master servers. The Master - Slave architecture works on Windows, UNIX®, and other operating systems. It 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 Replication System Pros •
An industry standard method for maintaining zone data
•
The master server always contains most up-to-date information
•
A central repository for zone data
•
It does not require other services to replicate data
Master — Master 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. Since 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 lists the pros and cons of the Master - Master method of replication:
Master-Master Replication System Pros •
A central repository for all zone data
•
Editing the DNS in one zone replicates to all others
•
Saves bandwidth and processing power by using existing LDAP replication to replicate DNS data
Cons •
•
•
Master server updates are required to make changes on other servers If a slave server is updated, a small delay exists before the update is propagated It requires latest version of BIND software to take advantage of updateforwarding
Cons • •
• • • •
Microsoft-only implementations Zone serial numbers can be inconsistent in SOA data Non-standard architecture Not favored in heterogeneous environments. Relies on LDAP for replication LDAP replication may not be acceptable for external zone data
Slave DNS Server Master DNS Server
Domain Controller
2
Slave DNS Server 2
1 1 Update locator records
2 Send updates to slave servers
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.
Slave DNS Server Master DNS Server
Domain Controller
3
Slave DNS Server 3
1 2
1 Perform transfer of Active Directory Zone
4 | BlueCat Networks
Advantages Of Adonis For Active Directory DNS Services Although Windows Server ships with the Microsoft DNS service, many network administrators use a non-Microsoft implementation of DNS. A non-Microsoft DNS-based solution such as the Adonis DNS Appliance integrates well into an Active Directory Environment.
Interoperability with Existing DNS Architecture The Adonis Server is based upon ISC’s BIND, the most widely used DNS service implementation and the international benchmark for DNS. Existing BIND architectures can interoperate easily with the Adonis Server, while maintaining a similar architecture.
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. The 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 performs additional data checking on the imported data to isolate and assist with the resolution of issues before deployment.
Worm viruses can unload 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 which eventually rendered some of the root servers to be off line. Many organizations also discovered that their own internal DNS servers were being attacked in a similar manner. The Adonis DNS Appliance contains an integrated firewall, IP packet spoofing, and a hardened Linux operating system that resists these types of attacks. Indeed, it is common knowledge that heterogeneous networks are more resilient to effective attacks since only some of the servers will be vulnerable to system-specific exploits.
Total Cost of Ownership (TCO) The total cost of the Adonis DNS Appliance is considerably lower than that of a Microsoft DNS server solution. Considering the volume of Windows updates, vulnerabilities, and scheduled maintenance combined with the simplistic management surrounding the Windows solution, the Adonis solution offers a lower cost of total ownership, even in the first year of deployment. For more detailed information about the TCO, see the BlueCat Networks documentation on the Adonis Server’s Return on Investment (ROI). MS DNS Server
Superior Configuration Management The Adonis Server contains an elegant and user-friendly interface for manipulating 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.
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 network application/ service outages and stability issues. This issue is compounded by the fact that some applications do not respect DNS Time to Live (TTL) values and will hold onto invalid data until restarted.
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 with the sheer volume of exploits in the Windows operating system that plague network administrators.
Active Directory
MS DNS Server Domain Controller
Update zone data Update locator records
MS DNS Server
How to Integrate Active Directory and DNS | 5
Summary
Active Directory DNS Records
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 authenticate with Active Directory. The Adonis DNS Appliance provides features that allow easy integration with Active Directory, while providing BINDbased DNS services throughout an organization. Organizations with existing DNS configurations that utilize BIND can be rest assured that 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.
The following section lists Active Directory-specific records that are registered by the NetLogon service.
SRV Records _ldap._tcp. SRV record that identifies an LDAP server in the domain named by . The LDAP server is not necessarily a Domain Controller (DC). This record is registered by all DCs. For example: _ldap._tcp.bluecatnetworks.com
_ldap._tcp.._sites. Enables a client to find an LDAP server in the domain named by . This record is registered by all DCs. For example: _ldap._tcp.richmondhill.bluecatnetworks.com
_ldap._tcp.dc._msdcs. Used by clients to locate a Domain Controller (DC) in the domain named by . This record is registered by all DCs. For example: _ldap._tcp.dc._msdcs.bluecatnetworks.com
_ldap._tcp.._sites.dc._msdcs. Enables a client to locate a DC for the given site and domain named by and respectively. For example: _ldap.tcp.richmondhill._sites.dc._msdcs. bluecatnetworks.com
_ldap._tcp.pdc._msdcs. Enables a client to locate the Primary Domain Controller (PDC) for a domain named by . This record is registered only by the PDC of the domain. For example: _ldap._tcp.pdc._mscdcs.bluecatnetworks.com
_ldap._tcp.gc._msdcs. Enables a client to find the Global Catalog (GC) server for the forest named by . Only the DC for the GC will register this record. For example: _ldap._tcp.gc._msdcs.bluecatnetworks.com
_ldap._tcp.._sites.gc._msdcs. Enables a client to find a GC for the forest named by . Only an LDAP server responsible for the GC will register this record. For example: _ldap._tcp.richmondhill._sites.gc._msdcs. bluecatnetworks.com
6 | BlueCat Networks _gc._tcp. Enables a client to locate a GC for the forest named by . Only an LDAP server responsible for the GC will register this record. The LDAP server is not necessarily a DC. For example: _gc._tcp.bluecatnetworks.com
_gc._tcp.._sites. Enables a client to find a GC for the site and forest named by and respectively. Only an LDAP server responsible for the GC will register this record. For example: _gc._tcp.richmondhill._sites.bluecatnetworks.com
_kerberos._tcp.._sites.dc._msdcs. Used by clients to locate the DC running a Kerberos KDC for the site and domain named by and respectively. For example: _kerberos._tcp.richmondhill._sites.dc._msdcs. bluecatnetworks.com
_kpasswd._tcp. Enables a client to find a Kerberos Password Change Server for the domain named by . The server is not necessarily a DC. All DC running the Kerberos KDC will register this record. For example: _kpasswd._tcp.bluecatnetworks.com
_ldap._tcp..domains._msdcs.< ForestName> Used by clients to find a DC given the domain GUID of in the forest named by . This lookup can used to resolve the DC if the domain name has changed. This record is used infrequently and will not work if the has been changed. For example: _ldap._tcp.01693484-b5c4-4b31-8608-80e77ccc78b8. domains._msdcs.bluecatnetworks.com
_kerberos._tcp. Enables a client to find a Kerberos Key Distribution Center (KDC) for the domain named by . This record will be registered by all DCs providing the Kerberos service. This service is RFC-1510 compliant with Kerberos 5 KDC. The server is not necessarily a DC. For example: _kerberos._tcp.bluecatnetworks.com
_kerberos._udp. Enables a client to find a Kerberos Key Distribution Center (KDC) for the domain named by . This record will be registered by all DCs providing the Kerberos service. This service is RFC-1510 compliant with Kerberos 5 KDC. The server is not necessarily a DC. This service supports UDP.For example:
_kpasswd._udp. Enables a client to find a Kerberos Password Change Server for the domain named by . The server is not necessarily a DC. All DC running the Kerberos KDC will register this record. For example: _kpasswd._udp.bluecatnetworks.com
A Records
. The server name named by is registered in the domain named by . This record is used by referral lookups to SRV and CNAME records. For example: dc1.bluecatnetworks.com
gc._msdcs. Enables a client to find a GC for a given forest named by . This record is used by referral from SRVrecords. For example: gc._msdcs.bluecatnetworks.com
_kerberos._tcp.bluecatnetworks.com
_kerberos._tcp.._sites. Enables a client to locate a server running the Kerberos KDC for a site and domain named by and respectively. The server is not necessarily a DC. For example: _kerberos._tcp.richmondhill._sites. bluecatnetworks.com
CNAME Records
._msdcs. Enables a client to locate any DC in the forest named by by the GUID of the MSFT-DSA (Directory Services) object. For example: 01693484-b5c4-4b31-8608-80e77ccc78b8._msdcs. bluecatnetworks.com
About BlueCat Networks Founded in 2001, BlueCat Networks – the IPAM Intelligence Company is a leader in providing enterprise-class IP Address Management (IPAM) platforms and secure DNS/DHCP network appliances. BlueCat services an account base of over 1000 accounts with thousands of units sold worldwide. Our award-winning ProteusTM IPAM platforms and AdonisTM family of DNS/ DHCP appliances has successfully garnered end-user acceptance by meeting the rising IP management demands of healthcare, government, financial services, education, retail, and manufacturing organizations. BlueCat Networks, a worldwide market leader in IPAM innovation and thought leadership, is benchmarking IPAM excellence in the networking industry. BlueCat Networks experiences overwhelming marketplace acceptance of its networking solutions, resulting in high double digit growth, year over year, since the company’s inception. BlueCat Networks is headquartered in Toronto, Ontario, Canada with offices in the United States, Europe and the Asia Pacific region. It sells networking appliances and services worldwide through direct and indirect sales channels in over 50 countries.
To Learn More For more information on BlueCat Networks, and our award winning Proteus IPAM solutions, please visit our website at www.bluecatnetworks.com or call us at 1-866-895-6931.
North American Corporate/R&D Headquarters: 502-4101 Yonge Street Toronto, ON M2P 1N6 Phone: +1.416.646.8400 Fax: +1.416.225.4728 Toll Free: +1.866.895.6931
European Head Office: BlueCat Networks BV Herengracht 466-2 1017CA Amsterdam The Netherlands T: +31 20 754 64 85
United Kingdom BlueCat Networks Europe Merlin House Brunel Road Theale Berkshire RG7 4AB Phone: +44.118.902.6680 Fax: +44.118.902.6401
Germany BlueCat Networks (Zentraleuropa) Altrottstrasse 31 D-69190 Walldorf, Germany Telephone: +49.6227.38489.10 Fax: +49.6227.38489.18
Asia Pacific Head Office 1 Fullerton Road #02-01 Singapore 049213 Phone: +65 6832 5124 Fax: +65 6408 3801
Shanghai, China 12/F, Shui On Plaza, No. 333 Huai Hai Zhong Rd Luwan District Shanghai, China
US Offices: Reston, VA 1818 Library Street Suite 500 Reston, VA 20190 Phone: +1.703.956.3551
Atlanta, GA 1165 Sanctuary Parkway Suite 260 Alpharetta, GA 30009 Phone: +1.770.777.2461 Fax: +1.770.777.2464
Chicago, IL 300 East 5th Avenue Suite 440 Naperville, IL 60563 Phone: +1.630.946.6297
Philadelphia, PA 1500 Market Street 12th Floor / East Tower Philadelphia, PA 19102 Phone: +1.215.246.3400
Los Angeles,CA 4640 Campus Drive Suite 103 Newport Beach, CA 92660 Phone: +1.949.260.8444
Beijing, China D202/2502 Topbox, No. 69 West Beichen Road Chaoyang District, Beijing China, 100029 Phone:+ 86.10.8202.4226 Fax: +86.10.8202.6488
Hong Kong S.A.R. Suite 1308, 655 Nathan Rd Kowloon, Hong Kong Phone: +852.2309.6874 Fax: +852.2216.6656
©2011. BlueCat Networks, the BlueCat Networks logo, the Proteus logo, IPAM Appliance, the Adonis logo, Adonis are trademarks of BlueCat Networks, Inc. Microsoft, Windows, and Active Directory are registered trademarks of Microsoft Corporation. Any product photos shown are for reference only and are subject to change without notice. All other product and company names are trademarks or registered trademarks of their respective holders. Printed in Canada.
bluecatnetworks.com
