# Single sign-on {% hint style="warning" %} 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](https://edocs.nexthink.com/infinity-transition/infinity-transition-phases/phase-1-prepare-for-transition-and-remove-finder#step-6-transition-to-the-cloud-native-single-sign-on-sso) extended documentation—part of the transition procedure to Nexthink Infinity. {% endhint %} 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 *s*ingle 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://-login..nexthink.cloud` * `` is the name of the Nexthink instance * `` 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](https://docs.nexthink.com/platform/user-guide/administration/account-management/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](#singlesign-on-permissionspermissions).
## Account provisioning By default, the user interface page shows a list of SSO groups. Account provisioning is mandatory, as manually adding users creates only local accounts. The Account provisioning tab remains grayed out until you have finalized the SSO configuration.
Map the groups defined in your IdP to the Nexthink user roles: 1. Connect to the Nexthink web interface using a local user account with administrative privileges. 2. Go to the **Single sign-on** configuration page and select the **Account provisioning** tab. 3. 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: `\`. * For **Role**, select a user role from the list. 4. Optionally, repeat the previous step to add more mappings. 5. 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. {% hint style="info" %} **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*. {% endhint %} ## SSO configuration To enable and configure SSO, as a Nexthink administrator: * Go to the **Single sign-on** configuration page * Select the [SSO configuration](#singlesign-on-ssoconfigurationssoconfiguration) tab. The Nexthink SSO mechanism relies on technologies powered by [Okta](https://www.okta.com). There may be references to `*.okta.com` and `*.oktacdn.com` domains name during the setup phase, for example, inside the `metadata.xml` file provided by the Nexthink web interface. Therefore, Nexthink recommends allowing Okta URLs in your firewall rules. Refer to the [connectivity-requirements](https://docs.nexthink.com/platform/configuring_nexthink/before-you-begin/technical-requirements/connectivity-requirements "mention") documentation. {% hint style="info" %} 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. {% endhint %}
Set up the **SSO configuration** tab as follows: 1. Toggle the **SAML 2.0 authentication** switch. 2. 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. 3. Download the Nexthink `metadata.xml` file and use it to configure SSO access with the identity provider. 4. 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. 5. 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`. {% hint style="info" %} 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](https://docs.nexthink.com/platform/getting-started/logging-in-to-the-web-interface) documentation. {% endhint %} ## SSO configuration examples #### **Configuring Active Directory Federation Services (AD FS) as an identity provider** 1. As a Nexthink administrator, go to the **Single sign-on** configuration page and select the **SSO Configuration** tab. 2. Toggle the **SAML 2.0 authentication** switch if not already enabled. 3. Set the metadata values as follows: * **IdP Issue URL** as `https:///adfs/services/trust/` and replace `` with the fully qualified domain name (FQDN) of your AD FS server. * **IdP Single sign-on URL** as `https:///adfs/ls/` and replace `` with the fully qualified domain name (FQDN) of your AD FS server. {% hint style="warning" %} Note that the values can contain `http` instead of `https`, depending on the AD FS metadata. {% endhint %} 1. Download the Nexthink `metadata.xml` file. 2. Log in to the Windows Server system running AD FS as an administrator. 3. Open the AD FS management console. 4. 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. 5. On the left-side tree, click **Relying Party Trusts** to get the list of trusted relying parties. 6. Right-click the trusted relying party entry that represents the newly added Nexthink web interface. 7. 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...**. 8. 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**. 9. 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**. 10. 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**. 11. Right-click again on the trusted relying party entry that represents the Nexthink web interface. 12. 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. 13. 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. 14. Return to the Nexthink web interface as a Nexthink administrator, go to the **Single sign-on** configuration page and select the **SSO Configuration** tab. 15. Upload the signature certificate retrieved from the AD FS management console. 16. 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`. 17. Click on **Save**. 18. Now, follow the instructions related to [user provisioning](#singlesign-on-userprovisioninguserprovisioning). #### **Configuring Entra ID as an identity provider** 1. As a Nexthink administrator, go to the **Single sign-on** configuration page and select the **SSO Configuration** tab. 2. Toggle the **SAML 2.0 authentication** switch if not already enabled. 3. Download the Nexthink service provider metadata file (metadata.xml). You will use this file later. 4. Log in to the [Azure portal](https://portal.azure.com/). 5. Click on **Enterprise applications,** then **New Application,** and finally **Create your own application**. 6. 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)** 7. Click on **Set up a single sign on**, then **SAML**, and finally **Upload metadata file**. 8. Click the **Upload metadata file** button located in the top-left corner of the page. 9. Select the `metadata.xml` file and save it. 10. 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]** 11. 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. 12. 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**. 13. 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**. 14. Take note of the **Login URL** and **Microsoft Entra Identifier**. You will use them later when configuring the SSO for your Nexthink instance. 15. On the third tile of the page **SAML Signing Certificate**, click the **Download** link associated with the first entry: **Certificate (Base64)**. 16. 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. 17. Return to the Nexthink web interface as a Nexthink administrator, go to the **Single sign-on** configuration page, and select the **SSO Configuration** tab. 18. 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. 19. Upload the IdP signature certificate downloaded from the Azure portal. 20. 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` 21. Click on **Save**. 22. Now, follow the instructions related to [user provisioning](#singlesign-on-userprovisioninguserprovisioning). #### **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.
MetadataEntity IDAssertion Consumer Service (ACS)ACS BindingNameID 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.See the 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](#singlesign-on-userprovisioninguserprovisioning). ## 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](https://docs.nexthink.com/platform/user-guide/administration/account-management/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 [Infinity Transition](https://docs.nexthink.com/platform/user-guide/administration/account-management/broken-reference) guide. *** RELATED TASKS * [Audit trail codes application](https://docs.nexthink.com/platform/security/exporting-audit-logs) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.nexthink.com/platform/user-guide/administration/account-management/single-sign-on.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.