Alcatel-Lucent VitalQIP Technology White Paper

Brand: Alcatel-Lucent

Model: VitalQIP

Type: Technology White Paper

T E C H N O L O G Y W H I T E P A P E R

Use Alcatel-Lucent VitalQIP® to centrally manage your Windows 2003 deploy-

ment.

This white paper addresses:

- Terms and concepts of Microsoft Windows 2003 networking

- How to add Windows 2003 components to an existing VitalQIP

installation

- How to add VitalQIP to an existing Microsoft network

- How to use either Lucent or Microsoft DHCP and DNS in Windows 2003 envi-

ronments

- Methods of ensuring the security of DNS

Integration of VitalQIP® with Microsoft

Windows 2003 Networking/Active

Directory

Introduction

The purpose of this document is to discuss integration of Active Directory and

other Microsoft networking concepts with VitalQIP. It is important to understand

that the use of the Windows 2003 OS with VitalQIP is a separate matter from

the integration of Active Directory and other Microsoft networking concepts with

VitalQIP. In general, VitalQIP Enterprise server, the VitalQIP client GUI, Alcatel-

Lucent DNS, or Alcatel-Lucent DHCP on a Windows 2003 platform will have very

similar functionality to the same software version running on UNIX.

Note: Unless otherwise specied, the term “Windows 2003” in this paper refers to

both Windows 2000 and Windows 2003. The term “MS-DNS” refers to Microsoft

Windows 2000 or Windows 2003 DNS but not Windows NT 4.0 DNS. The term

“MS-DHCP” refers to Microsoft Windows 2000 or Windows 2003 DHCP, but not

Windows NT 4.0 DHCP. Also, please note that the VitalQIP 6.x GUI uses “Win-

dows 2000” to refer to both Windows 2000 and Windows 2003.

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

Table of Content

Overview1.

Overview of solution2.

Solution 1: Adding Windows 2003 support to an existing VitalQIP •

installation: an all-Alcatel-Lucent solution

Solution 2: Adding VitalQIP to an existing Microsoft Network with •

minimal Alcatel-Lucent components

Solution 3: Modication of Solution 2 using Alcatel-Lucent DNS instead •

of MS-DNS

Solution 4: Modication of Solution 2 using VitalQIP 6.2 instead of •

VitalQIP 6.1 SP1

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

iii

Overview

Active Directory and Windows 2003 networking

In Windows 2000 and Windows 2003, the old proprietary WINS technology of Windows

NT was replaced with the use of DNS and RFC-2136-compliant Dynamic DNS Updates.

Microsoft’s design made extensive use of a resource record type called “SRV” to allow

network clients to nd the hostnames of critical network servers. In Microsoft’s design,

DNS data may be stored and synchronized using LDAP (Lightweight Directory Access

Protocol) technology, in a distributed database known as Active Directory. Sometimes,

the term “Active Directory” (AD) is used more broadly, but not quite correctly, to refer to

the entire Windows 2003 network structure instead of just the database itself.

SRV records and special underscore domains

A central part of Windows 2003 networking is that Domain Controllers (DCs) need to

“advertise” services by putting SRV records into DNS. SRV records are a resource re-

cord type to associate a service name with a server’s hostname. Windows 2003 clients

perform queries of these to nd out which servers offer particular network services. For

example, Windows 2003 Domain Controllers provide LDAP and Kerberos services for

clients to use, so the SRV records for LDAP and Kerberos tell the names of the available

DCs. SRV records were dened in the DNS standards documents long ago, but little

used before Windows 2000. SRV records need to get into DNS quickly – not by manual

entry to the VitalQIP GUI – and they need to propagate to all other DNS servers quickly.

Microsoft networking uses special child domains such as “_ldap._tcp.domain”, and so

on. These include:

_msdcs for the MS Domain Controllers•

_sites for AD Sites to indicate closely connected subnets•

_tcp for SRV records of network services that run on TCP such as LDAP, •

Kerberos, and global catalogs

_udp for SRV records of network services that run on UDP•

Operating system considerations

The choice of operating system should depend on your organization’s level of knowledge

and support for that OS. Be aware that the OS of the VitalQIP Enterprise server does not

need to match that of the VitalQIP Remote servers or clients; VitalQIP customers often

“mix-and-match” operating systems. You do not need to run VitalQIP on Windows 2003

just because it will manage a Windows 2003 deployment.

Benets of adding VitalQIP to an existing Microsoft infrastructure

VitalQIP provides additional functionality to that available from Microsoft tools. VitalQIP is

an IP management tool, not a directory service.

VitalQIP provides the ability to:

Manage your IP Address space holistically•

Manage networks centrally or in a distributed fashion•

Manage subnets and IP addresses•

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

Manage DNS servers and DHCP servers from a central location, regard less •

of the vendor or platform

Provide reporting and auditing capability•

Manage administrators and their capabilities at a very granular level•

Dene policies to ensure consistency throughout your network•

Operate in a mixed platform environment•

Perform error checking to ensure networks and servers are properly dened •

and overlapping scopes are not present

VitalQIP management of Sites and Domain Controllers

Active Directory information on the Domain Controllers is an important part of the net-

work infrastructure, and the ability to perform DC Generation is an important benet of

VitalQIP. Management of Domain Controllers from VitalQIP reduces the workload of ad-

