I have it bookmarked. :)

LDAP V3 - http://www.faqs.org/rfcs/rfc2251.html
LDAP Attribute Syntax - http://www.faqs.org/rfcs/rfc2252.html
LDAP DN representation - http://www.faqs.org/rfcs/rfc2253.html
LDAP Search Filters - http://www.faqs.org/rfcs/rfc2254.html
LDAP URL Format - http://www.faqs.org/rfcs/rfc2255.html
LDAP V3 X500 User Schema - http://www.faqs.org/rfcs/rfc2256.html



--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 
 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan
Sent: Friday, August 18, 2006 10:12 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Single Space in LDAP query dropped: Why?

That's a much more thorough explanation than mine.  :)  I was too lazy to 
even dust off the RFC URL.

Joe K.
----- Original Message ----- 
From: joe
To: ActiveDir@mail.activedir.org
Sent: Friday, August 18, 2006 7:40 AM
Subject: RE: [ActiveDir] Single Space in LDAP query dropped: Why?


Yeah this is a fun one.

It isn't if there is just a space, it is if there is a leading space. A 
leading space must be escaped otherwise (and any other leading space) will 
be trimmed.

There are also various oddities around trailing spaces depending on the 
attribute type where there are times it and actually all whitespace should 
be trimmed (IMO) but isn't. I have brought this up to MSFT in the past and 
the responses seemed a little inconsistent but they currently seem to feel 
everything is as it should be. There were some changes I have seen from 2K 
to K3. I want to say the Boolean types are some of the more frustrating 
pieces. You consider that you can only have either TRUE or FALSE, the 
software should be smart enough to trim the spaces but possibly that would 
be inconsistent with other directory implementations but then, that happens 
for quite a few things so why not there too?

The actual LDAP client side API does the cleanup, if you look at the trace 
you will see the filter has been "cleaned up" so the server never even sees 
the actual query that was submitted. If there is nothing but a space, the 
local client will kick back the filter and indicate a filter error. If there

was something more than the space it will be submitted without the space.

  joe

--
O'Reilly Active Directory Third Edition - 
http://www.joeware.net/win/ad3e.htm






From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Jef Kazimer
Sent: Friday, August 18, 2006 1:16 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Single Space in LDAP query dropped: Why?


I had posted this today, and I was curious if anyone knew why an LDAP filter

drops the query when searching for a single space value?  Though I was using

Joe's ADfind, I did have the same results in ADSIedit, and thought someone 
better than I, may know why.  It's not really a problem, just a curiousity.

Thanks,

Jef


http://jeftek.spaces.live.com/blog/cns!F2042DC08607EF2!642.entry

LDAP queries are spaced out...
I was looking at a metaverse object in MIIS today noticed some admin had set

the mail attribute to a single SPACE ( ) character.  The Metaverse is stored

in a SQL server, so naturally the query structure is different than any 
constraints of LDAP.
I wanted to discover how many other user objects had the same issue, so I 
decided to pull out ADfind and issue this command:
ADFIND -H MYSERVER -DEFAULT -F "(&(objectCategory=person)(mail= ))" -C
0 found
ok, so I thought it was my lack of quoting and tried:
ADFIND -H MYSERVER -DEFAULT -F "(&(objectCategory=person)(mail=' '))" -C
0 found
Since it's command line I was sure that the quoting would encapsulate it 
correctly, so I figure it is being stripped out by the LDAP query (I made 
this same Query ins ADSIedit and LDP with no luck) so perhaps there is an 
escape character for such a thing.   I have done many queries with filters 
like "description=The Man", and the space was interpreted correctly.  Yet it

seems, a single space, by itself is not passed to the query correctly.
So I check out the uber friendly RFCs and find escape characters for types 
such as * and NUL, but really no mention of  a single space as anything 
special.  I checked the LDAP V3 RFC as well for any real mention of when and

when a single space is dropped from the query, finding nothing related.
Fortunately,  using the escaped sequence in the query ("mail=\20") to 
represent a space worked just fine and returned the object I was looking 
for.
ADFIND -H MYSERVER -DEFAULT -F "(&(objectCategory=person)(mail=\20))" -C
48 found
So LDAP filters can container spaces as the value being queried for, but 
cannot be a single space without using an escape sequence to represent the 
value.
I suppose it's kind of silly, but I had never really looked for such an 
occurrence before, so it was an interesting learning experience. 

List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

Reply via email to