GSS-TSIG (Generic Security Service Algorithm for Secret Key Transaction) is used to authenticate DDNS updates. It is a modified form of TSIG authentication that uses the Kerberos v5 authentication system.
GSS-TSIG involves a set of client/server negotiations to establish a "security context." It makes use of a Kerberos server (running on the AD domain controller) that functions as the KDC (Kerberos Key Distribution Center) and provides session tickets and temporary session keys to users and computers within an Active Directory domain. The client and server collaboratively create and mutually verify transaction signatures on messages that they exchange. Windows 2000 server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 and Windows Server 2019 all support DDNS updates using GSS-TSIG.
You can configure the appliance to accept GSS-TSIG signed DDNS updates from a single client or multiple clients that belong to different AD domains in which each domain has a unique GSS-TSIG key. You can also configure the appliance to support one or multiple GSS-TSIG keys for each Grid member. For information about how to configure GSS-TSIG for DHCP and DNS, see Configuring GSS-TSIG keys. This feature also supports HA pairs and is compatible with DNS zones that have multiple primary servers configured. For more information about HA pairs and DNS zones with multiple primary servers, see About HA Pairs and Assigning Zone Authority to Name Servers respectively.
You can upload keytab files that contain one or multiple GSS-TSIG keys and manage the keys globally. NIOS supports up to 256 GSS-TSIG keys for each member in the Grid. NIOS logs administrative changes to GSS-TSIG keys in the audit log and failures in parsing or loading the keytab files in the syslog. Note that this feature is enabled only when you have installed the DNS license.

A NIOS appliance can use GSS-TSIG authentication for DDNS updates for either one of the following:

• A NIOS appliance serving DHCP can send GSS-TSIG authenticated DDNS updates to a DNS server in an AD domain or multiple AD domains whose domain controller is running Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 or Windows Server 2019. The DNS server can be in the same AD domain as the DHCP server or in a different domain.

  • For information about sending secure DDNS updates to a DNS server in the same domain, see Sending Secure DDNS Updates to a DNS Server in the Same Domain below.

  • For information about sending secure DDNS updates to a DNS server in a different domain, see Sending Secure DDNS Updates to a DNS Server in Another Domain below.

• A NIOS appliance serving DNS can accept GSS-TSIG authenticated DDNS updates from DHCP clients and servers in an AD domain or multiple AD domains whose domain controller is running Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 or Windows Server 2019.

  • For information, see Accepting GSS-TSIG-Authenticated Updates.

    Note that a NIOS appliance cannot support both of these features at the same time.
    
    

Kerberos Authentication for GSS-TSIG

A keytab file contains pairs of Kerberos principal names and their corresponding encryption keys. It can contain keys for a single realm or multiple realms. It is possible to infer the KDC from the principal because Windows uses uppercase AD domain names for Kerberos realm names. You must provide the principal name. The principal name may contain Kerberos realm, and the DNS servers for the domain are available for DNS name resolution. Therefore, resolving SRV _kerberos._tcp.REALM. will return the appropriate KDC. New TGTs cannot be acquired when the KDC that issues the TGT fails. If the appliance has successfully authenticated before the KDC failure, the secure updates will continue until the session key and TGT expire. The default expiration on Windows is 10 hours. If the appliance restarts or reboots, secure updates are deferred until the KDC becomes available.

Infoblox recommends restarting the DHCP service on NIOS to avoid any update failures, if the encryption key type is changed on the Microsoft server.
The following provides information about the traffic flow between the appliance and the KDC:

• Client uses keytab to get TGT for principal from KDC (AS-REQ/AS-REP).

• Client uses TGT to get session ticket from KDC (TGS-REQ/TGS-REP).

• Client uses session ticket to acquire TKEY from DNS server (TKEY/TKEY).

• Client uses TKEY to sign DNS updates (DNS-TSIG/DNS-TSIG).