ministrators, since data now has to be entered in only one place instead of two, thereby

leveraging the power of VitalQIP and minimizing data entry errors.

To enable DC Generation, the Sites must rst be dened as Subnet Organizations in

the VitalQIP GUI. A Site is an association of subnets that have an afnity to one another

and low “ping times” between them; a VitalQIP Subnet Organization is any user-dened

set of subnets. Next, the Domain Controllers need to be dened as servers in VitalQIP,

although it is not necessary to install VitalQIP Remote server software on them as it is

for DNS and DHCP Remote servers. Finally, the Domain Controllers are associated with

the appropriate Sites (that is, subnet organizations) in the Subnet Organization Prole’s

Windows 2000 Site tab.

When Domain Controller Generation is performed, VitalQIP creates data to go into

the LDAP datastore. This cannot be done unless VitalQIP has been congured with a

username and password that has suitable permissions in Active Directory. The VitalQIP

policy Delete Sites/Subnets from Active Directory controls whether VitalQIP can delete

sites and subnets in Active Directory, or just apply additions and modications.

Data about subnets and sites can easily be transferred from Active Directory to VitalQIP

using Microsoft’s LDIFDE utility together with Alcatel-Lucent’s qip-siteimport utility. This is

discussed in more detail in Solution 2, “Design overview” on page 12.

Data ow differences from a traditional VitalQIP design

In a classic VitalQIP environment, the VitalQIP database is the “master” source of infor-

mation, and DNS Generation pushes copies of its data to the DNS servers.

But in a Windows 2003 environment, the DNS servers receive dynamic updates of SRV

records and other resource records, which the VitalQIP database does not know about

– the data ow needs to be from the DNS server to VitalQIP as well. If the DNS servers

are receiving updates from Domain Controllers and/or Windows 2003 clients, but Vi-

talQIP does not have this data, the DNS Generation will replace the zones that have the

current SRV records with new zones that lack the current information. If that happens,

the network clients will not be able to locate network resources until the Domain control-

lers publish their SRV records again.

The data ow from DNS to the VitalQIP database can be handled either by the External

Updates feature of Alcatel-Lucent DNS (that is, the Continuous method), or by the

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

qip-syncexternal CLI command (that is, the Polling method). The former is discussed in

detail in Solution 1 on page 5; the latter is discussed in Solution 2 on page 12.

DNS data security needs

The DNS and DHCP design needs to ensure that the data gets into DNS, but that criti-

cal resource records don’t get deleted or overwritten with incorrect information from

unauthorized sources. With a classical VitalQIP design, this is simple matter of VitalQIP

administrator rights, but it is more complicated once dynamic updates are involved. This

can be handled by an Access-Control List for allow-update (discussed in detail in Solu-

tion 1), or by GSS-TSIG secure updates (discussed in detail in Solution 2). In brief, either

security system will prevent DHCP clients from accidentally “hijacking” the hostnames of

critical systems in DNS; for example preventing a user’s computer named “www” from

replacing the corporate web server. Hackers who do address spoong can circumvent

Access Control Lists, but not GSS-TSIG secure updates. On the other hand, GSS-TSIG

secure updates are far more complicated to implement and administer. Also, though they

are interoperable, there are some differences between Alcatel-Lucent’s implementation

of secure updates and Microsoft’s. These will be discussed in more detail in later sec-

tions.

Implementation of special underscore domains in VitalQIP

As mentioned in “SRV records and special underscore domains” above, Microsoft net-

working uses special child domains with names that start with underscores. You should

see which of these are required for your particular implementation, and consider den-

ing them as separate domains within VitalQIP. Then you can assign the appropriate

primary and secondary DNS servers to them, and set up the allowupdate permissions

with an Access Control List (ACL) that includes the VitalQIP Enterprise servers, VitalQIP

administrators, and also Domain Controllers. Dening the underscore zones as separate

domains rather than just dotted hostnames within the parent domain allows better secu-

rity – the domain controllers need to have allow-update permissions to the underscore

zones but not necessarily to the parent zones. For example, “_ldap._tcp.example.com”

might be considered as the “_ldap._tcp” dotted hostname in the “example.com” domain,

or as “_ldap” in the “_tcp.example.com” domain. In addition, dening the underscore

domains as separate from the parents allows more efcient data transfer from DNS to

VitalQIP.

DHCP clients in child domains

You might also wish to dene a “DHCP” sub-domain to hold only the DHCP clients in

that sub-domain. In this way, the Windows 2003 clients can be allowed to put their host-

names into DNS without fear of hijacking the hostnames of critical servers in the parent

domain. For example, you can allow updates from any client to the child domain “dhcp.

example.com”, and then a client called “www” would create an A record named “www.

dhcp.example.com” which would not have any conict with “www.example.com”. This

improves security, especially if neither an allow-update ACL nor a Microsoft secure zone

has been implemented. A second major benet is that qip-syncexternal will be more ef-

cient for a small, more focused zone in which only A records need to be compared to

VitalQIP, not other Resource Record types.

The downside of having DHCP clients broken out into a separate child domain is that

users may need to adjust the way that they perform DNS lookups of these names. For

example, if a DHCP client named “client” is in “example.com”, a user can do “nslookup

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

client.example.com” to nd the IP address (or enter “client1.example.com” into the web

browser or FTP or elsewhere). If “example.com” is in the DNS search sufx, just the

