Single sign-on

Customers using the Nexthink classic platform must transition to the cloud-native SSO mechanism.

If your SSO users' names do not follow the email format, refer to Phase 1 - Prepare for transition and remove Finder extended documentation—part of the transition procedure to Nexthink Infinity.

Many organizations adopt identity and access management (IAM) solutions to facilitate employee access to business applications through a single corporate login. This technique is known as single sign-on (SSO) access control. SSO improves the organization's security by reducing the passwords employees must remember and type in.

Security Assertion Markup Language (SAML) is a standard for exchanging authentication and authorization information securely between parties, namely the service provider which is an application that needs to authenticate users and the identity provider which is a system that issues assertions about user identity. SAML is widely used in organizations to implement SSO.

By leveraging SAML, allow Nexthink users to log in to the Nexthink web interface and Finder (classic) through your existing corporate identity provider.

Prerequisites

To enable SAML-based authentication of Nexthink users, you need an IAM corporate solution that supports SAML to provide a single sign-on authentication method. As an identity provider (IdP), the system must support the HTTP redirect binding to initiate SSO authentications with the Nexthink instance.

Within the authentication flow, those systems trying to connect to a Nexthink instance, if not already authenticated, are redirected to a secure gateway to obtain authorized access. Ensure your IT infrastructure allows access to the following URL:

https://<instance>-login.<region>.nexthink.cloud

<instance> is the name of the Nexthink instance
<region> is the name of the localization of the instance
- us for the United States
- eu for the European Union
- pac for the Asia-Pacific region
- meta for the Middle East, Turkey and Africa

Also, make sure you have the following:

A local administrator account to access the Nexthink web interface
One or more Nexthink user roles in your Nexthink instance
Users and groups of users in your SAML identity provider

Accessing single sign-on management

Select the Administration module from the main menu.
Select Single sign-on under the Account management section.

If you don’t see the menu entries, ensure your role has the right permissions.

User provisioning

By default, the user interface page shows a list of SSO groups. User provisioning is mandatory, as manually adding users creates local accounts only. The User provisioning tab remains grayed out until you have finalized the SSO configuration.

Map the groups defined in your IdP to the Nexthink user roles:

Connect to the Nexthink web interface using a local user account with administrative privileges.
Go to the Single sign-on configuration page and select the User provisioning tab.
Click on the New SSO group button in the top-right corner of the page.
- Enter the name of the group in the SSO group field.
  - When using Azure AD as an IdP, use the group identifier instead of the group name.
  - When using Active Directory Federation Services (AD FS), use the domain as a prefix to the name of the group: <domain>/<group_name>.
- For Role, select a user role from the list.
Optionally, repeat the previous step to add more mappings.
Click Save.

During login, the Nexthink web interface grants access to all users who are members of at least one of the mapped groups. The assigned role determines the exact permissions of the user.

Determining mapping precedence

Since users may belong to more than one group, the order in which you specify the mapping of the groups is important. If a user belongs to two groups and both groups are mapped to different roles, the system assigns the user to the roles that is mapped to the first group in the list.

The Everyone group

It is not possible to map an SSO group named Everyone as only the system can use it. The system rejects any mapping of groups named Everyone.

SSO configuration

To enable and configure SSO, as a Nexthink administrator:

Go to the Single sign-on configuration page
Select the SSO configuration tab.

The Nexthink SSO mechanism relies on technologies powered by Okta. There may be some references to the okta.com domain name during the setup phase, for example, inside the metadata.xml file provided by the Nexthink web interface. You may need to allow URLs oktacdn.com URLs in your firewall rules.

Once enabled, it might take a few minutes before all the new settings reach the various application layers and the Nexthink instance switches to the new authentication process.

Set up the SSO configuration tab as follows:

Toggle the SAML 2.0 authentication switch.
In the Upload IdP metadata section, configure the various fields using the information from your identity provider.
- IdP Issuer URI: The issuer URI of the identity provider. This value is usually the SAML Metadata entityID of the identity provider EntityDescriptor.
- IdP Single sign-on URL: The binding-specific, identity provider authentication request protocol endpoint that receives SAML AuthnRequest messages from the Nexthink instance. Nexthink uses HTTP-GET for its AuthnRequests. Please select HTTP-Redirect binding and not HTTP-POST.
- IdP Signature Certificate: The PEM or DER encoded public key certificate of the identity provider used to verify SAML message and assertion signatures. It must be Base64 encoded.
Download the Nexthink metadata.xml file and use it to configure SSO access with the identity provider.
Select the SAML options. SAML messages can be sent using different methods, called bindings:
- HTTP Redirect uses the HTTP Redirect method to send SAML messages. The content is sent using URL parameters. This is the default option.
- HTTP POST uses the HTML form to send SAML message via a POST request. Choose this option when SAML message content is too large to send it using URL parameters.
Configure the Attributes names used when provisioning users to retrieve user information. You must configure your identity provider to send those values as SAML attributes with the specified names. If the identity provider does not support custom attribute names to match Nexthink names, adjust them:
- Group attribute: The SAML attribute to retrieve the list of user groups. A user must have at least one group that matches a group defined in the user provisioning section to access Nexthink. The default value is nexthink.groups.
- Full name attribute: The SAML attribute to retrieve the user’s full name. The default value is nexthink.fullname.
- Email address attribute: The SAML attribute to retrieve the user’s email address. The default value is nexthink.email.
- Name ID format attribute: The expected format of the name. Some identify providers require to set it to urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. The default value is urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified.