The DNS server authenticates into the domain when the keytab file is generated on the KDC and its SPN (Service Principal Name) is mapped to an account. The server's private key is known to itself and to the KDC. The KDC generates the ticket and the DNS server allows the update.
Note the following when you upload multiple keytab files on the appliance:

• NIOS displays an error message and discards the keytab file if the file does not have a recognizable key, SPN, version or encryption type, and it saves the error message in the syslog.

• NIOS considers duplicate keys as invalid keys if the keys have the same SPN, version, and encryption type.

• If NIOS encounters an invalid key during an upload, it will not upload the other keys in the keytab and the operation fails. NIOS saves the warning and error message in the syslog and in Grid Manager.

Sending Secure DDNS Updates to a DNS Server in the Same Domain

An Infoblox DHCP server can send GSS-TSIG authenticated DDNS updates to a DNS server in an AD domain whose domain controller is running Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 or Windows Server 2019. The DHCP server, DNS server, and domain controller are all in the same AD domain. The process by which an Infoblox DHCP server dynamically updates resource records on a DNS server using GSS-TSIG authentication is shown in the below figure. In the illustration, the Kerberos Key Distribution Center (KDC) is running on an AD domain controller, which also provides DNS service.
An Infoblox DHCP Server Sends GSS-TSIG Updates to a DNS Server
 

After you enable the NIOS appliance to send GSS-TSIG authenticated updates to a DNS server, the following process occurs:

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

   1. The Infoblox appliance automatically logs in to the AD/Kerberos server.

   2. The Kerberos server sends the appliance a TGT (ticket-granting ticket).

   3. Using the TGT, the appliance requests a service ticket for the DNS server.

   4. The Kerberos server replies with a service ticket for that server.

2. TKEY negotiations (GSS Handshake):

   1. The appliance sends the DNS server a TKEY (transaction key) request. A Transaction Key record establishes shared secret keys for use with the TSIG resource record. For more information, see RFC 2930, Secret Key Establishment for DNS (TKEY RR).
      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.
      When a DHCP client sends a request for an IP address to the DHCP server, the following occurs:

3. 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, DNS server address, and a domain name.
      After the appliance assigns an IP address to the DHCP client, it sends the DDNS update to the DNS server as follows:

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

   1. GSS-TSIG-Authenticated DDNS Update

      1. The appliance sends an authenticated DDNS update, which may include the following resource records:

         • A or AAAA – Address record
           or
           PTR – Pointer record

         • TKEY – Transaction Key record

         • TSIG – TSIG record

      2. The DNS server verifies the DDNS update and allows it to complete.

      3. The DNS server sends a GSS-TSIG-authenticated response to the appliance, confirming the update.

Configuring DHCP to Send GSS-TSIG Updates in the Same Domain

Before configuring an Infoblox DHCP server to support GSS-TSIG, you must create a user account on the Kerberos server for the appliance. Then you must export the corresponding keytab file from the Kerberos server and import it onto the NIOS appliance. The below figure illustrates the initial configuration tasks.

Adding an Infoblox DHCP Server to an AD Environment with GSS-TSIG Support
 

The Infoblox DHCP server can send GSS-TSIG-signed DDNS updates to a DNS server for one domain only, though multiple Infoblox DHCP servers can update that domain. If you want more than one Infoblox DHCP server to update a DNS domain, you can either import the same keytab file to the other Infoblox DHCP servers or generate and import a different keytab file. In a Grid, each member can update a different domain.

To use an AD domain controller as a Kerberos Key Distribution Center, complete the following tasks on an AD/Kerberos server:

1. Add a user account for the NIOS appliance to the AD domain controller. For information, see Creating an AD User Account below.

2. Generate the keytab file for the NIOS appliance account and export it from the AD domain controller to a local directory on your management system. For information, see Generating and Exporting the Keytab File below.

To configure a NIOS appliance to support AD and send GSS-TSIG secure DDNS updates to a DNS server, complete the following tasks on a NIOS appliance:

1. Import the keytab file from your management system to the appliance and enable GSS-TSIG dynamic updates at the Grid or member level. For information, see Enabling GSS-TSIG Authentication for DHCP.

2. Configure the appliance to send GSS-TSIG dynamic updates to forward-mapping and optionally, reverse-mapping zones on the DNS server. For information, see Managing GSS-TSIG keys.

Creating an AD User Account

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

The AD domain controller automatically creates a Kerberos account for this user. 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 below and Enabling GSS-TSIG Authentication for DHCP). 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 of the AD domain controller when you create the user account or by specifying +DesOnly when you use the Ktpass tool to generate the keytab file. For instructions, see the next section, Generating and Exporting the Keytab File below.

• The newly created AD user account must be a member of the DnsUpdateProxy group or an account that allows it to update records that have potentially been added by another DHCP server, such as DNS Admins.

Generating and Exporting the Keytab File

You can use the Ktpass tool to generate and export the keytab file for the Kerberos account. 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, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 or Windows Server 2019, you must use the Ktpass tool for Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 or Windows Server 2019.
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, Windows Server 2008 R2, Windows Server 2010, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 or Windows Server 2019.
A Windows Server 2003 domain controller allows you to generate a keytab file with only one key for a principal. A Windows Server 2008, Windows Server 2008 R2 domain controller, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 or Windows Server 2019 allows you to generate a keytab file with multiple keys for one principal. This is useful when the KDC has principals with multiple encryption types. When the NIOS DHCP server uses a keytab with multiple keys, it negotiates a key based on those in the configured keytab file.

Infoblox strongly recommends the following encryption types for compatibility purposes:

Generating the Keytab on Windows 2000 Servers

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

1. Start a command prompt.

2. Enter the following command to export the keytab file for the NIOS appliance user account:  C:> ktpass -princ service_name/FQDN_instance@REALM -mapuser AD_username -pass password -out filename.keytab

   Note that the values are case-sensitive.

   where:

   • service_name/instance: The AD user name for the NIOS appliance and a character string. The AD user name must match the user logon name on the AD domain controller.

   • REALM: The Kerberos realm in uppercase. It must match the realm (or domain name) specified in the –mapuser option.

For example:

Generating the Keytab on Windows Servers 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:

1. Start a command prompt.

2. Enter the following command to generate the keytab file for the NIOS appliance user account:
   ktpass -princ service_name/FQDN_instance@REALM -mapuser AD_username@REALM -pass password -out filename.ktb -ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NT

   Note that the values are case-sensitive.
   
   

The following are some examples of keytab file:

where
-princ = Kerberos principal. Note that this parameter is case sensitive. Specifies the principal name for the host or service in this format: DNS/ns1.corpxyz.com@GSS.LOCAL

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

• GSS.LOCAL = 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. If you omit the account name, mapping is deleted from the specified principal. You can use ksetup without any parameters or arguments to see the current mapped settings and the default realm. Example: ksetup /mapuser <Principal> <Account>. To create an AD user account, see Creating an AD User Account above.

• jsmith = The AD user name for the NIOS appliance.

• GSS.LOCAL = The Kerberos realm in uppercase. The realm (or domain name) must be the same as that specified in the -princ option.

-pass = The AD user account password. The Ktpass command changes the account password to the specified value, thus incrementing the version number of the user account and the resulting keytab file.

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

-out = The name of the keytab file that is generated.

• ns1.ktb = The name of the keytab file

-ptype = Sets the principal type. This must be krb5_nt_principal.
-crypto = Specifies the encryption type. You can use the following encryption types:

• DES-CBC-CRC = Specifies DES encryption for the account. This encryption type is used for compatibility.

• DES-CBC-MD5 = Specifies DES encryption for the account. This encryption type adheres to the MIT implementation and is used for compatibility.

• RC4-HMAC-NT = Specifies 128-bit RC4-HMAC encryption for the account. This is enabled by default.

+DesOnly = Specifies DES encryption for the account.

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:

Generating the Keytab on Windows Servers 2008 or Windows Servers 2008 R2

