Canonical domain names for Windows authentication
Overview
Thanks to Windows authentication (SSO), Nexthink users can conveniently log in either to the Portal or to the Finder without the need to type in their credentials each time.
When configuring Windows authentication for Nexthink, ensure that you set the canonical name of your domain (and not an alias) as the Service Principal Name which associates the service instance to the service logon account of Nexthink (nxtPortalSSO). Failing to do so results in users not able to log in through Windows authentication.
DNS zones and resource records
DNS zones map domain names to IP addresses and other resources. Each resource record in a DNS zone defines a single mapping. We focus our attention on two types of records:
Type A records, which map a domain name to an IP address.
Type CNAME records, which define a domain name that is an alias for another domain name (the canonical name).
Let us consider an example of a DNS zone with two resource records. It is a Forward Lookup Zone whose name is example.com, which is the suffix of all the hosts in the zone. The DNS snap-in of the Administrative Tools of Windows Server shows the resource records as follows:
| Name | Type | Data |
|---|---|---|
portal | Host (A) |
|
myportal | Alias (CNAME) |
|
The first resource record in the zone, portal, is a record of type A. The record maps the name portal.example.com to the IP address 192.168.1.100. If this host provides the authentication service, portal.example.com is the canonical name that you must set as Service Principal Name to properly configure Windows authentication for Nexthink.
The second resource record in the zone, myportal, is a record of type CNAME. The record defines an alias for portal.example.com that is called myportal.example.com. While the alias myportal can replace the canonical name portal in many contexts, it is not suitable for configuring Windows authentication in Nexthink.
RELATED TASK
Last updated