You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Thorsten Kampe <th...@thorstenkampe.de> on 2009/07/12 19:18:52 UTC
Questions regarding ADS query handling
Hi,
I've been trying to query ApacheDS via Python-LDAP and I found a number
of weird things (in comparison to Active Directory and eDirectory):
1. when I run a query with attrlist = [''] - this actually returns all
attributes (like "attrlist = []" or "attrlist = None") - while in Active
Directory and eDirectory the server returns no attributes at all. Is
that intended?
2. ApacheDS seems to ignore "attrsonly = False" - it always returns the
values. Is that intended?
3. I ran a query against ou=system and ApacheDS returned ou=system seven
(!) times (each with a different createTimestamp value). That seems very
odd to me. Is there any explanation?
Thorsten
[1] search_s(base, SCOPE_SUBTREE, attrlist = [''], attrsonly = False)
Re: Questions regarding ADS query handling
Posted by Thorsten Kampe <th...@thorstenkampe.de>.
* Thorsten Kampe (Sun, 12 Jul 2009 19:18:52 +0200)
> 1. when I run a query with attrlist = [''] - this actually returns all
> attributes (like "attrlist = []" or "attrlist = None") - while in Active
> Directory and eDirectory the server returns no attributes at all. Is
> that intended?
I changed "attrlist = ['']" to "attrlist = ['1.1']" (from the ldapsearch
manpage - not very intuitive to say the least) and that worked.
Thorsten
Re: Questions regarding ADS query handling
Posted by Alex Karasulu <ak...@gmail.com>.
On Mon, Jul 13, 2009 at 6:05 PM, Alex Karasulu <ak...@gmail.com> wrote:
> Hi Thorsten,
>
> On Sun, Jul 12, 2009 at 1:18 PM, Thorsten Kampe <thorsten@thorstenkampe.de
> >
>
>>
>> 1. when I run a query with attrlist = [''] - this actually returns all
>> attributes (like "attrlist = []" or "attrlist = None") - while in Active
>> Directory and eDirectory the server returns no attributes at all. Is
>> that intended?
>
>
> This smell's like a corner case bug for ApacheDS. I see you filed a few
> issues in our JIRA. Don't know if this was one of them but feel free to add
> if you did not.
>
Stephan nailed this on the head with the use of the more standards oriented
1.1 pseudo attribute.
>
>>
>> 2. ApacheDS seems to ignore "attrsonly = False" - it always returns the
>> values. Is that intended?
>>
>
> Nope this is yet another bug.
>
I thought attrsonly=true doh! Luckily Stephan caught this for the both of
us.
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: Questions regarding ADS query handling
Posted by Alex Karasulu <ak...@gmail.com>.
Hi Thorsten,
On Sun, Jul 12, 2009 at 1:18 PM, Thorsten Kampe
<th...@thorstenkampe.de>wrote:
> Hi,
>
> I've been trying to query ApacheDS via Python-LDAP and I found a number
> of weird things (in comparison to Active Directory and eDirectory):
>
We really appreciate this. It's finding these oddities that allow us to
improve the server.
>
> 1. when I run a query with attrlist = [''] - this actually returns all
> attributes (like "attrlist = []" or "attrlist = None") - while in Active
> Directory and eDirectory the server returns no attributes at all. Is
> that intended?
This smell's like a corner case bug for ApacheDS. I see you filed a few
issues in our JIRA. Don't know if this was one of them but feel free to add
if you did not.
>
>
> 2. ApacheDS seems to ignore "attrsonly = False" - it always returns the
> values. Is that intended?
>
Nope this is yet another bug.
>
> 3. I ran a query against ou=system and ApacheDS returned ou=system seven
> (!) times (each with a different createTimestamp value). That seems very
> odd to me. Is there any explanation?
>
Yeah this is weird. I know that we made ou=schema return an updated
timestamp if any schema information has changed but I do not think we do
this for ou=system. Perhaps just reporting this as a bug is best now until
we get to the bottom of it.
>
>
> Thorsten
> [1] search_s(base, SCOPE_SUBTREE, attrlist = [''], attrsonly = False)
>
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: Questions regarding ADS query handling
Posted by Kiran Ayyagari <ay...@gmail.com>.
Hi Thorsten,
> Just to follow up my own questions: I really love ApacheDS because of
> the sheer beauty and simplicity of its setup and configuration but I
> find some rather odd behaviour the more I dig into internals:
>
> 4. I tried to query the RootDSE object via Python - without sucess -
what values you are expecting from RootDSE?
> then I tried the same with OpenLDAP's ldapsearch: same issue:
>
> thorsten@tkampe% ldapsearch -x -LLL -b "" -s base
> dn:
> objectClass: extensibleObject
> objectClass: top
most of the values in rootDSE are operational attributes append + at the end of the above
command to see them
>
> ...while the same queries work against an eDirectory and Active
> Directory server. It also seems that LDAP clients have problems
> displaying the RootDSE object: Softerra's six year old LDAP Browser and
> Apache Directory Studio can display the RootDSE object while LDAP Admin
> and LDAPSoft's LDAP Browser can't. What's going on here?
No idea at all
Kiran Ayyagari
Re: Questions regarding ADS query handling
Posted by Stefan Seelmann <se...@apache.org>.
Hi Thorsten,
>> ...while the same queries work against an eDirectory and Active
>> Directory server. It also seems that LDAP clients have problems
>> displaying the RootDSE object: Softerra's six year old LDAP Browser and
>> Apache Directory Studio can display the RootDSE object while LDAP Admin
>> and LDAPSoft's LDAP Browser can't. What's going on here?
Some clients are more smart and work around the various implementations.
> Looks like most clients don't understand or expect Operational
> Attributes (whatever that is):
See RFC 4512 [1]
> "ldapsearch -x -LLL -b "" -s base +" works for ApacheDS - while that of
> course fails against Active Directory and eDirectory. Hm.
You could always request the attributes you need explicitely, example:
"ldapsearch -x -LLL -b "" -s base namingContexts supportedControl"
Kind Regards,
Stefan
[1] http://tools.ietf.org/html/rfc4512#section-3.4
Re: Questions regarding ADS query handling
Posted by Thorsten Kampe <th...@thorstenkampe.de>.
* Thorsten Kampe (Sun, 12 Jul 2009 19:58:47 +0200)
> Just to follow up my own questions: I really love ApacheDS because of
> the sheer beauty and simplicity of its setup and configuration but I
> find some rather odd behaviour the more I dig into internals:
>
> 4. I tried to query the RootDSE object via Python - without sucess -
> then I tried the same with OpenLDAP's ldapsearch: same issue:
>
> thorsten@tkampe% ldapsearch -x -LLL -b "" -s base
> dn:
> objectClass: extensibleObject
> objectClass: top
>
> ...while the same queries work against an eDirectory and Active
> Directory server. It also seems that LDAP clients have problems
> displaying the RootDSE object: Softerra's six year old LDAP Browser and
> Apache Directory Studio can display the RootDSE object while LDAP Admin
> and LDAPSoft's LDAP Browser can't. What's going on here?
Looks like most clients don't understand or expect Operational
Attributes (whatever that is):
"ldapsearch -x -LLL -b "" -s base +" works for ApacheDS - while that of
course fails against Active Directory and eDirectory. Hm.
Thorsten
Re: Questions regarding ADS query handling
Posted by Thorsten Kampe <th...@thorstenkampe.de>.
Just to follow up my own questions: I really love ApacheDS because of
the sheer beauty and simplicity of its setup and configuration but I
find some rather odd behaviour the more I dig into internals:
4. I tried to query the RootDSE object via Python - without sucess -
then I tried the same with OpenLDAP's ldapsearch: same issue:
thorsten@tkampe% ldapsearch -x -LLL -b "" -s base
dn:
objectClass: extensibleObject
objectClass: top
...while the same queries work against an eDirectory and Active
Directory server. It also seems that LDAP clients have problems
displaying the RootDSE object: Softerra's six year old LDAP Browser and
Apache Directory Studio can display the RootDSE object while LDAP Admin
and LDAPSoft's LDAP Browser can't. What's going on here?
Thorsten
Re: Questions regarding ADS query handling
Posted by Thorsten Kampe <th...@thorstenkampe.de>.
* Stefan Seelmann (Sun, 12 Jul 2009 20:28:39 +0200)
> Thorsten Kampe schrieb:
> > 2. ApacheDS seems to ignore "attrsonly = False" - it always returns
> > the values. Is that intended?
>
> attrsonly=false returns the values, of course. Do you man attrsonly=true?
Yes, sure. I actually query with "values = False; attrsonly = not
values" - that's why I made that typo.
> > 3. I ran a query against ou=system and ApacheDS returned ou=system seven
> > (!) times (each with a different createTimestamp value). That seems very
> > odd to me. Is there any explanation?
>
> Yes, that is odd. Could you please create an issue in our Jira [2]? Thanks.
Will do...
Thorsten
Re: Questions regarding ADS query handling
Posted by Stefan Seelmann <se...@apache.org>.
Hi Thorsten,
Thorsten Kampe schrieb:
> Hi,
>
> I've been trying to query ApacheDS via Python-LDAP and I found a number
> of weird things (in comparison to Active Directory and eDirectory):
>
> 1. when I run a query with attrlist = [''] - this actually returns all
> attributes (like "attrlist = []" or "attrlist = None") - while in Active
> Directory and eDirectory the server returns no attributes at all. Is
> that intended?
Yes, different LDAP behave different. Please try to use attribute '1.1'
as defined in RFC 4511 [1], that is the magic number that should work
for all LDAP servers ;-)
> 2. ApacheDS seems to ignore "attrsonly = False" - it always returns the
> values. Is that intended?
attrsonly=false returns the values, of course. Do you man attrsonly=true?
> 3. I ran a query against ou=system and ApacheDS returned ou=system seven
> (!) times (each with a different createTimestamp value). That seems very
> odd to me. Is there any explanation?
Yes, that is odd. Could you please create an issue in our Jira [2]? Thanks.
Kind Regards,
Stefan
[1] http://tools.ietf.org/html/rfc4511#section-4.5.1.8
[2] https://issues.apache.org/jira/browse/DIRSERVER