On Fri, 2008-08-22 at 11:48 +0200, Petter Reinholdtsen wrote: > Ran into a problem with autoconfiguration here at the University of > Oslo. The rootDSE returned look like this: > > dn: > objectClass: top > objectClass: OpenLDAProotDSE > objectClass: labeledURIObject > structuralObjectClass: OpenLDAProotDSE > configContext: cn=config > namingContexts: cn=mail,dc=uio,dc=no > namingContexts: cn=system,dc=uio,dc=no > namingContexts: cn=services,dc=uio,dc=no > namingContexts: dc=uio,dc=no > monitorContext: cn=Monitor [...] > supportedLDAPVersion: 3 > supportedSASLMechanisms: DIGEST-MD5 > supportedSASLMechanisms: CRAM-MD5 > supportedSASLMechanisms: OTP > labeledURI: http://www.usit.uio.no/it/ldap/ Test-tjener for LDAP ved > Universit > etet i Oslo > entryDN: > subschemaSubentry: cn=Subschema > > The correct base DN to use is "cn=system,dc=uio,dc=no", and it is as > you can see the second of the lot. I was unable to convince the LDAP > administrators to add defaultNamingContexts, due to fears that this > might confuse Windows machines, and thus need to manually set the base > anyway. :(
That's too bad. Since attribute values aren't really supposed to be ordered (they seem to be ordered in most implementations though) just using the first value isn't that great a solution anyway (defaultNamingContext is actually quite a nice solution). Someone has sent me a patch implementing searching in multiple bases (partially) but I don't think that searching in all the provided namingContexts is a good idea either. I don't see an immediate solution for improving the current mechanism though. > In Debian Edu on the other hand, we have started using the automatic > configuration for nss-ldapd, but not for pam-ldap yet. Good to hear. -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
