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

 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 Dynamic Domain 2 Send updates to slave servers

Active Directory is an essential element of the Windows server Controller Registration

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
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
Master DNS Server
3
1 3
Slave DNS Server

▪▪ Global Catalog Servers Domain Controller 2

▪▪ Kerberos Password Change Servers 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 3 Send updates to slave via Incremental Zone Transfer (IXFR)

DC needs to be found. The Windows client contains a service

called NetLogon which uses a DC locating algorithm to find the
appropriate server.
When examining these records in the Microsoft DNS server, one
This algorithm works in the following manner: is led to believe that this data must reside in sub zones of the
1. A List of DCs is obtained via a DNS query using the domain parent domain. This is not necessarily the case, since Dynamic DNS
name, domain Globally Unique Identifier (GUID) and/or site (DDNS) updates have no way of creating additional zones. The
name. records are simply added as resource records with label separators
2. The locator pings each controller in random order and uses (“.”) into the parent domain’s zone file. Additionally, one will notice
that several of the records contain underscore (“_”) characters
the weighting factor discovered while getting the list of
as part of the names. This technique is common practice used
DCs. It waits up to one tenth of a second for a reply from
in Microsoft development tools and was borrowed for the DNS
the DC. The pinging continues until all controllers are tried
naming technique for Active Directory. The following list contains
or until a successful response is received.
the naming conventions used in the records:
3. After a DC responds successfully to a ping, the results from
the response are compared to the parameters required by DNS Label Description
the client. If there is a match, then the DC is used. Otherwise, _ldap LDAP service
the pinging of other DCs resumes. _tcp Service uses TCP connections
_udp Service uses UDP connections
_kerberos Record contains information about a Kerberos
Slave DNS Server Key Distribution Center (KDC)
_msdcs Service is running on a Domain Controller
Master DNS Server
Domain Controller 2
Slave DNS Server _kpasswd Kerberos Password Change service
2 _gc Global Catalog service
1

_sites Record contains information on a specific site

1 Update locator records
2 Send updates to slave servers 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.
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

own Address (A) and Pointer (PTR) records with their local DNS
Integrating Adonis into Active Directory server. In most cases, organizations use DHCP servers that can

The Adonis DNS Appliance easily integrates into the Active perform the registration directly on the DNS server, which is a
Directory environment. The simplest way to perform this operation more secure method. However, if desired, clients can still register
is to use the “Active Directory Wizard” for each zone that requires themselves directly with the DNS server by allowing those specific
AD integration. The wizard asks for the IP addresses of each clients to make dynamic updates. In either case, an ACL should be
Domain Controller that will register their records. Once complete, used to secure these updates.
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.
 How to Integrate Active Directory and DNS | 3

DNS Replication Master — Master When Microsoft introduced Active Directory with
Windows 2000, it changed its DNS implementation. The changes
There are two schools of thought about DNS record replication: included the ability to allow special characters in DNS labels and
Master — Slave and Master — Master. to store the entire DNS configuration inside the Active Directory.
Since Active Directory had its own replication scheme, a different
Master — Slave The current industry standard outlined in RFC DNS architecture known as Master - Master was developed. The
1034 and 1035, states that a secondary zone (slave) replicates its recommended Microsoft architecture for Active Directory specifies
contents from a primary (master) zone on a given internal network. that the DNS servers should reside on the domain controller, thus
This was enhanced by the DNS Notify mechanism (RFC 1996) eliminating the need to perform zone transfers.
that lets master servers notify their slaves when their contents
have changed. With the advent of Dynamic DNS (DDNS), faster The following table lists the pros and cons of the Master - Master
incremental zone transfers (IXFR) were developed. Slave servers method of replication:
could then accept and forward updates to their respective master
servers. The Master - Slave architecture works on Windows, UNIX®, Master-Master Replication System
and other operating systems. It is the recommended method for Pros Cons
managing DNS. The following table lists some of the pros and cons
• A central repository for all • Microsoft-only imple-
of a Master-Slave replication system:
zone data mentations
• Zone serial numbers can
Master-Slave Replication System • Editing the DNS in one zone
be inconsistent in SOA
replicates to all others
Pros Cons data
• Saves bandwidth and • Non-standard architec-
• An industry standard • Master server updates
processing power by using ture
method for maintaining are required to make
existing LDAP replication to • Not favored in heteroge-
zone data changes on other servers
replicate DNS data neous environments.
• If a slave server is
• The master server always • Relies on LDAP for rep-
updated, a small delay
contains most up-to-date lication
exists before the update
information • LDAP replication may
is propagated
• A central repository for • It requires latest version not be acceptable for
zone data of BIND software to take external zone data

• It does not require other advantage of update-

services to replicate data forwarding

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

3
Slave DNS Server
1 3
Domain Controller 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 MS DNS Server Active Directory MS DNS Server

The Adonis Server contains an elegant and user-friendly interface Domain Controller

for manipulating DNS configurations and record data. Powerful

features found in most applications include multi-level undo/redo, Update zone data
cut/copy/paste and data checking functionality that is absent from Update locator records

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.

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 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.
How to Integrate Active Directory and DNS | 5
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.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 <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 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 European Head Office: United Kingdom Germany Asia Pacific Head Office Shanghai, China Hong Kong S.A.R.
Corporate/R&D BlueCat Networks BV BlueCat Networks Europe BlueCat Networks 1 Fullerton Road 12/F, Shui On Plaza, No. 333 Huai Suite 1308, 655 Nathan Rd
Headquarters: Herengracht 466-2 Merlin House (Zentraleuropa) #02-01 Hai Zhong Rd Kowloon, Hong Kong
502-4101 Yonge Street 1017CA Amsterdam Brunel Road Altrottstrasse 31 Singapore 049213 Luwan District Phone: +852.2309.6874
Toronto, ON M2P 1N6 The Netherlands Theale Berkshire RG7 4AB D-69190 Walldorf, Germany Phone: +65 6832 5124 Shanghai, China Fax: +852.2216.6656
Phone: +1.416.646.8400 T: +31 20 754 64 85 Phone: +44.118.902.6680 Telephone: +49.6227.38489.10 Fax: +65 6408 3801
Fax: +1.416.225.4728 Fax: +44.118.902.6401 Fax: +49.6227.38489.18
Toll Free: +1.866.895.6931

US Offices: Atlanta, GA Chicago, IL Philadelphia, PA Los Angeles,CA Beijing, China

Reston, VA 1165 Sanctuary Parkway 300 East 5th Avenue 1500 Market Street 4640 Campus Drive D202/2502 Topbox, No. 69
1818 Library Street Suite 260 Suite 440 12th Floor / East Tower Suite 103 West Beichen Road
Suite 500 Alpharetta, GA 30009 Naperville, IL Philadelphia, PA Newport Beach, CA Chaoyang District,
Reston, VA Phone: +1.770.777.2461 60563 19102 92660 Beijing China, 100029
20190 Fax: +1.770.777.2464 Phone: +1.630.946.6297 Phone: +1.215.246.3400 Phone: +1.949.260.8444 Phone:+ 86.10.8202.4226
Phone: +1.703.956.3551 Fax: +86.10.8202.6488

©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