Article

(View Disclaimer)

Problem

A Forum reader recently asked:

"I'm creating a customize JSP page to add Dynamic Groups to the vault. I need to validate the filter condition and check for typos and syntax errors in the 'memberQueryURL' value entered by the user. Can any one share the validation logic for this MemberQuery URL value or?"

And here's the reply from Ofer Gigi ...

Solution

Values entered in attribute 'memberQueryURL' should basically follow the standard LDAP URL format. While the general standard may serve various ldap client application uses, for eDirectory Dynamic Group membership the general
form you would use goes like this:

ldap:///searchBaseDN??searchScope?searchFilter

searchBaseDN:

An LDAP Distinguished Name (DN) of an object from which the search should begin. Examples: ou=Engineering,o=Corp

searchScope:

Either 'base' ,'one' or 'sub'

'base' = This is the exact DN specified in searchBaseDN.
'one' = One level search. Look for objects that reside immediately beneath the object specified in searchBaseDN.
'sub' = Subtree. Look for objects that reside beneath the searchBaseDN as well as in any sub-level below it.

Obviously, 'one' and 'sub' only make sense when searchBaseDN points at a container object.

searchFilter

A string representation of an LDAP search filter. This is probably the trickier part of this attribute value. Although search filters can get pretty complex, the basic form of a filter is:

( some rule )

'some rule' is basically built from an ldap attribute name, a filter type (or Comparison mode) and a possible value.

Example 1
( title=Manager )

This would mean that you are searching for all objects that have a title attribute with the value 'Manager'. In this example I used the attribute name of 'title', a filter type of Equal (=), and a value of 'Manager'.

The most common filter types are EQUAL ( = ), GreaterOrEqual ( >= ), LessOrEqual ( <= ).

Example 2
( jobGrade > 8 )

You can prefix filter portions to gain more control of the search results:

! = NOT
& = AND
| = OR 

These would prefix the general ( some rule ) format.

Example 3
(!(title=Manager))

Here we are searching for all objects that do NOT have a value of 'Manager' in the title attribute. Note the surrounding brackets.

Example 4
(&(objectclass=user)(title=Manager))

We now look for all objects that has an objectclass value of 'user', AND (&) a title attribute with the value 'Manager'.

When searching for attribute values, you can also use wildcards:

Example 5
(phoneNumber=+808*)

This would get all objects with a phone number beginning with '+808'.

You could also do: (phoneNumber=*808*)
which would return objects with phone numbers like '+999 876 808' or
'123-656-8087', etc.

You could combine all the above (and more) to construct complex ldap search filters, as shown in the next example.

Example 6
(&(objectclass=user)(|(title=*head*)(title=*manager*))(!(phoneNumber=+808*)))

Get all 'user' objects that have either 'head' or 'manager' somewhere in their 'title' attribute, and have a phone number in area code '+808' .

While this does not cover all possible possibilities, you get the picture ...

If you want to read more on the LDAP search filter definition, have a look at rfc4515 (http://www.ietf.org/rfc/rfc4515.txt). Note that not all LDAP servers supports all possible search rules described in the rfc. This applies to eDirectory as well.

Novell refers to rfc2255 for the standard behind memberQueryURL attribute. A copy can be found at: http://www.ietf.org/rfc/rfc2255.txt. Note that
this rfc was replaced by rfc4516 (http://www.ietf.org/rfc/rfc4516.txt).

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.