sAMAccountName

[Michael Ströder]

Roland,

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
functional level.

> 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. :-)

Ciao, Michael.

-- 
Michael Ströder
E-Mail: michael at stroeder.com
http://www.stroeder.com