INTEGRATING VITALQIP WITH MICROSOFT WINDOWS NETWORKING/ ACTIVE DIRECTORY

Transcription

1 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

2 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

3 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 / 37 Conclusion / 38

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

5 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 company.com. IN A 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 server1.company.com. _kpasswd.udp.comany.com. IN SRV server1.company.com. _gc._tcp.default-first-site._sites.company.com. IN SRV server1.company. com. _ldap._tcp.dc._msdcs.company.com. IN SRV server1.company.com. 2

6 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-e d-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 _ldap._tcp.forestdnszones.company.com. IN SRV 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

7 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

8 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 , and then the Resource Records tab should have a second A record: company. com. IN A 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

9 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

10 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

11 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

12 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 Pushes Dynamic Updates Updates EDUP ALU DHCP ALU DNS DORA Dynamic updates SRV, CNAME 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

13 Figure 5: Option 81 Support E/S DB has D-DHCP: udp00123uds.company.com Push DHCP dhcpd.conf company.com Discover Client No IP Name=JoesPC MyDomain.com Offer dhcp.db JoesPC.??? Update JoesPC.?????? 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

14 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 Dynamic- DHCP 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

15 Figure 6: DNS Registration of Static Windows Clients (if allowed) E/S Pushes EDUP Dynamic Updates 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 DHCP object Hostname DHCP messages ALU DHCP GUI or CLIs Static object External object Hostname A checkbox PTR checkbox qip-qipupdated DNSUpdateRR messages ALU DNS Partially-managed object qip-syncexternal AFXR 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

16 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

17 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 Pushes Dynamic Updates Updates EDUP ALU DHCP ALU DNS (company.com) DORA Zone Transfers Windows Clients Dynamic updates MS-DNS (ad.company.com) Windows Logons Domain Controller Dynamic updates 14

18 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

19 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

20 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

21 Figure 10: Domain Controller updates and DNS registration Windows 2000 Client/Domain Controller MS DNS Client 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 DHCP object Hostname DHCP messages ALU DHCP GUI or CLIs Static object External object Hostname A checkbox PTR checkbox qip-qipupdated DNSUpdateRR messages ALU DNS Partially-managed object qip-syncexternal AFXR 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

22 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

23 Figure 12: Static IPs for MS-DNS Secure Zones VitalQIP GUI Enterprise server VitalQIP database 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

24 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