NS1 status

Articles in this section

See more

NS1 + Microsoft Active Directory DDNS

  • Updated
Follow

If you have deployed NS1 edge services (e.g., DNS and DHCP) in your network, you can configure dynamic DNS (DDNS) updates to achieve one of the following outcomes:

  • Option A: Configure DDNS such that you allow NS1 DHCP servers to send dynamic DNS (DDNS) updates to Microsoft Active Directory (AD) DNS servers.

  • Option B: Configure DDNS such that you allow Microsoft AD clients and servers to send dynamic updates to NS1 DNS servers.

If you allow NS1 to send dynamic updates to Active Directory DNS servers (option A), then the NS1 DHCP server will create resource records on behalf of a DHCP client whenever a lease is assigned. It will remove these records when the lease expires or is released.

If you are configuring the system for AD clients to send dynamic updates to NS1 DNS servers (option B), note that the NS1 DNS server can accept dynamic updates from any client sending unsigned or GSS-TSIG signed updates.

Before you begin, note the following:

  • You must have NS1 DNS and DHCP edge services deployed in your network.

  • You must have at least one DHCP service 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.

Option A: Configure DDNS updates from NS1 DHCP servers to Microsoft AD servers

Step 1: Create an AD user account

This is required if using GSS-TSIG. In order to send GSS-TSIG signed DDNS updates to a Microsoft DNS server, you must create an Active Directory user account dedicated to authentication.

  1. Log into the Windows Domain Controller for your Active Directory domain to which your Microsoft DNS server is joined.

  2. Click the Windows Start button, and navigate to Windows Administrative Tools > Active Directory Users & Computers.

  3. Right-click your domain in the list, and select New > User.

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

  5. Click Next.

  6. Enter a password twice, and then select the following options:

    • Deselect (disable) the “User must change password at next logon” option.

    • Select (enable) “User cannot change password.”

    • Select (enable) “Password never expires."

  7. Click Next to view a summary.

  8. Click Finish. This creates a new user account.

Step 2: Generate a keytab file

Warning

This step is required if using GSS-TSIG signed DDNS updates to or from a Microsoft DNS server. If you are using an insecure connection type, you do not need to create a service account or keytab file. Skip ahead to step 4. The NS1 DHCP server will first try an insecure update first, followed by a secure update if the AD DNS server is configured for "nonsecure and secure" or "secure" updates.

If you plan to send GSS-TSIG signed DDNS updates to or froma 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 DDNS updates.

  1. Click the Windows Start button, and navigate to Windows System > Command Prompt.

  2. 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/<dns_server_fqdn>@<AD DOMAIN NAME> -mapuser<USERNAME>@<AD_DOMAIN_NAME> -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1 -pass <PASSWORD> -mapOp set -out ns1dns.keytab

    • <dns_server_fqdn> is the fully-qualified domain name (FQDN) of the NS1 DNS server to receive the updates. Note that this value must be in all lowercase letters.

    • <AD_DOMAIN_NAME> is the domain name mapping to the AD service account created in step 1. Note that this value must be in all uppercase letters.

    • <USERNAME> is the username of the service account created in the previous step.

    • <PASSWORD> is the password of the service account created in the previous step.

    Example 1. Generating a keytab file

    The example below assumes the username to be ns1-ddns-svc, an AD domain of example.com, the NS1 DNS server FQDN to be ns1dns1.mydomain.test, a password set to MyPas$w0rd, and the desired output filename to be ns1dns.keytab.

    ktpass -princ DNS/ns1dns1.mydomain.test@EXAMPLE.COM -mapuser ns1-ddns-svc@EXAMPLE.COM -pass MyPas$w0rd -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1 -mapOp set -out ns1dns.keytab

Step 3: Upload the keytab file

Warning

