Re: sAMAccountName
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: sAMAccountName
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: [EMAIL PROTECTED] http://www.stroeder.com - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: sAMAccountName
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. - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: sAMAccountName
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: sAMAccountName
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: sAMAccountName
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. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: sAMAccountName
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 <[EMAIL PROTECTED]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev > -- Best Regards Chaos Eternal - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