To generate the keytab file using the Ktpass tool:

1. Start a command prompt.

2.  

Example:

where:
-princ = Kerberos principal. Note that this parameter is case sensitive. Specifies the principal name for the host or service in this format: DNS/ns1.corpxyz.com@GSS.LOCAL

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

• GSS.LOCAL = 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. If you omit the account name, mapping is deleted from the specified principal. You can use ksetup without any parameters or arguments to see the current mapped settings and the default realm. Example: ksetup /mapuser <Principal> <Account>. To create an AD user account, see Creating an AD User Account above.

• jsmith = The AD user name for the NIOS appliance.

• GSS.LOCAL = The Kerberos realm in uppercase. The realm (or domain name) must be the same as that specified in the -princ option.

-pass = The AD user account password. The Ktpass command changes the account password to the specified value, thus incrementing the version number of the user account and the resulting keytab file.

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

-out = The name of the keytab file that is generated.

• ns1.ktb = The name of the keytab file

-ptype = Sets the principal type. This must be krb5_nt_principal.
-crypto = Specifies the encryption type. Note that the RC4-HMAC-NT encryption type is enabled by default. You can also use the following:

• DES-CBC-CRC = Specifies DES encryption for the account. This encryption type is used for compatibility.

• DES-CBC-MD5 = Specifies DES encryption for the account. This encryption type adheres to the MIT implementation and is used for compatibility.

• RC4-HMAC-NT = Specifies 128-bit RC4-HMAC encryption for the account. This is enabled by default.

• AES256-SHA1 = Specifies 256-bit AES encryption for the account.

• AES128-SHA1 = Specifies 128-bit AES encryption for the account.

• ALL = Specifies all of the above encryption types. Do not use this option if DES support is disabled.

You can optionally specify the following:
+DesOnly = Specifies DES encryption for the account. You must use this only when you use DES-CBC-MD5 for compatibility. Note that Windows 7 and Windows Server 2008 R2 do not support DES by default. However, you can enable DES on the Windows 2008 server. Include this option if you did not enable DES encryption for the account. For more information, refer to the information available in a third-party portal at: http://weblogic-wonders.com/weblogic/2010/11/30/windows-7-des-encryption-support-for-kerberos-authentication/

• +setpass = Sets a new AD user account password. This is required if the +DesOnly option is specified. When you use this encryption type, you must change the user's password. Otherwise, the ticket issued for the principal becomes unusable.

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:

Generating the Keytab on Windows Servers 2012 or Windows Server 2012 R2

To generate the keytab file using the Ktpass tool:

• Start a command prompt.

• where:
  -princ = Kerberos principal. Note that this parameter is case sensitive. Specifies the principal name for the host or service in this format: DNS/ns1.corpxyz.com@GSS.LOCAL

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

• GSS.LOCAL = 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. If you omit the account name, mapping is deleted from the specified principal. You can use ksetup without any parameters or arguments to see the current mapped settings and the default realm. Example: ksetup /mapuser <Principal> <Account>. To create an AD user account, see Creating an AD User Account above.

• jsmith = The AD user name for the NIOS appliance.

• GSS.LOCAL = The Kerberos realm in uppercase. The realm (or domain name) must be the same as that specified in the -princ option.

-pass = The AD user account password. The Ktpass command changes the account password to the specified value, thus incrementing the version number of the user account and the resulting keytab file.

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

-out = The name of the keytab file that is generated.

• ns1.ktb = The name of the keytab file

-ptype = Sets the principal type. This must be krb5_nt_principal.
-crypto = Specifies the encryption type. You can specify the following encryption types:

• DES-CBC-CRC = Specifies DES encryption for the account. This encryption type is used for compatibility.

• DES-CBC-MD5 = Specifies DES encryption for the account. This encryption type adheres to the MIT implementation and is used for compatibility.

• RC4-HMAC-NT = Specifies 128-bit RC4-HMAC encryption for the account. This is enabled by default.