This step is required if using GSS-TSIG signed DDNS updates to or from a Microsoft DNS server.

  1. Log into the NS1 portal and navigate to the Security tab.

  2. On the Service Principals page, click the add (+) icon to add a new service principal ID.

  3. Under Upload Keytab File, click Keytab and locate the file you created in the previous step. Then, click Open.

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

  1. Log into the NS1 portal and navigate to DHCP > Remote Servers.

    screenshot-remote_servers_page_empty_.png

  2. Click the add (+) icon to create a remote, authoritative DNS server.

    screenshot-create_remote_server.png

  3. Enter the DNS server FQDN or IP address and (optionally) the DNS server port. Note the default port is 53.

  4. Select the connection type:

    • Only nonsecure - (Not recommended) Relies on the IP address of the updating server only.

    • Nonsecure followed by secure - (Default method for most Microsoft clients) First, an insecure update method is attempted. If refused, a secure update using GSS-TSIG is attempted. This allows the Micorosft server to determine if insecure or GSS-TSIG secured should be used. If selected, you must also select a service principal from the list, enter a KDC server IP or FQDN, and (optionally) enter a KDC server port. Likely, this is the same server used to generate the keytab file.

      screenshot-create_remote_server__nonsecure_followed_by_secure_.png

    • Only secure - Note that if you select this option, you must also select a service principal from the list, enter a KDC server IP or FQDN, and (optionally) enter a KDC server port. Likely, this is the same server used to generate the keytab file.

      screenshot-create_remote_server__using_only_secure_connection_.png

  5. Click Save remote server.

Step 5: Configure a remote forward and reverse zone

In this step, you will create forward and reverse remote zones, and connect it to a scope group and service principal.

  1. In the NS1 portal, navigate to DHCP > Remote Zones.

    Screenshot of the DHCP > Remote Zones page without any remote zones configured.

  2. Click the add (+) icon to create a new remote zone.

    screenshot-create_a_remote_zone_part_1.png

  3. Enter the fully-qualified domain name (FQDN) of the remote zone.

  4. Select one of the following Zone update methods:

    • Nonsecure (Not recommended)

    • Nonsecure followed by secure (GSS-TSIG)

    • Secure (GSS-TSIG)

    Warning

    Do not select the Secure (TSIG) method as this is not supported by Microsoft AD.

  5. Based on the update method you select, a list of remote servers with matching update methods appears in the drop-down menu. Select the remote server you created in the previous step.

    screenshot-create_a_remote_zone_nonsecure_followed_by_secure_.png

  6. Click Next.

    screenshot-create_a_remote_zone__part_2_.png

  7. Select an existing DHCP scope group. Refer to Managing scope groups for details.

  8. Then click Save Remote Zone. The new zone appears in the list.

    Note

    You can select a remote zone from the list to view details in the sidebar on the right.

  9. Repeat this process 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.

  1. In the NS1 portal, navigate to DHCP > Management to view a list of DHCP scope groups.

  2. Next to the scope group you associated with the remote zone in the previous step, select the menu icon screenshot-menu_icon.png and select Edit DDNS settings.

    screenshot-select_edit_ddns_settings.png

  3. Under Edit DDNS Settings, select Microsoft Active Directory DDNS.

    screenshot-edit_ddns_settings__active_directory_.png

  4. Under Choose a remote zone, start typing the names of the forward zone you created in step 5 and select it from the list. In the same field, enter the reverse zone you created in step 5 and select it from the list. Both the forward and reverse zones should appear under "Connected Remote Servers."

  5. Optionally, enter a default suffix. This is the suffix we append to create an FQDN from the hostname if it is not included in the client request.

  6. Optionally, enter a prefix. If NS1 is set to generate an FQDN for the client, the prefix is prepended to the FQDN.

  7. Click Save Microsoft Active Directory DDNS settings.

Now, once a DHCP client receives an IP address from NS1, NS1 communicates with Kerberos for authentication and authorization to update the remote Microsoft server and create a DDNS entry.

Option B: Configure DDNS updates from Microsoft AD to NS1 DNS servers.

Step 1: Create an AD user account

This is required if using GSS-TSIG. In order to send GSS-TSIG signed DDNS updates to a Microsoft DNS server, you must create an Active Directory user account dedicated to authentication.

  1. Log into the Windows Domain Controller for your Active Directory domain to which your Microsoft DNS server is joined.

  2. Click the Windows Start button, and navigate to Windows Administrative Tools > Active Directory Users & Computers.

  3. Right-click your domain in the list, and select New > User.

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

  5. Click Next.

  6. Enter a password twice, and then select the following options:

    • Deselect (disable) the “User must change password at next logon” option.

    • Select (enable) “User cannot change password.”

    • Select (enable) “Password never expires."

  7. Click Next to view a summary.

  8. Click Finish. This creates a new user account.

Step 2: Generate a keytab file

Warning

