Active Directory authentication

Overview

Nexthink supports the authentication of users via Active Directory services. Microsoft Active Directory (AD) is currently used as the authoritative user directory in a vast number of organizations, controlling the authentication and the access rights of users.

The benefits of integrating Nexthink with the AD services include the following:

Users need only one login and password (no need for a dedicated Nexthink account).
Administrators can take advantage of the password policy defined in AD.

For a better user experience, Nexthink recommends to combine AD authentication with Windows authentication, so that users can log in to Nexthink without having to retype their Windows credentials.

How authentication via AD works

To enable AD authentication in Nexthink, provide the user logon in the form someone@example.com when creating their account in Nexthink. Make sure that the AD account exists before adding it to Nexthink.

The user logon must be composed of the sAMAccountName of the user, followed by the domain or realm; both separated by the @ character. Note that the previous Windows logon format DOMAIN\username is not supported. Note as well that if a user got a User Principal Name (UPN) whose user logon name is different from the sAMAccountName, you still need to use the sAMAccountName when manually configuring the user's Nexthink account; otherwise, AD authentication will not work.

For example, if the sAMAccountName of user John Wick is jwick and he got assigned the user logon name (UPN prefix) john.wick, configure his Nexthink account with the first logon only:

jwick@example.com - UPN prefix equal to the sAMAccountName - Use this one.
john.wick@example.com - UPN prefix different from sAMAccountName.

To avoid the error prone manual creation of users and let users log in with their UPN (even if the UPN prefix does not match the sAMAccountName), Nexthink recommends the automatic provisioning of user accounts from Active Directory.

Beware that the account name part of the UPN is case sensitive. Thus, specify exactly the same name in Nexthink as it is registered in the AD, respecting the case. Nexthink uses the suffix part to resolve the name of the AD server (example.com in the example above), also known as the domain controller.

Once added to Nexthink, users can log in to the Finder or the Portal using their AD accounts (or Windows authentication, if enabled). During Finder login, the AD credentials provided by the user are forwarded to the Portal back-end using an encrypted channel. In the case of Portal login, the browser itself sends the AD credentials provided by the user to the Portal back-end. The Portal back-end is then responsible for contacting the AD server to authenticate the user.

Requirements for AD authentication

Allowed characters in user names

Use only printable characters in user names. The space and the following symbols are not allowed inside a user name:

/\[]:;|=,+*?<>@"&

Alternate UPN suffixes

Users provisioned who have an alternate UPN suffix defined, can authenticate in Portal and Finder using both their alternate UPN suffix or the UPN with the fully qualified domain name. To do so, it is required to use a mapping file so that the system knows which alternate UPN suffix is mapped to which fully qualified domain name. A sample mapping file is located in /var/nexthink/portal/conf/ad_upn_mappings.conf, and has the following content:

CODE

acme.com = ch.acme.com
acme.com = fr.acme.com

In this sample, the alternate UPN suffix acme.com is mapped both to the standard UPN suffixes ch.acme.com and fr.acme.com.

The mapping file has the following rules:

Lines starting with '#' are accepted as comments.
Empty lines are accepted
Mapping is defined in the form of alternate_suffix=standard_suffix.
- Separating spaces between suffixes and '=' are accepted, for instance alternate_suffix = standard_suffix.
'=' and space characters are not supported inside the suffixes:
- alternate suffix=standard_suffix is invalid.
- alternate=suffix=standard_suffix is also invalid.
Duplicate mappings are forbidden (twice the exact same mapping).
The maximum number of mappings is 50.
After updating the mapping file the portal needs to be restarted.

Note that if two users have the exact same UPN prefix, they need to use their fully qualified domain names to login. For instance, if ACME has two fully qualified domain names ch.acme.com and fr.acme.com, an administrator may create an alternate UPN suffix acme.com that is easier to memorize and quicker to type. If there are two users whose UPN are username@ch.acme.com and username@fr.acme.com, they must login using these UPN. If they use the alternate UPN suffix and try to login using username@acme.com, it will not work and the following error message will be displayed: "Authentication failed! The credentials you entered are invalid or cannot be authenticated."

Connectivity with AD server

For the Portal to be able to connect with the AD server, allow outgoing connections from the appliance on which the Portal runs through the following ports:

UDP port 53, for DNS.
TCP and UDP port 88, for Kerberos authentication on the AD server.
TCP ports 389 and 636, for non-secure and secure LDAP connections to the AD server.

Time synchronization

Because of the technique used for authenticating users, the Portal must be synchronized with the clock of the AD server. The configuration of the AD server may nevertheless specify a tolerance regarding clock discrepancy. A difference of at most 5 minutes is generally accepted by default.

Encryption methods

Nexthink supports the following encryption methods:

AES (128 bits)
RC4-HMAC

On the other hand, DES encryption (legacy for Windows 98) is not supported.

Finder session saving

The Finder can save sessions and user credentials. This applies to AD credentials as well. If the user chooses to additionally save the password, then the Finder stores only a hash of the password for security reasons.

RELATED TASKS

RELATED REFERENCE

Connectivity requirements