• AES256-SHA1 = Specifies 256-bit AES encryption for the account.

• AES128-SHA1 = Specifies 128-bit AES encryption for the account.

• ALL = Specifies all of the above encryption types. Do not use this option if DES support is disabled.

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:

Generating the Keytab on Windows Servers 2016 or Windows Servers 2019

To generate the keytab file using the Ktpass tool:

1. Start a command prompt.

2. Enter the following command to generate the keytab file for the NIOS appliance user account:

• DNS = This is an example of the service name in uppercase format.

• ns1.corpxyz.com = This is an example of the instance in FQDN (fully-qualified domain name) format; this is the same as the DNS name of the NIOS appliance.

• GSS.LOCAL = This is an example of the Kerberos realm in uppercase format. This must be the same as the AD domain name.

• jsmith = This is an example of the AD user name for the NIOS appliance.

• GSS.LOCAL = This is an example of the Kerberos realm in uppercase. The realm (or domain name) must be the same as that specified in the -princ option.

• 37Le37 = This is an example of the password of the user account for the NIOS appliance.

• ns1.ktb = This is an example of the name of the keytab file.

• DES-CBC-CRC = Specifies DES encryption for the account. This encryption type is used for compatibility purposes.

• DES-CBC-MD5 = Specifies DES encryption for the account. This encryption type adheres to the MIT implementation and is used for compatibility purposes.

• RC4-HMAC-NT = Specifies 128-bit RC4-HMAC encryption for the account. This is enabled by default.

• AES256-SHA1 = Specifies 256-bit AES encryption for the account.

• AES128-SHA1 = Specifies 128-bit AES encryption for the account.

• ALL = Specifies all of the above encryption types. Do not use this option if DES support is disabled.

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:

Creating an External Zone for GSS-TSIG Updates

For each network view, specify the zone to be updated, the IP address of the primary DNS server for that zone, and the security method, GSS-TSIG. The zone must be in the same Active Directory domain as the member that is sending the updates.
You can add information for a forward and reverse zone. The DHCP server updates the A record in the forward zone and the PTR record in the reverse zone.
To enable the NIOS appliance to send dynamic updates to a DNS server using GSS-TSIG for authentication:

1. If there are multiple network views in the Grid, select a network view.

2. On the Data Management tab, select the DHCP tab, expand the Toolbar, and then click Configure DDNS.

3. In the DNS Updates to External Zones table of the DDNS Properties editor, click the Add icon and complete the following fields in the Add External DDNS Zone panel:

   • Zone Name: Enter the name of the zone that receives the updates. You can specify both forward-mapping and reverse-mapping zones.

   • DNS Server Address: Enter the IP address of the primary name server for that zone.

   • Security: Choose GSS-TSIG from the drop-down list, complete the following, and then click Add:

     • Active Directory Domain: Choose the Active Directory domain associated with the keytab file.

     • DNS Principal: The name and domain of the DNS server receiving the DDNS updates. Note that this value is not the same as the Kerberos principal you specified when you generated the keytab file.
       Use the following format when you complete this field: DNS/dns_server_fqdn@ad_domain
       dns_server_fqdn: This is the FQDN of the DNS server. You can use the "dig" command to perform a DNS lookup to obtain the FQDN of the DNS server as it appears on the SOA record.
       ad_domain: This is the Active Directory domain of the DNS server.

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

Verifying the Configuration

After you configure the AD domain controller and the Infoblox DHCP server, you can view the syslog of the Infoblox DHCP server to verify if it successfully established a security context with the AD domain controller. The DHCP server displays a series of messages similar to the following:

In addition, you can log in to the Infoblox CLI and use the show dhcp_gss_tsig CLI command to troubleshoot your configuration. For information about this command, refer to the Infoblox CLI Guide.

Sending Secure DDNS Updates to a DNS Server in Another Domain

