The integration with Microsoft Active Directory allows NS1 Enterprise DHCP to send dynamic DNS (DDNS) updates to Microsoft AD DNS servers.
- You must have at least one DHCP container with DDNS enabled.
- The Microsoft AD server must have the DNS role configured.
- Optionally, an AD user with a service principal name assigned and the corresponding keytab file created and exported.
If using an insecure connection type, you do not need to create a service account or keytab file. Skip ahead to step 4.
Step 1: Create an Active Directory user account
*Required if using GSS-TSIG
If you plan to send GSS-TSIG signed DDNS updates to a Microsoft DNS server, you must create an Active Directory user account dedicated to authentication.
Log into the Windows Domain Controller for your Active Directory domain to which your Microsoft DNS server is joined.
Click the Windows Start button, and navigate to Windows Administrative Tools > Active Directory Users & Computers.
- Right-click your domain in the list, and select New > User.
- In the New Object - User dialogue box, enter the following information:
*Indicates a required field.
- First name
- Last name
- Full name*
- User logon name*
Note the user logon name is used again for generating the keytab file, NS1 recommends creating a login name that clearly indicates the purpose of the user account to be used for DDNS updates by the NS1 DHCP server (ex. ns1-ddns-svc).
- Enter a password twice, and then select the following options:
- De-select (disable) the “User must change password at next logon” option
- Select (enable) “User cannot change password”
- Select (enable) “Password never expires.
Click Next to view a summary.
Click Finish. This creates a new user account.
Step 2: Generate a keytab file
*Required if using GSS-TSIG
If you plan to send GSS-TSIG signed DDNS updates to a Microsoft DNS server, you must create a keytab file on the Microsoft AD Domain Controller. A keytab is a file containing pairs of Kerberos principals and encrypted keys (which are derived from the Kerberos password). You can use a keytab file to authenticate to various remote systems using Kerberos without entering a password. This is required for performing secure, authenticated DNS updates from NS1 to AD DNS.
- Click the Windows Start button, and navigate to Windows System > Command Prompt.
- Run the command below to use ktpass to assign a Kerberos service principal name to the user account you created in step 1, and to generate a keytab file containing this information.
ktpass -princ DNS/[User Logon Name]@[AD DOMAIN NAME] -mapuser [User Logon Name]@[AD DOMAIN NAME] -pass [Password] -out mykeytab.keytab -ptype krb5_nt_principal -crypto AES128-SHAwhere
- [User Logon Name] is the username for the service account you created in step 1.
- [AD Domain Name] is the domain name that must map to the AD service account as created in Step 1.
- [Password] is the service user account password you created in step 1. Note that changing the password value here will reset the password associated with the service account.
Example: If the username is ns1-ddns-svc and the AD Domain Name is addev.ns1.com, the command used would be:
ktpass -princ DNS/ns1-ddns-svc@ADDEV.NS1.COM -mapuser ns1-ddns-svc@ADDEV.NS1.COM -pass MyPas$w0rd -out mykeytab.keytab -ptype krb5_nt_principal -crypto AES256-SHA1The example above generates a keytab file called mykeytab.keytab in the current working directory. In the next step, we will upload the keytab file to the NS1 portal.
Step 3: Upload the keytab file
*Required if using GSS-TSIG
Log into the NS1 Enterprise DDI portal, and navigate to the Security tab.
On the Service Principals page, click the add (+) icon to add a new service principal ID.
- Under Upload Keytab File, click Keytab and locate the file you created in the previous step. Then, click Open.
- Click Upload. The service principal(s) contained in the keytab file appear in the list. Note the Principal Details sidebar containing details about the keytab file as configured in step 2.
Step 4: Connect to a remote server
In this step, you will create a pointer (remote connection) to the remote Windows server.
- Log into the NS1 portal, navigate to DHCP > Remote Servers.
Click the add (+) icon to create a remote, authoritative DNS server.
Enter the DNS server FDQN or IP address, the port number (optional).
Select the connection type—either "Insecure" or "GSS-TSIG secure." If you select the “secure” option, you must also provide the KDC Server FDQN or IP address. This is likely the same server you used to generate the keytab. Enter the KDC server port number (optional), and select one of the service principals from the drop-down list.
If GSS-TSIG is selected as the connection type, the time of the computer upon which the DHCP containers running must be within five minutes of the AD servers—otherwise the dynamic updates will fail.
- Click Save Remote Server.
The update mechanism used by NS1 DHCP must match that of Microsoft AD DNS server. Within the AD DNS zone properties, navigate to the General tab. If the Dynamic Updates setting is set to “Secure Only,” you must use the GSS-TSIG connection type and a service principal must be assigned. If the Dynamic Updates setting is set to “Nonsecure and Secure,” you can use either the insecure or GSS-TSIG secure connection type. Validate this for both the forward lookup and reverse lookup zones. The NS1 DHCP server will try an insecure update first, followed by a secure update if the AD DNS server is configured for “nonsecure and secure” or “secure” updates.
Step 5: Configure a remote forward & reverse zone
In this step, you will create forward and reverse remote zones, and connect it to a scope group and service principal.
- Navigate to DHCP > Remote Zones.
- Click the add (+) icon to create a new remote zone.
Enter the domain name.
Select the remote server from the list.
Select an existing DHCP scope group. (Refer to this article for instructions on how to create a scope group.)
Click Save Remote Zone. The new zone appears in the list.
Additional information about the zone appears in the right-hand sidebar. This includes a “Last Update” indicator (Success or Failure) showing the last state of the DDNS update. It is not a health check.
Repeat steps 2-6 to create the corresponding reverse remote zone.
Step 6: Edit DDNS settings
In the last step, you must configure the DHCP scope group to allow for NS1 DDNS updates to the Microsoft server.
In the NS1 portal, navigate to DHCP > Management to view a list of existing scope groups.
Click the menu icon to the right of the scope group you specified in Step 5, and click Edit DDNS Settings.
- Under Edit DDNS Settings, select the Microsoft Active Directory DDNS option.
Under Choose a remote zone, start typing the names of the forward zone you created in step 5, and select it from the list.
- Similarly, start typing the name of the reverse zone you created in step 5, and select it from the list.
Optionally, enter a default suffix. This is the suffix we append to create an FQDN from the hostname if it isn’t included in the client request.
Optionally, enter a prefix. If NS1 is set to generate an FQDN for the client, the prefix is prepended to the FQDN.
Click Save Microsoft Active Directory DDNS settings.
This concludes the implementation process. Now, once a DHCP client receives an IP address from NS1, NS1 communicates with Kerberos to get authenticated and authorized to update the remote windows server and create a DDNS entry.