After configuring Single sign-on (SSO), Nexthink displays the SSO login page by default. Therefore, Non-SSO local users must use the "/login" page for authentication.

For more information read Logging in to the web interface documentation.

SSO configuration examples

Configuring Active Directory Federation Services (AD FS) as an identity provider

As a Nexthink administrator, go to the Single sign-on configuration page and select the SSO Configuration tab.
Toggle the SAML 2.0 authentication switch if not already enabled.
Set the metadata values as follows:
- IdP Issue URI as https://<yourdomain.com>/adfs/services/trust and replace <yourdomain> with the fully qualified domain name (FQDN) of your AD FS server.
- IdP Single sign-on URL as https://<yourdomain.com>/adfs/ls and replace <yourdomain.com> with the fully qualified domain name (FQDN) of your AD FS server.
Download the Nexthink metadata.xml file.
Log in to the Windows Server system running AD FS as an administrator.
Open the AD FS management console.
Right-click on Relying Party Trusts and select Add Relying Party Trust... to trigger the wizard to add a trusted relying party.
- In the Welcome step, choose a Claims aware relying party.
- Click Start.
- On the Select Data Source step, select the option Import data about the relying party from a file.
- Click Browse... to specify the location of the metadata.xml file.
- Select the metadata.xml file and click Open.
- Click Next.
- On the Specify Display Name step, type in a suitable name for the relying party.
- (optional) Type in any additional information about the relying party under Notes.
- Click Next repeatedly to skip the rest of the steps in the wizard until you reach the last one.
- Click Close to complete the process.
On the left-side tree, click Relying Party Trusts to get the list of trusted relying parties.
Right-click the trusted relying party entry that represents the newly added Nexthink web interface.
From the context menu, select the entry to edit the policy for issuing claims:
- In Windows Server 2016, select Edit Claim Issuance Policy....
- In Windows Server 2012, select Edit Claim Rules....
In the Issuance Transform Rules tab, click Add rule... to map the UPN of the user to the Name ID, which the Nexthink web interface matches against the username field for authenticating.
- For Choose Rule Type select Send LDAP Attributes as Claims under Claim rule template.
- Click Next.
- For Configure Claim Rule:
  - For Claim rule name, enter a proper name for the rule, for example, Map UPN to Name ID.
  - For Attribute store select Active Directory.
  - For Mapping of LDAP attributes to outgoing claim types select User-Principal-Name for LDAP Attribute, and Name ID for Outgoing Claim Type.
- Click Finish.
Return to the Issuance Transform Rules tab and click Add rule... to add a new rule to send the UPN as Name ID in an email format.
- For Choose Rule Type select Transform an Incoming Claim under Claim rule template.
- Click Next.
- For Configure Claim Rule:
  - For Claim rule name, enter a proper name for the rule, for example, UPN as Name ID in email format.
  - For Incoming claim type, select UPN.
  - For Outgoing claim type, select Name ID.
  - For Outgoing name ID format, select Email.
  - Keep the option Pass through all claim values checked.
- Click Finish.
Again in the Issuance Transform Rules tab, click Add rule... to add the claims.
- For Choose Rule Type select Send LDAP Attributes as Claims under Claim rule template.
- Click Next.
- For Configure Claim Rule:
  - For Claim rule name enter a proper name for the rule, for example, Nexthink claims.
  - For Attribute store select Active Directory.
  - For Mapping of LDAP attributes to outgoing claim types select Token-Groups - Qualified by Domain Name and Group as Outgoing Claim Type.
  - Add one line and for Mapping of LDAP attributes to outgoing claim types select Display-Name and Surname as Outgoing Claim Type.
  - Add one line and for Mapping of LDAP attributes to outgoing claim types, select E-Mail-Addresses and E-Mail Address as Outgoing Claim Type.
- Click Finish
- Click OK.
Right-click again on the trusted relying party entry that represents the Nexthink web interface.
Select Properties from the menu. The dialog box to watch and modify the properties of the relying party appears.
- Under the Advanced tab, select SHA-256 for Secure hash algorithm.
- Click OK to close the properties dialog box.
Download the signature certificate of the AD FS server by expanding Service and clicking on Certificates. Double-click on the Token-signing certificate, go to the Details tab, and click on Copy to File... to open the certificate export wizard:
- Select Base-64 encoded X.509 (.CER) and click Next.
- Save the file for later.
Return to the Nexthink web interface as a Nexthink administrator, go to the Single sign-on configuration page and select the SSO Configuration tab.
Upload the signature certificate retrieved from the AD FS management console.
Set the attribute values as listed below.
- Group attribute as http://schemas.xmlsoap.org/claims/Group.
- Full name attribute as http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname.
- Email address attribute as http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.
- Name ID format attribute as urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified.
Click on Save.
Now, follow the instructions related to user provisioning.

