Provisioning user accounts from Active Directory


Provisioning user accounts from Active Directory


Manually adding user accounts to Nexthink may be a tedious process when many users need access to the Portal and, optionally, to the Finder. If you manage your corporate user accounts with Active Directory (AD), take advantage of groups in AD to dynamically provision user accounts to Nexthink and set their permissions accordingly.

Basically, the solution consists on mapping AD groups to user profiles in Nexthink. Then the Portal automatically provisions user accounts from the AD users that belong to those groups.


The provisioning of user accounts to Nexthink requires an Active Directory setup with a single domain. The groups to be provisioned must not contain users from other domains, whatever the nature of the group (local, global or universal)

The solution has been tested on Domain Controllers running the following versions of Windows Server:

  • Windows Server 2008 R2
  • Windows Server 2012 R2

Other versions may or may not be suitable for provisioning users.

Configuring LDAP

To provision user accounts from Active Directory, configure first the LDAP connection of the Portal to the AD server (Domain Controller):

  1. Log in to the Web Console of the master Appliance (the Appliance that hosts the Portal) from a web browser. Replace the example by the actual address of the Portal:
  2. Click the PORTAL tab at the top of the window.
  3. Select Active Directory from the left-hand side menu.
  4. Tick the option Enable account provisioning.
  5. Fill out the form that shows up:
    • Server name: A generic name to identify your AD server.
    • Server address: The IP address of your Active Directory server (we currently do not support the DNS or Netbios name), followed by the TCP server port (usually 389, for non-secured LDAP connection).
    • Enable LDAP over SSL: Optionally tick the box to use a secure connection to the AD server. If you enable SSL, import the AD server certificate into the Portal when necessary.
    • Bind DN: The Distinguished Name of the account for connecting to the AD server. Example: CN=portalAD, OU=servers, DC=company, DC=local.
    • Bind Password: The password that corresponds to the Bind DN account.
    • Users base DN: The starting node in the AD tree for searching users. It must be an Organizational Unit.
    • Groups base DN: The starting node in the AD tree for searching groups. It must be an Organizational Unit.
    • Scope: Where to look for users and groups from their defined base nodes. There are three possible values:
      • base: Search only for entries at the base DN.
      • onelevel: Search for entries one level under the base DN, but not including the base DN nor any nodes at a deeper level.
      • subtree: Search for entries at the base DN and all levels under it. Threescopeoption.png
  6. Optional: Click TEST LDAP PARAMETERS to check the connection with the AD server. The Portal must be running for the test to work.
  7. Click on Save changes to save the configuration.

The Portal does not immediately update user and group information after saving the configuration. Instead, the Portal is scheduled to synchronize with the AD server every hour. Alternatively, force a synchronization with the AD server from the account management dashboard in the Portal (see how in Mapping AD groups to user profiles below).

Preparing your existing users

Your existing users may fall into the following two categories:

  • Users authenticated by Active Directory, that is, those whose username is a UPN of the form [email protected].
  • Users not authenticated by Active Directory.

Depending on their category, and before mapping AD groups to profiles, prepare your existing users for a successful migration to the provisioning of users from AD.

Migration of users authenticated by Active Directory

For users authenticated by Active Directory who belong to any of AD groups to be mapped, the migration is straightforward. After provisioning, their Portal and Finder content is preserved, but their profile may be modified according to the AD groups to which they belong.

If a user authenticated by Active Directory does not belong to any of the AD groups to be mapped, the user continues to exist as an AD authenticated user in Nexthink. The user keeps the same content and profile as before provisioning.

Migration of users not authenticated by Active Directory

For users not authenticated by Active Directory, but by the Portal itself, convert them first to AD authenticated users. To that end, change their username to a proper UPN and proceed as in the previous case.

If a Nexthink user does not exist in Active Directory, you will not be able to supply a UPN name for the user and the migration will not be carried out. After provisioning, the user continues to exist as a Nexthink-only user.

Mapping AD groups to user profiles

Once the Portal is able to retrieve AD information on groups and users from the Domain Controller, map the groups that the Portal finds AD to user profiles in Nexthink. The Portal retrieves AD groups of any scope (domain, global, or universal) and of any type (security or distribution).

