michael at stroeder.com
Thu Dec 6 11:39:03 CET 2007
Roland Hedberg wrote:
> I'm now convinced that this all comes down to LDAP schema problems.
Somewhat...I recommend not to care too much.
> The schema file I have describing the AD schema has samAccountName as an
> attribute in the 'securityPrincipal' aux class.
> But, it turns out that the AD I working against has no problem using the
> attribute without adding the 'securityPrincipal' object class.
> In fact, in that server the attribute seems to be part of the object
> class 'User' !?
Welcome to the wonderful world of LDAP access to Active Directory. Don't
take the schema literally especially when accessing W2K/AD. Some things
improved with W2K3. Also some W2K/AD installations have the W2K3R2
schema installed. And also some behaviour might depend on the domain
> I've search the net for up-to-date versions of the AD schema but they
> seem hard to get by.
> Anyone got a recent version ?
It would not help:
1. The schema is not really cleanly enforced.
2. It depends on Windows version and local configuration. Not sure about
the domain functional level though.
> I found one fairly recent but that caused other problems since some
> attributes previously part of the standard schema now has move over to
> the Microsoft exchange schema.
Also a reason why one should not bother with retrieving a recent AD
schema at all. I vaguely remember even more mess with e.g. inetOrgPerson
class when installing Exchange before W2K3R2 schema etc.
Conclusion: Make your AD-specific scripts simply work even if it looks
not LDAPv3 compliant and leave the schema mess to your AD admins. :-)
E-Mail: michael at stroeder.com
More information about the python-ldap