Integrating VitalQIP® with Microsoft® Windows™ Networking /Active

Transcription

INTEGRATING
VITALQIP® WITH
MICROSOFT®
WINDOWS™
NETWORKING/
ACTIVE
DIRECTORY
USE VITALQIP® TO CENTRALLY
MANAGE WINDOWS DEPLOYMENTS
STRATEGIC WHITE PAPER
This white paper addresses:
Meaning of “Active Directory” and possible meanings of “Integration”
Terms and concepts of Microsoft Networking
Supporting Windows clients with ALU DNS and DHCP
Managing MS-DNS with VitalQIP
GSS-TSIG Secure Zones for ALU DNS and MS-DNS
Managing MS-DHCP with VitalQIP
Domain Controller Generation of Sites and Subnets
LDAP Authentication Callouts from VitalQIP to Active Directory
TABLE OF CONTENTS
Introduction
/
1
Windows Networking Terms and Concepts
/
1
Active Directory and Windows networking / 1
How can VitalQIP be “Integrated” with Active Directory? / 1
DNS Registration of Windows Clients / 1
SRV records / 2
DNS Records Used for Active Directory / 2
What is a Domain Controller? / 3
Supporting Windows Clients with ALU DNS and DHCP
/
4
Resource Records for Domain Controllers / 4
Updating SRV and CNAME records in ALU DNS Primary Servers / 4
Updates of Resource Records from ALU DNS to VitalQIP / 4
Use of primary/secondary DNS servers and zone transfers / 6
Resource records for ALU DHCP clients: / 8
Getting DHCP Hostnames into VitalQIP and DNS / 8
Getting DHCP clients into DNS (Use of DHCP Option 81) / 9
Resource records for Windows clients with static IP addresses / 10
Allow or not allow DNS Registration of static clients? / 10
Understanding Internal, External, and Partially-managed IP objects in VitalQIP / 11
Solution Implementation / 12
Implementing a typical solution using ALU DNS and ALU DHCP / 12
Non-managed MS-DNS for a child domain / 13
Managing MS-DNS with VitalQIP
/
15
Benefits of adding VitalQIP to existing Microsoft infrastructure / 15
How is MS-DNS different from ALU DNS or BIND DNS? / 15
Relationship with Active Directory Domain Services / 15
AD replication between DNS servers / 16
Ownership of resource records / 16
Secure zones and lack of allow-update ACL / 16
Interactions between VitalQIP and MS-DNS / 17
Use of qip-syncexternal to pull data from MS-DNS into VitalQIP / 17
External objects in VitalQIP for MS-DNS clients / 18
Two types of DNS Generation to MS-DNS / 18
Dynamic updates to non-secure zones in MS-DNS / 20
Dynamic updates to secure zones in MS-DNS / 20
Implementing VitalQIP management of MS-DNS servers / 21
Deciding how VitalQIP interacts with MS-DNS / 21
Pre-configure MS-DNS to be managed by VitalQIP / 21
Installing VitalQIP Services on MS-DNS remote servers / 21
What is VitalQIP MS DNS Update Service? / 22
“Semi-managed” MS-DNS servers / 23
Creating MS-DNS server profiles in VitalQIP / 23
Creating zone profiles in VitalQIP / 24
Considerations of 64-bit Windows / 25
Multi-master DNS / 25
Use VitalQIP GUI rather than MS DNS Manager / 25
GSS-TSIG Secure Zones for ALU DNS and MS-DNS
/ 26
Vocabulary for secure zones / 26
Allow-update permissions and secure zones / 26
Other meanings of “secure zone” / 26
How GSS-TSIG secure updates work / 26
When to use secure zones / 27
Key distribution centers (KDCs) and Kerberos keys / 27
Access control information for resource records in MS-DNS / 27
Managing Windows secure zones by VitalQIP / 27
Managing MS-DHCP with VitalQIP
/ 28
Differences between MS-DHCP and ALU DHCP / 28
BootP/DHCP Interchangeability / 28
Terminology of types of IP addresses / 28
DHCP configuration files and lease databases / 28
No DHCP failover and access control / 29
Authorization of MS-DHCP servers / 29
Implementation of VitalQIP support of MS-DHCP / 29
VitalQIP installation on the MS-DHCP Remote Server / 29
Create MS-DHCP server profile in VitalQIP / 29
Migration of DNS and Sites data into VitalQIP / 29
qip-msextract utility / 30
Defining new DHCP scopes for MS-DHCP in VitalQIP / 30
DHCP Generation to MS-DHCP / 30
Getting MS-DHCP client hostnames into MS-DNS / 30
Getting DHCP lease information into VitalQIP – VitalQIP MS DHCP Monitor Service / 31
Getting MS-DHCP client hostnames into ALU DNS / 32
Migration of MS-DHCP data to ALU DHCP / 33
VitalQIP management of Sites and Domain Controllers / 34
Overview / 34
What is Domain Controller Generation? / 34
Data Replication between domain controllers / 34
Implementation / 34
LDAP Authentication Callouts from VitalQIP to Active Directory
Conclusion
/ 38
/ 37
INTRODUCTION
This document discusses integrating Active Directory (AD) and other Microsoft networking concepts with Alcatel-Lucent VitalQIP®. It is important to understand that using
the Windows operating system (OS) with VitalQIP is different from integrating Active
Directory and other Microsoft networking concepts with VitalQIP. In general, VitalQIP,
Alcatel-Lucent DNS, or Alcatel-Lucent DHCP on a Windows platform has very similar
functionality to the same software version running on a UNIX platform.
Note: Unless otherwise specified, the term “Windows” in this paper refers to all versions of
Microsoft Windows currently supported by VitalQIP. As of late 2013 (VitalQIP 8.0PR2), that
is Windows 2003™ Server (32-bit) and Windows 2008™ R2 Server (32- or 64-bit). Support for
Windows 2012™ is expected in future releases. “Microsoft DNS” (MS-DNS) and “Microsoft
DHCP” (MS-DHCP) refer to the native DNS and DHCP of these Windows versions.
WINDOWS NETWORKING TERMS AND CONCEPTS
Active Directory and Windows networking
In Windows 2000™ or higher, the old, proprietary WINS technology of Windows NT™ was
replaced with the use of DNS and Request for Comments (RFC)-2136-compliant dynamic
DNS updates. Microsoft’s design made extensive use of a resource record type called SRV
to allow network clients to find the hostnames of critical network servers. In Microsoft’s
design, DNS data may be stored and synchronized using Lightweight Directory Access
Protocol (LDAP) technology, in a distributed database known as Active Directory.
Sometimes, the term Active Directory is used more broadly, but not quite correctly, to
refer to the entire Windows network structure instead of just the database itself.
How can VitalQIP be “Integrated” with Active Directory?
“Integration” could mean many things:
• Supporting Windows clients in ALU DNS: Conventional VitalQIP remote servers
running ALU DNS and ALU DHCP need at least a few configuration changes for
Windows clients
• Allowing all Windows clients to register directly in ALU DNS: This decision requires an
understanding of external objects in VitalQIP, and a consideration of GSS-TSIG secure
zones
• DNS designs with both ALU DNS and non-managed MS-DNS: These designs might use
child-zone delegations or slave zones, but also should consider reverse zones.
• VitalQIP management of MS-DNS.
• VitalQIP management of MS-DHCP as well.
• Domain controller generation of sites and subnets.
• LDAP authentication callouts for VitalQIP login requests.
DNS registration of Windows Clients
Ideally, each Windows client in a network should have both an A record and a PTR
record in DNS. DHCP servers do this on behalf of DHCP clients, but Windows clients
with static IP address are often configured to try to update DNS directory. This behavior
is controlled by one of the TCP/IP settings of the Windows registry: “Register this connection’s address in DNS”. Another of these settings controls the preferred DNS server(s).
Integrating VitalQIP ® with Microsoft ® Windows™ Networking /Active Directory
ALCATEL-LUCENT ENTERPRISE WHITE PAPER
1
Windows clients that have DNS registration enabled will first query their preferred DNS
server first to find the Start of Authority (SOA) record of their own domain. That SOA
record indicates the name of the primary DNS server for the domain. Then the client tries
to send a dynamic update to that DNS server to add an A record for itself. Then it does
the same for its PTR record.
The “Supporting Windows clients with ALU DNS and DHCP” section of this paper discusses the pros and cons of allowing these clients to register in ALU DNS, as well as an
alternative approach. Later sections discuss methods of getting these records from MS-DNS.
SRV records
A central part of Windows networking is that domain controllers (DCs) need to advertise
services by putting SRV records into DNS. SRV records are a resource record type to associate a service name with a server’s hostname. Windows clients query SRV records to
find out which servers offer particular network services. For example, Windows domain
controllers provide LDAP and Kerberos services for clients to use, so the SRV records for
LDAP and Kerberos maps the service names to the hostnames of the domain controllers
which provide the services. SRV records need to get into DNS quickly– not by manual
entry from the VitalQIP graphical user interface (GUI) – and they need to propagate to all
other DNS servers quickly.
DNS Records Used for Active Directory
Each DNS domain that supports Windows services needs to have some specific records.
The first thing needed is an A record to resolve the name of the domain to the IP of each
Domain Controller. For example:
company.com.
IN
A 10.1.1.1
company.com.
IN
A 10.2.2.2
The other special DNS records are dotted names under the domain name. Microsoft
networking uses special names which have underscores, such as “_ldap._tcp.comany.
com”. The middle parts of these names include:
• _msdcs for the MS domain controllers – usually created as a separate child domain
with its own SOA record and name server (NS) records.
• _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
For example:
_kerberos._tcp.company.com. IN SRV 0 100 88 server1.company.com.
_kpasswd.udp.comany.com. IN SRV 0 100 464 server1.company.com.
_gc._tcp.default-first-site._sites.company.com. IN SRV 0 100 3268 server1.company.
com.
_ldap._tcp.dc._msdcs.company.com. IN SRV 0 100 389 server1.company.com.
2
Besides the SRV records, special CNAME records called Globally Unique Identifier (GUID
records are used. These have long hexadecimal strings pointing to the hostnames of
domain controllers. For example:
73f53af0-e116-443d-acaf-6e71dfa5fd49._msdcs.company.com. IN CNAME server1.
company.com.
Windows 2003 or higher also has ForestDNSZones and DomainDNSZones concerning
LDAP replication between the domain controllers. The A records for each of these point
to the domain controllers with those partitions. Also there are also SRV records concerning the services available for these. For example:
ForestDNSZones.company.com. IN A 10.1.1.1
_ldap._tcp.ForestDNSZones.company.com. IN SRV 10 100 389 server1.company.com.
What is a Domain Controller?
A Domain Controller is a system running a version of Microsoft Windows Server that has
the Active Directory Domain Services role. This means that it has an LDAP data store
(DFS File system and DFS Replication), as well as Kerberos Key Distribution Center, Net
Logon service to allow Windows clients to login, and other services. Some – but not
necessarily all – domain controllers in a traditional Microsoft network would also have
DNS service installed, and some might also have DHCP service.
3
SUPPORTING WINDOWS CLIENTS
WITH ALU DNS AND DHCP
Resource Records for Domain Controllers
Updating SRV and CNAME records in ALU DNS primary servers
If Windows 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 clients need to be able to locate network services by querying SRV records in
DNS and then resolving those server hostnames to IP addresses. Likewise, GUID CNAME
records need to be updated in DNS quickly for Windows clients to find network services.
SRV records are created and maintained by Microsoft domain controllers. The SRV
records are created when the domain controllers come online and periodically thereafter,
and deleted when the domain controllers do proper shutdowns. To determine which DNS
server is to be updated, the domain controller first sends an SOA query to the IP address
configured in its local TCP/IP properties as the Preferred DNS server. Then, DNS looks
at the SOA record to see which DNS server is identified as the primary server for that
domain or reverse zone, and sends the Dynamic DNS (DDNS) transaction to that server.
In a traditional Microsoft design, the servers than run Active Directory Domain Services
often also run Microsoft’s DNS Service – in other words they are both domain controllers
and DNS servers. But this is not required, nor is MS-DNS. domain controllers can send
updates to any DNS server able to receive RFC 2136 DDNS updates, for example, any
server based on BIND 9.xDNS servers can accept updates from the domain controller if
allow-update permissions for the appropriate domains and reverse zones have been set
to include the IP address of the domain controller.
In theory, SRV records can be entered through the VitalQIP GUI and then pushed to
DNS, but this is difficult to do in a timely manner. It is usually better to add the domain
controllers to the allow-update Access Control List (ACL) of the appropriate domains in
Alcatel-Lucent DNS so that they can dynamically add or delete the necessary records.
The next step is the connection from Alcatel-Lucent DNS to the VitalQIP database:
Updates of resource records from ALU DNS to VitalQIP
In a classic VitalQIP environment, the VitalQIP database is the “master” source of
information, and DNS Generation pushes copies of its data to the DNS servers. In a
Windows environment, however, the DNS servers receive dynamic updates of SRV and
other resource records that the VitalQIP database does not know about – the data needs
to flow from the DNS server to VitalQIP as well. If the DNS servers receive updates from
DCs and/or Windows clients, but VitalQIP does not have this data, DNS Generation will
replace the zones that have the current SRV records with new zones that lack the current
information. If that occurs, the network clients will not be will be unable to locate
network resources until the DCs publish their SRV records again.
Data can flow from DNS to the VitalQIP database either by the External Updates feature
of Alcatel-Lucent DNS (the continuous method), or by the qip-syncexternal commandline interface (CLI) command (the polling method). External updates are much faster and
more efficient than running qip-syncexternal, and are preferred when using ALU DNS.
The qip-syncexternal CLI is only needed for MS-DNS or other non-ALU DNS.
4
External Updates are enabled in the VitalQIP GUI, in the zone options of those domains
and reverse zones that are expected to receive updates from DCs. The policy setting is
called Import External Updates. If External Updates are enabled, then the GUI selects
the specific types of resources records. Only SRV and CNAME records should be enabled.
Figure 1: Import External Updates in the VitalQIP GUI
Each Domain Controller also needs two A records, but these usually can be entered
manually. One A record is for its own hostname pointing to its IP address, and one A
record is the domain name pointing to the IP address. To implement this in VitalQIP,
create a static IP object for the domain controller’s hostname, and an additional A record
on the DNS Resource Records tab of either the Object Profile or Domain Profile. For
example, a static IP object can be created for “Server1.company.com” at the IP address
10.1.1.1, and then the Resource Records tab should have a second A record: company.
com. IN A 10.1.1.1
ALU DNS servers with External Updates enabled create messages for the VitalQIP
Message service whenever they receive dynamic updates from non-QIP sources. The
messages are of the “DNSUpdateRR” type. Message Service then passes them to the
destinations configured in the Message Routes. There should be one Message Route for
DNSUpdateRR messages to go to the QIP Update Service on the Enterprise server so the
new records will be added to the VitalQIP database. In addition, if there are multiple DNS
primary servers for these domains, a second DNSUpdateRR message route should point
to the DNS Update Service on the E/S so that other DNS primary servers will be updated.
(Note: QIP updates from DNS sources are not automatically forwarded to DNS Update
Service; that is only for QIP Updates from DHCP servers.) The qip.pcy of a DNS server
should have message routes similar to:
5
MessageRoute=DNSUpdateRR:A:0:QIP Update Service (Update RR):VitalQIP QIP Update
Service:<ip_address_of_Enterprise server>
MessageRoute=DNSUpdateRR:A:0:DNS Update Service (Update RR):VitalQIP DNS
Update Service:<ip_address_of_Enterprise server>
The above information and more is also discussed in the white paper “Dynamic Update
Configuration”.
Use of primary/secondary DNS servers and zone transfers
Differences between ALU (or BIND) DNS and MS-DNS:
In most VitalQIP installations, one DNS server is a master (primary) for a particular
domain and other DNS servers might be slaves (secondary). This contrasts with the multimaster configuration recommended by Microsoft, in which all DNS servers are master for
the zone and LDAP replication keeps the data consistent. MS-DNS servers are usually also
Domain Controllers . This means that they , which have a local copy of the LDAP repository containing the DNS data, as well as other AD-related information. Either approach
works, as long as DDNS updates and/or zone transfers reach all necessary DNS servers.
Multi-master DNS for ALU DNS:
VitalQIP can support multiple primary ALU DNS servers for any zone, but it is less
common than in MS-DNS and is not recommended except in special cases. ALU DNS
servers that are primary for the same zone can pass updates between each other via the
VitalQIP Enterprise server. The zones need to have External Updates enabled, the DNS
servers need to have message routes to VitalQIP DNS Update Service on the E/S. Then
DNS Update Service can forward each dynamic update to the other primaries for that
zone. Caveats for multi-master DNS include:
a.DNS Generation should be minimized in a multi-master design, because it only goes to
one master and it will be at least slightly out of synch with the other masters.
b.DNS Generation should be done to each of the master servers as closely as possible to
the same time
c.Do not deploy dynamic zones that have one primary DNS server on MS-DNS and one
primary DNS server on ALU DNS – they will be unable to replicate with each other.
Recovery from an offline DNS primary server:
If a DNS primary server goes offline, the Windows clients would still have correct DNS
resolution from the secondary DNS servers, but the DCs won’t be able to make updates in
DNS. Therefore, the resource records for AD will become increasing stale if the primary is
offline for an extended period. The domain controllers are unable to update a secondary
server, and might not be able to update an alternative primary server either, unless they
have an SOA record identifying it. However, a DNS server can easily be reconfigured
from a secondary to a primary in the zone profile in VitalQIP, and DNS Generation to the
newly-promoted primary server fixes the problem. Of course, downtime for production
DNS servers should be avoided as much as possible; high-availability hardware might
help. See the Alcatel-Lucent Disaster Recovery white paper for more details.
Having two primary servers, therefore, does not really provide fault tolerance by itself. In
most cases, it is best to assign one DNS server as the primary and other ALU DNS servers
as secondaries.
6
Primary/secondary for ALU DNS:
Windows clients require resource records for Active Directory be as up to date as possible – records that are refreshed once every six hours are unacceptable. Any zones
which contain SRV records should have Notify set to Yes. This causes the DNS primary
server to immediately notify all secondary servers upon any change, and the secondary
server requests an incremental zone transfer (IXFR).
Though Notify=Yes can be set in the Zone options in VitalQIP, setting it in Server/Zone
Options is better. In the Domain Profile of an AD-related domain, first set a reasonable
Refresh Time, such as 900 seconds (15 minutes). Then go to the Zone Options Tab, and
set the zone options such as allow-transfer and allow-update as appropriate. The GUI
has separate settings for each type of DNS – be sure to set the zone options for all types
that might eventually be used someday. Set Notify to No as the zone default, since the
zone will have multiple secondary servers but only one primary sever, and the secondary
servers should not send Notify messages to each other.
Figure 2: ALU DNS Zone options
7
After saving the changes on the Zone options tab, assign the Primary DNS Server on the
DNS Server tab. Under that assignment, the zone options can be customized, and the
important customization for the DNS Primary server should be Notify=Yes. Then save,
and assign the secondary servers – they can all keep the zone defaults. DNS Generation
to the primary creates a named.conf with a master zone statement with Notify yes; DNS
Generation to a secondary creates a named.conf with slave zone statements with Notify
No. Likewise, allow-transfers can be None for secondaries and set to a correct allowtransfer ACL for just the primary.
Figure 3: ALU DNS Server/Zone options
Resource records for ALU DHCP clients:
Getting DHCP hostnames into VitalQIP and DNS
In many organizations, DHCP clients need to perform reverse lookups of their own
hostnames in DNS to verify their IP addresses. In an ALU DHCP environment, the message flow is as follows:
1 The DHCP clients register their names in the DHCP server when they get leases.
2 Whenever an ALU DHCP server has DHCP lease activity, it generates messages to the
VitalQIP Message Service (according the DHCP policy UpdateQIP).
3 The Message Service has a message route to send DHCP messages to the VitalQIP QIP
Update Service, which is usually on the Enterprise server.
4 The QIP Update Service can then check the database to be certain that the new DHCP
client hostname does not conflict with an existing static IP object’s hostname (such as
“www”) of the same domain.
5 The QIP Update Service has the policy UpdateDNS set to True by default, in which
case it forwards those updates to the DNS Update Service, via the VitalQIP Message
Service for type DNSUpdateObject.
8
6 The VitalQIP DNS Update Service sends DDNS updates to the DNS primary server.
7 Then the DNS primary server has IXFR zone transfers to secondary DNS servers.
Figure 4: Typical VitalQIP management of Windows Clients using ALU DNS and ALU DHCP
E/S
Pushes
Dynamic
Updates
Pushes
EDUP
Updates
ALU
DHCP
ALU
DNS
Dynamic updates
SRV, CNAME
DORA
Windows
Clients
Windows
Logons
Domain
Controller
Getting DHCP clients into DNS (Use of DHCP Option 81)
By default, an Alcatel-Lucent DHCP server registers the client hostname in the domain
associated with the IP object in the VitalQIP database. A Windows client, however, can
also be configured locally with its own domain, which does not necessarily match the
domain configured in VitalQIP. That domain name is passed to the DHCP server in DHCP
Option 81 (client fully qualified 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, should be done 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 configured in VitalQIP. The setting of Suppress works well when each subnet is in only one
domain and where the users who configure desktop systems do not necessarily understand the DNS infrastructure. This is the default because it is the most common situation
for VitalQIP customers. There may, however, be some cases where it is advantageous to
use the domain requested by the client, if it exists. This can be accomplished by setting
the Option81Support value for the Alcatel-Lucent DHCP server to the appropriate value
(Client, Server, or Ignore)
• “Client” sets the flags in the option 81 data of the outgoing DHCP Offer and
acknowledgement (ACK) packets to allow the DHCP client to update its A record while
the server updates the PTR record.
• “Server” sets the flags in the option 81 data of the outgoing DHCP Offer and ACK
packets to tell the DHCP client that the server will update the A and PTR records.
• “Ignore” precludes echoing the option 81 data in the outgoing DHCP Offer and ACK
packets, which causes some Windows DHCP clients to update their own A and PTR records
9
Figure 5: Option 81 Support
E/S
Client
DHCP
dhcpd.conf
DB has D-DHCP:
10.1.2.3
udp00123uds.company.com
Discover
Push
company.com
No IP
Name=JoesPC
MyDomain.com
Offer
dhcp.db
10.1.2.3
JoesPC.???
???
JoesPC.???
Update
Req
Ack
If “Option81Support” is set to Suppress (default), then “???” = “company.com”
If Option81Support is set to Client, Server, or Ignore, then “???” = “MyDomain.com”
(difference between Client, Server, and Ignore is only the source of the updates to DNS)
Resource records for Windows clients with static IP addresses
Allow or not allow DNS registration of static clients?
Devices whose IP addresses are statically configured are often important servers or
network printers. They don’t use DHCP, but their IP addresses need to be in DNS. In a
traditional VitalQIP environment, static IP objects are created in the VitalQIP GUI, which
then puts their A and PTR records into DNS. But as discussed, many devices, such as
Windows servers, also try to register their own IP addresses in DNS. In Windows, this is
controlled by the Windows registry setting “Register this connection’s address in DNS”.
Some non-Windows clients also try to emulate this Windows behavior.
VitalQIP administrators can choose whether or not to allow these registrations, by setting
“Allow-update” permissions for each zone in DNS. Updates from DCs will be from
known IP addresses, but DNS needs “Allow-update=any” if the administrator wants to
allow any device to plug into the network and get into DNS automatically.
The advantages of “Allow-update=any” are:
1.The VitalQIP administrators don’t need prior notice of new servers and printers before
they come online, and don’t need to take the time to create static IP objects.
2.The devices can unregister themselves if they go offline with proper shutdowns –
whereas static objects in VitalQIP might remain and use up IP addresses for years if
device owners don’t report it.
3.It is more like a traditional Microsoft-centric network.
The disadvantages are:
1.There is no protection against users having device names that conflict with other IP
addresses. For example, if any Windows user renames his computer as “www”, the
name in DNS would become indistinguishable from a corporate website.
2.More load is created on DNS and VitalQIP to process many external updates to DNS.
3.Incorrectly configured devices can erroneously delete correct records.
10
4.Hackers could easily make changes to DNS to redirect names such as “www” to their
own systems. (GSS-TSIG secure zones as well as allow-update permissions are needed
to fully prevent this, but allow-update permissions alone will help greatly).
For most customers using Alcatel-Lucent DNS, the disadvantages far outweigh the
advantages, so they do not put “allow-update any” for their zones in DNS. For customers
using MS-DNS with GSS-TSIG secure zones, problem #1 (above) is not overwhelming –
there is some protection against duplicate device names due to its concept of ownership
of resource records.
In solutions that use Alcatel-Lucent DNS, therefore, the best-practice is to not allow
updates from static devices. That means VitalQIP administrators need to create static IP
objects for each domain controller, and each of them should have at least two A records:
one for its real hostname, and one for the domain name to point to its IP. Other types of
servers and printers that need fixed static IPs also need static IP objects, and customers
need to have some business process for VitalQIP administrators to know about these
systems before they are put onto the network.
Understanding Internal, External, and Partially-managed IP objects in VitalQIP
For special cases in which customers have some control over the end-user devices
and really want them to automatically register in ALU DNS without intervention from
VitalQIP administrators, VitalQIP has special object types.
When any IPv4 object is created in VitalQIP – either static, Manual-DHCP, or DynamicDHCP – it is given an object class, such as Workstation, Printer, Server, Undefined, etc.
These are collectively considered as Internal objects. Any of these internal Object Classes
could be used for either static or dynamic IP objects. In solutions with ALU DNS following the best practices discussed above, all IPv4 Objects have one of the internal Object
Classes. These Objects can be modified only via VitalQIP– either the GUI or a CLI, or
automatically by QIP Update Service in response to DHCP activity.
With an alternative design, however, DNS can receive dynamic updates from external
sources to create A or PTR records for IPs that don’t yet exist in VitalQIP. If the zone
has external updates enabled for A or PTR records, and if the devices are in a subnet
that is managed by VitalQIP, then VitalQIP is updated with new IPv4 objects for the IP
addresses that already exist in DNS. These are created as IPv4 objects with an object
class set to External. As long as they remain External objects, they can only be modified
via dynamic updates to DNS, with DNS then passing the updates to QIP.
In other words, devices that are A) running Windows, B) configured to register in
DNS, and C) have static IP address send dynamic updates to DNS. If DNS allows these
updates, it creates A and PTR records for them. Then, if it is ALU DNS with Import
External Updates enabled for A and PTR records, it sends updates to VitalQIP, which
results in External objects.
11
Figure 6: DNS Registration of Static Windows Clients (if allowed)
E/S
Pushes
Dynamic
Updates
EDUP
ALU
DNS
Dynamic updates
A, PTR
Dynamic updates
SRV, CNAME
Windows
Clients
Domain
Controller
VitalQIP also has Partially- managed objects. These are created in VitalQIP like static IP
objects and pushed to DNS like static objects to provide the initial hostname. If, however,
the devices later register in DNS and change those records, then updates to them are
accepted by VitalQIP. This allows the users of that device to change the hostname at a
later time without VitalQIP administrator intervention.
Figure 7: Sources of updates to each object type in VitalQIP
Vital QIP Database
Hostname
A checkbox
PTR checkbox
Hostname
DHCP
DHCP object
messages
ALU
DHCP
qip-qipupdated
Static object
GUI
or
CLIs
Hostname
A checkbox
External object
Partially-managed
object
DNSUpdateRR
messages
PTR
checkbox
ALU
DNS
AFXR
qip-syncexternal
MS
DNS
Solution Implementation
Implementing a typical solution using ALU DNS and ALU DHCP
1 Review the design decisions discussed above.
2 The global policy settings for DynamicDNS should have Static DDNS Updates set to
True, Use DNS Update Service set to True, and Update Secondaries set to False. The
Global Policy “FirstIn-LastIn” should always be set to LastIn.
12
3 In the VitalQIP GUI, create any additional networks, subnets, domains, or reverse
zones necessary to support Windows, beyond what already exists in your VitalQIP
infrastructure.
4 In the VitalQIP GUI, enter the Windows domain controllers as static IP objects.
5 On the Resource Records tab of each static object of a domain controller, or on the
Resource Records tab of the domain, enter an A record for the domain name to
resolve to the IP address of each domain controller.
6 On the zone options tab of the domain profile of each domain that will have
AD-integrated Windows clients, open the zone options for the correct DNS server type
and set correct values. Import External Updates should be enabled for but only for
SRV and CNAME records. Set the allow-update to Use List, and the list should be the
IPs of the VitalQIP E/S and all domain controllers. Set Notify to No at the zone level.
Then, on the Servers tab, change Notify to Yes just for the DNS primary server as an
override of the zone default. There should usually be one primary server and multiple
secondary servers.
7 Set the correct zone options and server/zone options of each reverse zone that will
have AD-integrated Windows clients. These should be the same as the domains,
except that import external updates should be disabled for reverse zones.
8 Set the options and message routes in the qip.pcy file on the Enterprise server and all
Remote servers as mentioned above:
• Each DHCP server should have a DHCP message route to QIP Update Service on
the E/S
• Each Alcatel-Lucent DNS servers should have a DNSUpdateRR message route
to the QIP Update Service on the Enterprise server. (The DNSUpdateRR message
route to DNS Update Service is needed only if there are zones with multiple
primary servers.)
• 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.
9 Arrange a cut-over time.
10 At the appropriate time, assign the domains and reverse zones to the correct DNS
primary and secondary servers. (Do not do this too far in advance of the actual
change on the servers, since the VitalQIP assignments affect dynamic updates
immediately).
11 Perform DNS and DHCP Generation to all servers.
12 Verify thatWindows clients are getting their hostnames into DNS, and that they can
access the necessary SRV records.
Non-managed MS-DNS for a child domain
Some VitalQIP customers prefer to have Microsoft AD only loosely integrated with
VitalQIP. In this type of design, MS-DNS servers have separate domains that contain
the SRV records in addition to any DNS registrations from clients. The ALU DNS servers
might have child-zone delegations or forwarding to or from MS-DNS servers. The ALU
DNS servers can be designated as secondary servers for the zones hosted by the MS-DNS
servers, or vice-versa.
VitalQIP has a “non-managed DNS servers” feature, which means entering the IP address
and zone information for a DNS primary server for which a VitalQIP DNS server will
13
be a secondary. This translates to a slave zone statement in the named.conf when
DNS Generation is performed to the VitalQIP DNS server. This is appropriate when the
VitalQIP database does not have any IP objects or other records for the domains and is
not expected to send any updates.
Figure 8: Non-managed MS-DNS for a child domain
E/S
Pushes
Dynamic
Updates
Pushes
EDUP
Updates
ALU
DNS
ALU
DHCP
(company.com)
Zone
Transfers
DORA
Windows
Clients
Dynamic
updates
MS-DNS
(ad.company.com)
Dynamic
updates
Windows
Logons
Domain
Controller
14
MANAGING MS-DNS WITH VITALQIP
Benefits of adding VitalQIP to existing Microsoft infrastructure
Even if an organization is already running a Microsoft Windows network using
MS-DHCP, MS-DNS, and all of Microsoft’s recommendations, you can add VitalQIP to
provide a central management point. VitalQIP is highly interoperable with third-party
software such as MS-DNS and MS-DHCP, so it can easily provide centralized management for these systems. 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 IP address spaces holistically
• Manage networks centrally or in a distributed fashion
• Manage subnets and IP addresses
• Manage DNS and DHCP servers from a central location, regardless of the vendor or
platform
• Report and audit DNS and DHCP changes
• Manage administrators and their capabilities at a very granular level
• Define policies to ensure consistency throughout networks
• Operate in a mixed platform environment
• Perform error checking to ensure networks and servers are properly defined and
overlapping scopes are not present
How is MS-DNS different from ALU DNS or BIND DNS?
All DNS servers are based on the Internet RFCs for DNS, but there are important differences between DNS servers. ALU DNS is based on ISC BIND DNS, though it has
extensions such as External Updates that allow it to work better in a VitalQIP environment. MS DNS – as used in Windows Server 2003 and Windows Server 2008 – however,
has some important differences. The following sections explain some of the differences
that are important to VitalQIP management of MS-DNS.
Relationship with active directory domain services
MS-DNS is tightly integrated with Microsoft AD. A Windows server has Roles, and
each Role consists of Services. When a Windows server has a Role of Active Directory
Domain Services, it is a Domain Controller. It has a few services which provide it with
the AD database, replication of data to other domain controllers, Netlogon Service to
allow Windows clients to login to the domain, and Kerberos Key Distribution Service to
provide security. “DNS Services” is a separate Role for a Windows server, but Microsoft
strongly recommends that it be installed on the same server as AD Domain Services. This
is because MS-DNS does not keep zones and configuration data in flat text files (as BIND
and ALU DNS does), but instead keeps data in the same distributed datastore that holds
the User and Computer information. The AD database is based on LDAP and is organized
in partitions that replicate between domain controllers. Microsoft Windows has several
GUIs to manage the data in AD, such as Active Directory Users and Computers; AD Sites
and Services; and AD Domains and Trusts. The Microsoft DNS Manager GUI is a similar
tool to directly manage DNS data which is in the AD database.
15
AD replication between DNS servers
Because DNS data is part of the AD datastore, it is replicated between all domain controllers via remote procedure calls (RPCs). This means that all MS-DNS servers are primary
DNS servers for the domains that are in AD. If one MS-DNS server for an AD domain is
dynamically updated, then all of the other MS-DNS servers for that domain are automatically updated as well.
MS-DNS servers can still have slave zones pulled from other servers and can still send
zone transfers to other servers, but MS-DNS servers with site links for replication don’t
need to perform DNS zone transfers between each other.
Ownership of resource records
In BIND or ALU DNS, each DNS resource record is saved as a line in a flat text file. But
in MS-DNS, resource records are elements in the AD database. Each record has ownership and permissions, much like files in a Windows file system. These can be seen by
right-clicking and selecting Properties in Microsoft’s DNS Manager. Important resource
records in DNS are protected against change by Windows users who lack permissions to
make such changes.
Figure 9: Resource Record level security in MS-DNS (using Windows Server 2008R2 DNS Manager)
Secure zones and lack of allow-update ACL
In BIND or ALU DNS, each zone has Allow-update permissions. Allow-update can be set
to none, any, or use list. If it is a list, the list specifies the IPs allowed to send updates for
each zone. Optionally, zones can also have TSIG or GSS-TSIG security to authenticate
16
the updater. But, because MS-DNS has the owners and permissions for each resource
record that are based on Windows users, it does not have any allow-update list based on
IP addresses. In MS-DNS, each zone can have Dynamic updates set to none; secure and
non-secure (same as “allow-update=any”); or secure only. The setting “secure only”
uses the Kerberos which is built into all Windows systems to authenticate the updater
via GSS-TSIG. In other words, the identity of the client that sent the dynamic update is
confirmed by a domain controller. The client computer that sent the update is associated
with a Windows user account, and the permissions associated with the Windows user
account are compared with the permissions of the resource record being updated in DNS.
GSS-TSIG and secure updates are discussed in more detail in the next chapter.
Interactions between VitalQIP and MS-DNS
VitalQIP is an IP address management (IPAM) tool, which can manage multiple DNS and
DHCP remote servers. The DNS servers can be any mix of ALU DNS, third-party BIND
9.x DNS, and MS-DNS. “Management” can mean getting data from the remote servers
to display in the IPAM GUI, creating zone files and configuration files for DNS, and
sending updates to DNS. Some, but not all of these functions require VitalQIP services to
be installed on the DNS servers. The following discussions explain the various ways in
which the VitalQIP Enterprise server can interface with MS-DNS.
Use of qip-syncexternal to pull data from MS-DNS into VitalQIP
MS-DNS gets data from several sources: domain controller that are advertising services;
perhaps Windows static clients registering in DNS; perhaps MS-DHCP servers sending
updates to MS-DNS based on DHCP activity; and perhaps Windows administrators making entries into the Microsoft DNS Manager GUI. For VitalQIP to function as an IPAM,
that data needs to be in the VitalQIP database as well.
VitalQIP has the qip-syncexternal CLI command for this purpose. 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 as necessary. Because it
uses standard AXFR zone transfers, it does not require Alcatel-Lucent DNS. Almost all
DNS servers, including all Microsoft and BIND DNS versions so far, support AXFR zone
transfer and, therefore, work with qip-syncexternal. This CLI is run from an Enterprise
server or a distributed server console, and its IP needs to be in the allow-transfer permissions of the DNS server from which it pulls data.
For VitalQIP to be able to process the data from the zone transfer that is the first part of
qip-syncexternal, it must have a DNS server profile of the DNS server, and it must have
zones that match the zones on the DNS server. The zones on the MS-DNS server might
include a “_msdcs” child zone of the main AD zone – for example “_msdcs.company.
com” – which might have its own SOA record. If so, that zone should also be defined in
VitalQIP. But the resource for _tcp, _udp, and _sites are usually just dotted names under
the parent domain, not separate child zones, so they should not be separate child zones
in VitalQIP either (a change from previous Alcatel-Lucent recommendations). Likewise,
the resource records for forestdnszones and domaindnszones in Windows 2008 should
also not be separate child zones.
The qip-syncexternal CLI can be run manually, or scheduled via “cron” or some other
scheduler; or run automatically via a user exit script.
17
Figure 10: Domain Controller updates and DNS registration
Windows 2000
Client/Domain
Controller
Client
MS
DNS
qip-syncexternal
MS
DNS
MS
DNS
VitalQIP
database
External objects in VitalQIP for MS-DNS clients
In general, qip-syncexternal puts the new resource records to the Resource Records tab
of the domain profile or reverse zone profile in VitalQIP. For A and PTR records whose
IPs are within VitalQIP-managed subnets, however, it will create or update IPv4 Objects
of type External. These objects can only be changed via dynamic updates to DNS, unless
VitalQIP administrators first change them to internal.
Figure 11: (also used in the previous section) Sources of updates to each object type in VitalQIP
Vital QIP Database
Hostname
A checkbox
PTR checkbox
Hostname
DHCP
DHCP object
messages
ALU
DHCP
qip-qipupdated
Static object
GUI
or
CLIs
Hostname
A checkbox
External object
DNSUpdateRR
messages
PTR
checkbox
Partially-managed
object
ALU
DNS
AFXR
qip-syncexternal
MS
DNS
Two types of DNS Generation to MS-DNS
DNS Generation from VitalQIP to an ALU or BIND DNS server involves creating zone
files for some or all of the master zones, as well as the configuration information such as
the named.conf. It requires two selections:
• Type: Update or Configuration and Data
• Target Zones: All Zones, Selected Zones, or Changed-Zones Only
“Update” means that the files are produced and then DNS will reload. “Configuration and
Data” lacks the reload at the end.
18
DNS Generation from VitalQIP to an MS-DNS server is different, however, since MS-DNS
doesn’t really have zone files. DNS Generation to an MS-DNS server also requires two
selections but one of them is different:
• Type: All Records or Changed Records Only
• Target Zones: All Zones, Selected Zones, or Changed-Zones Only
DNS Generation of All Records means VitalQIP sends entire zones to the MS-DNS server
and also creates dnscmd commands telling the MS-DNS server to delete all the existing
resource records from the AD database and replace them with new records. (In some
VitalQIP versions before 8.0PR2, this is called a “Configuration and Data” push even
though its operation to MS-DNS is very different from its operation to an ALU or BIND
DNS server). DNS Generation of Changed Records Only (previously called “Update”)
pushes only the changed resource records for each zone.
DNS generation of “Changed Records Only” can be considered as a reverse of qipsyncexternal. Both involve an AXFR zone transfer from MS-DNS and comparing the zone
transfer to the VitalQIP database. But qip-syncexternal updates the VitalQIP database
(for external objects) whereas DNS Generation with “Changed Records Only” updates
MS-DNS. This selection is independent of the “Changed Zones only” selection, which is
based on database flags on each zone.
When a changed records only DNS Generation is performed, the RMI QAPI process on
the Enterprise server creates add.delta files and delete.delta files, which are lists of the
resource records that were in VitalQIP but not in MS-DNS, or vice-versa. The VitalQIP
Remote Service then transfers them to the MS-DNS server, Then MS DNS Update Service
updates the local MS-DNS Service based on these files.
An All Records DNS Generation to an MS-DNS server should be performed only under
special circumstances, such as setting up a new DNS environment. It should not be
performed on any existing MS-DNS server unless a) qip-syncexternal has already been
run; and b) AD replication is turned off.
19
Figure 12: Static IPs for MS-DNS Secure Zones
VitalQIP GUI
VitalQIP
database
Enterprise server
File Generation
Service
Changed records only
Remote Server/
Domain Controller
VitalQIP
Remote Service
VitalQIP MS DNS
Update Service
MS DNS
Dynamic updates to non-secure zones in MS-DNS
The current best-practice is to only perform DNS generation rarely, and instead rely on
dynamic updates from VitalQIP to DNS. This is even more important for MS-DNS than
for ALU DNS. If MS-DNS has a master zone with dynamic updates set to “Secure and
Non-secure”, and if VitalQIP has associated that server to that zone, then VitalQIP generates dynamic updates to MS-DNS whenever there are DHCP-related changes to the zone,
or whenever VitalQIP administrators make changes through the GUI or CLIs. The updates
are sent by VitalQIP DNS Update Service/qip-dnsupdated, and the process is exactly the
same as with ALU DNS remote servers.
Dynamic updates to non-secure zones do not require any software to be installed on the
MS-DNS server.
Dynamic updates to secure zones in MS-DNS
If the zone has dynamic updates set to “secure only” in MS-DNS, then the process is
more complex.
When the VitalQIP Enterprise server processes updates from DHCP clients, or from the
VitalQIP GUI or CLIs, then VitalQIP DNS Update Service on the Enterprise server knows
which DNS servers need to receive dynamic updates, and if those zones are on MS-DNS
and/or are secure zones. If it is a secure zone on MS-DNS, the VitalQIP DNS update
service on the enterprise server does not attempt to send dynamic updates directly to
MS-DNS, but rather sends messages to VitalQIP MS DNS Update Service running locally
on the MS-DNS server via the VitalQIP Message Service. This is a conduit request; no
Message Route is needed.
GSS-TSIG secure zones and the VitalQIP MS DNS Update Service are discussed in more
detail in the next chapter.
20
Implementing VitalQIP management of MS-DNS servers
Deciding how VitalQIP interacts with MS-DNS
Plan carefully before performing any installations or changing any configurations. One
of the most basic questions is which zones will be hosted on MS-DNS, and what level of
management is needed from VitalQIP. Based on the above discussion of types of interaction between VitalQIP and MS-DNS, decide whether the zones in MS-DNS are to be
managed by VitalQIP. The MS-DNS servers could be handled in any one of the following
ways by VitalQIP:
1.Fully managed by VitalQIP, including the ability for DNS generation
2.VitalQIP able to send updates to any zones on MS-DNS, including secure zones
3.VitalQIP only able to send non-secure updates to MS-DNS
4.No updates from VitalQIP to MS-DNS, but VitalQIP still able to pull data from MS-DNS
5.Completely unmanaged by VitalQIP (potentially linked to VitalQIP-managed DNS
servers through DNS forwarding or child zone delegations or zone transfers)
The first two methods require installing VitalQIP components on the MS-DNS server.
The first four require creating a DNS server profile in VitalQIP and creating appropriate
permissions in MS-DNS.
Pre-configure MS-DNS to be managed by VitalQIP
The IP address of the VitalQIP Enterprise server must be added to the allow-transfer permissions for each existing MS-DNS zone for which qip-syncexternal or DNS Generation
will be run in the future. If dynamic updates from VitalQIP are required for any existing
zones, the Dynamic Updates settings for those zones should be set to “Nonsecure and
Secure” or “Secure only”. If set to “Secure only”, the GSS-TSIG secure zones section of
this paper provides more detail.
Installing VitalQIP Services on MS-DNS remote servers
VitalQIP installation should be performed on those MS-DNS servers that need to get DNS
Generation or secure dynamic updates from VitalQIP. Only minimal VitalQIP components
are needed:
• VitalQIP remote service, which handles DNS generation for any type of DNS/DHCP
remote server.
• VitalQIP message service which connects the remote server to the enterprise server.
• VitalQIP SSL tunnel service, to add SSL tunneling to message service if secure message
routes are defined.
• VitalQIP MS DNS Update Service (see below).
When the VitalQIP installation asks for features selection, only the remote server package
should be selected. The subcomponent remote service is required by the installer for any
remote service package – this includes the VitalQIP Message Service and SSL Tunnel
Service as well as the remote service itself. Then select “MS-DNS Support” as a second
component of the remote service package – this causes VitalQIP MS DNS Update Service
to be installed as well. Deselect ALU DNS component – ALU DNS cannot run on the
same server as MS-DNS. It is possible to support both MS-DNS and MS-DHCP on the
same server.
21
Figure 13: VitalQIP installation on an MS-DNS Server
What is VitalQIP MS DNS Update Service?
VitalQIP has a service that is installed only on VitalQIP Remote Servers running MS-DNS.
The VitalQIP MS DNS Update Service has two different functions:
a Processing add.delta and delete.delta files from changed-records-only DNS generation
for both secure zones and non-secure zones.
b Processing dynamic update messages from the Enterprise server for secure zones.
In either case, VitalQIP MS DNS Service updates the zone in MS-DNS on the same server.
MS DNS Update Service will first try to do a GSS-TSIG update, and then call dnscmd if
the update fails. Using both methods means that secure updates from the VitalQIP E/S
can be handled reliably and efficiently, without the Enterprise server needing to have
correct and up-to-date Kerberos keys. This should also make VitalQIP support of MS-DNS
secure zones more adaptable to future Windows releases.
This process uses a sec.dat file created from VitalQIP to obtain the security principal and the
zone information – though the security principal is used only for the GSS-TSIG updates and
is not needed to run dnscmd commands. The sec.dat file is created during DNS Generation
to an MS-DNS server, or it could also be copied manually. Please contact VitalQIP
Support or use the AskAL Knowledgebase for more details of configuring the sec.dat.
22
Figure 14: VitalQIP management of MS-DNS with secure zones
E/S
Pushes
Dynamic
Updates
VQIP MS-DNS
Update Service
qip-syncexternal
MS-DNS
Dynamic
updates
A, PTR
Dynamic
updates
SRV, CNAME
Windows
Clients
Windows
Logons
Domain
Controller
“Semi-managed” MS-DNS servers
Some customers prefer that MS-DNS servers be “semi-managed” by VitalQIP. In this
scenario the MS-DNS servers don’t have any locally installed VitalQIP components, but
VitalQIP is still able to run qip-syncexternal to pull data from them and still attempts to send
non-secure dynamic updates. In this case, the MS-DNS servers and their zones are entered
in VitalQIP as if they were managed. VitalQIP needs a DNS server profile with the correct
name and IP address, even if there won’t ever be any DNS Generation to the MS-DNS
server. Please consult with VitalQIP Support or Professional Services for more details.
Creating MS-DNS server profiles in VitalQIP
The VitalQIP GUI allows several types of DNS servers to be defined in VitalQIP. The supported version(s) of MS-DNS varies depending on the VitalQIP version – please refer to
your VitalQIP Release Notes to learn if the MS-DNS should be Windows 2003, Windows
2008(R2), or some other version of Windows. The correct name, domain, and IP address
of the MS-DNS server is always required. The Default Directory should always be
%systemroot%\system32\dns – but see the information in the Administrator’s Reference
Guide concerning 64-bit Windows.
The “Boot type” should be “Directory”, which means AD integrated. Once Boot Type
is set correctly, then “Secure DNS Updates” can be set to true or false. If “Secure DNS
Updates” is true, then zone assignments to this server can be changed to “secure”. If
VitalQIP is to send either DNS Generations or secure dynamic updates for those zones,
it needs to have appropriate usernames/passwords. The Windows user names are called
Principal Names. The user for Strong Kerberos Principal can be any Windows user who
exists in Active Directory Users and Computers under the applicable Domain (Realm).
The user for Proxy Kerberos Principal needs to be a member of the DNSUpdateProxy
Security Group. Please see the Administrator’s Reference Manual for more details.
23
Figure 15: Microsoft DNS server profile
Creating zone profiles in VitalQIP
VitalQIP requires domain profiles and reverse zone profiles of the zones managed by
MS-DNS before it can send updates or pull data from those zones using qip-syncexternal.
The MS-DNS server is assigned on the Primary/Secondary servers tab of each zone
profile. The Zone options tab of each zone has Windows 2000 Zone options, such as
allow-transfer and allow-query permissions, that are applicable to all MS-DNS servers but
not to ALU DNS servers. In addition, associating one particular server to one particular
zone can override the general zone options. MS-DNS secure zones are indicated here.
Note that VitalQIP has a policy “allow-update” (yes or no) and a checkbox for “Send
Secure Updates” which translate into the single MS-DNS policy “Dynamic updates” of
none, secure and non-secure, or secure only.
24
Figure 16: Zone/server options for MS-DNS
Considerations of 64-bit Windows
As of the end of 2013, the only 64-bit Windows for which VitalQIP can manage MS-DNS
or MS-DHCP is Windows 2008 R2. VitalQIP 7.3 or 8.0 can manage MS-DNS and
MS-DHCP on Windows 2003 and original non-R2 Windows 2008 only if they are 32-bit.
The new Windows 2012 is not yet supported by VitalQIP. VitalQIP is currently a 32-bit
application, and as such requires a “sysnative” path to be able to read MS-DNS and
MS-DHCP data from the Windows system directory. Please refer to the Administrator’s
Reference Guide for your version of VitalQIP for more details of how to do this.
Multi-master DNS
Since MS-DNS servers use AD, MS-DNS servers can replicate data with each other.
VitalQIP only needs to update one of them. If a zone has multiple primary servers, it is
best to avoid having secondary servers on more than one of them, since this may cause
serial numbers to become out of sync. Additionally, verify all primary servers for a given
zone are MS-DNS or that all are Alcatel-Lucent DNS; zone replication does not work if
the two types are mixed, since they use different methods.
Use VitalQIP GUI rather than MS-DNS manager
Once VitalQIP is configured to manage the MS-DNS server, administrators should refrain
from using the Microsoft DNS Manager GUI to enter records to DNS. Static IP objects
entered via VitalQIP are easier to manage and will have better error checking than
external objects created via the MS-DNS console and then processed via qip-syncexternal.
Conflicts might result if both GUIs are used.
25
GSS-TSIG SECURE ZONES
FOR ALU DNS AND MS-DNS
Vocabulary for secure zones
TSIG: (Transaction SIGnature)(RFC 2845) uses shared secret keys to securely identify
each endpoint of a connection as allowed to make or respond to a DNS update or
transfer.
GSS-TSIG: Generic Security Service for TSIG (RFC 3645): uses Kerberos services to
exchange keys rather than distributing the keys manually.
Kerberos: Works on the basis of “tickets” to authenticate nodes; used on domain
controllers.
KDC: Key distribution center, used in Kerberos. Kerberos key distribution center is a
service that runs on Windows servers that are Domain Controllers
DES: (Data Encryption Standard) legacy encryption used in original Windows, but not
accepted in Windows 2008 or BIND 9.7 by default.
RC4-MAC: Stronger encryption, default for Windows 2003 and Windows 2008.
AES128 and AES256: Strongest encryption supported in Windows 2008.
Allow-update permissions and secure zones
If all clients are allowed to update DNS, security is needed to prevent any client from
taking over the resource records of critical network resources, such as web servers. For
example, a general user should not be able create an A record for “www.company.com”,
when that name is already in use and associated with a static IP address. With ALU or
BIND DNS, this is prevented by setting allow-update to not allow general users to update
DNS directly, and by the fact that the QIP Update Service checks for such duplicates arising from DHCP and gives preference to the static IP address before sending the dynamic
updates on to DNS. In others, ALU and BIND DNS servers have an Access Control List
(ACL) for allow-update. With MS-DNS, unwanted updates are prevented by the use of
secure zones. The use of secure zones is a stronger solution that prevents hostile attacks
not just accidents, although it is more complicated to set up and use and requires more
resources for DNS. ALU DNS can use both allow-update ACLs and secure zones.
Other meanings of “secure zone”
Note that “secure zone” in other contexts can refer to TSIG secure updates to BIND DNS,
using manually generated and copied keys. It can also refer to DNSSEC, which, in short,
uses keys to authenticate data to DNS resolver clients. But within the context of AD
integration, “secure zone” implies GSS-TSIG and Kerberos.
How GSS-TSIG secure updates work
When a dynamic update is made to a secure zone on a DNS server, security verification
happens in (very simplistically) two stages. First the GSS-TSIG protocol verifies the
identity of the sender and the receiver, and validates the contents of the update have not
been tampered with. This stage uses Kerberos as the underlying security provider. Both
ALU DNS and MS-DNS use keys from a Windows KDC to authenticate the identity of
the system sending updates. All Windows systems that are members of the AD domain
are authenticated, as are non-Windows systems with appropriate keytab information.
MS-DNS – but not ALU or BIND DNS – then compares the identity of the updater to the
access control information for the resource record. Last, the DNS server adds or deletes a
record or a set of records from the zone.
26
When to use secure zones
GSS-TSIG security is more important when all IPs in a network are allowed to update
DNS than it is when only the Enterprise server and a few others systems have permission. Since MS-DNS does not have allow-update ACLs, its use is more common for
MS-DNS than for ALU DNS.
ALU DNS can use GSS-TSIG secure zones, which can be useful in special cases. If the
ALU DNS server has zones that have “allow-update” set to “any”, the GSS-TSIG security
will at least authenticate that the system sending the update has a key, such as having
logged into the Windows domain. GSS-TSIG security can also be useful for highly secure
environments, where hackers spoofing IP addresses inside the network is a realistic
threat, such that an allow-update ACL is insufficient security. Most VitalQIP customers
prefer not to use secure zones, however, since they add complication and overhead.
Internet-facing external DNS servers usually should not allow any dynamic updates, even
secure ones.
Key distribution centers (KDCs) and Kerberos keys
VitalQIP’s implementation of GSS-TSIG – like Microsoft’s – requires keys from a
Windows domain controller running Key Distribution Service (a KDC). An MS-DNS
server gets the keys automatically via the OS.
If the VitalQIP Enterprise server is Windows-based and is already a member of the AD
domain, then its DNS Update Service can get these keys automatically via the Windows
OS. For a Linux- or Solaris-based Enterprise server – or for any ALU or BIND DNS server
even if running on Windows – keys are obtained by running the Microsoft’s “ktpass”
utility on the KDC. Please see the VitalQIP Administrator’s Reference Manual for details.
Access control information for resource records in MS-DNS
As discussed in the previous chapter, AD keeps security information for each data item,
including every DNS resource record.
If the access control information does not forbid the updater from making changes to the
AD entry it is trying to modify, the update succeeds. At this stage, if the entry had no
security or did not previously exist, the access control information for the entry is updated
such that only the updaters (and administrators) are allowed to make changes to the entry.
There is one exception to this rule: when the updater is a member of a special security
group called DNSUpdateProxy. Objects created by members of the DNSUpdateProxy group
have no security; therefore, any authenticated user can take ownership of the objects.
Managing Windows secure zones with VitalQIP
VitalQIP does not attempt to store the access control information for each DNS record.
Therefore, the clients associated with these records do not own the records created by DNS
Generation from VitalQIP. Instead, records created by VitalQIP have one of two owners:
either the Strong Kerberos Principal, or the Proxy Kerberos Principal. VitalQIP uses the
Strong Kerberos Principal to create the records for Static IP objects, so that only VitalQIP
can update them. The Proxy account is used to create External or Partially Managed
Objects. This allows the clients themselves, or the MS-DHCP server, to take over ownership
of these records, and be able to update the records as changes occur. Records for dynamic
27
DHCP addresses can be generated with either the Strong Kerberos Principal or the Proxy
Kerberos Principal, depending on the value of the allow DHCP clients to modify dynamic
object resource records policy. If this is set to true, the records are associated with the
Proxy account and can be taken over by the DHCP clients. If, however, the policy is set
to false, the records are owned by the Strong account and only VitalQIP can update them.
Although this is a global policy, it can be overridden at a more granular level.
MANAGING MS-DHCP WITH VITALQIP
Differences between MS-DHCP and ALU DHCP
BOOTP/DHCP interchangeability
Bootstrap Protocol (BOOTP) is a legacy protocol used before DHCP, and still in use today
by a few older devices on some networks. MS-DHCP and ALU DHCP can both hand out
BOOTP addresses in addition to DHCP addresses, if necessary. ALU DHCP can give out
BOOTP addresses in two ways: either BOOTP objects are defined in VitalQIP and pushed
to the DHCP server, or the DHCP Policy “ShareAutoBootpAndDynDHCP” needs to be at
a non-default setting of “true”. MS-DHCP, however, treats DHCP and BOOTP addresses
interchangeably by default. Therefore, A-BOOTP and M-BOOTP objects should not be
defined for subnets that are pushed to MS-DHCP.
Terminology of types of IP addresses
Both MS-DHCP and ALU DHCP have dynamic DHCP scopes: any address in the scope
can be leased to any device in that subnet.
Both types of DHCP use the concept of reserving specific IP addresses for certain devices,
identified by their MAC address. In VitalQIP and ALU DHCP, this is called Manual-DHCP.
In MS-DHCP, this is called “reservations”. When VitalQIP performs DHCP Generation to
MS-DHCP, Manual DHCP objects are pushed out as reservations.
VitalQIP also has Automatic DHCP, which is similar to Dynamic DHCP with the exception that Automatic DHCP objects are, by default, assigned an infinite lease time. This
has no equivalent in MS-DHCP. Only Dynamic DHCP and Manual DHCP objects can be
pushed to MS-DHCP, not Automatic DHCP or either type of BOOTP objects.
All subnets have some IPs (e.g., router IPs) that should not be handed out by DHCP.
VitalQIP is an IPAM solution, so it has a few classifications of IP addresses that are not
DHCP and are not pushed to DHCP servers. These include static IPs which are in DNS
but not in DHCP, “reserved” IPs which are marked as in use but not pushed to either
DNS or DHCP, and unused addresses. (Note that “Reserved” has a different meaning
in VitalQIP than it does in MS-DHCP). When VitalQIP performs DHCP Generation to
ALU DHCP, the non-DHCP IPs in the subnets are not included in any way. The dhcpd.
conf has a list of subnets, and a list of Manual DHCP objects and Dynamic DHCP
scopes within each subnet. In MS-DHCP, however, the non-DHCP IPs are pushed out as
Excluded. All IPs in each subnet between the start address and end address are available
for any DHCP client except for those designated as “Reserved” or “Excluded”.
DHCP configuration files and lease databases
When ALU DHCP reloads after a push, the reload is fast because it is just loading the
dhcpd.conf and dhcpd.pcy are loaded. But when MS-DHCP reloads after a push, the
DHCP configuration is processed into AD via a series of netsh.exe commands that delete
28
the old configuration and create a new one. Therefore, it can take a long time if the
MS-DHCP server is large. Both ALU DHCP and MS-DHCP have local database files to
store the lease information: in ALU DHCP it is the text file dhcp.db; in MS-DHCP for
Windows 2008 it is the binary file %systemroot%\systems32\dhcp\Dhcp.mdb
No DHCP failover and access control
The VitalQIP concepts of DHCP primary and DHCP failover do not apply to MS-DHCP;
fault tolerance can be provided only with split-scope DHCP. Many other ALU DHCP
features – such as Access Control – are also not available with MS-DHCP or any other
non-ALU DHCP.
Authorizing MS-DHCP servers
Microsoft DHCP for Windows has a feature in which the DHCP Service queries the LDAP
data store (that is, AD) to see if it is authorized. It will fail to start if unauthorized, to
prevent “rogue” DHCP servers. Any user with a Windows installation media can install a
DHCP server with a few mouse clicks, even by accident, and that server could potentially
hand out IP addresses that conflict with the real DHCP server or with static IP addresses.
Only an administrator with the proper permissions, however, can authorize a DHCP
server in the AD database. Therefore, unauthorized Windows DHCP servers will not start
and become rogue servers.
Alcatel-Lucent DHCP doesn’t need authorization. It is designed to be configured and
managed by VitalQIP, and is not designed to be a stand-alone DHCP server. VitalQIP
ensures that DHCP servers with overlapping scopes are not deployed in the network.
VitalQIP, however, does create the authorization record in AD when it performs DHCP
Generation to a Remote server that is running MS-DHCP
Implementing VitalQIP support of MS-DHCP
VitalQIP installation on the MS-DHCP Remote Server
As with MS-DNS, a VitalQIP installation is required on the Windows server, but it is only
minimal services. All remote servers have VitalQIP Remote Service, VitalQIP Message
Service, and VitalQIP SSL Tunnel Service. The sub-component “MS-DHCP Support” adds
the qip-msextract utility and the VitalQIP MS DHCP Monitor Service.
Create MS-DHCP server profile in VitalQIP
The VitalQIP database requires basic information about each DHCP server before it can
perform DHCP Generation or process data from its leases. The Microsoft DHCP Server
settings in VitalQIP are mostly a subset of the settings for ALU DHCP, but there is a
setting “Active Directory server”. This is to create the AD authorization for the MS-DHCP
server. For details, see the Web Client User’s Guide chapter on DHCPv4 servers, which
explains the MS-DHCP type as well as ALU DHCPv4.
Migrating DNS and Sites data into VitalQIP
During early stages of a migration, it can be helpful to run qip-dnscsv to get data from
MS-DNS zones and to run the Microsoft LDIFDE utility to get the Sites and Subnets data
from AD. The data files created by qip-dnscsv are imported to VitalQIP using other CLI
utilities, such as “entersubnet” and “entersimpleobj”. The procedures to use qip-dnscsv
are explained in detail in Chapter 3 of the VitalQIP Command Line Interface Guide. The
data from LDIFDE can be read into VitalQIP using the qip-siteimport utility, which is
described in detail in Chapter 1 of the VitalQIP Command Line Interface Guide.
Some data might need to be edited or entered via the GUI after completing this process.
29
qip-msextract utility
When the VitalQIP environment is first set up, the qip-msextract utility can be used to
migrate the existing MS-DHCP DHCP scopes, reservations, exclusions, and current leases
into the VitalQIP database. This utility is installed as part of VitalQIP remote server
installation on an MS-DHCP server – it needs the VitalQIP library files and needs to run
the Microsoft utility “netsh.exe” locally on the DHCP server. It creates some text files
that can be read by other VitalQIP CLIs, which can put the information in the VitalQIP
database. Please refer to the AskAL knowledgebase “How to use the qip-msextract CLI”
or the “Advanced DHCP Configurations” chapter of the VitalQIP Administrator Reference
Manual for details. Note that the MS-DHCP Server profile, domains, and subnet profiles
must exist in VitalQIP before qip-msextract is run, because it will not create new subnets
automatically.
Defining new DHCP scopes for MS-DHCP in VitalQIP
Even if the previous information is migrated from AD to VitalQIP, some changes and
editing are likely necessary. All dynamic objects in the subnets associated with MS-DHCP
must be either “Dynamic DHCP” or “Manual-DHCP”. Manual-DHCP corresponds to
“Reserved” addresses in MS-DHCP terminology: the address is reserved for one specific
MAC address, and can therefore have a fixed hostname. MS-DHCP should not have more
than one DHCP template per subnet.
DHCP Generation to MS-DHCP
When the DHCP Server Profile, subnets, and other DHCP-related data are correct in
VitalQIP, it can perform DHCP Generation to done to the MS-DHCP server. This is a
series of netsh commands to give the DHCP a new configuration, though it keeps its
lease data for existing scopes.
Getting MS-DHCP client hostnames into MS-DNS
MS-DHCP can send secure dynamic updates directly to MS-DNS. If this is already working, then it is unnecessary to make any changes after introducing VitalQIP. Although
Windows clients are able to register their own hostnames in DNS by DDNS updates
directly from the client to the server, both Microsoft and Alcatel-Lucent recommend the
MS-DHCP server perform these updates. This allows all DHCP clients, not just Windows
DHCP clients, to have their hostnames in DNS. It also provides more security. The DHCP
server sends the DDNS updates to the DNS primary server for that domain and reverse
zone, potentially using GSS-TSIG secure updates.
MS-DHCP has several options for updating DNS that are similar to the “Option81Support”
policy of ALU DHCP. By default, it updates DNS on behalf of all its clients that send
DHCP Option 81 (Client fully qualified domain name [FQDN]) information, which is
mostly Windows clients. The updates go to the primary DNS server for the domain
requested by the client, not necessarily to the domain that is configured in VitalQIP.
MS-DHCP can be configured to send DDNS updates for all clients, not just those that
send Option81, in which case the MS-DHCP server assumes the client is the same domain
as itself. The various options are configured under Additional Policies in the MS-DHCP
Server profile in VitalQIP, as netsh commands to set dnsconfig options for DHCP. Please
refer to Microsoft documentation to find the correct netsh commands.
30
Figure 17: VitalQIP management of MS-DNS and MS-DHCP
E/S
Pushes
Dynamic
Updates
VQIP MS-DNS
Update Service
qip-syncexternal
MS-DNS
Dynamic
updates
A, PTR
Dynamic
updates
SRV, CNAME
Windows
Clients
Windows
Logons
Domain
Controller
Getting DHCP lease information into VitalQIP – VitalQIP MS DHCP Monitor Service
VitalQIP has a service to monitor MS-DHCP’s leases and send them to the VitalQIP
Enterprise server. In brief, the VitalQIP MS DHCP Monitor Service works by monitoring
the debug logs of Microsoft’s DHCP Service. It restarts MS-DHCP and turns this logging
on automatically, if necessary. The VitalQIP MS DHCP Monitor Service processes this log
on a periodic basis, with the time period configured by the “SleepTime” parameter in the
qip.pcy file. The Monitor Service then creates VitalQIP Messages of Type “DHCP” for the
VitalQIP Message Service, in the same way that Alcatel-Lucent DHCP does. The VitalQIP
Message Service then handles these messages according to the Message Routes. In this
case, the MS-DHCP server should have a Message Route of type DHCP going to the QIP
Update Service at the Enterprise server IP address.
31
Figure 18: MS-DHCP client updates for MS-DNS secure zones
Client
DHCP Client
Remote server
MS DHCP
VitalQIP MS DHCP
Monitor Service
Enterprise server
VitalQIP
Message Service
Remote server
VitalQIP SIP
Update Service
MS DNS
VitalQIP
database
Getting MS-DHCP client hostnames into ALU DNS
MS-DHCP can send DDNS updates directly to Alcatel-Lucent DNS, just as it can to
MS-DNS. It is advantageous, however, to perform DNS updates after the Enterprise
server has checked the names for duplicates and renamed DHCP hosts to avoid
duplicates. MS-DHCP should have the DNSConfig options set so that it does not send
dynamic updates. Instead, the VitalQIP MS DHCP Monitor Service sends the DHCP lease
information to the QIP Update Service (via the Message Service), the QIP Update Service
checks for duplicates, and then forwards the corrected names to the DNS Update Service,
which can send DDNS updates to Alcatel-Lucent DNS. The flow of DHCP Client updates
is shown below.
32
Figure 19: MS-DHCP Client Updates for Alcatel-Lucent DNS
Client
DHCP Client
MS DHCP
Remote server
VitalQIP MS DHCP
Monitor Service
Enterprise server
VitalQIP
Message Service
VitalQIP SIP
Update Service
VitalQIP
database
VitalQIP DNS
Update Service
Remote server
Lucent DNS
Secure Zone
Migrating MS-DHCP data to ALU DHCP
Though VitalQIP can manage MS-DHCP – as explained above – few VitalQIP customers
have chosen to do so. More commonly, customers replace the MS-DHCP servers with
ALU DHCP – even if they continue to use MS-DNS. ALU DHCP has better integration
with the other VitalQIP components, ALU DHCP offers better scalability and better
features, and DHCP Generation to ALU DHCP is much easier and faster than DHCP
Generation to MS-DHCP. The qip-msextract utility can be used to migrate MS-DHCP
scopes and configurations to VitalQIP. See the Advanced DHCP Configuration chapter in
the Administrator Reference Manual.
33
VITALQIP MANAGEMENT OF
SITES AND DOMAIN CONTROLLERS
Overview
Windows clients use Sites information from AD to find network services at their own
location. A Site is an association of subnets that have an affinity to one another and low
“ping times” between them. Sites and Subnet data can be seen in the Microsoft “Active
Directory Sites and Services” GUI.
VitalQIP is an IPAM that should already have complete information about all subnets.
Subnet Organizations in VitalQIP are user-defined groupings of subnets. These can be
used to correspond to AD Sites, and then VitalQIP is able to send that data to AD. Using
VitalQIP to manage sites and subnets reduces the administrator workload, since data is
now only entered in one place instead of two, thereby leveraging the power of VitalQIP
and minimizing data entry errors.
What is Domain Controller Generation?
The Domain Controller Generation feature of VitalQIP pushes the assigned Subnet
Organizations from VitalQIP to a Domain Controller. VitalQIP creates LDAP Data
Interchange Format (LDIF) files to add, delete, or rename AD sites that correspond to
Subnet Organizations in VitalQIP, and the subnets under each of them. It then connects
directly to the Directory Services on the domain controller via the LDAP port, provides a
username/password to the domain controller, and the domain controller processes the
adds and deletes.
Some customers prefer for VitalQIP to push out additions but not deletions. The VitalQIP
policy Delete Sites/Subnets from Active Directory controls whether VitalQIP can delete
sites and subnets in AD.
domain controller Generation is a very different process from DNS Generation and DHCP
Generation. The domain controller does not need a VitalQIP Remote service or any other
VitalQIP components, and File Generation Service on the E/S is not involved. It is done
with the “qip-sitegen” CLI command, or via the web GUI that invokes the CLI.
Note that the Sites and Subnet data is just a small part of the AD database of a domain
controller.
Data replication between domain controllers
Like other data in AD, Sites and Subnets are replicated between domain controllers.
VitalQIP allows multiple domain controllers to be assigned to a Windows Site (Subnet
Organization), but this should not be configured if the multiple domain controllers will
replicate among themselves.
Implementation
1.Have correct subnets in VitalQIP
If subnets are listed in AD and not in VitalQIP, they can be migrated. Data about
subnets and sites can easily be transferred from AD to VitalQIP using Microsoft’s
LDIFDE utility, together with Alcatel-Lucent’s qip-siteimport utility.
2.Create the Domain Controller Profile in VitalQIP
VitalQIP does not require a Remote Service to be installed on the domain controller,
but it does need to know the correct IP address, LDAP port number and other
34
information. The username needs to be fully qualified, such as “CN=Administrator
,CN=Users,DC=company,DC=com”. This username/password must have suitable
permissions in AD.
Figure 20: Domain Controller profile in VitalQIP:
3.Have Subnet Organizations in VitalQIP that correspond to Windows Sites
In VitalQIP, the term “Subnet Organization” is any grouping of subnets and it could
be used for a few purposes. However, in this case, each Subnet Organization must
correspond to a Windows Site. Each Subnet Organization has a Windows Site tab,
which allows the Windows site to have a different name than the subnet organization,
and also allows assignment of Domain Controllers. No subnet can belong to more
than one Subnet Organization, but not all Subnet Organizations in VitalQIP need to be
Windows Sites that are assigned to domain controllers.
4.Assign domain controllers to each Site (Subnet Organization)
Finally, the domain controllers are associated with the appropriate Sites (that is, subnet
organizations) in the Subnet Organization Profile’s Windows 2000 Site tab. Do not
assign redundant domain controllers that already replicate between themselves; this
could cause data inconsistencies.
35
Figure 21: Assign just one domain controller to each Site if they have replication
5.Perform a Domain controller Generation Preview for All Sites and Subnets.
Verify that the .ldf produced are correct, for all Sites that are assigned to that domain
controller in VitalQIP, and all subnets within the corresponding Subnet Organization.
6.Perform Domain Controller Generation to server, for all sites and subnets.
On the first push, the adds are expected to fail for those sites and subnets that already
exist in AD
7.Perform subsequent pushes as Changed Sites and Subnets
This type of push creates adds and deletes based on the VitalQIP database’s change
flags of what was changed since the last push to that server.
The Web Client User’s Guide has a chapter titled “Domain Controllers” which has the
details of the above operations.
36
LDAP AUTHENTICATION CALLOUTS
FROM VITALQIP TO ACTIVE DIRECTORY
Another type of “Active Directory integration” is authenticating VitalQIP users against
Windows usernames/passwords, which is based on AD Domain Controllers. When users
login to the VitalQIP GUI or CLIs, they need to enter a username/password. Permissions
in VitalQIP are determined by the username used.
In a default VitalQIP configuration, a master administrator defines administrator accounts
for other VitalQIP users, and assigns passwords at the time of each account’s creation.
When the user logs into QIP, the username/password are checked against the VitalQIP
database, and then the permissions are assigned accordingly. A few security policies
such as expiration times and password reuse can be set in QIP, though security is not as
extensive as in the Windows OS.
However, it is also possible to configure VitalQIP to check passwords against AD domain
controllers. The VitalQIP master admin still must create accounts in VitalQIP because
permissions must be defined, but the passwords in VitalQIP are not used. Instead, the
qip-ldapauth CLI is invoked when a user enters a username/password, and then the
domain controller replies about whether or not the username/password is authenticated.
Then the VitalQIP permissions are read. This way users don’t need to learn and maintain
a separate username/password from the one that they already have for Windows, and
the stronger password security of the Windows OS can be applied.
Please refer to the Authenticate Administrator’s chapter of the VitalQIP Administrator
Reference Manual for more details about setting this up. The follow diagram gives an
overview of the components involved, including the qip.pcy, qip-ldapauth.pcy, and
ApplicationContext.xml which have the configuration for it.
Figure 22: LDAP Authentication Callouts from VitalQIP to Active Directory
applicationcontext.xml
Web GUI
Tomcat
qip-ldapauth.pcy
Web CLIs
qip.pcy
qip-ldapauth
Thick
client
qip-logind
qip-ldapauth.log
Old
CLIs
37
Domain
Controllers
CONCLUSION
VitalQIP offers powerful features for managing a Windows network. Many large
organizations have various groups and components using various types of networks,
DNS platforms, and DHCP platforms, usually including at least some groups that
use MS Active Directory. VitalQIP is an ideal solution for tying it all together.
www.alcatel-lucent.com Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of
Alcatel-Lucent. All other trademarks are the property of their respective owners. The information presented
is subject to change without notice. Alcatel-Lucent assumes no responsibility for inaccuracies contained herein.
Copyright © 2014 Alcatel-Lucent. All rights reserved. E2014014022EN (April)

Integrating VitalQIP® with Microsoft® Windows™ Networking /Active

Transcription

Similar documents

Promoting Inter-ccTLD Cooperation in Africa - ISOC-NY

Internet of Things. A recent visit to CES:

Prediction of laminar-turbulent transition with DNS, LES and RANS

1. Run nslookup to obtain the IP address of a Web server

PEP February 2016 NEWSLETTER

SVR302: Windows Server code name “Longhorn” Technical Overview

DOMAIN REGISTRATION AND HOSTING OF A WEBSITE: THE

ICANN Talk - State of Global DNSSEC

SyS64738: [email protected] Agris Krusts: agris@zone

Shut the Front Door (and the Back Door too)