This step is required if using GSS-TSIG signed DDNS updates to or from a Microsoft DNS server. If you are using an insecure connection type, you do not need to create a service account or keytab file. Skip ahead to step 4. The NS1 DHCP server will first try an insecure update first, followed by a secure update if the AD DNS server is configured for "nonsecure and secure" or "secure" updates.

If you plan to send GSS-TSIG signed DDNS updates to or froma 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 DDNS updates.

  1. Click the Windows Start button, and navigate to Windows System > Command Prompt.

  2. 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/<dns_server_fqdn>@<AD DOMAIN NAME> -mapuser<USERNAME>@<AD_DOMAIN_NAME> -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1 -pass <PASSWORD> -mapOp set -out ns1dns.keytab

    • <dns_server_fqdn> is the fully-qualified domain name (FQDN) of the NS1 DNS server to receive the updates. Note that this value must be in all lowercase letters.

    • <AD_DOMAIN_NAME> is the domain name mapping to the AD service account created in step 1. Note that this value must be in all uppercase letters.

    • <USERNAME> is the username of the service account created in the previous step.

    • <PASSWORD> is the password of the service account created in the previous step.

    Example 2. Generating a keytab file

    The example below assumes the username to be ns1-ddns-svc, an AD domain of example.com, the NS1 DNS server FQDN to be ns1dns1.mydomain.test, a password set to MyPas$w0rd, and the desired output filename to be ns1dns.keytab.

    ktpass -princ DNS/ns1dns1.mydomain.test@EXAMPLE.COM -mapuser ns1-ddns-svc@EXAMPLE.COM -pass MyPas$w0rd -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1 -mapOp set -out ns1dns.keytab

Step 3: Upload the keytab file

Warning

This step is required if using GSS-TSIG signed DDNS updates to or from a Microsoft DNS server.

  1. Log into the NS1 portal and navigate to the Security tab.

  2. On the Service Principals page, click the add (+) icon to add a new service principal ID.

  3. Under Upload Keytab File, click Keytab and locate the file you created in the previous step. Then, click Open.

  4. 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: Assign the service principal(s) to the DNS service

  1. In the NS1 portal, navigate to DNS > Networks. Select the relevant Cloud-Managed DDI (or other DDI edge) network from the list to view its details on the right.

    screenshot-networks_page_add_principal_.png

  2. Click the Service Princpals tab on the right sidebar and click Add principal.

    screenshot-add_service_principals_modal.png

  3. Begin typing the name of the service principal created in the previous step, and select the principal(s) uploaded with the keytab file.

  4. Click the X in the upper-right corner to exit the modal.

Step 5: Import the zone file from Active Directory

  1. Run the command below from the Active Directory Domain Controller to export the zone file. By default, this file is stored in %systemroot%/System32/Dns directory.

    dnscmd [<servername>] /zoneexport <zonename> <zoneexportfile>

    For example, with a server and realm of ddi.test:

    dnscmd ddi.test /zoneexport ddi.test ddi-test.txt

  2. Modify the zone file:

    • At the top of the zone file, add $TTL <number> to indicate the zone's time-to-live (TTL) value. This is required for import into the NS1 platform. For more information, refer to Best Practices: TTL configuration.

    • Modify the existing A records to point to the NS1 DNS server (as opposed to the AD domain controller), except for the domain controller A record which is required for Kerberos authentication.

  3. In the NS1 portal, navigate to DNS > Zones, and then click Add Zone.

    screenshot-add_zone_22april2022_.png

  4. Enter the Domain name. This is the fully qualified domain name (FQDN) matching the zone name exported from Active Directory.

  5. Optionally, you can attach the zone to one or more DNS views if you created these already — otherwise, leave this blank as you will be instructed to create a new DNS view for this particular integration in step 9.

  6. Optionally, click Override zone name and enter a unique Zone name. The zone name is a nominal identifier for this zone that will be used later when configuring the access control list (ACL). If you do not enter a zone name, one will be automatically generated.

  7. Select the DNS network(s) on which to publish the zone. The network you select should match the network on which you applied the service principal. Likely, this is the Cloud-Managed DDI or another NS1 edge network.

  8. Under Zone Settings, select Zone file import. Click Browse files and select the Active Directory zone file you exported and edited.

    screenshot-create_zone-zone_file_import.png

  9. Click Save zone. The new zone (and the number of associated records that were also imported) appears in the list.

Step 6: Change the primary MNAME of the zone via API

After importing the AD zone into the NS1 platform, execute the command below to update the MNAME via API.