shortname “client1” would be enough. But once “client1” is moved to “dhcp.example.

com”, the lookup needs to be performed using the longer full name “client1.dhcp.exam-

ple.com” or else the search sufx needs to be changed.

Authorizing a DHCP server for Active Directory

Microsoft DHCP for Windows 2003 has a feature that the DHCP Service will query the

LDAP data store (that is, Active Directory) to see if it has been authorized. It will fail to

start if it is not authorized. The purpose of this is to prevent “rogue” DHCP servers. Any

network user who has a Windows CD-ROM can install a DHCP server with a few mouse

clicks, even by accident, and that server could hand out IP addresses that conict with

the real DHCP server or with static IP addresses. But only an administrator with the

proper permissions can authorize a DHCP server in the LDAP database. Therefore, un-

authorized Windows 2003 DHCP servers will not start and become rogue servers. (The

mechanism is a little different for MS-DHCP servers which are only in a Workgroup not

part of a domain, but still some protection from rogue servers is provided.)

Alcatel-Lucent DHCP has no need to be authorized in LDAP because it never accesses

LDAP. Alcatel-Lucent DHCP is designed to be congured and managed by VitalQIP, and

is not designed to be a stand-alone DHCP server. VitalQIP ensures that DHCP servers

with overlapping scopes will not be deployed in the network. VitalQIP, however, does

create the authorization record in Active Directory when it performs a DHCP Generation

to a Remote server that is running MS-DHCP.

To see how VitalQIP can be integrated with Windows 2003 networking and Active Di-

rectory, we will look at two different cases. Solution 1 examines the case of an existing,

typical VitalQIP installation which already has Alcatel-Lucent DNS and Alcatel-Lucent

DHCP but which now needs to support Windows 2003 Domain Controllers, Active

Directory, and other Microsoft networking functionality. Solution 2 examines the case

of a typical “Microsoft shop” which is committed to using MS-DNS, MS-DHCP, and all

the deployment options recommended by Microsoft, but which wants to add VitalQIP to

make the management of these resources easier. Each solution contains a discussion of

the design goals, the conguration options being used, some design considerations, and

a brief overview of the procedures for implementing it. Your own organization may not

match either of these situations exactly and may need a solution that has elements of

both. The second solution, especially, is intended as an example rather than as an exact

design for a production system.

Solution 3 comprises a small modication of Solution 2 that uses Alcatel-Lucent DNS

rather than MS-DNS, but still uses MS-DHCP and GSS-TSIG secure updates. Like

Solution 2, it is intended for an organization that is new to VitalQIP but is already using

Microsoft networking.

The above solutions assume the use of VitalQIP 6.1SP1, although some minor changes

may be necessary to support an earlier or later version of VitalQIP. This paper also

briey presents Solution 4, which is similar to Solution 2 but incorporates some new

functionality that is included in VitalQIP 6.2.

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

Overview of Solutions

Design overview

If Windows 2003 networking is being added to an existing VitalQIP installation, a primary

concern is how to get the SRV records into DNS and then into the VitalQIP database.

The Windows 2003 clients need to be able to locate network services by performing

queries of SRV records in DNS, and resolving those server hostnames to IP addresses.

Adding these records in the traditional way (entering them into the VitalQIP GUI and

performing DNS Generation) is difcult to do in a timely manner. Instead, the Domain

Controllers should be added to the Access Control List of the appropriate domains in

Alcatel-Lucent DNS so that they can add or delete the necessary records dynamically.

Alcatel-Lucent DNS, in turn, can use External Updates to put this information into the

VitalQIP database.

If Alcatel-Lucent DHCP is being used already, it would be best to keep the existing mes-

sage routes and methods, and let Alcatel-Lucent DHCP and the Enterprise server put

the DHCP hostname into DNS, not the clients themselves. In brief, the DHCP clients

VitalQIP Message Service. The VitalQIP Message Service sends those messages to the

VitalQIP QIP Update Service, which validates the hostnames and passes the data to the

VitalQIP DNS Update Service. The VitalQIP DNS Update Service sends DDNS Updates

to the DNS servers, as shown in the message ow diagram in Figure 1.

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

Solution 1: Adding Windows 2003 support to an existing VitalQIP

installation: an all-Alcatel-Lucent solution

Use of primary/secondary DNS servers and zone transfers

In most VitalQIP installations, one DNS server is a master (primary) for a particular

domain and other DNS servers might be slaves (secondary) for it. This is in contrast to

the multi-master conguration recommended by Microsoft, which has all DNS servers be

master for the zone and lets LDAP replication keep the data consistent. Either approach

can work, as long as DDNS updates and/or zone transfers reach all the necessary DNS

servers.

If the DNS servers are already working correctly, keeping the existing design as much as

possible can minimize downtime for the implementation of Windows 2003 networking.

Clients, however, need to have SRV records as up-to-date as possible; the default Re-

fresh Time of six hours is unacceptable. For the special underscore zones that contain

these SRV records, the following alternatives are recommended:

Have a much shorter Refresh Time (down to 10 minutes). or•

Set “Notify=Yes”. If Notify is set to Yes, the DNS primary server noties the •

secondary servers immediately upon any change, and the secondary server

requests an IXFR zone transfer or

Route the DNS update via the DNS Update Service and have the policy •

