GlobalSCAPE Knowledge Base

Retrieving specific sets of users using infinitely complex LDAP Filters



  • EFT Server version 5.x

(For version 6.x, refer to Advanced LDAP Filtering in the EFT Server online help.)


Create complex filters for retrieving subsets of users across your LDAP directory with EFT Server’s LDAP authentication manager. This method is similar to retrieving only users in a specific group in Active Directory. EFT Server follows the filtering conventions outlined in

To configure an LDAP filter

  1. In EFT Administrator, select the Server tab. You should be connected to the server.
  2. Select the LDAP site you want to configure from the left-hand navigation tree, or if you do not have an LDAP site, create one by selecting Configuration -> New Site from the menu. Select LDAP as the authentication provider.
  3. In the right pane, select the Site Options tab.
  4. Select the ADVANCED button.
  5. In the LDAP Authentication Options dialog, enter the host address or domain name for the LDAP Server, for example: GS0015, or
  6. Enter the port number for the LDAP Server connection. This is usually 389 for non-SSL connections and 636 for SSL connections.
  7. Enter the base Distinguished Name (dn) for the server. The base dn depends on your schema and could be something like: o=myorganization or dn=forest,dn=myorg,dn=com
  8. Enter the LDAP directory username and password (if required) to bind to the LDAP server and retrieve the list of users.
  9. Specify if SSL is required.
  10. Specify a default location to store the local copy of the list of users provided by the LDAP Server.
  11. Enter an attribute to use as the login name qualifier. The Attribute field defines the LDAP Attribute name used in the LDAP entry that represents the user’s account or login name. It is typically cn but could be something else, such as uid. If you are unsure, leave it as cn.
  12. Enter the complex filter.
  13. Note that each entry in an LDAP tree consists of one or more attributes that define that entry. Each attribute has a name (attribute type) and is assigned one or more values. The entry itself is defined using a unique identifier such as its Distinguished Name,or dn, which is constructed from selected attributes in the entry followed by the parent’s dn, such as: cn=john smith,dc=example,dc=com


dn: cn=Jane Smith,dc=example,dc=com

cn: Jane Smith

givenName: Jane

sn: Smith

telephoneNumber: 555 1234

telephoneNumber: 555 5678


manager: cn=Alma Mia,dc=example,dc=com

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: person

objectClass: top

The Filter field appends a filter to the LDAP search query so that only the entries that match the filter are retrieved. A default filter is provided that verifies the ObjectClass attribute of a particular entry is of type “Person”. There can be many other types, such as, for example, “Printer”.

Suppose you only want to pull users from an Organization Unit (ou) container (similar to a group under AD) that is a couple levels removed from the root Organization (o) container. In this case, simply applying a filter where (ObjectClass=Person) pulls users from the entire organization, and not just the desired OU. Pulling users from the desired OU is done by defining a more complex filter.

Here is an example of an LDAP directory with multiple ous under an o:

[-] o=GlobalSCAPE

  • [-] o=GlobalSCAPE
    • [-] ou=ResearchAndDevelopment
      • cn=jbond
      • cn=jsmith
    • [-] ou=HumanResources
      • cn=jdoe
    • [+] ou=Marketing
    • [+] ou=PM

Before we craft the filter, let’s take a look at the entry properties for ResearchAndDevelopment and for one of the entries contained within that ou.

For ResearchAndDevelopment:

DN: ou=ResearchAndDevelopment,o=MyOrganization

ObjectClass: Top

ObjectClass: OrganizationalUnit

ObjectClass: ndsLoginProperties

ObjectClass: ndsContainerLoginProperties

Ou: ResearchAndDevelopment

And for jbond:

DN: cn=jbond,ou=ResearchAndDevelopment,o=MyOrganization

ObjectClass: Person

ObjectClass: ndsLoginProperties

ObjectClass: Top

GroupMembership: cn=TestGroup,o=MyOrganization

sn: bond

cn: jbond

Let’s assume we want to pull all users (of ObjectType = Person) from the R&D and HR ous but not any users from Marketing and PM. This requires a complex filter:


The filter above is called an extensible match search because it specifies an attribute name: “ou” and that the DN’s attributes should be considered as part of the entry.

If ou:= rather than ou:dn:= had been used, no results would have been returned, because the ResearchAndDevelopment entry doesn’t match the ObjectClass=Person criteria and jbond (which does have an ObjectClass=Person) doesn’t match the ou=ResearchAndDevelopment criteria EXCEPT for the fact that it does have ou=ResearchAndDevelopment as part of that entries’ Distinguished Name (dn). Therefore ou:dn:=ResearchAndDevelopment DOES return jbond as one of the users in the search result.

Here is another query similar to the first one except that we are excluding Mr. Bond by using an exclusion filter and including everyone else under R&D and HR.


Now let’s use an example where we pull all users from all ous except those in the R&D and HR containers:


The filter above basically says: Include all entries that have an ObjectClass attribute equal to person, but don’t return any entries where ResearchAndDevelopment or HumanResources is specified as an ou attribute in the dn.

Here is one last example. This one retrieves a user with an ObjectClass=Person attribute and a GroupMembership attribute equal to cn=TestGroup,o=MyOrganization.

(&(objectclass=Person)(groupMembership=cn=TestGroup,o= MyOrganization))

Note that the use of value=value=value in the above example can be confusing. In this case the entire string that follows the first equal sign after GroupMembership must match cn=TestGroup,o=MyOrganization, which is the case for the jbond entry (see further above for the jbond entry attributes).

Once you have entered a filter, click APPLY and then connect to the server using your favorite FTP client. Test your setup by using one of the accounts that should be in the returned LDAP query. If configured properly, you should be allowed to connect to the server.

NOTE: The operators used in the search filter (&, |, =, ~=, etc.) are all defined in RFC 2254.

NOTE: LDAP filtering is a complex task that requires an advanced understanding of LDAP. Please refer to RFC 2252 - Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions, RFC 2251 - Lightweight Directory Access Protocol (v3), and RFC 2254 - The String Representation of LDAP Search Filters for detailed information.

Last Modified: 12 Years Ago
Last Modified By: GlobalSCAPE 5
Article not rated yet.
Article has been viewed 21K times.
Also In This Category