python-ldap-dev

sAMAccountName

[Roland H. <rol...@ad...>]

Hi!

A short while ago there was a discussion about how to add users to an AD
using python-ldap.

I benefited a lot from that discussion, so you have my thanks too.

On the topic python-ldap <-> AD:

My problem is that I can add an entry using the User object class and
attributes contained in that class without any problems.

But when I try to add the samAccountName attribute and thereby the
object class SecurityPrincipal the server complains.

The error message I get is 'Server is unwilling to perform' which
doesn't really tell me a lot :-)

Anyone got a clue ?

The AD isn't 'mine', but if there is something you need to know about it
in order to answer my question I can ask the person in charge.

-- Roland

Re: sAMAccountName

[<mi...@st...>]

Roland,

Roland Hedberg wrote:
> 
> But when I try to add the samAccountName attribute and thereby the
> object class SecurityPrincipal the server complains.

Could you please post a small test script?

Are you sure the value of the samAccountName does not collide with any
other user entry?

> The error message I get is 'Server is unwilling to perform' which
> doesn't really tell me a lot :-)

Most times it also returns a numeric error code with that message. You
could try to search for that. Also the guys in the AD newsgroups on MS'
NNTP server are quite helpful. Don't forget to let us know... ;-)

Ciao, Michael.

Re: sAMAccountName

[Roland H. <rol...@ad...>]

Michael Ströder wrote:
> 
> Roland Hedberg wrote:
>> But when I try to add the samAccountName attribute and thereby the
>> object class SecurityPrincipal the server complains.
> 
> Could you please post a small test script?
> 
> Are you sure the value of the samAccountName does not collide with any
> other user entry?

Oh, absolutely!

I'm now convinced that this all comes down to LDAP schema problems.

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' !?

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 ?

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.

So anyone got one of those too ?

Sigh !

-- Roland

Re: sAMAccountName

[<mi...@st...>]

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: mi...@st...
http://www.stroeder.com

Re: sAMAccountName

[Roland H. <rol...@ad...>]

Michael Ströder wrote:
> 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. :-)

I'm extremely sorry to hear this.
And wished I was able to leave it to the AD admins, but alas I can't.

Anyway, thanks Michael for the information.

-- Roland

Re: sAMAccountName

[<mi...@st...>]

Roland,

Michael Ströder wrote:
> Roland Hedberg wrote:
>> The error message I get is 'Server is unwilling to perform' which
>> doesn't really tell me a lot :-)
> 
> Most times it also returns a numeric error code with that message. You
> could try to search for that. Also the guys in the AD newsgroups on MS'
> NNTP server are quite helpful. Don't forget to let us know... ;-)

FWIW:

news://msnews.microsoft.com/microsoft.public.windows.server.active_directory

Ciao, Michael.

Re: sAMAccountName

[Geert J. <ge...@bo...>]

Roland Hedberg wrote:

> On the topic python-ldap <-> AD:
>
> My problem is that I can add an entry using the User object class and
> attributes contained in that class without any problems.
>
> But when I try to add the samAccountName attribute and thereby the
> object class SecurityPrincipal the server complains.
>   

I am not 100% sure wether this is the same issue, but I have noticed
that you cannot create a security principal in AD without a valid
password. But because you can only set the password once the principal
is created, this is a cyclical dependency. You can get out of this by
creating the account in the disabled state (by setting the appropriate
flag in userAccountControl), then setting the password, and then
enabling it.

On a related note, you may be interested in my current project
Python-AD: http://www.boskant.nl/trac/python-ad/ The code is ready for
use and I will make the first release in a couple of days. At the moment
the code is available though Mercurial.

I have an working example script of create a user with Python-AD here:
http://www.boskant.nl/trac/python-ad/wiki/TutorialFive The example sets
sAMAccountName and it works flawlessly.

Regards,
Geert

Re: sAMAccountName

[<mi...@st...>]

Geert Jansen wrote:
> 
> On a related note, you may be interested in my current project
> Python-AD: http://www.boskant.nl/trac/python-ad/

How are you using Kerberos? Do you expect the user to run MIT's kinit
before sending a SASL/GSSAPI bind request? Does it also work with
heimdal? Do you make use of a Windows logon when running on Windows?

Ciao, Michael.

Re: sAMAccountName

[Geert J. <ge...@bo...>]

Michael Ströder wrote:
> Geert Jansen wrote:
>   
>> On a related note, you may be interested in my current project
>> Python-AD: http://www.boskant.nl/trac/python-ad/
>>     
>
> How are you using Kerberos? Do you expect the user to run MIT's kinit
> before sending a SASL/GSSAPI bind request? Does it also work with
> heimdal? Do you make use of a Windows logon when running on Windows?
>   

The user doesn't need to run  kinit (but he can do so and in that case
those credentials can be picked up). I provide a class called "Creds"
that the user can use to acquire credentials:

    from ad import Creds, activate
    creds = Creds(domain)
    Creds.acquire(username, password)
    activate(creds)

Behind the scenes a new private ccache and Kerberos configuration are
installed using the $KRB5CCNAME and $KRB5_CONFIG environment variables.

I have not tested this with Heimdal so far. If it supports the
environment variables above it should work. Also I haven't tested
windows but I think that the Creds interface should be portable to that
platform as well.

Regards, Geert

Re: sAMAccountName

[Chaos E. <cha...@gm...>]

i think, the may be some problem if you set sAMAccountName inconsistent with
userPrincipalName.

BTW, If one Directory Server tells you that it UNWILLING TO PERFORM some
operations then you can not complete the same operations using ANY ldap
client!

On Dec 6, 2007 12:36 AM, Roland Hedberg <rol...@ad...> wrote:

> Hi!
>
> A short while ago there was a discussion about how to add users to an AD
> using python-ldap.
>
> I benefited a lot from that discussion, so you have my thanks too.
>
> On the topic python-ldap <-> AD:
>
> My problem is that I can add an entry using the User object class and
> attributes contained in that class without any problems.
>
> But when I try to add the samAccountName attribute and thereby the
> object class SecurityPrincipal the server complains.
>
> The error message I get is 'Server is unwilling to perform' which
> doesn't really tell me a lot :-)
>
> Anyone got a clue ?
>
> The AD isn't 'mine', but if there is something you need to know about it
> in order to answer my question I can ask the person in charge.
>
> -- Roland
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>



-- 
Best Regards
Chaos Eternal

Re: sAMAccountName

[<mi...@st...>]

Chaos Eternal wrote:
> i think, the may be some problem if you set sAMAccountName inconsistent
> with userPrincipalName.

AFAIK sAMAccountName and userPrincipalName are independent can be set
according to completely different naming conventions. You should try out
what is possible using the MMC User and Groups snapin.

Ciao, Michael.