UpdateSecondaries set to True, so that the DNS Update Service sends the

change directly to all primary and secondary servers.

Having “Notify=Yes” for large zones that have very frequent updates will hurt the perfor-

mance of the DNS primary server. If the DNS design requires frequent updates and zone

transfers of large zones, DNS lookups will be faster if they are performed on the DNS

secondary servers rather than on the primary server.

Alternatively, you may wish to have all applicable DNS servers as Primary for these par-

ticular zones and none of them as Secondary; that is, a multi-master DNS design. This

is easier to do if the underscore domains have been dened separately from the parent

domains: the child domains can be multi-master but you can keep your existing primary/

secondary design for the parent domain. In that case, the problems of zone transfers

of the underscore domains will never arise since all updates will be shared using the

External Update mechanism. Certain changes in VitalQIP (for example, changes on the

Resource Records tab) would need to be pushed to all DNS primary servers, but those

changes in VitalQIP would generally be for the parent domain, and not for the under-

score child domains.

If you have multiple primary servers for a certain zone, we recommend the following:

Do not have secondary servers as well for the same zone, especially not with a •

secondary server getting the zones from several primary servers at the same time.

Although VitalQIP allows this conguration, it often causes data inconsistencies

between the DNS servers, as well as serial number mismatches.

The primary servers should be all Alcatel-Lucent DNS or all MS Windows 2003 •

DNS. You should not have one primary be Alcatel-Lucent and another Microsoft

because they do not replicate the zone information in the same way.

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

Getting records from Domain Controllers into Alcatel-Lucent DNS Primary

Servers

SRV records are created and maintained by Microsoft Domain Controllers (DCs). The

SRV records are created when the DCs come online and periodically thereafter, and

deleted when the DCs do a proper shutdown. To determine which DNS server gets the

updates, the DC rst sends an SOA query to whatever DNS server is congured in its lo-

cal TCP/IP Properties as the Preferred DNS Server. Then, DNS looks at the SOA record

to see which DNS server is identied as the primary server for that domain or reverse

zone, and sends the DDNS transaction to that server.

This solution works with any DNS server that is able to receive RFC 2136 DDNS up-

dates, for example, any server that is based on BIND 8.x or BIND 9.x. Windows 2003

DNS is not required. For the DNS server to be able to accept updates from the DC, the

allow-update permissions for the appropriate domains and reverse zones should be set

to include the IP address of the DC.

If the Windows 2003 clients are congured to use Secure Updates, Alcatel-Lucent DNS

can still receive these updates if it is appropriately congured and has suitable Kerberos

principal information, although standard BIND 8.x or BIND 9.x servers cannot. Secure

zones would not usually be a part of Solution 1, but could be implemented to protect

against IP spoong attacks if necessary. This would require that the customer have

knowledge and experience with Kerberos.

Getting records from DNS to VitalQIP

As mentioned above, one of the challenges in Windows 2003 integration is to get SRV

records and other data from dynamic updates into VitalQIP’s database (Sybase or

Oracle). This can be done in one of two ways (disregarding manual methods):

1. Qip-syncexternal: This is a command line interface utility, which is similar to the

previous “qipminiddma” utility of VitalQIP 5.x. In brief, it works by requesting a zone

transfer from a particular DNS server, then comparing the contents of that zone or

zones with the VitalQIP database and updating the database as necessary. It must

run periodically, at least once before each DNS Generation to that DNS server, al-

though that can be automated. This will be discussed in more detail in Solution 2.

2. External Updates: If the DNS server is running Alcatel-Lucent DNS 3.1 or 4.0,

the recommended method is external updates. An Alcatel-Lucent DNS server can

be congured to forward all updates of certain types and certain zones to VitalQIP

Message Service, and then Message Service and DNS Update Service can be

congured to forward these to the Enterprise server and/or to other DNS servers.

This happens in a continuous fashion, ensuring that SRV records and other critical

information are preserved and are distributed quickly. External updates are gener-

ally preferable to qip-syncexternal because:

VitalQIP administrators will be able to see new records in the GUI almost •

immediately

DDNS updates that come in during the execution of qip-syncexternal •

might be lost if DNS Generation is performed immediately afterwards; qip-

syncexternal can take awhile to run whereas a single DDNS update is very

quick

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

They are processed in a continuous fashion and therefore avoid creating •

periods of heavy load on the DNS server and on the database.

In this all-Alcatel-Lucent solution, the underscore zones should have the Alcatel-Lucent

Zone Option Import External Updates enabled, and the appropriate message service

should have a Message Route of type DNSUpdateRR going to the QIP Update Service

of the Enterprise server. The QIP Update Service puts the records into the VitalQIP

database, but it does not forward external updates (EDUP) to the DNS Update Service

or DNS. If you have other DNS servers that should get copies of the updates, you should

have a second message route of type DNSUpdateRR going to a DNS Update Service.

See the message ow diagram in Figure 2.

22.

In an all-Alcatel-Lucent solution, we would expect that static hostnames including the

Domain Controllers themselves be dened in the VitalQIP database, and the DHCP

hostnames come in via the DHCP server. Importing of A and PTR records, therefore,

would not be useful since VitalQIP would already have all the A and PTR records of the

DNS server. Only SRV and CNAME records should be enabled in this case, not A and

