Active Directory authentication
Active Directory authentication
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.
How authentication via AD works
To enable AD authentication in Nexthink, you just need to provide the User Principal Name (UPN) of a user when creating their account in Nexthink. Make sure that the AD account exists before adding it to Nexthink.
The UPN is composed of a user name followed by the UPN suffix (also called domain or realm), separated from the user name by @. For instance: [email protected]. Note that the old format DOMAIN\username is not supported.
Beware that the username part 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. 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
Since Nexthink uses the UPN suffix to resolve the name of the AD server, you must use fully qualified domain names in the UPN of users. Alternate UPN suffixes defined by administrators do not work.
For instance, if the fully qualified domain name of a department inside a company is department.example.com, an administrator may create an alternate UPN suffix dep.com that is easier to memorize and quicker to type. A user in that department may thus log in to Windows using either:
However, the user cannot log in to the Finder or the Portal using the shorter UPN suffix. Neither the Engine nor the Portal know about alternate UPN suffixes. You must use the fully qualified domain name version as user account in Nexthink.
To know the full name of a user that is logged in to Windows, open the Finder and tick the box Use Windows authentication in the login dialog. The retrieved user name is the actual full name of the user:
Connectivity with AD server
For the Portal to be able to connect with the AD server, the appropriate ports must be open in the appliances on which they run.
- UDP 53 for DNS.
- TCP 389 and TCP 636 for non-secure and secure LDAP connections to the AD server.
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.
Nexthink supports the following encryption methods:
- AES (128 bits)
On the other hand, DES encryption (legacy for Windows 98) is not supported.
Finder session saving
The Finder allows to 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.