To map AD groups to user profiles:

  1. Log in to the Portal as central administrator.
  2. Click the ADMINISTRATION drop-down menu at the top of the window.
  3. Under ACCOUNT MANAGEMENT, select the option Accounts to open the dashboard for editing accounts.
  4. Optional: Click the button Synchronize with AD at the top of the dashboard to force the Portal to update the information on users and groups from the Domain Controller. While the update process is going on, the Portal displays the message Synchronization in progress in place of the button.
  5. Click the button Set AD groups at the top of the dashboard. The dialog for mapping AD groups to profiles shows up.
  6. Click the button Add group to set a new mapping.
    1. Type in the name of a group in the column AD group name. As you type, a list of the possible groups to complete the name appear below. Finish typing or select one of the groups provided as a suggestion.
    2. Select an available user profile from the list in the Profile column.
      • If the profile is parameterized, choose the view domain of the users to be imported from the View list in the Domain column.
      • Additionally, if the parameterized profile is of the administration type, choose the administration domain of the users to be imported from the Admin list in the Domain column.
  7. Optional: Repeat the previous step to add more mappings.
  8. Click OK.

The Portal automatically adds the users in the mapped AD groups to its own list of user accounts. Their Username in the Portal is the same as their account name in Active Directory (UPN of the form [email protected]).

Determining mapping precedence

Active Directory users may belong to more than one AD group. If you defined different mappings for the AD groups to which a particular user belongs, the first defined mapping takes precedence. That is, the order in which you define the mappings determines their priority.

See the AD group and the mapped profile of a particular user under the columns AD group and Profile in the accounts management dashboard. These fields, as the whole list of accounts, are refreshed when the Portal synchronizes with AD.

Authentication and permissions of provisioned user accounts

User accounts provisioned from AD groups naturally make use of Active Directory authentication. For all users that use this type of authentication, the Portal checks user credentials against Active Directory at each login attempt. Therefore, if a particular user is removed from AD, the user is immediately unable to log in to the Portal anymore.

On the other hand, a change of membership to an AD group may result in a different profile being assigned to a provisioned user, but only after the Portal synchronizes with AD. Since the profile determines the permissions and access rights of the user in Nexthink, the user may temporally have out-of-date access rights in force. If immediate effects are required, use manual synchronization.

Deleting and disabling provisioned user accounts

Changing the mappings of AD groups to profiles or the composition of AD groups themselves may result in some of the previously provisioned users no longer being part of the provisioning. Specifically, any of these two actions may lead to that situation:

  • Removing a mapping of an AD group to a profile.
  • Revoke the membership of a user to an AD group that takes part in a mapping.

Users that are left out of account provisioning after any of these operations fall into either one of these two categories:

  • Users who never logged in to Nexthink.
  • Users who logged in to Nexthink at least once.

Users who never logged in to Nexthink (via the Portal, the Finder, or NXQL request) are physically removed from the system, otherwise they are just disabled. A disabled user does not appear in the list of accounts and cannot log in. However, the configuration and content associated to a disabled user is kept in the system. If a disabled user is recreated as a result of being mapped again, the account is reactivated with all its previous configuration and content.

If you actually delete a provisioned user from the list of accounts in the Portal, by selecting the user and clicking the bin icon in the Accounts dashboard, all the configuration and content associated to the user is removed from the system and the user can no longer log in. However, beware that if the user still belongs to one of the mapped AD groups, the account will be recreated at the next synchronization of the Portal with the AD. If you do not want a deleted user account to reappear in Nexthink, remember to revoke its membership to any of the mapped AD groups.

Maximum number of users

The default maximum number of users in the product is 500. This limit includes both currently existing users and previously existing users that logged in to the product at least once (via the Portal, the Finder, or NXQL request) and were subsequently removed.

Provisioned users from AD groups who never logged in and were subsequently removed from the provisioning (for instance, because of a deleted mapping) are physically removed from the system and they do not take part in the counting of users to compute the limit. On the other hand, disabled users do count for the limit.