PTR (nor TXT or AAAA records, which normally would not occur in a Windows 2003

network.)

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

Getting DHCP client hostnames into DNS

In many organizations, DHCP clients need to do reverse lookups of their own hostnames

in DNS to verify their IP addresses. In a pure VitalQIP environment, the Alcatel-Lucent

DHCP server would usually initiate these updates. Whenever an Alcatel-Lucent DHCP

server has DHCP activity, it will generate messages to the VitalQIP Message Service

(according the DHCP policy UpdateQIP). The Message Service would generally have a

message route to send DHCP messages to the VitalQIP QIP Update Service, which is

usually on the Enterprise server. The QIP Update Service can then check the database

to be certain that the new DHCP client hostname does not conict with an existing static

IP object’s hostname (such as “www”) of the same domain. If the QIP Update Service

has the policy UpdateDNS set to True, it forwards those updates to the DNS Update

Service (via the VitalQIP Message Service for type DNSUpdateObject). The DNS

Update Service then sends DDNS updates to the appropriate DNS servers.

Getting DHCP clients into DNS (Use of DHCP Option 81)

By default, a Alcatel-Lucent DHCP server registers the client hostname in the domain

that is associated with the IP object in the VitalQIP database. A Windows 2003 client,

however, can also be congured locally with its own domain, which will not necessar-

ily match the domain congured in VitalQIP. That domain name would be passed to the

DHCP server in DHCP Option 81 (which is the option for Client Fully Qualied Domain

Name) in the DHCP-Discover or DHCP-Request from the client. The Alcatel-Lucent

DHCP Policy Option81Support tells the DHCP server what, if anything, it should do with

this data. The default setting is “Suppress”, which tells the DHCP server to ignore the

client’s domain name and use the one that is congured in VitalQIP. This suits the needs

of most customers, where each subnet is in only one domain, and where the users who

congure desktop systems do not necessarily understand the DNS infrastructure. There

may be some cases though, where it might be advantageous for the DHCP server to put

the client into the requested domain (if it exists). Setting the Option81Support value for

the Alcatel-Lucent DHCP server to the appropriate value (Client or Server) can accom-

plish that.

Getting static IP addresses into DNS

By default, the VitalQIP Global Policy Static DDNS Updates is set to True, and by de-

fault any new IP object in VitalQIP has the checkboxes enabled for dynamic updates

because the Static and Dynamic DNS Masks have all checkboxes enabled. This means

that whenever a VitalQIP administrator adds or creates an IP object, the GUI will put the

A record and PTR record for it into DNS. If the Global Policy Use DNS Update Service is

set to False, the GUI sends the DDNS Update directly to DNS. If it is set to True, the GUI

creates messages of type DNSUpdateObject and DNSUpdateRR and sends them to the

Message service specied by its QIPMESSAGESERVICE environment variable.

In Solution 1, the Static DDNS Updates policy should be left at the default of True, and

the dynamic update checkboxes should be enabled for all objects. In this way, frequent

DNS Generation can be avoided even if you need to dene many static IP addresses.

Windows 2003 systems could also put their own A records and PTR records into DNS,

if the allowupdate ACL permitted it. But for Solution 1, we recommend that the ACL not

permit it. Windows 2003 DHCP Clients would get into DNS via Alcatel-Lucent DHCP as

explained in “Getting DHCP clients into DNS (Use of DHCP Option 81)“. Windows 2003

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

Domain Controllers would be in the ACL for the underscore domains, and this would

allow them to handle the SRV records and CNAME records automatically. We recom-

mend, however, that the A and PTR records, which would be in a non-underscore parent

domain, be entered as static IP objects in the VitalQIP GUI. Likewise, any other servers

with static IP addresses should be entered as such in the GUI.

See the message ow diagram in Figure 3.

Maintaining security for DNS zones

In BIND 8.x (either 3rd party ISC BIND or Alcatel-Lucent DNS 3.1, but not MS-DNS),

authorization for updates or transfers or queries for each zone is given according to the

Access Control Lists. Each zone has three policies (allow-update, allow-query, allow-

transfer) which can be set to None, Any, a list of IP addresses or subnet addresses,

localhost, or localnets.

BIND 9.x (including Alcatel-Lucent DNS 4.0) has some additional security: control mes-

sages are sent via an MD5 signature and shared secrets.

In this all-Alcatel-Lucent solution, allow-update should be set to “Use List” for most do-

mains and reverse zones. All zones should allow updates from the Enterprise server and

VitalQIP client GUIs. If you have a long list of VitalQIP client GUIs, you can congure Vi-

talQIP so that GUIs send updates via the DNS Update Service on the Enterprise server

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

rather than directly to DNS. (To do this, set the Global Policy Use DNS Update Service

to True, ensure the environment variable QIPMESSAGESERVICE is correct on all client

GUI systems, and have Message Route of types DNSUpdateObject and DNSUpdateRR

set to “qip-dns” at the IP address of the Enterprise server.) The underscore domains

should allow updates from the Domain Controllers as well. We recommend, however,

against allowing all systems to update DNS. This would be a security risk, because any

user could rename a system to “www” or another critical network resource, and Windows

2003 could send it to DNS and replace that hostname.

In most corporate environments, GSS-TSIG would not be required. However, if the

deployment network is in a hostile environment, GSS-TSIG may be a valuable security