Domain and forest trust relationships provide clients authenticated access to resources in other domains. Some trusts are automatically created, such as the two-way, direct trust between parent and child domains in a forest. Other trusts must be created manually. Refer to the Microsoft Active Directory documentation for information on establishing trusts between domains.
Once a direct trust exists between two AD domains, a KDC from one domain can grant a referral to the KDC of the other domain. The Infoblox DHCP server can then use the referral to request access to services in the other domain.
In the following figure the Infoblox DHCP server in the child.corpxyz.com domain needs to send GSS-TSIG authenticated DDNS updates to the DNS server in its parent domain, corpxyz.com domain. There is an automatic two-way trust between the domains because corpxyz.com domain is the parent of child.corpxyz.com domain.

Sending Secure DDNS Updates to a DNS Server in Another Domain
 

After you configure the Infoblox DHCP server and AD domain controller, the following occurs:

1. Kerberos – In Same Domain
   The Infoblox DHCP server uses the TGT (ticket-granting ticket) from the AD/Kerberos server, ad.child.corpxyz.com, to request a service ticket for DNS/ns1.corpxyz.com@corpxyz.COM. The Kerberos server replies with a referral ticket for the Kerberos server in the corpxyz.com domain, ad.corpxyz.com.

2. Kerberos — In the Other Domain
   The Infoblox DHCP server uses the referral ticket and requests a service ticket from ad.corpxyz.com for DNS/ns1.corpxyz.com@corpxyz.COM. The Kerberos server replies with a service ticket for DNS/ns1.corpxyz.com@corpxyz.COM.

3. TKEY Negotiations (GSS Handshake)
   The Infoblox DHCP server sends the DNS server ns1.corpxyz.com a TKEY (transaction key) request, which includes the service ticket. The DNS server replies with a TKEY response that includes a TSIG (transaction signature). The Infoblox appliance and the DNS server have established a security context, enabling the DHCP server to send DDNS updates to the DNS server.

Configuring DHCP to Send GSS-TSIG Updates to Another Domain

Before the DHCP server can send secure DDNS updates to a DNS server in a different domain, you must ensure that a direct trust relationship exists between the domain of the DHCP server and that of the DNS server. (For information, refer to the Active Directory documentation.)
Following are the tasks to configure the AD domain controller and the Infoblox DHCP server for secure updates to another domain. All the configuration is done on the AD domain controller for the domain of the DHCP server and on the Infoblox DHCP server.:

1. Complete the following tasks on the AD domain controller for the domain of the DHCP server:

   1. Add a user account for the Infoblox DHCP server. In the configuration example, the user account is ibdhcp. For information, see Creating an AD User Account above.

   2. Generate the keytab file for the Infoblox DHCP server and export it from the AD domain controller to a local directory on your management system. For the DHCP server in the Sending Secure DDNS Updates to a DNS Server in Another Domain,  the principal is ibdhcp/ib.child.corpxyz.com@CHILD.corpxyz.COM. For information, see Generating and Exporting the Keytab File above.

2. Complete the following tasks on the Infoblox DHCP server:

   1. Import the keytab file from your management system to the appliance and enable GSS-TSIG dynamic updates at the Grid or member level. For information, see Enabling GSS-TSIG Authentication for DHCP.

   2. Configure the external forward-mapping zone for the DDNS updates. Note that the DNS principal uses the domain of the DNS server, regardless of the domain of the DHCP server. For the DNS server in the figure Sending Secure DDNS Updates to a DNS Server in Another Domain above, the DNS principal is DNS/ns1.corpxyz.com@corpxyz.COM. For information, see Managing GSS-TSIG keys.

Configuration Example

Following are the steps to configure the example shown in the figure Sending Secure DDNS Updates to a DNS Server in Another Domain above:

On the Active Directory domain controller:

1. Create a user account for the Infoblox DHCP server. The user account is ibdhcp.

2.  

On the Infoblox DHCP server:

1. Enable GSS-TSIG at the member level.

2. From the DHCP tab, click the Members tab -> member checkbox -> Edit icon.

