Download Report

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: info@bluecatnetworks.com
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.<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
6 | BlueCat Networks
_gc._tcp.<ForestName>
Enables a client to locate a GC for the forest named by <ForestName>. 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 <SiteName> and <ForestName> respectively. Only an LDAP server responsible for the GC will register this record. For example:
_gc._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> respectively. 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
_ldap._tcp.<DomainGuid>.domains._msdcs.< ForestName>
Used by clients to find a DC given the domain GUID of <DomainGuid> 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 necessarily 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 necessarily a DC. This service supports UDP.For example:
_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 domain 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
_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> respectively. The server is not necessarily a DC. For example:
_kerberos._tcp.richmondhill._sites.
bluecatnetworks.com
CNAME Records
<DSAGuid>._msdcs.<ForestName>
Enables a client to locate any DC in the forest named by <ForestName> 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