solution.

Implementation Steps

Review the design decisions discussed above.1.

In the VitalQIP GUI, create any additional networks, subnets, domains, or reverse 2.

zones that might be necessary to support Windows 2003, beyond what already

exists in your VitalQIP infrastructure.

In the VitalQIP GUI, enter the Windows 2003 DCs as static IP addresses.3.

Set the options on the domains and reverse zones as mentioned above: suitable 4.

refresh times or some alternative way for secondary servers to be updated

quickly, suitable allow-update ACLs, the correct primary and secondary DNS

servers, and Import External Updates enabled for SRV and CNAME for the

underscore zones.

Set the options and message routes in the qip.pcy le on the Enterprise server 5.

and all Remote servers as mentioned above:

DHCP servers should have a DHCP message route to QIP Update Service•

Alcatel-Lucent DNS servers should have DNSUpdateRR message routes if •

they have external updates enabled for one or more zones

The Enterprise server (that is, QIP Update Service) should have a •

DNSUpdateObject message route to the DNS Update Service, and have the

UpdateDNS policy set to True

If the Use DNS Update Service policy is set to True, the Message Service(s) •

used by the GUI should have DNSUpdateObject and DNSUpdateRR message

routes to the DNS Update Service

Arrange a time for the cut-over.6.

Set the Global Policies as mentioned above: ensure that Static DDNS Update is 7.

set to True, and that Static DNS Mask and Dynamic DNS Mask are all enabled.

Make sure that the setting for Use DNS Update Service is appropriate and

consistent with the ACLs on your zones and the message routes for your GUIs.

At the appropriate time, assign the domains and reverse zones to the correct 8.

DNS primary and secondary servers. (Do not do this far in advance of the actual

change on the servers, since the VitalQIP assignments will affect dynamic

updates immediately.)

Perform DNS and DHCP Generation to all servers.9.

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

Verify that Windows 2003 clients are getting their hostnames into DNS, and that 10.

they can access the necessary SRV records.

Create Subnet Organizations in VitalQIP.11.

Create Domain Controller Proles in VitalQIP.12.

Verify DC Generation.13.

Design overview

If your organization is already running a Microsoft Windows 2003 network using Micro-

soft DHCP (MSDHCP), Microsoft DNS (MS-DNS), and all of Microsoft’s recommenda-

tions, you can add VitalQIP to provide a central point of management. VitalQIP has a

high interoperability with third-party software such as MS-DNS and MS-DHCP, so it is

easy for it to provide centralized management of these systems. This includes reporting

and auditing capabilities.

This solution assumes that you already have many MS-DNS and MS-DHCP servers in

production, a working Active Directory deployment, secure updates using GSS-TSIG,

and so on. The Domain Controllers put resource records into MS-DNS, as do other

Windows 2003 systems that have static addresses. The hostnames of all DHCP clients

(Windows 2003 or otherwise) are sent to MS-DNS by MSDHCP, via secure updates.

The following sections assume that the Microsoft Windows 2003 networking, especially

secure updates, is already working correctly per Microsoft’s reference design, and that

you want to add VitalQIP to make the management of these servers easier.

In this design, separate treatment of the three types of domains (parent domains, child

domains for DHCP clients, and underscore child domains for SRV records) is important,

because each of these needs different policies and different handling.

The parent domains which contain the A records of the servers could be handled •

in the same way as before, getting updated directly from the Windows 2003 clients

via secure updates. The records could get into VitalQIP via the qip-syncexternal

CLI. Alternatively, they could be made into static zones with static IP addresses,

with Allow-update set to None, and being changed only by DNS Generation.

The DHCP clients, whose hostnames would change frequently, should be in a •

separate domain that has updates allowed. VitalQIP would not need to get these

records from MS-DNS, because it would already have the data. VitalQIP would

have received the data from MS-DHCP via the VitalQIP MS-DHCP Monitor service.

The underscore domains for the SRV records should be secure zones that would •

be dynamically updated by Domain Controllers, and then qip-syncexternal would

pull the records into VitalQIP.

Reverse zones would contain the hostnames of many DHCP clients, so, like the •

DHCP child domain, it would need to have updates allowed. The qip-syncexternal

CLI might need to be run against some or all of the reverse zones if the DNS

design provides for client updates that VitalQIP does not already know about from

other sources.

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

Solution 2: Adding VitalQIP to an existing Microsoft Network with

minimal Alcatel-Lucent components

DNS Generation is seldom needed, because most dynamic data is already in DNS via

DDNS updates from clients and MS-DHCP. Domain Controller Generation and DHCP

Generation to MS-DHCP can be done whenever conguration changes occur.

This solution is intended as an example—in the real world few large organizations have

“pure” Windows 2003 environments like this.

Use of multi-master DNS

In this solution, each domain and reverse zone is assigned to one or more Microsoft AD-

integrated MSDNS primary servers, but there are no secondary servers. AD-integrated

DNS servers need to have local copies of the LDAP database for this domain, meaning

that they are Domain Controllers. Dynamic updates from VitalQIP are sent to all DNS

servers by the VitalQIP DNS Update Service. Dynamic updates from DCs and Windows

2003 clients to a single DNS primary server are replicated to the others via LDAP, in

accordance with Microsoft’s reference design. If a zone has multiple primary servers, it

is best to avoid having any secondary servers, since this may cause the complication

