A NIOS appliance can support Active Directory and process secure GSS-TSIG-authenticated DDNS updates from DHCP clients, DHCP servers, and AD domain controllers. The appliance supports servers running Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, or Windows Server 2016 with the Active Directory service installed. The process in which a DHCP client dynamically updates its resource records on a DNS server using GSS-TSIG authentication is shown in Figure 21.10. The illustration also shows the relationship of the clients, the DHCP server, the DNS server, and the Kerberos server (running on the AD domain controller).

Note: For explanations of the alphanumerically notated steps in Figure 21.10, see the section following the illustration.

Figure 21.10 Authenticating DDNS Updates with GSS-TSIG

DHCP – IP Address and Network Parameters Assignment
1. The DHCP client requests an IP address.
2. The DHCP server assigns an IP address, subnet mask, gateway address, and a DNS server address.
Active Directory – Computer and User Logins
1. The computer sends a DNS request to locate the AD domain controller, and then logs in to the domain controller.

Note: Computer accounts have passwords that the AD domain controller and computer maintain automatically. There are two passwords for each computer: a computer account password and a private key password. By default, both passwords are automatically changed every 30 days.

b. The user manually logs in to a domain.

3. DNS – Query for the Kerberos Server

1. The computer (or client) automatically sends a query for kerberos._udp.dc_msdcs.dom_name_ to the DNS server whose IP address it received through DHCP.
2. The NIOS appliance replies with the name of the Kerberos server.

4. Kerberos – Login, and TGT and Service Ticket Assignments

1. The client automatically logs in to the Kerberos server.
2. The Kerberos server sends the client a TGT (ticket-granting ticket).
3. Using the TGT, the AD member requests a service ticket for the DNS server.
4. The Kerberos server replies with a service ticket for that server.

5. DDNS – Dynamic Update of the Client's Resource Records

1. Unauthenticated DDNS Update Attempt (Refused)
  1. The client sends an unauthenticated DDNS update.
  2. The DNS server refuses the update.
2. TKEY negotiations (GSS Handshake):
  1. The client sends the DNS server a TKEY (transaction key) request. A Transaction Key record estab- lishes shared secret keys for use with the TSIG resource record. For more information, see RFC 2930,Secret Key Establishment for DNS (TKEYRR).
    The request includes the service ticket. The service ticket includes the appliance's principal and proposed TSIG (transaction signature) key, along with other items such as a ticket lifetime and a timestamp.
  2. The DNS server responds with a DNS server-signed TSIG, which is a "meta-record" that is never cached and never appears in zone data. A TSIG record is a signature of the update using an HMAC-MD5 hash that provides transaction-level authentication. For more information, see RFC 2845,Secret Key Transaction Authentication for DNS (TSIG).

The two participants have established a security context.

c. GSS-TSIG-Authenticated DDNS Update (Accepted)

1. 1. The client sends an authenticated DDNS update, which includes the following resource records:

- - - A – Address record
      or
      PTR – Pointer record
    - TKEY – Transaction Key record
    - TSIG – TSIG record

ii. The DNS server authenticates the DDNS update and processes it.

iii. The DNS server sends a GSS-TSIG-authenticated response to the AD member, confirming the update.

Note: For GSS-TSIG authentication to work properly, the system clock times of the Infoblox DHCP server, AD domain controller and DNS server must be synchronized. One approach is to use NTP and synchronize all three devices with the same NTP servers.

Configuring DNS to Receive GSS-TSIG Updates

You can configure an appliance to support Active Directory and accept secure DDNS updates from clients using GSS-TSIG. The initial configuration tasks are shown in Figure 21.11. The appliance supports servers running Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, or Windows Server 2016 with the Active Directory service installed.

Figure 21.11 Adding a NIOS Appliance to an AD Environment with GSS-TSIG Support

On an already functioning AD domain controller:

Enable zone transfers to the NIOS appliance.
Add a user account for the NIOS appliance serving DNS. A corresponding account on the Kerberos server is automatically created. For information, see Creating an AD User Account.
Export the keytab file for the NIOS appliance account from the Kerberos server to a local directory on your management system. For information, see Generating and Exporting the Keytab File.

On an Infoblox appliance:

