Provisioning user accounts from Active Directory
Last updated
Was this helpful?
Version 6.30
Last updated
Was this helpful?
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 is to map 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 works in Active Directory setups with one or multiple domains.
In the case of a setup with multiple domains, the following constraints apply:
Each group to be provisioned must not contain users from different domains, whatever the nature of the group (local, global or universal). That is, all users in a group must belong to the same domain.
Nexthink recommends creating dedicated global groups in each domain for the Nexthink users to be provisioned.
In case are used, please refer to the dedicated section to check the extra configuration needed.
The solution has been tested on Domain Controllers running the following versions of Windows Server:
Long term servicing channel (LTSC)
Windows Server 2008 R2 Windows Server 2012 R2 Windows Server 20216
Semi-annual Channel (SAC)
Windows Server version 1709
Other versions may not be suitable for provisioning users.
To provision user accounts from Active Directory, configure first the LDAP connection of the Portal to the AD servers (Domain Controllers):
Log in to the Web Console of the primary Appliance (the Appliance that hosts the Portal) from a web browser. Replace the example by the actual address of the Portal: https://portal.yourcompany.com:99
Click the PORTAL tab at the top of the window.
Select Active Directories from the left-hand side menu.
Click the button ADD ACTIVE DIRECTORY to add a new AD server.
Fill out the form that shows up:
Server name: A generic name to identify your AD server.
Server address: The DNS name or the IP address of your Active Directory server, followed by the TCP server port (usually 389, for non-secured LDAP connection).
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.
The password can include any printable ASCII character except for the less than sign, the single quote, and the double quotes: < ' ".
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.
Optional: Click TEST LDAP PARAMETERS to check the connection with the AD server. The Portal must be running for the test to work.
Click on Save changes to save the configuration.
Provisioning users from Active Directory can be very resource intensive in setups with a high number of groups.
To optimize provisioning performance, consider the Groups filter and Recursion through groups parameters to limit the number of retrieved groups. If you are not familiar with LDAP search queries or with recursion through groups, please contact Nexthink Support before updating these parameters.
The default synchronization frequency is 24h. Do not increase this frequency unless there is a real business need.
Prerequisites
For example, if you add the following filter to the Groups filter field:
!(cn=*RESTRICTED*)
The resulting filter used by the Portal is:
(&(objectClass=group)(!(cn=*RESTRICTED*))
Note that Microsoft Active Directory does not support extensible matching.
More examples of Group filters
Retrieve groups that contain either nexthink or portal in their name (partial match of group name): |(cn=*nexthink*)(cn=*portal*)
Select groups based on their distinguished names. The filter below returns just the two specified groups:|
(distinguishedName=cn=g1,ou=admin,dc=nexthink,dc=com)(distinguishedName=cn=g2,ou=admin,dc=nexthink,dc=com)
Retrieve all groups that are members of the group named nexthinkGroups: memberOf=cn=nexthinkGroups
By default, the Portal retrieves the members of a group recursively, that is, it will automatically retrieve users in nested groups. For very large AD deployments, this can lead to performance issues, in such cases it is recommended to disable recursion: untick the option Recursion through groups to avoid recursing through nested groups. In this case only the users that are direct members of the group will be retrieved.
Your existing users may fall into the following two categories:
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.
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.
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.
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:
Log in to the Portal as central administrator.
Click the ADMINISTRATION drop-down menu at the top of the window.
Under ACCOUNT MANAGEMENT, select the option Accounts to open the dashboard for editing accounts.
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 Controllers. While the update process is going on, the Portal displays the message Synchronization in progress in place of the button.
Click the button Set AD groups at the top of the dashboard. The dialog for mapping AD groups to profiles shows up.
Click the button Add group to set a new mapping.
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 appears below. The groups are displayed in the form groupName@domainName. Finish typing or select one of the groups provided as a suggestion. Note that it is not possible to provision two groups that have the same name if they are in the same domain.
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 Profile 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 Profile Domain column.
Optional: Repeat the previous step to add more mappings.
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 user@company.suffix).
The status and the time of the last AD synchronization are displayed at the bottom of the screen. In case of failed synchronization, see the errors in the tooltip.
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.
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.
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.
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.
If you need to overcome the limit of 500 users, please contact Nexthink Support.
RELATED TASKS
RELATED REFERENCES
Enable LDAP over SSL: Optionally tick the box to use a secure connection to the AD server. If you enable SSL, when necessary.
Groups filter: Use this LDAP search filter to optimize the provisioning. It is important for Active Directories having a lot of groups, as it can improve the synchronization time and resource consumption. Filters restrict the groups to be added to the portal that are listed in the Nexthink mapping screen. Please refer to the section for more details about how to use this feature.
Recursion through groups: Untick this box to disable the recursion through groups during the provisioning, which may increase the performance of the provisioning. Only do so if advised by Customer Success Services, because the impact on provisioning needs to be tested case by case. Please refer to the section for more details about how to use this feature.
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 below).
Use group filters to limit the number of groups retrieved from AD. Group filters only have an impact on the retrieved groups and not on the retrieval of members within the groups. To know more about writing filters, refer to . To focus on groups only, any filter added to the Web Console is logically combined with the filter (objectClass=group) by using the & operator.
Users authenticated by Active Directory, that is, those whose username is a of the form user@company.suffix.
User accounts provisioned from AD groups naturally make use of . 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.
