HOW TO INTEGRATE ACTIVE DIRECTORY AND DNS. Whitepaper

Transcription

1 HOW TO INTEGRATE ACTIVE DIRECTORY AND DNS Whitepaper

2 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 0, 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. 40 Yonge Street, Suite 50 Toronto, Ontario Canada MP N6 Telephone: Fax: info@ Website: www. 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.

3 How to Integrate Active Directory and DNS iii Executive Summary Windows 000 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 s. 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.

4 iv BlueCat Networks Contents Executive Summary iii Active Directory and DNS Dynamic DomainController Registration Integrating Adonis into Active Directory 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

5 How to Integrate Active Directory and Slave DNS DNS Server Master DNS Server 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. AD is based upon LDAP and uses security based on MIT s Kerberos project. AD was first available in Windows 000 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 (DC). This information is stored in a series of DNS records specifying the following information: LDAP Servers Kerberos s Addresses of the s 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 DC locating algorithm to find the appropriate server. This algorithm works in the following manner:. A List of DCs is obtained via a DNS query using the domain name, domain Globally Unique Identifier (GUID) and/or site name.. 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. Master DNS Server Update locator records Send updates to slave servers Dynamic Domain Controller Registration Without the proper DNS information, a client cannot discover which server to contact for authentication. Each 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 36). 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 _ldap _tcp _udp _kerberos _msdcs _kpasswd _gc _sites dc gc Master DNS Server Update locator records Send updates to slave servers 3 3 Perform transfer of Active Directory Zone Send Dynamic Updates to add/update controller s records 3 Send updates to slave via Incremental Zone Transfer (IXFR) Description LDAP service Service uses TCP connections Service uses UDP connections Record contains information about a Kerberos Key Distribution Center (KDC) Service is running on a Kerberos Password Change service Global Catalog service Record contains information on a specific site (DC) Global Catalog (GC) A registered DNS record can contain one or more of the above names to describe a service that can be queried.

6 BlueCat Networks For example, the following record locates an LDAP service, on server. in : _ldap._tcp. SRV server. 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 server. For a detailed list of these records see the Active Directory DNS Records section of this document. Integrating Adonis into Active Directory 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 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. 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 000 type networks also enable clients to register their own Address (A) and Pointer (PTR) records with their local DNS server. In most cases, organizations use DHCP servers that can perform the registration directly on the DNS server, which 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. In either case, an ACL should be used to secure these updates. Manually performing the integration without the Wizard involves a few simple steps:. Create an Access Control List (ACL) that contains the addresses of all the s. Add this ACL to each DNS server.. For the master DNS server, allow zone transfers. 3. For each master zone, allow dynamic updates using the ACL.

7 Perform transfer of Active Directory Zone 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 034 and 035, 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 996) 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 Cons 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 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 Master Master When Microsoft introduced Active Directory with Windows 000, 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 Cons 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 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 Master DNS Server Update locator records 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. Master DNS Server 3 3

8 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, 000, and 003) 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. Superior Configuration Management 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 MS DNS Server Active Directory MS DNS Server 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. Update zone data Update locator records 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.

9 How to Integrate Active Directory and DNS 5 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 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 Active Directory DNS Records The following section lists Active Directory-specific records that are registered 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 Domain Controller (DC). This record is registered by all DCs. For example: _ldap._tcp. _ldap._tcp.<sitename>._sites.<domainname> Enables a client to find an LDAP server in the domain named by <DomainName>. This record is registered by all DCs. For example: _ldap._tcp.richmondhill. _ldap._tcp.dc._msdcs.<domainname> Used by clients to locate a (DC) in the domain named by <DomainName>. This record is registered by all DCs. For example: _ldap._tcp.dc._msdcs. _ldap._tcp.<sitename>._sites.dc._msdcs.<domainname> Enables a client to locate a DC for the given site and domain named by <SiteName> and <DomainName> respectively. For example: _ldap.tcp.richmondhill._sites.dc._msdcs. _ldap._tcp.pdc._msdcs.<domainname> Enables a client to locate the Primary (PDC) for a domain named by <DomainName>. This record is registered only by the PDC of the domain. For example: _ldap._tcp.pdc._mscdcs. _ldap._tcp.gc._msdcs.<domainname> Enables 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. For example: _ldap._tcp.gc._msdcs. _ldap._tcp.<sitename>._sites.gc._msdcs.<forestname> Enables a client to find a GC for the forest named by <ForestName>. Only an LDAP server responsible for the GC will register this record. For example: _ldap._tcp.richmondhill._sites.gc._msdcs.