of serial numbers getting out of synch. Additionally, be sure that all primary servers for

a specic zone are MS-DNS or that all are Alcatel-Lucent DNS (the zone replication will

not work if the two types are mixed since they use different methods).

Conguring VitalQIP for secure updates from Domain Controllers to MS-

DNS

In the reference design, the DCs put SRV records and other data into DNS using Secure

Updates. The records are replicated to all primary DNS servers. In this case there are no

secondary DNS servers.

When the data is congured in VitalQIP, the special underscore domains need to be con-

gured with the Windows 2000 Zone Option Allow-Update set to “Yes”, and the domains

need to be assigned to all the correct DNS servers. The “Windows 2000 DNS Server”

Prole should have Boot Method set to Directory, and Secure DNS Updates set to True.

The GSS-TSIG conguration information also needs to be entered into the VitalQIP DNS

Server Prole (see “Maintaining security for DNS zones” on page 19).

The ow of Domain Controller updates is shown in Figure 4.

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

Getting records from DNS into VitalQIP

In this design, Domain Controllers, MS-DHCP servers, and perhaps Windows 2003 stat-

ic clients all put records into DNS: A records, PTR records, CNAME records, and SRV

records. This data needs to be in the VitalQIP database as well, so they can be man-

aged and so that VitalQIP can perform DNS Generation when needed. For MS-DNS, this

process is performed by the qip-syncexternal CLI command. In brief, this CLI requests a

zone transfer from a particular DNS server, compares the contents of that zone or zones

with the VitalQIP database and updates the database when necessary. Because it works

using standard AXFR zone transfers, it does not require Alcatel-Lucent DNS. Almost all

DNS servers, including all Microsoft and Alcatel-Lucent DNS versions, support AXFR

zone transfer and therefore work with qipsyncexternal. This CLI can be run from any

VitalQIP client or server that is on the “allow-transfer” list of the DNS server and has the

VitalQIP CLI utilities, as well as the required Sybase or Oracle client installed.

The qip-syncexternal CLI must run periodically, at least once before each DNS Genera-

tion to that DNS server, either automatically or manually. The time between qip-syncex-

ternal and DNS Generation needs to be kept to a minimum so that the time window for

loss of dynamic updates is as small as possible. This can be done by:

Performing the DNS Generation via the qip-dnsupdate CLI rather than from the •

GUI or via Scheduled Automatic Update – a batch le can call the qip-syncexternal

CLI and then call the qip-dnsupdate CLI immediately afterwards. This batch le can

be run by a scheduler, no more than once per day and preferably less.

Having a “prednsuserexitfgs” user exit congured on the File Generation server to •

run qipsyncexternal automatically at the beginning of each DNS Generation

Running qip-syncexternal manually before each push. •

You might want to run qip-syncexternal more often than DNS Generation, so that the

VitalQIP GUI information remains correct. However, note that qip-syncexternal can put

a considerable load on both DNS and the VitalQIP database when it is run frequently for

large zones.

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

If the DHCP and underscore child domains are separated from the parent domain, but

most static IP addresses are located in the parent domain, qip-syncexternal can be used

as follows for each domain,:

Run it frequently for the underscore domains for all record types even though the •

primary emphasis is on capturing SRV records and CNAME records. Since the

underscore domains are fairly small, this can run quickly.

Run it seldom, if ever, for the DHCP child domain: the DHCP hostnames should •

already be in the VitalQIP database if the DHCP server is updating VitalQIP (see

“Getting DHCP client hostnames into DNS” on page 16). The DHCP domain

would have only A records to be updated, not any CNAME or SRV records.

Run it occasionally to capture A records from the parent zone, if allow-update is •

enabled and if Windows clients with static IP address are supposed to put records

into it. qip-syncexternal ignores hostnames that are already in VitalQIP as static IP

objects.

Run it occasionally to capture PTR records from the reverse zones, if Windows •

clients with static IP addresses are supposed to put records into them. In other

words, the handling of the reverse zone would depend on the handling of the

parent forward zone.

Determining when and how to perform DNS Generation

Frequent DNS Generation should not be needed because resource records from MS-

DHCP clients and Windows 2003 clients get into DNS directly. However, a few changes

in VitalQIP will require a DNS Generation; for example:

Changes in zone options•

Adding or deleting a zone fr om a particular server•

Changes in server options•

Manual changes on the Resource Records tab•

Changes in static IP objects (for non-Windows 2003 servers that cannot register •

in DNS themselves)

When one of these cases arises, the VitalQIP administrator should perform DNS Gen-

eration, unless there is already a scheduled one that will occur soon enough to meet the

requirements. The DNS Generation must also involve qip-syncexternal, as explained in

“Getting records from DNS into VitalQIP”.

A new feature of VitalQIP 6.1 SP1 is very important for this scenario of performing DNS

Generation to AD-integrated MS-DNS servers. A full DNS Generation to replace an

entire zone in MS-DNS will trigger the LDAP replication of the entire zone with all other

DNS servers. In addition, the GSS-TSIG ownership information of each record in a se-

cure zone will be lost when DNS Generation is performed. To minimize these problems,

DNS Generation to an AD-integrated zone on MS-DNS should be performed with the

new “Changed Records Only” option. In this type of DNS Generation, only differences

