Advanced LDAP Filtering

EFT’s LDAP authentication manager allows you to create complex filters for retrieving sub-sets of users across your LDAP directory, similar to retrieving users only in a specific group in Active Directory. The Server follows the filtering conventions outlined in http://www.faqs.org/rfcs/rfc2254.html.

User updates is an asynchronous process; therefore, other administration interface updates may be ongoing, causing a delay in the presentation of the user updates.

LDAP filtering is a complex task that requires an advanced understanding of LDAP. For detailed information, 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. The operators used in the search filter (&, |, =, ~=, etc.) are defined in RFC 2254.

When you How EFT Sites are Defined, you must specify the User Filter on the LDAP Authentications page of the wizard. You can also specify or edit the user filter in the LDAP Authentication Options dialog box.

The default User Filter is (objectClass=person). This means that every ObjectClass attribute of a particular entry of type person will be returned in the search result, which may be highly inefficient if you want to authenticate only the users in your marketing department.

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 (dn), that is constructed from selected attributes in the entry followed by the parent’s dn, such as: cn=john smith,dc=example,dc=com.

Below is a sample entry, with its attributes and values:

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

cn: Jane Smith

givenName: Jane

sn: Smith

telephoneNumber: 555 1234

telephoneNumber: 555 5678

mail: jsmith@example.com

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

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: person

objectClass: top

The User 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 printer.

Suppose you only want to pull users from an Organization Unit (ou) container (similar to a group under AD) that is a couple of levels removed from the root Organization (o) container. In this case, simply applying a filter where (objectClass=person) pulls users from the entire organization, instead of just the desired OU. Pulling users from the desired OU is accomplished by defining a more complex filter, as described below.

Below is an example of an LDAP directory with multiple ou under an o:

[-] o=Globalscape

[-] ou=ResearchAndDevelopment

cn=jbond

cn=jsmith

[-] ou=HumanResources

cn=jdoe

[+] ou=Marketing

[+] ou=PM

Below are 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

Suppose you want to pull all users of ObjectType = Person from the R&D and HR ous, but not any users from Marketing and PM. The filter would be:

(&(objectClass=person)(|(ou:dn:=ResearchAndDevelopment)(ou:dn:=HumanResources)))

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

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

Below is a similar query, except that Mr. Bond is excluded using an exclusion filter and including everyone else under R&D and HR.

(&(&(!(cn:dn:=jbond))(|(ou:dn:=ResearchAndDevelopment)(ou:dn:=HumanResources)))(objectclass=Person))

Here is an example of pulling all users from all ou except those in the R&D and HR containers:

(&(!(|(ou:dn:=ResearchAndDevelopment)(ou:dn:=HumanResources)))(objectClass=person))

The filter above includes all entries that have an ObjectClass attribute equal to person, but do not return any entries where ResearchAndDevelopment or HumanResources is specified as an ou attribute in the dn.

Here is one last example that 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))

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.

Once you have defined a filter, click Test to verify the results, before continuing with How EFT Sites are Defined or editing the LDAP authentication options.

More examples:

Search filter

Description

(objectClass=*)

All objects

(&(objectCategory=person)(objectClass=user)(!cn=andy))

All user objects but "andy"

(sn=sm*)

All objects with a surname that starts with "sm"

(&(objectCategory=person)(objectClass=contact)(|(sn=Smith)(sn=Johnson)))

All contacts with a surname equal to "Smith" or "Johnson"