3. On the DDNS -> Basic tab of the editor, complete the following:

   • Override: Select this checkbox.

   • DDNS Updates: Select the Enable DDNS Updates checkbox.

   • GSS-TSIG: Select Override, and then complete the following:

     • Enable GSS-TSIG Updates: Select this checkbox.

     • Domain Controller (KDC): Enter ad.child.corpxyz.com. This is the KDC in the domain of the DHCP server.

     • Manage Key tab Files: Click Manage Key tab Files. In the Manage GSS-TSIG Keys dialog box, click the Add icon. Click Select, navigate to the keytab file, select the keytab file that you just uploaded, ibdhcp/ib.child.corpxyz.com@CHILD.corpxyz.COM, and then click Upload. Click Close.

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

5. Configure the external forward mapping zone, corpxyz.com:

   1. On the DHCP tab, expand the Toolbar, and then click Configure DDNS.

   2. In the DNS Updates to External Zones table of the DDNS Properties editor, click the Add icon and complete the following fields in the Add External DDNS Zone panel:

      • Zone Name: Enter corpxyz.com.

      • DNS Server Address: Enter the IP address of the primary DNS server to which the Infoblox DHCP server sends DDNS updates. In the example, the DNS server is ns.corpxyz.com. Therefore, enter its IP address, which is 10.23.2.24.

      • Security: Choose GSS-TSIG from the drop-down list, complete the following, and then click Add:

        • Active Directory Domain: Choose child.corpxyz.com.

        • DNS Principal: Enter DNS/ns1.corpxyz.com@corpxyz.COM.

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

Sending GSS-TSIG Updates to a DNS Server in Another Forest

The Infoblox DHCP server can also send secure DDNS updates to a DNS server that belongs to a domain in another forest, as long as a forest trust exists. Refer to the Microsoft Active Directory documentation for information on establishing forest trusts.
Similar to the authentication process between domains, the authentication process between forests also uses referrals. The appliance follows the referral chain until it reaches the domain controller of the domain in which the service is located. Note that forest trusts are not transitive. For example, if the DHCP server is in forest A and the DNS server is in forest C, a direct trust must exist between forest A and forest C for the DDNS updates to succeed. Having a trust between forest A and B, and between forest B and C is not sufficient.
In the below figure, a trust exists between the A.Local forest and the B.Local forest. The Infoblox DHCP server in the A.Local forest needs to dynamically update the DNS server in the B.Local forest.

Sending Secure DDNS Updates to a DNS Server in Another Forest

The following authentication process occurs:

1. Kerberos – In Same Domain
   The Infoblox appliance uses the TGT (ticket-granting ticket) from the AD/Kerberos server, ad.child.corpxyz.com, to request a service ticket for DNS/ns1.corp200.com@CORP200.COM. The Kerberos server does not find the principal name in its domain database and after consulting the global catalog, it replies with a referral ticket for its parent domain.

2. Kerberos — Referral Chain
   The appliance contacts a domain controller in corpxyz.com and requests a referral to a domain controller in the corp200.com domain in B.Local Forest.
   When it receives the referral, the DHCP server contacts the domain controller and requests a service ticket for the DNS server, ns1.corp200.com. The domain controller replies with a service ticket for[ DNS/ns1.corp200.com@CORP200.COM.|mailto:DNS/ns1.corp200.com@CORP200.COM]

3. TKEY Negotiations (GSS Handshake)
   The Infoblox appliance sends the DNS server ns1.corp200.com a TKEY (transaction key) request, which includes the service ticket. The DNS server replies with a TKEY response that includes a TSIG (transaction signature). The Infoblox appliance and the DNS server have established a security context.

Configuring DHCP to Send GSS-TSIG Updates to a Different Forest

Configuring the Infoblox DHCP server for dynamic updates to a DNS server in another forest is similar to the configuration used to send dynamic updates to another domain in the same forest. For information, see Configuring DHCP to Send GSS-TSIG Updates to Another Domain section.