curl -skX PUT https://api.nsone.net/v1/zones/$AD_DOMAIN_NAME -H "X-NSONE-KEY: $NSONE_API_KEY" -d "{\"zone\": \"$AD_DOMAIN_NAME\", \"primary_master\": \"$SUBDOMAIN.$AD_DOMAIN_NAME\"}"

where

  • $AD_DOMAIN_NAME is the zone's FQDN as specified in the keytab file (e.g., addev.ns1.com).

  • $SUBDOMAIN is the subdomain specified in the keytab file (e.g., ns1dns)

curl -skX PUT https://api.nsone.net/v1/zones/addev.ns1.com -H "x-nsone-key: $NSONE_API_KEY" -d "{\"zone\": \"addev.ns1.com\", \"primary_master\": \"ns1dns.addev.ns1.com\"}"

Step 7: Create an A record and answer pointing to the NS1 DNS server

  1. In the NS1 portal, navigate to DNS > Zones. Click the name of the AD zone you imported in step 5 to view details.

  2. Click + Add record.

    screenshot-add_record.png

  3. Under Record Type, ensure type "A" is selected from the list.

  4. In the name field, enter the name of the NS1 DNS server (i.e., $SUBDOMAIN.$AD_DOMAIN_NAME).

  5. Enter a TTL value (in seconds). The default TTL is 3600 seconds (1 hour). For more information, refer to Best Practices: TTL Configuration.

  6. Under Answers, enter the IP address of the NS1 DNS server, and then click Add Answer to save it.

  7. Click Save record.

Step 8: Create an access control list

An access control list (ACL) is a named object associated with one or more IP addresses, TSIG keys, or GSS-TSIG identities (service principals). For the purpose of AD configuration, you will add an IP address and GSS-TSIG identity to the ACL.

  1. In the NS1 portal, navigate to DNS > ACLs, and then click the + sign to create a new ACL.

    screenshot-create_acl.png

  2. Enter a name for the access control list (e.g., ddnsupdate).

  3. Next to Add items, select one (or more) of the following options to specify the clients and/or identities who will have access to zone imported from AD:

    • IP address - Select this option if configuring nonsecure updates. Enter a client IPv4 address, subnet, or range.

    • GSS-TSIG identity - Select this option if configuring secure updates from the AD server (ie., if you generated and uploaded a keytab file). Enter the Kerberos Principals Name. This is a service principal that will be able to provide dynamic updates to the NS1 DNS server. For nonsecure updates, enter “*” as the GSS-TSIG identity. For secure updates, enter an exact match identity or a wildcard identity, for example, “*@DDI.TEST” or “CLIENT$@DDI.TEST” where “CLIENT” is the name of a client machine.

    Note

    You can specify multiple IP addresses, TSIG keys, and/or GSS-TSIG identities within the same ACL. The list of objects (i.e., addresses, keys, identities) you specify are processed from top to bottom where objects of the same type are processed using logical "or" statements and objects of different types are processed as logical "and" statements. You can rearrange the order of objects within an ACL to adjust the processing order and logic.

  4. Click Save ACL.

Step 9: Attach the ACL to a DNS view

In this step, you will attach the access control list (ACL) you just created to a new DNS view. Note that you can attach multiple ACLs to a single DNS view. In doing so, you must ensure the ACLs are organized in the proper "rule order."

  1. In the portal, navigate to DNS > Views.

  2. Click the plus sign (+) to create a new DNS view.

    screenshot-create_dns_view.png

  3. Enter a name for the DNS view.

  4. Optionally, enter the DNS network(s) on which you want to publish the DNS view. You can leave this field blank if you are not ready to publish the view.

  5. Next to ACLs, click the Update tab and begin typing the name of the ACL you created in the previous step. In doing so, you are giving the clients and/or identities listed in that ACL "write" access to the zones associated with this view.

    Note

    Granting someone “update” access does not automatically grant them “read” access.

  6. Next to ACLS, click the Read tab and re-enter name of the ACL you created earlier.

    Note

    If granting multiple ACLs “read” access, take note of the order in which they appear under ACL Rule Order. Queries are processed from top to bottom using logical “and” statements. To re-order the ACLs, click the icon to the left of an ACL and then drag-and-drop.

  7. Under Zones, begin typing the name of the zone imported from AD in step 5.

  8. Click Save view.

Related articles