Import the keytab file from your management system to the Infoblox appliance and enable GSS-TSIG authentication on the appliance. For information, see Importing the Keytab File and Enabling GSS-TSIG Authentication.
Configure a forward-mapping zone with the same name as the AD zone. For information, see Creating an Authoritative Forward-Mapping Zone.
(Optional) Create a reverse-mapping zone for the network address space that corresponds to the domain name space in the forward-mapping zone. For information, see Creating an Authoritative Reverse-Mapping Zone.
Import the zone data from the AD domain controller. For information, see Importing Zone Data.
Enable the acceptance of GSS-TSIG-signed updates from the AD controller and from the DHCP clients and servers whose addresses the DHCP server assigns. For information, see Accepting GSS-TSIG Updates.

Creating an AD User Account

Connect to the AD domain controller and create a user account for the NIOS appliance.

Note: The name you enter in the User logon name is the name that you later use when exporting the keytab file.
This is also the principal name. The text in the First name, Initials, Last name, and Full name fields is irrelevant to this task.

The AD domain controller automatically creates a Kerberos account for this user with an accompanying keytab. Note the following:

If you define an expiration date for the user account and you later create a new account when the first one expires, the keytab for the corresponding Kerberos account changes. At that point, you must update the keytab file on the NIOS appliance (see Generating and Exporting the Keytab File and Importing the Keytab File and Enabling GSS-TSIG Authentication). Optionally, if your security policy allows it, you can set the user account for the NIOS appliance so that it never expires.
If the AD domain controller is running Windows Server 2003, the user account must have the DES encryption type enabled. You can enable this either in the Account tab when you create the user account or by specifying +DesOnly when you use the Ktpass tool to generate the keytab file.

Generating and Exporting the Keytab File

You can generate and export the keytab file for the Kerberos account by using the Ktpass tool. Note that the version of the Ktpass tool that you use must match the Windows version of the domain controller. For example, if you are using a domain controller running Windows Server 2008 or Windows Server 2008 R2, you must use the Ktpass tool for Windows Server 2008 or Windows Server 2008 R2.
You enter different commands for generating and exporting the keytab file, depending on whether you are generating the keytab file from a server running Microsoft Windows 2000, Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2.

Generating the Keytab on Windows 2000

To export the keytab file using a Microsoft Windows 2000 Resource Kit:

Start a command prompt.
Enter the following command to export the keytab file for the NIOS appliance user account:

For example:

Generating the Keytab on Windows Server 2003

The Ktpass tool is included in the Windows Server 2003 Support Tools. To export the keytab file using a Microsoft Windows 2003 Resource Kit:

Start a command prompt.
Enter the following command to export the keytab file for the NIOS appliance user account:

For example:where:
-princ = Kerberos principal

DNS = Service name in uppercase format
ns1.corpxyz.com = Instance in FQDN (fully-qualified domain name) format; this is the same as the DNS name of the NIOS appliance
corpxyz.COM = The Kerberos realm in uppercase format; this must be the same as the AD domain name

-mapuser = Maps the Kerberos principal name to the AD user account

ns1@corpxyz.com = The AD user name for the NIOS appliance

-pass = The AD user account password

37Le37 = The password of the user account for the NIOS appliance

-out = Exports the keytab file

ns1.keytab = The name of the keytab file

-ptype = Sets the principal type. This must be krb5_nt_principal.
-crypto = Specifies the encryption type. This must be des-cbc-md5.
+DesOnly = Specifies DES encryption for the account. Include this if you did not enable DES encryption for the account.

Generating the Keytab on Windows Server 2008/Windows Server 2008 R2

A Windows Server 2008 or Windows Server 2008 R2 domain controller allows you to generate a keytab file with multiple keys for one principal. The Infoblox DNS server accepts GSS-TSIG updates from DHCP clients that provide a Kerberos ticket for any of the keys in its configured keytab. To generate the keytab file using the Ktpass tool:

Start a command prompt.
Enter the following command to export the keytab file for the NIOS appliance user account:

For example:where:
-princ = Kerberos principal

DNS = Service name in uppercase format
ns1.corpxyz.com = Instance in FQDN format; this is the same as the DNS name of the NIOS appliance
corpxyz.COM = The Kerberos realm in uppercase; this must be the same as the AD domain name

-mapuser = Maps the Kerberos principal name to the AD user account

ns1@corpxyz.com = The AD user name for the NIOS appliance

-pass = The AD user account password

37Le37 = The password of the user account for the NIOS appliance

-out = Exports the keytab file

ns1.keytab = The name of the keytab file

-ptype = Sets the principal type. This must be krb5_nt_principal.
-crypto = Specifies the encryption type.
After you execute the command to generate the keytab file, the AD domain controller displays a series of messages similar to the following to confirm that it successfully generated the keytab file:

Note: The keytab file contains highly sensitive data for the NIOS appliance account. Ensure that you store and transport its contents securely.

Modifying an AD User Account

To change any AD user account information (login, password, etc):

Remove the previous user account from AD.
Create a new user for GSS-TSIG mapping.
Generate a new keytab file.
Import the keytab file to the DNS server.

Importing the Keytab File and Enabling GSS-TSIG Authentication

Before you can enable GSS-TSIG authentication, you must import the keytab file from the Kerberos account for the NIOS appliance. To import the keytab file:

From the Data Management tab, select the DNS tab and click the Members tab -> member check box -> Edit icon.
In the Member DNS Properties editor, click Toggle Expert Mode.
When the additional tabs appear, click GSS-TSIG and do the following:

If a principal name and version number are listed, there is a keytab file loaded on the appliance. Compare this information with that for the NIOS appliance account on the Kerberos server to make sure that they match. If there is no keytab file on the NIOS appliance or if the loaded keytab file does not match that on the Kerberos server, you must load the correct keytab file.

- Click Upload, click Browse to navigate to the keytab file, and then click Upload.
- Enable GSS-TSIG authentication of clients: Select this check box.

4. Save the configuration and click Restart if it appears at the top of the screen.

Each time you export a keytab file from a Kerberos server running on Windows Server 2003, the version number of the keytab file increases incrementally. Because the version number on the keytab file that you import to the NIOS appliance must match the version that is in use on the Kerberos server, you should select the last keytab file that is exported from the Kerberos server if you have exported multiple keytab files. (A Kerberos server running on Windows 2000 does not increase the version number of keytab files with each export.)

Accepting GSS-TSIG Updates

You can allow a Grid or specific members or zones to accept GSS-TSIG signed updates from domain controllers and DHCP clients and servers, as follows:

Grid: From the Data Management tab, select the DNS tab, expand the Toolbar and click Grid DNS Properties.
Member: From the Data Management tab, select the DNS tab -> Members tab -> member check box -> Edit icon.
Zone: From the Data Management tab, select the DNS tab -> Zones tab -> zone check box -> Edit icon.
To override an inherited property, click Override next to it and complete the appropriate fields.
Select the Updates tab and do the following in the Basic subtab:

- Allow GSS-TSIG signed updates: Select this option.

3. Save the configuration and click Restart if it appears at the top of the screen.

You can then use the Active Directory wizard or navigate to the Active Directory tab of the Authoritative Zone editor to enable the appliance to create underscore zones for the records hosted by domain controllers and to allow GSS-TSIG signed updates to the underscore zones.
To use the Active Directory wizard:

From the Data Management tab, select the DNS tab, expand the Toolbar and click Configure Active Directory.
In the Configure Active Directory wizard, complete the following, and then click Next:

- Select Zone: Click this and select a zone. The name of the zone must match the name in the AD domain controller so the zone transfer from the AD domain controller to the NIOS appliance can succeed.
- Allow GSS-TSIG-signed (secure) updates from Domain Controllers: Select this option.

3. Complete the following:

- Do you want to create underscore zones to hold the records added by the Domain Controllers?
  This option allows the appliance to create the following subzones that the DNS server must have to answer AD-related DNS queries:
  _msdcs.zone
  _sites.zone
  _tcp.zone
  _udp.zone
  domaindnszones.zone
  forestdnszones.zone
  Note that these zones are automatically generated. You cannot edit these zones or import data into them.
- Allow GSS-TSIG-signed updates to underscore zones: Select this check box to allow underscore zones to accept GSS-TSIG signed updates.

4. Save the configuration and click Restart if it appears at the top of the screen.
To use the Authoritative Zone editor:

From the Data Management tab, select the DNS tab -> Zones tab -> zone check box -> Edit icon.
In the Authoritative Zone editor, select the Active Directory tab and do the following:
- Allow unsigned updates from these Domain Controllers: Clear this check box.
- Automatically create underscore zones: (select)
  This option automatically creates the following subzones that the DNS server must have to answer AD-related DNS queries:
  _msdcs.zone
  _sites.zone
  _tcp.zone
  _udp.zone
  domaindnszones.zone
  forestdnszones.zone
  Note that these zones are automatically generated and cannot be manually edited.

- Allow GSS-TSIG-signed updates to underscore zones: Select this check box to allow underscore zones to accept GSS-TSIG signed updates.

3. Save the configuration and click Restart if it appears at the top of the screen.

Browser not supported