Bluecat Networks Whitepaper - How to Integrate Active Directory and DNS

Whitepaper

HOW TO INTEGRATE ACTIVE DIRECTORY AND DNS

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 502Toronto, OntarioCanada M2P 1N6Telephone: 416-646-8400Fax: 416-225-4728E-mail: [email protected]: 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.

ii | BlueCat Networksii | BlueCat Networks

How to Integrate Active Directory and DNS | iii

Executive Summary

Windows® 2000 Server was a pivotal point for Microsoft in central-izing and consolidating directory services. Active Directory® (AD) is based on well known network services such as Lightweight Direc-tory Access Protocol (LDAP) and Kerberos. AD utilizes DNS for its location mechanism. DNS has grown to become not only the cor-nerstone 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 per-formed easily while providing a robust, secure, and highly main-tainable 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

How to Integrate Active Directory and DNS | 1

Active Directory and DNSActive 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:

▪ LDAP Servers ▪ Kerberos Domain Controllers ▪ Addresses 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 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.

Dynamic Domain Controller RegistrationWithout 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).

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)

A registered DNS record can contain one or more of the above names to describe a service that can be queried.

1

2

2

Domain Controller

Slave DNS Server

Master DNS Server

Slave DNS Server

1

2

Update locator records

Send updates to slave servers

1

3

23

Domain Controller

Slave DNS Server

Master DNS Server

Slave DNS Server

1

2

Perform transfer of Active Directory Zone

Send Dynamic Updates to add/update controller’s records

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

1

2

2

Domain Controller

Slave DNS Server

Master DNS Server

Slave DNS Server

1

2



1

3

23

Domain Controller

Slave DNS Server

Master DNS Server

Slave DNS Server

1

2




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 0389 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.

Integrating Adonis into Active DirectoryThe 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.

Manually performing the integration without the Wizard involves a few simple steps:

1. Create an Access Control List (ACL) that contains the ad-dresses 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.

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

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.


DNS ReplicationThere 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 SystemPros 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 update-forwarding

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 SystemPros 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 imple-mentations

• Zone serial numbers can be inconsistent in SOA data

• Non-standard architec-ture

• Not favored in heteroge-neous environments.

• Relies on LDAP for rep-lication

• LDAP replication may not be acceptable for external zone data

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.

1

2

2

Domain Controller

Slave DNS Server

Master DNS Server

Slave DNS Server

1

2



1

3

23

Domain Controller

Slave DNS Server

Master DNS Server

Slave DNS Server

1

2





Advantages Of Adonis For Active Directory DNS ServicesAlthough 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.

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.

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).


Update zone data

Domain Controller

MS DNS Server Active Directory MS DNS Server

MS DNS Server


SummaryActive 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 BIND-based 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.

Active Directory DNS RecordsThe 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.bluecatnetworks.com

_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.bluecatnetworks.com

_ldap._tcp.dc._msdcs.<DomainName>Used by clients to locate a Domain Controller (DC) in the domain named by <DomainName>. This record is registered by all DCs. For example:

_ldap._tcp.dc._msdcs.bluecatnetworks.com

_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. bluecatnetworks.com

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

_ldap._tcp.pdc._mscdcs.bluecatnetworks.com

_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.bluecatnetworks.com

_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.bluecatnetworks.com


_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.bluecatnetworks.com

_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 re-sponsible for the GC will register this record. For 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 <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.01693484-b5c4-4b31-8608-80e77ccc78b8.domains._msdcs.bluecatnetworks.com

_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-1510 compliant with Kerberos 5 KDC. The server is not neces-sarily a DC. For example:

_kerberos._tcp.bluecatnetworks.com

_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-1510 compliant with Kerberos 5 KDC. The server is not neces-sarily a DC. This service supports UDP.For example:

_kerberos._tcp.bluecatnetworks.com

_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> re-spectively. The server is not necessarily a DC. For 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 domain named by <SiteName> and <DomainName> re-spectively. For example:

_kerberos._tcp.richmondhill._sites.dc._msdcs.

bluecatnetworks.com

_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.bluecatnetworks.com

_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.bluecatnetworks.com

A Records<ServerName>.<DomainName>The server name named by <ServerName> is registered in the do-main named by <DomainName>. This record is used by referral lookups to SRV and CNAME records. For example:

dc1.bluecatnetworks.com

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.bluecatnetworks.com

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:

01693484-b5c4-4b31-8608-80e77ccc78b8._msdcs.

bluecatnetworks.com

About BlueCat NetworksFounded 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 MoreFor 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.

©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.

b l u e c a t n e t w o r k s . c o m

US Offices:Reston, VA1818 Library StreetSuite 500Reston, VA20190Phone: +1.703.956.3551

North AmericanCorporate/R&DHeadquarters:502-4101 Yonge StreetToronto, ON M2P 1N6Phone: +1.416.646.8400Fax: +1.416.225.4728Toll Free: +1.866.895.6931

Atlanta, GA1165 Sanctuary ParkwaySuite 260Alpharetta, GA 30009Phone: +1.770.777.2461Fax: +1.770.777.2464

European Head Office:BlueCat Networks BVHerengracht 466-2 1017CA Amsterdam The Netherlands T: +31 20 754 64 85

United KingdomBlueCat Networks EuropeMerlin HouseBrunel RoadTheale Berkshire RG7 4ABPhone: +44.118.902.6680Fax: +44.118.902.6401

Chicago, IL300 East 5th AvenueSuite 440Naperville, IL60563Phone: +1.630.946.6297

GermanyBlueCat Networks (Zentraleuropa)Altrottstrasse 31D-69190 Walldorf, GermanyTelephone: +49.6227.38489.10Fax: +49.6227.38489.18

Philadelphia, PA1500 Market Street12th Floor / East TowerPhiladelphia, PA19102Phone: +1.215.246.3400

Los Angeles,CA4640 Campus DriveSuite 103Newport Beach, CA92660Phone: +1.949.260.8444

Asia Pacific Head Office1 Fullerton Road#02-01Singapore 049213Phone: +65 6832 5124Fax: +65 6408 3801

Beijing, ChinaD202/2502 Topbox, No. 69West Beichen RoadChaoyang District, Beijing China, 100029Phone:+ 86.10.8202.4226Fax: +86.10.8202.6488

Shanghai, China12/F, Shui On Plaza, No. 333 Huai Hai Zhong RdLuwan DistrictShanghai, China

Hong Kong S.A.R.Suite 1308, 655 Nathan RdKowloon, Hong KongPhone: +852.2309.6874Fax: +852.2216.6656

Bluecat Networks Whitepaper - How to Integrate Active Directory and DNS

Documents

Transcript of Bluecat Networks Whitepaper - How to Integrate Active Directory and DNS