10 6 BlueCat Networks _gc._tcp.<forestname> Enables a client to locate a GC for the forest named by <Forest- Name>. Only an LDAP server responsible for the GC will register this record. The LDAP server is not necessarily a DC. For example: _gc._tcp. _kerberos._tcp.<sitename>._sites.dc._msdcs.<domainname> Used by clients to locate the DC running a Kerberos KDC for the site and domain named by <SiteName> and <DomainName> respectively. For example: _kerberos._tcp.richmondhill._sites.dc._msdcs. _gc._tcp.<sitename>._sites.<forestname> Enables a client to find a GC for the site and forest named by <Site- Name> and <ForestName> respectively. Only an LDAP server responsible for the GC will register this record. For example: _gc._tcp.richmondhill._sites. _kpasswd._tcp.<domainname> Enables 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 Kerberos KDC will register this record. For example: _kpasswd._tcp. _ldap._tcp.<domainguid>.domains._msdcs.< ForestName> Used by clients to find a DC given the domain GUID of <Domain- Guid> in the forest named by <ForestName>. 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 <ForestName> has been changed. For example: _ldap._tcp b5c4-4b e77ccc78b8. domains._msdcs. _kpasswd._udp.<domainname> Enables 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 Kerberos KDC will register this record. For example: _kpasswd._udp. _kerberos._tcp.<domainname> Enables a client to find a Kerberos Key Distribution Center (KDC) for the domain named by <DomainName>. This record will be registered by all DCs providing the Kerberos service. This service is RFC-50 compliant with Kerberos 5 KDC. The server is not necessarily a DC. For example: _kerberos._tcp. 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. For example: dc. _kerberos._udp.<domainname> Enables a client to find a Kerberos Key Distribution Center (KDC) for the domain named by <DomainName>. This record will be registered by all DCs providing the Kerberos service. This service is RFC-50 compliant with Kerberos 5 KDC. The server is not necessarily a DC. This service supports UDP.For example: gc._msdcs.<forestname> Enables a client to find a GC for a given forest named by <ForestName>. This record is used by referral from SRVrecords. For example: gc._msdcs. _kerberos._tcp. _kerberos._tcp.<sitename>._sites.<domainname> Enables a client to locate a server running the Kerberos KDC for a site and domain named by <SiteName> and <DomainName> respectively. The server is not necessarily a DC. For example: _kerberos._tcp.richmondhill._sites. CNAME Records <DSAGuid>._msdcs.<ForestName> Enables a client to locate any DC in the forest named by <Forest- Name> by the GUID of the MSFT-DSA (Directory Services) object. For example: b5c4-4b e77ccc78b8._msdcs.

11 About BlueCat Networks Founded in 00, 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 000 accounts with thousands of units sold worldwide. Our award-winning Proteus TM IPAM platforms and Adonis TM 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. or call us at North American Corporate/R&D Headquarters: Yonge Street Toronto, ON MP N6 Phone: Fax: Toll Free: European Head Office: BlueCat Networks BV Herengracht CA Amsterdam The Netherlands T: United Kingdom BlueCat Networks Europe Merlin House Brunel Road Theale Berkshire RG7 4AB Phone: Fax: Germany BlueCat Networks (Zentraleuropa) Altrottstrasse 3 D-6990 Walldorf, Germany Telephone: Fax: Asia Pacific Head Office Fullerton Road #0-0 Singapore 0493 Phone: Fax: Shanghai, China /F, Shui On Plaza, No. 333 Huai Hai Zhong Rd Luwan District Shanghai, China Hong Kong S.A.R. Suite 308, 655 Nathan Rd Kowloon, Hong Kong Phone: Fax: US Offices: Reston, VA 88 Library Street Suite 500 Reston, VA 090 Phone: Atlanta, GA 65 Sanctuary Parkway Suite 60 Alpharetta, GA Phone: Fax: Chicago, IL 300 East 5 th Avenue Suite 440 Naperville, IL Phone: Philadelphia, PA 500 Market Street th Floor / East Tower Philadelphia, PA 90 Phone: Los Angeles,CA 4640 Campus Drive Suite 03 Newport Beach, CA 9660 Phone: Beijing, China D0/50 Topbox, No. 69 West Beichen Road Chaoyang District, Beijing China, 0009 Phone: Fax: 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.