Is the Nx Cloud up? Visit our Status Page for the current health and performance of the Nx Cloud.

Status Page

Configuring LDAP Search Bases for Specific Groups and Users

Nx Support
Updated

This article outlines a straightforward method to configure LDAP search bases to retrieve only specific Active Directory (AD) groups - and the users within those groups - via the LDAP configuration interface in the VMS.

Introduction

Starting in version 6.0, the VMS allows administrators to query and manage AD groups as if they were native VMS groups. These can then be used for roles and permission assignments just like manually created VMS groups.

This capability has led to common questions about best practices for retrieving only desired groups and their associated users using LDAP filters.

Purpose

The goal is to provide a simple, practical example for configuring LDAP search bases that:

  • Pull only selected groups.

  • Include only users who are members of those groups.

While more advanced configurations are possible, the steps below will meet the needs of most environments.

NOTE: A basic understanding of LDAP settings and configuration is assumed. All examples are illustrative; your Base DNs and filters will likely differ depending on your directory structure.

Important Considerations

  • Standard LDAP Calls: the VMS does not use any proprietary or custom code for LDAP operations. All LDAP queries are executed by the server backend using standard protocols, identical to manual LDAP calls executed in a command line.

  • Filter Validation: Since VMS accepts standard LDAP syntax, it's recommended to test your filters using an external LDAP query tool (e.g., ldapsearch on Linux or a GUI tool like Apache Directory Studio).

To proceed with configuration, follow the detailed steps provided below. 

For detailed instructions on configuring an LDAP call, refer to the following resource:

https://serverfault.com/questions/76012/easiest-way-to-set-up-ldap-for-dev-testing 

Groups

To retrieve groups in the VMS, you can follow one of two configuration approaches. The first involves pulling all groups from a specific Organizational Unit (OU), which is ideal if all VMS-related Active Directory groups are organized within a single, dedicated OU. The second approach involves specifying individual groups by their Common Name (CN) in separate search bases, which is useful when the desired groups are distributed across multiple OUs.

How to pull all groups within a given OU:

  1. Add a new search base.
  2. Name the search base as you would desire.
  3. Set the Base DN to the logical AD path of the OU you wish to pull groups from.
  4. Assuming you want to pull all groups within the OU into the VMS, set the Filter to “objectclass=group”, this will tell the LDAP search that you want all groups within the OU that you specified in the Base DN to be pulled only.

Example:

In this example, the Base DN (1) is set to the default Users OU which includes all default groups and users within the Active Directory. The filter (2) is configured to filter to just the specific group you wish to pull from within that OU.

NOTE: You can alternatively also set the Base DN to the group’s CN directly which will result in the same information/data pulled. For example, the above example could be configured with an empty “Filter” field and a “Base DN” that is set to “CN=VMS Live Users,CN=Users,DC=nxtest,DC=local” and it would pull the same as what is shown within the screenshot.

Users

To pull users within the VMS, you will want to follow one of two configuration paths, the first of which involves pulling all users within a given OU (for those that have configured all of their VMS AD users within a single OU created for that purpose), and the second involves pulling specific users by their group membership within the Active Directory.

How to pull all users within a given OU

  1. Add a new search base.
  2. Name the search base as you would desire.
  3. Set the Base DN to the logical AD path of the OU you wish to pull users from.
  4. Keep the filter empty.

Example:

In the above example, the Base DN (1) is set to the OU that has all VMS users within the example lab. The Filter (2) is empty because I want to pull all users from within the OU.

NOTE: Keep in mind, when a filter is not set, you are telling the VMS that when it performs the LDAP call that you want it to pull EVERYTHING within the specified Base DN. This can be a common reason for why environments see large numbers of users pulled when they only wanted to pull specific users. Incorrect filters and missing filters can cause that to occur.

How to pull only users who have a specific group membership assigned to them in AD

  1. Add a new search base.
  2. Name the search base as you would desire.
  3. Set the Base DN to the logical AD path of the OU you wish to pull users from.
  4. Set the filter based on group membership by setting memberOf=CN=[Name Of Group],(CN or OU depending on OU used)=[OU where group exists],DC=[your domain],DC=[your domain extension, ie. .com, local, etc.]

Example:

The Base DN (1) in the above example is set to the default Users OU where all users were added. The Filter (2) is set to “memberOf=CN=VMS Power User,OU=VMS Groups,DC=nxtest,DC=local” which will filter to only users who are a member of the group “VMS Power User”.

NOTE: If you wish to pull users from multiple groups, you can do so by either adding an individual search base for each group’s members you wish to pull, For example, I could add a second search base for users who are also members of the “VMS Live User Group” AD group that exists in this same example lab. There are also complex filters which are briefly covered in the next section of this article that could allow you to add a single search base that looks for users across multiple group memberships.

More Complex Filters

The examples above demonstrate how to retrieve users who are members of specific groups, groups located within particular OUs, or even a single group. However, if your domain forest includes multiple groups or users spread across different OUs, you would need to configure a separate search base for each distinct criterion. While this method is functional, it can quickly become cumbersome in complex environments.

To address this, it's helpful to understand how LDAP search filter logic can be used to streamline configuration. By using more advanced filtering, you can create search bases that serve multiple purposes. For instance, if you want to include all users who are members of any one of five different groups, instead of creating five separate search bases, you can use a single filter to capture them all. The following information provides guidance on how to construct such filters and adapt them to similar scenarios.

LDAP filters support Boolean operators to combine multiple criteria:

  • & (AND): All conditions must be true.

  • | (OR): At least one condition must be true.

  • ! (NOT): Excludes entries matching the condition.

By combining these operators, you can create flexible filters tailored to your environment. Below are example scenarios to illustrate how this logic can be applied (please adapt these to fit your specific needs).

Example:

To retrieve all users who are members of any one of three specific Active Directory security groups—but not necessarily all three—you can use a filter like the following:

(|(memberOf=CN=VMS Live Users,OU=VMS Groups,DC=nxtest,DC=local)
 (memberOf=CN=VMS Power Users,OU=VMS Groups,DC=nxtest,DC=local)
 (memberOf=CN=VMS View Users,OU=VMS Groups,DC=nxtest,DC=local))

The | (OR) operator after the opening parenthesis indicates that the filter will match users who belong to at least one of the specified groups.

If instead you want to find users who are members of all three groups, simply replace the | with an & (AND) operator. This change ensures that only users who belong to every group listed in the filter are returned.

For a deeper understanding of how LDAP filters function, please refer to the resource available here:

https://ldap.com/ldap-filters/ 

Related to

Related articles

Comments

0 comments

Article is closed for comments.