between the current zone and the VitalQIP database are applied via dynamic update

or (in the case of a zone with allow-update = no) dnscmd commands. In Solution 2, the

zone might be large, but the changes from a single DNS Generation would be few, and

a replication “storm” would be avoided.

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

Distinguishing Internal, External, and Partially-Managed IP Objects in Vi-

talQIP

IP Objects created in the VitalQIP GUI or CLIs will have Object Classes such as Server,

Router, Workstation, and so on. But when A and PTR records are imported into VitalQIP

from DNS via qipsyncexternal or External Updates, VitalQIP might need to create new IP

Objects. If VitalQIP receives an A record or PTR record for an IP address which is within

a known subnet and with a hostname within a known domain, it will create a new IP

object whose Object Class is “External”. These objects may not be modied in the GUI

or CLIs, unless the Object Class is changed rst. But External objects may be modied

by further external updates or qip-syncexternal. The A or the PTR checkbox of the object

will get unchecked if a Delete is received for the A or PTR, and the external object will be

“tombstoned” in the GUI if both are unchecked. On the other hand, if VitalQIP gets an A

record or PTR record from an external source and that record is in conict with an exist-

ing IP object that is not “External”, the A record or PTR record will be rejected.

Also, VitalQIP 6.1 SP1 or higher has an intermediate Object Class called Partially Man-

aged objects. These objects are created and deleted by VitalQIP Administrators, but

can be modied (such as changed hostnames) by external updates. Partially Managed

objects can be created for important Windows 2003 systems with static IP addresses

that need to be in VitalQIP before they are deployed on the network. This will allow the

addresses to reserved in VitalQIP, but for the hostnames of these IP addresses to be

changed later via qip-syncexternal.

In this solution, the parent domains might have a mix of static IP objects dened in

VitalQIP, external objects, and partially managed objects. But the DHCP child domains

would not have these; they would contain only dynamic IP objects dened in VitalQIP.

Dening DHCP Scopes

When the VitalQIP environment is rst set up, the qip-msextract utility can be used to mi-

grate the existing MS-DHCP data into the VitalQIP database. At this time, those objects

should be dened as Dynamic since they will be pushed to MS-DHCP as addresses that

can be leased out.

When new scopes are dened in VitalQIP later, those scopes should also be Dynamic

objects. For MSDHCP servers, all objects in the scopes must be either “Dynamic DHCP”

or “Manual-DHCP”. Manual- DHCP corresponds to “Reserved” addresses in MS-DHCP

terminology: the address is reserved for one specic MAC address, and can therefore

have a xed hostname. A MS-DHCP server does not have a separate type for Bootp;

it will reallocate a DHCP address for Bootp if a Bootp address is needed. No objects

should be dened with Dynamic Conguration types Automatic-DHCP, Manual-Bootp, or

Automatic-Bootp. Also, for MS-DHCP you should not have more than one DHCP Tem-

plate per subnet.

For Solution 2 especially, DHCP scopes should be created with a domain name such

as “dhcp.example.com” which is a child of the main domain such as “example.com”. In

this way, the zone options for each domain can be set correctly, qip-syncexternal can

be specic to the desired data, and security of the hostnames will be less critical. For

example, if a DHCP client has a hostname “www”, this will be in DNS as “www.dhcp.

example.com” not as a replacement for the corporate webserver “www.example.com”.

Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory

Getting DHCP client hostnames into DNS

In this design, we assume that the clients of MS-DHCP were already putting correct

hostnames and domains into MS-DNS, via secure DDNS Updates from MS-DHCP

to MS-DNS. Although Windows 2003 clients would be able to register their own host-

names in DNS by DDNS updates directly from the client to the server, both Microsoft

and Alcatel-Lucent recommend that it is better for the MS-DHCP server to perform these

updates. This allows all DHCP clients, not just Windows 2003 DHCP clients, to have

their hostnames in DNS. Also, it provides more security. The DHCP server would send

the DDNS updates to the DNS primary server for that domain and reverse zone. These

might be using GSS-TSIG secure updates.

Since Solution 2 assumed that this is already working correctly before the addition of

VitalQIP, no changes are needed in order to make the systems manageable by VitalQIP,

except possibly splitting the DHCP clients into a separate child domain. Any DDNS

updates from VitalQIP would be redundant. The qip.pcy le of the system that is running

VitalQIP QIP Update Service should have the UpdateDNS policy set to False. This will

cause the QIP Update Service to update the database for these entries but not forward

the updates to the DNS Update Service.

MS-DHCP has several options for how it updates DNS. By default, it updates DNS on

behalf of all its clients that send DHCP Option 81 (Client FQDN) information, which

would mostly be Windows 2003 clients. The updates go to the DNS server that is the pri-

mary for the domain requested by the client, not necessarily to the domain that is cong-

ured in VitalQIP. MS-DHCP can be congured to send DDNS updates for all clients, not

just those that send Option81, in which case the MS-DHCP server will assume that the

client is the same domain as itself. The various options are congured under Additional

Policies in the MS-DHCP Server Prole in VitalQIP. The ow of DHCP Client updates is

shown in Figure 5.

Page is loading ...

Alcatel-Lucent VitalQIP Technology White Paper

Alcatel-Lucent VitalQIP Technology White Paper

Alcatel-Lucent VitalQIP Technology White Paper

Related papers

Other documents