LDAP search filters using OU not supported?

[Robert]

I've been trying to get a search filter working against AD but it's
not working.

The search filter uses (ou=...) as one of the clauses and after a bit
of Googling it seems that AD doesn't support search filters that use
OUs.

Could someone confirm that this is the case (ideally with a link to
some documentation that states this) and, if it is the case, does
anyone have any recommendations for alternative ways to specify a set
of OUs in a search filter?

Thanks.


Robert

 

[Richard Mueller [MVP]]

I've been trying to get a search filter working against AD but it's
not working.

The search filter uses (ou=...) as one of the clauses and after a bit
of Googling it seems that AD doesn't support search filters that use
OUs.

Could someone confirm that this is the case (ideally with a link to
some documentation that states this) and, if it is the case, does
anyone have any recommendations for alternative ways to specify a set
of OUs in a search filter?

In a search filter clause of a query you specify the value of an attribute
of the objects you are searching for. The problem is that no objects have a
value assigned to an "ou" attribute except OU container objects. User
objects, for example, have no value assigned to an "ou" attribute. There is
also no "parent" attribute.

Per this link:
http://support.microsoft.com/default.aspx?scid=kb;en-us;187529

rfc2253 specifies the LDAP syntaxes on which the ADSI LDAP syntax is based.
I think rfc 2254 also applies. I haven't seen these documents. From my web
site at this link: http://www.rlmueller.net/ADOSearchTips.htm

I state the following:

====
The search filter specifies all conditions that must be met for a record to
be included in the RecordSet. Each condition is in the form of a conditional
statement, such as "(cn=TestUser)", which has a Boolean result. Each such
condition is enclosed in parenthesis. The general form of a condition is an
attribute and a value separated by an operator, which is usually the equals
sign "=". Other operators that can separate attributes and values are ">=",
and "<=" (the operators "<" and ">" are not supported).
====

You can, of course, specify the DN of an OU in the base clause of an LDAP
query. But no attribute of objects indicates where they are in AD expect the
Distinguished Name, and wildcards are not allowed in DN attributes. What
exactly are you trying to do? Maybe there is another way.

 

[Robbie]

You can, of course, specify the DN of an OU in the base clause of an LDAP
query. But no attribute of objects indicates where they are in AD expect the
Distinguished Name, and wildcards are not allowed in DN attributes. What
exactly are you trying to do? Maybe there is another way.

Many thanks for all the information.

It's a long and not very interesting saga but I'm working with a
Vignette Portal implementation at the moment. I'm in the process of
configuring it to work with an organisation's AD.

The particular issue is that this organisation wants to use SSO but
when doing this Vignette Portal requires that all users exist in a
single "realm" (which in this context is essentially an OU). However,
users exist in multiple (top level) OUs.

There is a way to get round this which is to leave the realm blank
which results in the whole AD structure is being searched from the
base DN. This is clearly not really very optimal.

The product supports being able to supply a search filter to restrict
which users are found so I have been trying to come up with a suitable
search filter.

My first attempt was along the lines of:

(|(ou=X)(ou=Y))

But having learned that AD doesn't support search filters like this,
this approach is clearly never going to work.

Using the DN as an alternative would be good but, as you say, this
probably won't work either because I would need to use wildcards.

Can you therefore think of any way to construct a search filter that
will enable me to somehow restrict a search of AD to particular OUs?


Robert

 

[Robert]

Richard -

I just found this example of doing a partial match on a DN:

Found at:

http://confluence.atlassian.com/display/DEV/How+to+write+a+LDAP+search+filter

Would that work with AD?


Robert

 

[Robert]

I just tried this and it doesn't seem to work.


Robert

 

[Richard Mueller [MVP]]

I just tried this and it doesn't seem to work.


Robert

I tried several variations and none worked. This link gives more on filter
syntax:

http://msdn.microsoft.com/en-us/library/aa746475.aspx

The LDAP_MATCHING_RULE_IN_CHAIN looks interesting, but still does not help.

If you can specify the base, you can restrict to one OU, but not more. Other
options are to use groups to restrict the users (place all users in the OU's
in a group). The filter could then be similar to:

(&(objectCategory=person)(objectClass=user)(memberOf=cn=TestGroup,ou=West,dc=MyDomain,dc=com))

Another option would be to assign a value to an attribute for all users. For
example, user objects have an "ou" attribute, it just is not populated. It's
also multi-valued. Perhaps you can run a script that assigns the RDN of the
parent container to this attribute for all users. Then you could indeed use
the filter you originally suggested:

(&(objectCategory=person)(objectClass=user)(ou=West))

There is always some risk using attributes that seem available, but I've
never heard of anything using this (except OU objects where it is
mandatory). Also, note that the RDN of the parent OU may not uniquely
identify it. There could be several OU's called "Sales". For example
"ou=Sales,ou=East,dc=MyDomain,dc=com" and
"ou=Sales,ou=West,dc=MyDomain,dc=com".

 

[Robert]

Richard-

Thanks for those suggestions.

I had another idea which is whether it's possible to specify multiple
OUs as part of the initial context.

I'm defnining the initial context along the lines of :

ldap://serverort/dc=x,dc=y

But could I add multiple OUs to this URL so that the context itself is
restricted to these OUs?


Robert

 

[Robert]

But could I add multiple OUs to this URL so that the context itself is
restricted to these OUs?

I'm going to answer my own question again by saying that having
checked the LDAP spec, it seems URLs of this form can take a DN but
not a list of OUs.


Robert