Configuring Entra ID as an identity provider

As a Nexthink administrator, go to the Single sign-on configuration page and select the SSO Configuration tab.
Toggle the SAML 2.0 authentication switch if not already enabled.
Download the Nexthink service provider metadata file (metadata.xml). You will use this file later.
Log in to the Azure portal.
Click on Enterprise applications, then New Application, and finally Create your own application.
On the right-side panel labeled Create your own application, enter the application name, for example, Nexthink for the Input Name field, and select Integrate any other application you don't find in the gallery (Non-gallery)
Click on Set up a single sign on, then SAML, and finally Upload metadata file.
Click the Upload metadata file button located in the top-left corner of the page.
Select the metadata.xml file and save it.
Click the pencil icon in the top-right corner of the second tile to edit the Attributes & Claims. The page to edit the claims will appear.
- Ensure that the Unique User Identifier (Name ID) is the user principal name (UPN) in the email format:
  - user.userprincipalname [nameid-format:emailAddress]
Click the Add a group claim button to include the user groups in the issued SAML assertions.
- Choose Groups assigned to the application, for the groups associated to the user to be returned in the claim.
- Select Group ID for the Source attribute to return.
- Under Advanced options, tick Customize the name of the group claim.
- For the Name (required) field use nexthink.groups.
- Click Save to return to the User Attributes & Claims page.
Click the button Add new claim to include the full name of the user in the issued SAML assertions to load the Manage user claims page.
- For the Name field use nexthink.fullname.
- Choose Attribute as the type of Source.
- For the Source attribute field use user.displayname.
- Click Save.
Click the button Add new claim to include the user email in the issued SAML assertions to load the Manage user claims.
- For the Name field use nexthink.email.
- For the Source attribute field use user.mail or user.userprincipalname.
- Click Save.
Take note of the Login URL and Microsoft Entra Identifier. You will use them later when configuring the SSO for your Nexthink instance.
On the third tile of the page SAML Signing Certificate, click the Download link associated with the first entry: Certificate (Base64).
Obtain the identifiers of the groups in Entra ID to map them to Nexthink roles later.
- Go back to the main page of the Azure portal and click on Microsoft Entra ID in the left-side panel.
- Under Manage, select Groups. The list of active groups appears on the page Groups - All groups.
- Select one of the groups you wish to map to a Nexthink role.
- In the left-side menu of the page, select Properties under Manage.
- On the Properties page, under the General settings section, click the paper icon to the right of the Object ID field to copy the group identifier.
- Paste the Object ID somewhere else, for example, in a text editor, and save it for later use.
- Click Discard at the top of the Properties page to return to the group selection and repeat the operation for as many groups as you need to map to Nexthink roles.
Return to the Nexthink web interface as a Nexthink administrator, go to the Single sign-on configuration page, and select the SSO Configuration tab.
Set the metadata values as follow:
- IdP Issue URI as Microsoft Entra Identifier gathered before.
  In some cases, you must add a / character at the end.
- IdP Single sign-on URL as Login URL gathered before.
Upload the IdP signature certificate downloaded from the Azure portal.
Set the attribute values as follows:
- Group attribute as nexthink.groups
- Full name attribute as nexthink.fullname
- Email address attribute as nexthink.email
- Name ID format attribute as urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
Click on Save.
Now, follow the instructions related to user provisioning.

Configuring a generic SAML identity provider

Although it is impossible to detail the configuration instructions for every SAML identity provider available on the market, the procedure to configure a compliant provider should not differ significantly from the examples above.

Metadata

Entity ID

Assertion Consumer Service (ACS)

ACS Binding

NameID format

As a Nexthink administrator, go to the Single sign-on configuration page and select the SSO Configuration tab.

Toggle the SAML 2.0 authentication switch if not already enabled.

Download the Nexthink metadata.xml file.

See the metadata.xml file.

urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

Once SSO has been configured, follow the instructions related to user provisioning.

Permissions

To enable proper permissions for single sign-on management:

Select Administration from the main menu.
Click on Role from the navigation panel.
Click on the New Role button to create a new role, or edit an existing role by hovering over it and clicking on the edit icon to change the role configuration.
In the Permissions section, scroll down to the Administration section and enable Administrator rights.

Refer to the Roles documentation for a detailed description of the permission options.

Transitioning from SSO (classic)

If you already configured SSO before March 15, 2023, you might see a message asking you to configure it again. Proceed with the configuration as soon as possible, as support for the classic SSO mechanism ends on March 31, 2025. Log in to Nexthink Community and follow the steps defined in the guide.

RELATED TASKS

Audit trail codes application

Last updated 2 days ago