Advanced LDAP Filtering

EFT Server’s LDAP (Lightweight Directory Access Protocol; an application protocol for querying and modifying directory services running over TCP/IP.) 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 (Active Directory is a Microsoft implementation of LDAP directory services used to provide central authentication and authorization services for Windows-based computers.). EFT Server follows the filtering conventions outlined in http://www.faqs.org/rfcs/rfc2254.html.

Follow the procedure in Creating a Site that Uses LDAP Authentication. Specify the User Filter on the LDAP Authentications page of the wizard. The defaults are shown below.

The default User Filter is (objectClass=person). This means that every single type person object 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 - Active Directory is a Microsoft implementation of LDAP directory services used to provide central authentication and authorization services for Windows-based computers.) 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.

Below is an example of an LDAP directory with multiple ous 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 ou:= rather than ou:dn:= had been used, 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 ous 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 g roupMembership 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 creating the Site.

More examples: