From tioteath at gmail.com Tue Oct 2 11:24:46 2012 From: tioteath at gmail.com (Tio Teath) Date: Tue, 2 Oct 2012 12:24:46 +0300 Subject: [python-ldap] result() hangs up, when called with non-existing search_id Message-ID: When I'm trying to call result(search_id) with non-existing or broken search_id, the operation takes forever, i.e. execution stops. It doesn't seems proper behavior. From michael at stroeder.com Wed Oct 3 13:14:05 2012 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 03 Oct 2012 13:14:05 +0200 Subject: [python-ldap] result() hangs up, when called with non-existing search_id In-Reply-To: References: Message-ID: <506C1DFD.4030300@stroeder.com> Tio Teath wrote: > When I'm trying to call result(search_id) with non-existing or broken > search_id, the operation takes forever, i.e. execution stops. I tend to just say: Don't do this. > It doesn't seems proper behavior. This is the behaviour of the OpenLDAP client lib. There's not much we can do about it at python-ldap's level. Which OpenLDAP version are you using? Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3883 bytes Desc: S/MIME Cryptographic Signature URL: From mihait.upb at gmail.com Fri Oct 26 18:31:13 2012 From: mihait.upb at gmail.com (Mihai Tabara) Date: Fri, 26 Oct 2012 19:31:13 +0300 Subject: [python-ldap] Can't get a more specific exception when binding to LDAP server Message-ID: Hi everyone, I am struggling finding a way to get a more particular exception than 'Invalid_credentials(49)' when a binding to LDAP server cannot be established. I am pretty sure it is a common issue but my previous search didn't get me too far. Please accept my apologies if spamming with my question. So, let's assume my account on LDAP server has just been deactivated due to password aging, and therefore, password expiration. Trying to reach my account within a "ldapwhoami" call from ldap-utils Unix tools goes naturally and returns awaited response. === root at debian:~# ldapwhoami -e ppolicy -x -D "uid=mihait,ou=Users,dc=example,dc=com" -w secret ldap_bind: Invalid credentials (49); Password expired === ... whereas a call from python-ldap bindings returns only the generic 'invalid credentials' exception as follows: === >>conn = ldap.initialize("ldap://localhost:389") >>try: >> conn.simple_bind_s("uid=mihait,ou=Users,dc=example,dc=com", "secret") >>except ldap.INVALID_CREDENTIALS, e: >> print e >>conn.unbind_s() {'desc': 'Invalid credentials'} === Since I'm a newbie in stuff regarding LDAP, I tried different approaches and, unsuccessfully searched all over the web for possible explanations. Found out that C bindings handle this issue with a ldap_get_option() function which, basically calls for an extended text message (via the LDAP_OPT_ERROR_STRING attribute) In the same time, I found in the python-ldap docs an instance method similarly named which is associated with my LDAPObject; when calling it, returns None. When dug for more in the ldap/ldapobject.py, the corresponding fields, which I presume are "error_number" and "error_string" from CLASSATTR_OPTION_MAPPING dicionary hold None values. (at least error_string does whereas error_number holds 49). Since the C bindings manage to solve this problem, I expect python should do the same. Consequently, I'm definitely doing something wrong. Can anyone assist me with this, please ? Thanks a lot. Kind regards, Mihai -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Fri Oct 26 19:26:13 2012 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 26 Oct 2012 19:26:13 +0200 Subject: [python-ldap] Can't get a more specific exception when binding to LDAP server In-Reply-To: References: Message-ID: <508AC7B5.9030701@stroeder.com> Mihai Tabara wrote: > I am struggling finding a way to get a more particular exception than > 'Invalid_credentials(49)' when a binding to LDAP server cannot be established. > I am pretty sure it is a common issue but my previous search didn't get me too > far. Please accept my apologies if spamming with my question. > > So, let's assume my account on LDAP server has just been deactivated due to > password aging, and therefore, password expiration. > > Trying to reach my account within a "ldapwhoami" call from ldap-utils Unix > tools goes naturally and returns awaited response. > > === > root at debian:~# ldapwhoami -e ppolicy -x -D > "uid=mihait,ou=Users,dc=example,dc=com" -w secret > ldap_bind: Invalid credentials (49); Password expired Using -e ppolicy with OpenLDAP command-line tool sends the password policy control along with the (simple) bind request. Check out Demo/pyasn1/ppolicy.py in recent python-ldap source distribution to learn how to do that with python-ldap 2.4.6+. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3883 bytes Desc: S/MIME Cryptographic Signature URL: From mihait.upb at gmail.com Mon Oct 29 12:25:23 2012 From: mihait.upb at gmail.com (Mihai Tabara) Date: Mon, 29 Oct 2012 13:25:23 +0200 Subject: [python-ldap] Can't get a more specific exception when binding to LDAP server In-Reply-To: <508AC7B5.9030701@stroeder.com> References: <508AC7B5.9030701@stroeder.com> Message-ID: On Fri, Oct 26, 2012 at 8:26 PM, Michael Str?der wrote: > Using -e ppolicy with OpenLDAP command-line tool sends the password policy > control along with the (simple) bind request. > > Check out Demo/pyasn1/ppolicy.py in recent python-ldap source distribution > to > learn how to do that with python-ldap 2.4.6+. > > Ciao, Michael. > > Hi Michael, Thanks a lot for your answer. I have found the indicated script, within full-explanation about the password policy control, but, unfortunately I am still unable to get what I want. By the way, I'll make sure I'll read the CHANGES file next time, actually found a lot of useful information in it :) The scenario is at follows: 1. Say, my account in expiring in 3000 seconds === (sandbox)root at debian:/tmp# python ppolicy.py ldap://localhost:389/ *** ldap://localhost:389 - SimpleLDAPObject.set_option ((17, 3), {}) => result: None *** ldap://localhost:389 - SimpleLDAPObject.simple_bind (('uid=mihait,ou=Users,dc=example,dc=com', 'secret', [('1.3.6.1.4.1.42.2.27.8.5.1', False, None)], None), {}) => result: 1 *** ldap://localhost:389 - SimpleLDAPObject.result4 ((1, 1, -1, 0, 0, 0), {}) => result: (97, [], 1, [('1.3.6.1.4.1.42.2.27.8.5.1', 0, '0\x07\xa0\x05\x80\x03\x07|\xb1')]) PasswordPolicyControl error None timeBeforeExpiration 3000 graceAuthNsRemaining None === 2. Say my account is expired === (sandbox)root at debian:/tmp# python ppolicy.py ldap://localhost:389/ *** ldap://localhost:389 - SimpleLDAPObject.set_option ((17, 3), {}) => result: None Password for None: Password: *** ldap://localhost:389 - SimpleLDAPObject.simple_bind (('uid=mihait,ou=Users,dc=example,dc=com', 'secret', [('1.3.6.1.4.1.42.2.27.8.5.1', False, None)], None), {}) => result: 1 *** ldap://localhost:389 - SimpleLDAPObject.result4 ((1, 1, -1, 0, 0, 0), {}) => LDAPError - INVALID_CREDENTIALS: {'desc': 'Invalid credentials'} Simple bind failed: {'desc': 'Invalid credentials'} === Quick observations: * for testing, I'm changing the pwdChangedType attribute via Apache Directory Studio * I have used the indicated script (Demo/pyasn1/ppolicy.py), but hardcoded the ldap_url.who and ldap_url.cred directly into the bind operation within line 18. === ldap_url = ldapurl.LDAPUrl(sys.argv[1], who="uid=mihait,ou=Users,dc=example,dc=com", cred="secret") === The INVALID_CREDENTIALS returned response in case of password expiration shouldn't have had some extra info describing the cause ? (e.g. password expired, account locked) I suppose I am using something wrong. Can you please assist me with this too ? Thanks a lot, Mihai -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Mon Oct 29 19:46:04 2012 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 29 Oct 2012 19:46:04 +0100 Subject: [python-ldap] Can't get a more specific exception when binding to LDAP server In-Reply-To: References: <508AC7B5.9030701@stroeder.com> Message-ID: <508ECEEC.90608@stroeder.com> Mihai Tabara wrote: > On Fri, Oct 26, 2012 at 8:26 PM, Michael Str?der > wrote: > > Using -e ppolicy with OpenLDAP command-line tool sends the password policy > control along with the (simple) bind request. > > Check out Demo/pyasn1/ppolicy.py in recent python-ldap source distribution to > learn how to do that with python-ldap 2.4.6+. > > I have found the indicated script, within full-explanation about the password > policy control, but, unfortunately I am still unable to get what I want. Ah, sorry! Forgot this line in TODO: - Attach response controls to LDAPError instances to deliver the controls to the calling application in case of an error It means that response controls cannot be received by the application if the resultCode is not 0. This is a serious deficiency of the current implementations. C coders want to fix that. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3883 bytes Desc: S/MIME Cryptographic Signature URL: From mihait.upb at gmail.com Wed Oct 31 07:22:38 2012 From: mihait.upb at gmail.com (Mihai Tabara) Date: Wed, 31 Oct 2012 08:22:38 +0200 Subject: [python-ldap] Can't get a more specific exception when binding to LDAP server In-Reply-To: <508ECEEC.90608@stroeder.com> References: <508AC7B5.9030701@stroeder.com> <508ECEEC.90608@stroeder.com> Message-ID: On Mon, Oct 29, 2012 at 8:46 PM, Michael Str?der wrote: > Mihai Tabara wrote: > > On Fri, Oct 26, 2012 at 8:26 PM, Michael Str?der > > wrote: > > > > Using -e ppolicy with OpenLDAP command-line tool sends the password > policy > > control along with the (simple) bind request. > > > > Check out Demo/pyasn1/ppolicy.py in recent python-ldap source > distribution to > > learn how to do that with python-ldap 2.4.6+. > > > > I have found the indicated script, within full-explanation about the > password > > policy control, but, unfortunately I am still unable to get what I want. > > It means that response controls cannot be received by the application if > the > resultCode is not 0. This is a serious deficiency of the current > implementations. C coders want to fix that > > Looking forward for it :) Thanks again for your answer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cll at rincon.com Wed Nov 28 04:37:39 2012 From: cll at rincon.com (Carolyn Lanser) Date: Wed, 28 Nov 2012 03:37:39 +0000 Subject: [python-ldap] Programmatically enable/disable LDAP users from Python? Message-ID: I would like to programmatically enable/disable LDAP user accounts. From the command prompt I can use dsutil and this apparently sets/removes the nsAccountLock operational attribute. I have attempted to do modify_s() to set and remove this attribute from w/in Python but always get the following error message: "Insufficient 'write' privilege to the 'nsAccountLock' attribute of entry ''". Is there a way to set/remove/add operational attributes or otherwise enable/disable ldap users programmatically through Python? Thanks, C -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaoseternal at gmail.com Wed Nov 28 04:43:37 2012 From: chaoseternal at gmail.com (Chaos Eternal) Date: Wed, 28 Nov 2012 11:43:37 +0800 Subject: [python-ldap] Programmatically enable/disable LDAP users from Python? In-Reply-To: References: Message-ID: Hi, this depends on which ldap server you are using. On Nov 28, 2012 11:39 AM, "Carolyn Lanser" wrote: > I would like to programmatically enable/disable LDAP user accounts. From > the command prompt I can use dsutil and this apparently sets/removes the > nsAccountLock operational attribute. I have attempted to do modify_s() to > set and remove this attribute from w/in Python but always get the following > error message: "Insufficient 'write' privilege to the 'nsAccountLock' > attribute of entry ''".**** > > Is there a way to set/remove/add operational attributes or otherwise > enable/disable ldap users programmatically through Python?**** > > Thanks, C**** > > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.dukes.aix at gmail.com Wed Nov 28 04:48:45 2012 From: chris.dukes.aix at gmail.com (Chris Dukes) Date: Tue, 27 Nov 2012 22:48:45 -0500 Subject: [python-ldap] Programmatically enable/disable LDAP users from Python? In-Reply-To: References: Message-ID: <50B5899D.80504@gmail.com> You're going to have to read up on ACLs for the LDAP server you're using. I suspect that you're failing to bind as a privileged user as you did not mention it in your email. dsutil defaults to $LDAP_ADMIN_USER or cn=Directory Manager, and may further abuse a connection to localhost to determine authority. On 11/27/2012 10:37 PM, Carolyn Lanser wrote: > > I would like to programmatically enable/disable LDAP user accounts. > From the command prompt I can use dsutil and this apparently > sets/removes the nsAccountLock operational attribute. I have attempted > to do modify_s() to set and remove this attribute from w/in Python but > always get the following error message: "Insufficient 'write' > privilege to the 'nsAccountLock' attribute of entry ''". > > Is there a way to set/remove/add operational attributes or otherwise > enable/disable ldap users programmatically through Python? > > Thanks, C > > > > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at phyn3t.com Wed Nov 28 06:30:08 2012 From: peter at phyn3t.com (Peter Fisher) Date: Tue, 27 Nov 2012 21:30:08 -0800 Subject: [python-ldap] Programmatically enable/disable LDAP users from Python? In-Reply-To: References: Message-ID: <4F552BF9-977B-44A6-BA8E-8322E983F236@phyn3t.com> Look in your ldap servers slapd.conf (or related conf file) for the ACL that restricts this attribute. If your ldap server is OpenLDAP you could view: http://www.openldap.org/doc/admin24/access-control.html Cheers, Peter Fisher. On Nov 27, 2012, at 7:37 PM, Carolyn Lanser wrote: > nsAccountLock -------------- next part -------------- An HTML attachment was scrubbed... URL: From cll at rincon.com Wed Nov 28 20:10:13 2012 From: cll at rincon.com (Carolyn Lanser) Date: Wed, 28 Nov 2012 19:10:13 +0000 Subject: [python-ldap] Programmatically enable/disable LDAP users from Python? In-Reply-To: References: Message-ID: Chaos/Peter/Chris- Thank you for the replies. I was binding incorrectly (anonymously instead of with an admin dn). However I am still having issues. I printed out a user?s attributes before/after using dsutil to disable an account to see what changed, hoping that it would lead to an easy solution. The only difference I saw was nsAccountLock was present and set to [?true?] when the account was deactivated. I tried to simulate this programmatically, but this did not work. I changed the value of nsAccoutnLock to not be true but dsutil account-status still showed the account as active. Likewise, setting nsAccountLock on an active account was not sufficient to disable an account. Therefore it seems my assumptions were incorrect. We are using Oracle Directory Server Enterprise Edition (11.1.1.5.0). Does anybody have experience programmatically (using Python) enabling/disabling accounts? Perhaps this is just a Oracle LDAP implementation limitation? Cheers, C ________________________________ From: Chaos Eternal [mailto:chaoseternal at gmail.com] Hi, this depends on which ldap server you are using. On Nov 28, 2012 11:39 AM, "Carolyn Lanser" > wrote: I would like to programmatically enable/disable LDAP user accounts. From the command prompt I can use dsutil and this apparently sets/removes the nsAccountLock operational attribute. I have attempted to do modify_s() to set and remove this attribute from w/in Python but always get the following error message: "Insufficient 'write' privilege to the 'nsAccountLock' attribute of entry ''". Is there a way to set/remove/add operational attributes or otherwise enable/disable ldap users programmatically through Python? Thanks, C ________________________________ From: Peter Fisher Look in your ldap servers slapd.conf (or related conf file) for the ACL that restricts this attribute. If your ldap server is OpenLDAP you could view: http://www.openldap.org/doc/admin24/access-control.html Cheers, Peter Fisher. ________________________________ From: Chris Dukes > To: python-ldap at python.org Subject: Re: [python-ldap] Programmatically enable/disable LDAP users from Python? Message-ID: <50B5899D.80504 at gmail.com> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" You're going to have to read up on ACLs for the LDAP server you're using. I suspect that you're failing to bind as a privileged user as you did not mention it in your email. dsutil defaults to $LDAP_ADMIN_USER or cn=Directory Manager, and may further abuse a connection to localhost to determine authority. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.dukes.aix at gmail.com Wed Nov 28 21:35:37 2012 From: chris.dukes.aix at gmail.com (Chris Dukes) Date: Wed, 28 Nov 2012 15:35:37 -0500 Subject: [python-ldap] Programmatically enable/disable LDAP users from Python? In-Reply-To: References: Message-ID: <50B67599.4020905@gmail.com> nsAccountLock is an operational attribute. Whether or not you may manipulate that via an LDAP connection is up to Oracle. I suggest contacting Oracle Support instead of us as you are having issues with LDAP as implemented by Oracle, not with how python-ldap speaks LDAP to another LDAP server. http://docs.oracle.com/cd/E19225-01/821-0092/bzaoe/index.html The magic question you need to ask is "How do I disable an LDAP account via ldapmodify?" Once you have that answer you can implement it with nearly any API to the LDAP protocol. On 11/28/2012 02:10 PM, Carolyn Lanser wrote: > > Chaos/Peter/Chris- > > Thank you for the replies. I was binding incorrectly (anonymously > instead of with an admin dn). > > However I am still having issues. I printed out a user?s attributes > before/after using dsutil to disable an account to see what changed, > hoping that it would lead to an easy solution. The only difference I > saw was nsAccountLock was present and set to [?true?] when the account > was deactivated. I tried to simulate this programmatically, but this > did not work. I changed the value of nsAccoutnLock to not be true but > dsutil account-status still showed the account as active. Likewise, > setting nsAccountLock on an active account was not sufficient to > disable an account. > > Therefore it seems my assumptions were incorrect. We are using Oracle > Directory Server Enterprise Edition (11.1.1.5.0). Does anybody have > experience programmatically (using Python) enabling/disabling > accounts? Perhaps this is just a Oracle LDAP implementation limitation? > > Cheers, > > C > > ------------------------------------------------------------------------ > > *From:*Chaos Eternal [mailto:chaoseternal at gmail.com] > > Hi, this depends on which ldap server you are using. > > /On Nov 28, 2012 11:39 AM, "Carolyn Lanser" > wrote:/ > > /I would like to programmatically enable/disable LDAP user accounts. > From the command prompt I can use dsutil and this apparently > sets/removes the nsAccountLock operational attribute. I have attempted > to do modify_s() to set and remove this attribute from w/in Python but > always get the following error message: "Insufficient 'write' > privilege to the 'nsAccountLock' attribute of entry ''"./ > > /Is there a way to/set/remove/add operational attributes or otherwise > enable/disable ldap users programmatically through Python? > > /Thanks, C/ > > ------------------------------------------------------------------------ > > From: Peter Fisher > > Look in your ldap servers slapd.conf (or related conf file) for the > ACL that restricts this attribute. > > If your ldap server is OpenLDAP you could view: > > http://www.openldap.org/doc/admin24/access-control.html > > > > Cheers, > > Peter Fisher. > > ------------------------------------------------------------------------ > > From: Chris Dukes > > > To: python-ldap at python.org > > Subject: Re: [python-ldap] Programmatically enable/disable LDAP users > > from Python? > > Message-ID: <50B5899D.80504 at gmail.com > > > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > You're going to have to read up on ACLs for the LDAP server you're using. > > I suspect that you're failing to bind as a privileged user as you did > not mention it in your email. dsutil defaults to $LDAP_ADMIN_USER or > cn=Directory Manager, and may further abuse a connection to localhost > to determine authority. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cll at rincon.com Thu Nov 29 16:00:44 2012 From: cll at rincon.com (Carolyn Lanser) Date: Thu, 29 Nov 2012 15:00:44 +0000 Subject: [python-ldap] Programmatically enable/disable LDAP users from Python? In-Reply-To: References: Message-ID: Chris- I agree. It sounds like an Oracle implementation detail that I?m missing. I?ll see if I can get some help from Oracle Support. I appreciate your time. Cheers, C ________________________________ Message: 2 From: Chris Dukes > nsAccountLock is an operational attribute. Whether or not you may manipulate that via an LDAP connection is up to Oracle. I suggest contacting Oracle Support instead of us as you are having issues with LDAP as implemented by Oracle, not with how python-ldap speaks LDAP to another LDAP server. http://docs.oracle.com/cd/E19225-01/821-0092/bzaoe/index.html The magic question you need to ask is "How do I disable an LDAP account via ldapmodify?" Once you have that answer you can implement it with nearly any API to the LDAP protocol. From: Carolyn Lanser Sent: Wednesday, November 28, 2012 12:10 PM To: 'Chaos Eternal'; 'Peter Fisher'; 'Chris Dukes' Cc: python-ldap at python.org; Carolyn Lanser Subject: RE: [python-ldap] Programmatically enable/disable LDAP users from Python? Chaos/Peter/Chris- Thank you for the replies. I was binding incorrectly (anonymously instead of with an admin dn). However I am still having issues. I printed out a user?s attributes before/after using dsutil to disable an account to see what changed, hoping that it would lead to an easy solution. The only difference I saw was nsAccountLock was present and set to [?true?] when the account was deactivated. I tried to simulate this programmatically, but this did not work. I changed the value of nsAccoutnLock to not be true but dsutil account-status still showed the account as active. Likewise, setting nsAccountLock on an active account was not sufficient to disable an account. Therefore it seems my assumptions were incorrect. We are using Oracle Directory Server Enterprise Edition (11.1.1.5.0). Does anybody have experience programmatically (using Python) enabling/disabling accounts? Perhaps this is just a Oracle LDAP implementation limitation? Cheers, C ________________________________ From: Chaos Eternal [mailto:chaoseternal at gmail.com] Hi, this depends on which ldap server you are using. On Nov 28, 2012 11:39 AM, "Carolyn Lanser" > wrote: I would like to programmatically enable/disable LDAP user accounts. From the command prompt I can use dsutil and this apparently sets/removes the nsAccountLock operational attribute. I have attempted to do modify_s() to set and remove this attribute from w/in Python but always get the following error message: "Insufficient 'write' privilege to the 'nsAccountLock' attribute of entry ''". Is there a way to set/remove/add operational attributes or otherwise enable/disable ldap users programmatically through Python? Thanks, C ________________________________ From: Peter Fisher Look in your ldap servers slapd.conf (or related conf file) for the ACL that restricts this attribute. If your ldap server is OpenLDAP you could view: http://www.openldap.org/doc/admin24/access-control.html Cheers, Peter Fisher. ________________________________ From: Chris Dukes > To: python-ldap at python.org Subject: Re: [python-ldap] Programmatically enable/disable LDAP users from Python? Message-ID: <50B5899D.80504 at gmail.com> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" You're going to have to read up on ACLs for the LDAP server you're using. I suspect that you're failing to bind as a privileged user as you did not mention it in your email. dsutil defaults to $LDAP_ADMIN_USER or cn=Directory Manager, and may further abuse a connection to localhost to determine authority. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyasha.chigwamba at voss-solutions.com Thu Nov 29 16:54:39 2012 From: nyasha.chigwamba at voss-solutions.com (Nyasha Chigwamba) Date: Thu, 29 Nov 2012 17:54:39 +0200 Subject: [python-ldap] Attribute syntax definitions Message-ID: Hi All, I am implementing a mini LDAP client that is schema aware. I am at a point where I can retrieve all object classes and information about their attributes. I have seen that for the attribute syntax, only the oid of the syntax is available. Is there a reference table that describes what all syntax oids map to. I can only find RFC 4517 ( http://tools.ietf.org/html/rfc4517). Is this sufficient and accurate enough for any LDAP server type? Thank you in advance. Regards, Nyasha -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu Nov 29 22:08:30 2012 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 29 Nov 2012 22:08:30 +0100 Subject: [python-ldap] Attribute syntax definitions Message-ID: <50B7CECE.2050302@stroeder.com> nyasha.chigwamba at voss-solutions.com wrote: > I am implementing a mini LDAP client that is schema aware. Hmm, LDAP clients which are schema-aware don't stay "mini"... ;-) > I am at a point > where I can retrieve all object classes and information about their > attributes. I have seen that for the attribute syntax, only the oid of the > syntax is available. Is there a reference table that describes what all > syntax oids map to. I can only find RFC 4517 ( > http://tools.ietf.org/html/rfc4517). Is this sufficient and accurate enough > for any LDAP server type? RFC 4517 is a good start and most server deployments do not go beyond this. But there are vendor specific LDAPSyntax implementations with any possible OID. What you do you want to do with LDAP syntaxes? In general: If you want to write a truely generic schema-aware LDAP client be prepared to get a lot of stuff you did not expect. Being the author of web2ldap - IMHO the LDAP client with the most versatile schema support - I went through struggling a lot with various LDAP server implementations each with their own limitations and bugs in the schema. Also be prepared that you're client might not be allowed to read the subschema subentry due to access control restrictions. Maybe you should describe in more detail what you're trying to achieve. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3883 bytes Desc: S/MIME Cryptographic Signature URL: From Stephen_Peterson at cable.comcast.com Thu Nov 29 22:48:35 2012 From: Stephen_Peterson at cable.comcast.com (Peterson, Stephen) Date: Thu, 29 Nov 2012 21:48:35 +0000 Subject: [python-ldap] jython support Message-ID: <08708A1F6A48C745870F8A51E9C002D21CC8306D@PACDCEXMB14.cable.comcast.com> What do you suggest I use for python-ldap or do to it to get ldap client support on Jython? I inherited code that was using ldap-python throughout. And when I moved Django to jython I tried installing python-ldap but got an error saying that it was not supported. Looking around the web I see other people having other similar issues with python/jython compatiblility. . . they indicate it is multiprocessing vs multi-threading issue. I have no idea what to do here. Anyone else encounter this issue? What did you do? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaoseternal at gmail.com Thu Nov 29 23:23:07 2012 From: chaoseternal at gmail.com (Chaos Eternal) Date: Fri, 30 Nov 2012 06:23:07 +0800 Subject: [python-ldap] jython support In-Reply-To: <08708A1F6A48C745870F8A51E9C002D21CC8306D@PACDCEXMB14.cable.comcast.com> References: <08708A1F6A48C745870F8A51E9C002D21CC8306D@PACDCEXMB14.cable.comcast.com> Message-ID: Python-leap is depends on leap c library, while jython doesn't use c libraries. Java has native ldap support. On Nov 30, 2012 5:49 AM, "Peterson, Stephen" < Stephen_Peterson at cable.comcast.com> wrote: > What do you suggest I use for python-ldap or do to it to get ldap client > support on Jython? I inherited code that was using ldap-python throughout. > And when I moved Django to jython I tried installing python-ldap but got an > error saying that it was not supported. Looking around the web I see other > people having other similar issues with python/jython compatiblility. . . > they indicate it is multiprocessing vs multi-threading issue. I have no > idea what to do here. Anyone else encounter this issue? What did you do? > > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Fri Nov 30 08:54:01 2012 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 30 Nov 2012 08:54:01 +0100 Subject: [python-ldap] jython support In-Reply-To: <08708A1F6A48C745870F8A51E9C002D21CC8306D@PACDCEXMB14.cable.comcast.com> References: <08708A1F6A48C745870F8A51E9C002D21CC8306D@PACDCEXMB14.cable.comcast.com> Message-ID: <50B86619.5090208@stroeder.com> Peterson, Stephen wrote: > What do you suggest I use for python-ldap or do to it to get ldap client > support on Jython? python-ldap does not support Jython since it's a C wrapper module around the OpenLDAP client libs. I personally never used Jython so I can't give good advice. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3883 bytes Desc: S/MIME Cryptographic Signature URL: From nyasha.chigwamba at voss-solutions.com Fri Nov 30 09:51:28 2012 From: nyasha.chigwamba at voss-solutions.com (Nyasha Chigwamba) Date: Fri, 30 Nov 2012 10:51:28 +0200 Subject: [python-ldap] Attribute syntax definitions In-Reply-To: <50B7CECE.2050302@stroeder.com> References: <50B7CECE.2050302@stroeder.com> Message-ID: Thank you Michael. Comments inline. Regards, Nyasha. On Thu, Nov 29, 2012 at 11:08 PM, Michael Str?der wrote: > nyasha.chigwamba at voss-solutions.com wrote: > > I am implementing a mini LDAP client that is schema aware. > > Hmm, LDAP clients which are schema-aware don't stay "mini"... ;-) > Hmmm...a look at the schema directory of your web2ldap application, I see it gets quite involved! > > > I am at a point > > where I can retrieve all object classes and information about their > > attributes. I have seen that for the attribute syntax, only the oid of > the > > syntax is available. Is there a reference table that describes what all > > syntax oids map to. I can only find RFC 4517 ( > > http://tools.ietf.org/html/rfc4517). Is this sufficient and accurate > enough > > for any LDAP server type? > > RFC 4517 is a good start and most server deployments do not go beyond this. > But there are vendor specific LDAPSyntax implementations with any possible > OID. > > What you do you want to do with LDAP syntaxes? > I would like to I would like to validate input in my client when adding or modifying new object instances. > > In general: If you want to write a truely generic schema-aware LDAP client > be > prepared to get a lot of stuff you did not expect. Being the author of > web2ldap - IMHO the LDAP client with the most versatile schema support - I > went through struggling a lot with various LDAP server implementations each > with their own limitations and bugs in the schema. > I have been using JExplore on Ubuntu. I can't remember why I never completed the web2ldap installation but now that you mention, it might be worthwhile for me to try out the standalone installation. > Also be prepared that you're client might not be allowed to read the > subschema > subentry due to access control restrictions. > > Maybe you should describe in more detail what you're trying to achieve. > I would like to be able to create new instances of the various object classes from my client with the correct attributes in the correct format. The ideal would be to support the all CRUD functions but I can live with create, read, and delete. In my client, I am doing the following: 1. Read the dn of the 'subschemaSubentry' from the root DSE (bearing in mind that this might not be possible due to access restrictions). 2. Read the schema by searching the dn retrieved in (1) for 'objectClasses' and 'attributeTypes'. 3. Package the schema into a format that is compatible with the rest of my application (pretty much the object classes and their attributes, including data_formats of the attributes). [I should probably only restrict this to the leaf nodes in the object class hierarchies] 4. The next task that I would like to tackle involves listing all the instances of each [structural?] object class under a given base dn. 5. If (4) works, I would like to start adding and deleting the instances. Could I be reinventing the wheel here? I need to integrate LDAP into other applications that I work with so I might need interface directly with the LDAP servers. > > Ciao, Michael. > > > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From esiotrot at gmail.com Fri Nov 30 09:54:38 2012 From: esiotrot at gmail.com (Michael Wood) Date: Fri, 30 Nov 2012 10:54:38 +0200 Subject: [python-ldap] jython support In-Reply-To: <08708A1F6A48C745870F8A51E9C002D21CC8306D@PACDCEXMB14.cable.comcast.com> References: <08708A1F6A48C745870F8A51E9C002D21CC8306D@PACDCEXMB14.cable.comcast.com> Message-ID: On 29 November 2012 23:48, Peterson, Stephen wrote: > > What do you suggest I use for python-ldap or do to it to get ldap client support on Jython? I inherited code that was using ldap-python throughout. And when I moved Django to jython I tried installing python-ldap but got an error saying that it was not supported. Looking around the web I see other people having other similar issues with python/jython compatiblility. . . they indicate it is multiprocessing vs multi-threading issue. I have no idea what to do here. Anyone else encounter this issue? What did you do? I've not used Jython or LDAP in Java, but maybe the following will help: http://www.jython.org/archive/21/docs/usejava.html https://www.google.com/search?q=java+ldap+tutorial -- Michael Wood From Stephen_Peterson at cable.comcast.com Fri Nov 30 16:23:51 2012 From: Stephen_Peterson at cable.comcast.com (Peterson, Stephen) Date: Fri, 30 Nov 2012 15:23:51 +0000 Subject: [python-ldap] jython support In-Reply-To: References: <08708A1F6A48C745870F8A51E9C002D21CC8306D@PACDCEXMB14.cable.comcast.com>, Message-ID: <08708A1F6A48C745870F8A51E9C002D21CC83D76@PACDCEXMB14.cable.comcast.com> Yes that is what I was "afraid" of. :-) Thanks ________________________________________ From: Michael Wood [esiotrot at gmail.com] Sent: Friday, November 30, 2012 3:54 AM To: Peterson, Stephen Cc: python-ldap at python.org Subject: Re: [python-ldap] jython support On 29 November 2012 23:48, Peterson, Stephen wrote: > > What do you suggest I use for python-ldap or do to it to get ldap client support on Jython? I inherited code that was using ldap-python throughout. And when I moved Django to jython I tried installing python-ldap but got an error saying that it was not supported. Looking around the web I see other people having other similar issues with python/jython compatiblility. . . they indicate it is multiprocessing vs multi-threading issue. I have no idea what to do here. Anyone else encounter this issue? What did you do? I've not used Jython or LDAP in Java, but maybe the following will help: http://www.jython.org/archive/21/docs/usejava.html https://www.google.com/search?q=java+ldap+tutorial -- Michael Wood From michael at stroeder.com Mon Dec 3 22:12:29 2012 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 03 Dec 2012 22:12:29 +0100 Subject: [python-ldap] Attribute syntax definitions In-Reply-To: References: <50B7CECE.2050302@stroeder.com> Message-ID: <50BD15BD.6000202@stroeder.com> Nyasha Chigwamba wrote: > What you do you want to do with LDAP syntaxes? > > I would like to I would like to validate input in my client when adding or > modifying new object instances. LDAP syntaxes are most times not sufficient for input validation of attribute values. Most times one needs more. In web2ldap I have plugin classes I can register for LDAP syntaxes and attribute types. They have full access to the whole LDAP entry and the subschema. Very handy. > I would like to be able to create new instances of the various object classes > from my client with the correct attributes in the correct format. How generic should this be? Note that DIT content rules also influence the set of attributes usable in an entry. Some developers of a widely used LDAP client blame MS AD for not having LDAPv3 compliant subschema but they fail to evaluate the DIT content rules... Luckily python-ldap supports DIT content rules out-of-the-box. > The ideal > would be to support the all CRUD functions but I can live with create, read, > and delete. In my client, I am doing the following: > 1. Read the dn of the 'subschemaSubentry' from the root DSE (bearing in mind > that this might not be possible due to access restrictions). 'subschemaSubentry' is an operational attribute in every entry. Bear in mind that each part of the DIT could have its own subschema. > 2. Read the schema by searching the dn retrieved in (1) for 'objectClasses' > and 'attributeTypes'. > 3. Package the schema into a format that is compatible with the rest of my > application (pretty much the object classes and their attributes, including > data_formats of the attributes). [I should probably only restrict this to the > leaf nodes in the object class hierarchies] You should also implement subschema caching. > 4. The next task that I would like to tackle involves listing all the > instances of each [structural?] object class under a given base dn. > 5. If (4) works, I would like to start adding and deleting the instances. How generic is this meant to be? Do you aim to fully support all LDAP servers? Are you using python-ldap's module ldap.schema for that? Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3883 bytes Desc: S/MIME Cryptographic Signature URL: From fathed at gmail.com Fri Dec 7 23:51:34 2012 From: fathed at gmail.com (Chris Gray) Date: Fri, 7 Dec 2012 14:51:34 -0800 Subject: [python-ldap] simple_bind_s, no exception on empty password Message-ID: Hey everyone, I have a question with simple_bind_s. The code below, if passing in the wrong password, will return 1 as the exit code. It will return 0 if the bind is successful. That's pretty much all I need it to do. My problem is, if I just hit enter on the getpass() prompt, my exit code ends up being 0 anyway. Changing the bind line to ldap_conn.simple_bind_s(ldap_user, "") has the same effect, no exception thrown. That seems to do not even try to do the bind, but the lack of exception doesn't seem to be the right behavior either. Variable data is changed to protect... or some reason. Any suggestions? Thanks! Chris import sys import ldap import getpass ldap_user = sys.argv[1] ldap_pass = getpass.getpass() #if ldap_pass == "": # ldap_pass = "badpassword" ldap_conn = ldap.initialize('ldap://domaincontroller.fqdn') ldap_conn.protocol_version = 3 ldap_conn.set_option(ldap.OPT_REFERRALS, 0) ldap_domains = ['domain1', 'domain2', 'domain3', 'domain4', 'domain5', 'domain6', 'domain7'] for domain in ldap_domains: try: ldap_user += '@' + domain ldap_conn.simple_bind_s(ldap_user, ldap_pass) sys.exit(0) except Exception: pass sys.exit(1) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tktucker at gmail.com Sat Dec 8 02:39:34 2012 From: tktucker at gmail.com (Tom Tucker) Date: Fri, 7 Dec 2012 20:39:34 -0500 Subject: [python-ldap] simple_bind_s, no exception on empty password In-Reply-To: References: Message-ID: If you figure this out, please let me know. ;-) I check for credentials issues with 'except ldap.INVALID_CREDENTIALS' after attempting an add, delete, etc activity. On Fri, Dec 7, 2012 at 5:51 PM, Chris Gray wrote: > Hey everyone, I have a question with simple_bind_s. > > The code below, if passing in the wrong password, will return 1 as the > exit code. It will return 0 if the bind is successful. That's pretty much > all I need it to do. > > My problem is, if I just hit enter on the getpass() prompt, my exit code > ends up being 0 anyway. > > Changing the bind line to ldap_conn.simple_bind_s(ldap_user, "") has the > same effect, no exception thrown. That seems to do not even try to do the > bind, but the lack of exception doesn't seem to be the right behavior > either. > > Variable data is changed to protect... or some reason. > > Any suggestions? > Thanks! > Chris > > > import sys > import ldap > import getpass > > > ldap_user = sys.argv[1] > ldap_pass = getpass.getpass() > #if ldap_pass == "": > # ldap_pass = "badpassword" > > ldap_conn = ldap.initialize('ldap://domaincontroller.fqdn') > ldap_conn.protocol_version = 3 > ldap_conn.set_option(ldap.OPT_REFERRALS, 0) > > ldap_domains = ['domain1', > 'domain2', > 'domain3', > 'domain4', > 'domain5', > 'domain6', > 'domain7'] > > for domain in ldap_domains: > try: > ldap_user += '@' + domain > ldap_conn.simple_bind_s(ldap_user, ldap_pass) > sys.exit(0) > except Exception: > pass > > sys.exit(1) > > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fathed at gmail.com Sat Dec 8 03:04:16 2012 From: fathed at gmail.com (Chris Gray) Date: Fri, 7 Dec 2012 18:04:16 -0800 Subject: [python-ldap] simple_bind_s, no exception on empty password In-Reply-To: References: Message-ID: Yeah, I was checking that, but since the empty password was working, I switched it to catch all exceptions. None were triggered. I might just end up using the com objects, as I'm in windows land anyway. Looking at the ldap library code, this might be an OpenLDAP issue more so than an issue with the python-ldap library. On Fri, Dec 7, 2012 at 5:39 PM, Tom Tucker wrote: > > If you figure this out, please let me know. ;-) > I check for credentials issues with 'except ldap.INVALID_CREDENTIALS' > after attempting an add, delete, etc activity. > > > On Fri, Dec 7, 2012 at 5:51 PM, Chris Gray wrote: > >> Hey everyone, I have a question with simple_bind_s. >> >> The code below, if passing in the wrong password, will return 1 as the >> exit code. It will return 0 if the bind is successful. That's pretty much >> all I need it to do. >> >> My problem is, if I just hit enter on the getpass() prompt, my exit code >> ends up being 0 anyway. >> >> Changing the bind line to ldap_conn.simple_bind_s(ldap_user, "") has the >> same effect, no exception thrown. That seems to do not even try to do the >> bind, but the lack of exception doesn't seem to be the right behavior >> either. >> >> Variable data is changed to protect... or some reason. >> >> Any suggestions? >> Thanks! >> Chris >> >> >> import sys >> import ldap >> import getpass >> >> >> ldap_user = sys.argv[1] >> ldap_pass = getpass.getpass() >> #if ldap_pass == "": >> # ldap_pass = "badpassword" >> >> ldap_conn = ldap.initialize('ldap://domaincontroller.fqdn') >> ldap_conn.protocol_version = 3 >> ldap_conn.set_option(ldap.OPT_REFERRALS, 0) >> >> ldap_domains = ['domain1', >> 'domain2', >> 'domain3', >> 'domain4', >> 'domain5', >> 'domain6', >> 'domain7'] >> >> for domain in ldap_domains: >> try: >> ldap_user += '@' + domain >> ldap_conn.simple_bind_s(ldap_user, ldap_pass) >> sys.exit(0) >> except Exception: >> pass >> >> sys.exit(1) >> >> _______________________________________________ >> python-ldap mailing list >> python-ldap at python.org >> http://mail.python.org/mailman/listinfo/python-ldap >> >> > -- Intelligence is a matter of opinion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaoseternal at gmail.com Sat Dec 8 04:05:54 2012 From: chaoseternal at gmail.com (Chaos Eternal) Date: Sat, 8 Dec 2012 11:05:54 +0800 Subject: [python-ldap] simple_bind_s, no exception on empty password In-Reply-To: References: Message-ID: Hi, Chris This is the RIGHT behavior when the LDAP Server which allows anonymous bind. According to LDAP rfc, when no password provided to simple_bind, the bind will be considered anonymous. if you really dont want this to be happening , my suggestion is that you can use whoami_s right after a successful bind to check whether the DN is desired. On Sat, Dec 8, 2012 at 6:51 AM, Chris Gray wrote: > Hey everyone, I have a question with simple_bind_s. > > The code below, if passing in the wrong password, will return 1 as the exit > code. It will return 0 if the bind is successful. That's pretty much all I > need it to do. > > My problem is, if I just hit enter on the getpass() prompt, my exit code > ends up being 0 anyway. > > Changing the bind line to ldap_conn.simple_bind_s(ldap_user, "") has the > same effect, no exception thrown. That seems to do not even try to do the > bind, but the lack of exception doesn't seem to be the right behavior > either. > > Variable data is changed to protect... or some reason. > > Any suggestions? > Thanks! > Chris > > > import sys > import ldap > import getpass > > > ldap_user = sys.argv[1] > ldap_pass = getpass.getpass() > #if ldap_pass == "": > # ldap_pass = "badpassword" > > ldap_conn = ldap.initialize('ldap://domaincontroller.fqdn') > ldap_conn.protocol_version = 3 > ldap_conn.set_option(ldap.OPT_REFERRALS, 0) > > ldap_domains = ['domain1', > 'domain2', > 'domain3', > 'domain4', > 'domain5', > 'domain6', > 'domain7'] > > for domain in ldap_domains: > try: > ldap_user += '@' + domain > ldap_conn.simple_bind_s(ldap_user, ldap_pass) > sys.exit(0) > except Exception: > pass > > sys.exit(1) > > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap > From fathed at gmail.com Sat Dec 8 08:01:59 2012 From: fathed at gmail.com (Chris Gray) Date: Fri, 7 Dec 2012 23:01:59 -0800 Subject: [python-ldap] simple_bind_s, no exception on empty password In-Reply-To: References: Message-ID: Hmm, that's handy info. And that seems to work: if ldap_conn.whoami_s().lower() == "u:" + ldap_user.lower(): This of course leads to new problems. First, .lower() says it is to be considered deprecated. http://docs.python.org/2/library/string.html After searching the webs, everything I see still uses .lower() or .upper(), even if it says it's written for Python3. So, not really sure if I should be concerned about that for now. And the second issue, type(ldap_conn.whoami_s()) is "str". Everything else I've read suggests that ActiveDirectory is LDAPv3, which should always be unicode. This probably isn't something I really need to be concerned about, but I'd rather solve it now instead of waiting for someone else to have an odd problem. I'm in python 2.7. I tried adding this to top, as I've seen suggested, from __future__ import unicode_literals Doing that does make this string be unicode, "u:" + ldap_user.lower(), but not the string returned from the whoami_s call. Leaving it out returns both types as "str" (which is to be expected). I guess I would need a python3 version of the python-ldap library to solve that, meaning I should wait for the unicode issue, or try something like this: ldap_conn.whoami_s().decode('unicode_escape').encode('iso8859-1').decode('utf8'), which does set the type to unicode. This does work, just seems messy. Here's the current working version checking the supplied username against the whoami_s, (with deprecated .lower) Thanks Chaos Eternal! from __future__ import unicode_literals import sys import ldap import getpass ldap_user = sys.argv[1] ldap_pass = getpass.getpass() ldap_conn = ldap.initialize('ldap://domaincontroller') ldap_conn.protocol_version = 3 ldap_conn.set_option(ldap.OPT_REFERRALS, 0) ldap_domains = ['domain1', 'domain2', 'domain3', 'domain4', 'domain5', 'domain6', 'domain7'] for domain in ldap_domains: try: ldap_user = domain + "\\" + ldap_user ldap_conn.simple_bind_s(ldap_user, ldap_pass) ldap_who = ldap_conn.whoami_s().decode('unicode_escape').encode('iso8859-1').decode('utf8').lower() if ldap_who == "u:" + ldap_user.lower(): sys.exit(0) except Exception: pass sys.exit(1) On Fri, Dec 7, 2012 at 7:05 PM, Chaos Eternal wrote: > Hi, Chris > > This is the RIGHT behavior when the LDAP Server which allows anonymous > bind. According to LDAP rfc, when no password provided to simple_bind, > the bind will be considered anonymous. > > if you really dont want this to be happening , my suggestion is that > you can use whoami_s right after a successful bind to check whether > the DN is desired. > > > On Sat, Dec 8, 2012 at 6:51 AM, Chris Gray wrote: > > Hey everyone, I have a question with simple_bind_s. > > > > The code below, if passing in the wrong password, will return 1 as the > exit > > code. It will return 0 if the bind is successful. That's pretty much all > I > > need it to do. > > > > My problem is, if I just hit enter on the getpass() prompt, my exit code > > ends up being 0 anyway. > > > > Changing the bind line to ldap_conn.simple_bind_s(ldap_user, "") has the > > same effect, no exception thrown. That seems to do not even try to do the > > bind, but the lack of exception doesn't seem to be the right behavior > > either. > > > > Variable data is changed to protect... or some reason. > > > > Any suggestions? > > Thanks! > > Chris > > > > > > import sys > > import ldap > > import getpass > > > > > > ldap_user = sys.argv[1] > > ldap_pass = getpass.getpass() > > #if ldap_pass == "": > > # ldap_pass = "badpassword" > > > > ldap_conn = ldap.initialize('ldap://domaincontroller.fqdn') > > ldap_conn.protocol_version = 3 > > ldap_conn.set_option(ldap.OPT_REFERRALS, 0) > > > > ldap_domains = ['domain1', > > 'domain2', > > 'domain3', > > 'domain4', > > 'domain5', > > 'domain6', > > 'domain7'] > > > > for domain in ldap_domains: > > try: > > ldap_user += '@' + domain > > ldap_conn.simple_bind_s(ldap_user, ldap_pass) > > sys.exit(0) > > except Exception: > > pass > > > > sys.exit(1) > > > > _______________________________________________ > > python-ldap mailing list > > python-ldap at python.org > > http://mail.python.org/mailman/listinfo/python-ldap > > > -- Intelligence is a matter of opinion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaoseternal at gmail.com Sat Dec 8 08:06:17 2012 From: chaoseternal at gmail.com (Chaos Eternal) Date: Sat, 8 Dec 2012 15:06:17 +0800 Subject: [python-ldap] simple_bind_s, no exception on empty password In-Reply-To: References: Message-ID: Another way is to check whether the password is empty before bind. On Dec 8, 2012 3:01 PM, "Chris Gray" wrote: > Hmm, that's handy info. And that seems to work: > > if ldap_conn.whoami_s().lower() == "u:" + ldap_user.lower(): > > This of course leads to new problems. > First, .lower() says it is to be considered deprecated. > http://docs.python.org/2/library/string.html > > After searching the webs, everything I see still uses .lower() or > .upper(), even if it says it's written for Python3. So, not really sure if > I should be concerned about that for now. > > And the second issue, > type(ldap_conn.whoami_s()) is "str". Everything else I've read suggests > that ActiveDirectory is LDAPv3, which should always be unicode. > This probably isn't something I really need to be concerned about, but I'd > rather solve it now instead of waiting for someone else to have an odd > problem. > > I'm in python 2.7. I tried adding this to top, as I've seen suggested, > from __future__ import unicode_literals > > Doing that does make this string be unicode, "u:" + ldap_user.lower(), > but not the string returned from the whoami_s call. > Leaving it out returns both types as "str" (which is to be expected). > > I guess I would need a python3 version of the python-ldap library to solve > that, meaning I should wait for the unicode issue, or try something like > this: > ldap_conn.whoami_s().decode('unicode_escape').encode('iso8859-1').decode('utf8'), > which does set the type to unicode. This does work, just seems messy. > > Here's the current working version checking the supplied username against > the whoami_s, (with deprecated .lower) > > Thanks Chaos Eternal! > > > from __future__ import unicode_literals > import sys > import ldap > import getpass > > ldap_user = sys.argv[1] > ldap_pass = getpass.getpass() > > ldap_conn = ldap.initialize('ldap://domaincontroller') > ldap_conn.protocol_version = 3 > ldap_conn.set_option(ldap.OPT_REFERRALS, 0) > > ldap_domains = ['domain1', > 'domain2', > 'domain3', > 'domain4', > 'domain5', > 'domain6', > 'domain7'] > > for domain in ldap_domains: > try: > ldap_user = domain + "\\" + ldap_user > ldap_conn.simple_bind_s(ldap_user, ldap_pass) > ldap_who = > ldap_conn.whoami_s().decode('unicode_escape').encode('iso8859-1').decode('utf8').lower() > if ldap_who == "u:" + ldap_user.lower(): > sys.exit(0) > except Exception: > pass > > sys.exit(1) > > > On Fri, Dec 7, 2012 at 7:05 PM, Chaos Eternal wrote: > >> Hi, Chris >> >> This is the RIGHT behavior when the LDAP Server which allows anonymous >> bind. According to LDAP rfc, when no password provided to simple_bind, >> the bind will be considered anonymous. >> >> if you really dont want this to be happening , my suggestion is that >> you can use whoami_s right after a successful bind to check whether >> the DN is desired. >> >> >> On Sat, Dec 8, 2012 at 6:51 AM, Chris Gray wrote: >> > Hey everyone, I have a question with simple_bind_s. >> > >> > The code below, if passing in the wrong password, will return 1 as the >> exit >> > code. It will return 0 if the bind is successful. That's pretty much >> all I >> > need it to do. >> > >> > My problem is, if I just hit enter on the getpass() prompt, my exit code >> > ends up being 0 anyway. >> > >> > Changing the bind line to ldap_conn.simple_bind_s(ldap_user, "") has the >> > same effect, no exception thrown. That seems to do not even try to do >> the >> > bind, but the lack of exception doesn't seem to be the right behavior >> > either. >> > >> > Variable data is changed to protect... or some reason. >> > >> > Any suggestions? >> > Thanks! >> > Chris >> > >> > >> > import sys >> > import ldap >> > import getpass >> > >> > >> > ldap_user = sys.argv[1] >> > ldap_pass = getpass.getpass() >> > #if ldap_pass == "": >> > # ldap_pass = "badpassword" >> > >> > ldap_conn = ldap.initialize('ldap://domaincontroller.fqdn') >> > ldap_conn.protocol_version = 3 >> > ldap_conn.set_option(ldap.OPT_REFERRALS, 0) >> > >> > ldap_domains = ['domain1', >> > 'domain2', >> > 'domain3', >> > 'domain4', >> > 'domain5', >> > 'domain6', >> > 'domain7'] >> > >> > for domain in ldap_domains: >> > try: >> > ldap_user += '@' + domain >> > ldap_conn.simple_bind_s(ldap_user, ldap_pass) >> > sys.exit(0) >> > except Exception: >> > pass >> > >> > sys.exit(1) >> > >> > _______________________________________________ >> > python-ldap mailing list >> > python-ldap at python.org >> > http://mail.python.org/mailman/listinfo/python-ldap >> > >> > > > > -- > Intelligence is a matter of opinion. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fathed at gmail.com Sat Dec 8 08:09:40 2012 From: fathed at gmail.com (Chris Gray) Date: Fri, 7 Dec 2012 23:09:40 -0800 Subject: [python-ldap] simple_bind_s, no exception on empty password In-Reply-To: References: Message-ID: Yeah, I sort of was doing that, but in the wrong location. That solution in theory works for me just fine, as I don't allow accounts with no password. I may end up doing that regardless, but I think your suggestion to double check with the whoami_s is good as well, and probably should be done for correctness even if I check for a blank password. Thanks again! Chris On Fri, Dec 7, 2012 at 11:06 PM, Chaos Eternal wrote: > Another way is to check whether the password is empty before bind. > On Dec 8, 2012 3:01 PM, "Chris Gray" wrote: > >> Hmm, that's handy info. And that seems to work: >> >> if ldap_conn.whoami_s().lower() == "u:" + ldap_user.lower(): >> >> This of course leads to new problems. >> First, .lower() says it is to be considered deprecated. >> http://docs.python.org/2/library/string.html >> >> After searching the webs, everything I see still uses .lower() or >> .upper(), even if it says it's written for Python3. So, not really sure if >> I should be concerned about that for now. >> >> And the second issue, >> type(ldap_conn.whoami_s()) is "str". Everything else I've read suggests >> that ActiveDirectory is LDAPv3, which should always be unicode. >> This probably isn't something I really need to be concerned about, but >> I'd rather solve it now instead of waiting for someone else to have an odd >> problem. >> >> I'm in python 2.7. I tried adding this to top, as I've seen suggested, >> from __future__ import unicode_literals >> >> Doing that does make this string be unicode, "u:" + ldap_user.lower(), >> but not the string returned from the whoami_s call. >> Leaving it out returns both types as "str" (which is to be expected). >> >> I guess I would need a python3 version of the python-ldap library to >> solve that, meaning I should wait for the unicode issue, or try something >> like this: >> ldap_conn.whoami_s().decode('unicode_escape').encode('iso8859-1').decode('utf8'), >> which does set the type to unicode. This does work, just seems messy. >> >> Here's the current working version checking the supplied username against >> the whoami_s, (with deprecated .lower) >> >> Thanks Chaos Eternal! >> >> >> from __future__ import unicode_literals >> import sys >> import ldap >> import getpass >> >> ldap_user = sys.argv[1] >> ldap_pass = getpass.getpass() >> >> ldap_conn = ldap.initialize('ldap://domaincontroller') >> ldap_conn.protocol_version = 3 >> ldap_conn.set_option(ldap.OPT_REFERRALS, 0) >> >> ldap_domains = ['domain1', >> 'domain2', >> 'domain3', >> 'domain4', >> 'domain5', >> 'domain6', >> 'domain7'] >> >> for domain in ldap_domains: >> try: >> ldap_user = domain + "\\" + ldap_user >> ldap_conn.simple_bind_s(ldap_user, ldap_pass) >> ldap_who = >> ldap_conn.whoami_s().decode('unicode_escape').encode('iso8859-1').decode('utf8').lower() >> if ldap_who == "u:" + ldap_user.lower(): >> sys.exit(0) >> except Exception: >> pass >> >> sys.exit(1) >> >> >> On Fri, Dec 7, 2012 at 7:05 PM, Chaos Eternal wrote: >> >>> Hi, Chris >>> >>> This is the RIGHT behavior when the LDAP Server which allows anonymous >>> bind. According to LDAP rfc, when no password provided to simple_bind, >>> the bind will be considered anonymous. >>> >>> if you really dont want this to be happening , my suggestion is that >>> you can use whoami_s right after a successful bind to check whether >>> the DN is desired. >>> >>> >>> On Sat, Dec 8, 2012 at 6:51 AM, Chris Gray wrote: >>> > Hey everyone, I have a question with simple_bind_s. >>> > >>> > The code below, if passing in the wrong password, will return 1 as the >>> exit >>> > code. It will return 0 if the bind is successful. That's pretty much >>> all I >>> > need it to do. >>> > >>> > My problem is, if I just hit enter on the getpass() prompt, my exit >>> code >>> > ends up being 0 anyway. >>> > >>> > Changing the bind line to ldap_conn.simple_bind_s(ldap_user, "") has >>> the >>> > same effect, no exception thrown. That seems to do not even try to do >>> the >>> > bind, but the lack of exception doesn't seem to be the right behavior >>> > either. >>> > >>> > Variable data is changed to protect... or some reason. >>> > >>> > Any suggestions? >>> > Thanks! >>> > Chris >>> > >>> > >>> > import sys >>> > import ldap >>> > import getpass >>> > >>> > >>> > ldap_user = sys.argv[1] >>> > ldap_pass = getpass.getpass() >>> > #if ldap_pass == "": >>> > # ldap_pass = "badpassword" >>> > >>> > ldap_conn = ldap.initialize('ldap://domaincontroller.fqdn') >>> > ldap_conn.protocol_version = 3 >>> > ldap_conn.set_option(ldap.OPT_REFERRALS, 0) >>> > >>> > ldap_domains = ['domain1', >>> > 'domain2', >>> > 'domain3', >>> > 'domain4', >>> > 'domain5', >>> > 'domain6', >>> > 'domain7'] >>> > >>> > for domain in ldap_domains: >>> > try: >>> > ldap_user += '@' + domain >>> > ldap_conn.simple_bind_s(ldap_user, ldap_pass) >>> > sys.exit(0) >>> > except Exception: >>> > pass >>> > >>> > sys.exit(1) >>> > >>> > _______________________________________________ >>> > python-ldap mailing list >>> > python-ldap at python.org >>> > http://mail.python.org/mailman/listinfo/python-ldap >>> > >>> >> >> >> >> -- >> Intelligence is a matter of opinion. >> > -- Intelligence is a matter of opinion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fathed at gmail.com Mon Dec 10 10:27:45 2012 From: fathed at gmail.com (Chris Gray) Date: Mon, 10 Dec 2012 01:27:45 -0800 Subject: [python-ldap] simple_bind_s, no exception on empty password In-Reply-To: References: Message-ID: So, here's the final version I ended up going with. With added use of SSL/TLS so no more clear text passwords over the wire. I'm not really sure if the unicode matters too much, but I do need support Hangul (Korean). Haven't tested that yet. For the cert, just open mmc, add the cert snapin for local computer certs, and export your root ca cert. Only the public of course (you shouldn't have the private root cert on your workstation anyway). The DER format works fine for me. from __future__ import unicode_literals import sys import ldap import getpass ldap_user = sys.argv[1] ldap_pass = getpass.getpass() if ldap_pass == "": sys.exit(1) ldap.set_option(ldap.OPT_PROTOCOL_VERSION, ldap.VERSION3) ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_ALLOW) ldap.set_option(ldap.OPT_REFERRALS, 0) ldap.set_option(ldap.OPT_X_TLS_DEMAND, True) ldap_conn = ldap.initialize('ldaps://ldapaddress:636') ldap_conn.set_option(ldap.OPT_X_TLS_CERTFILE, 'Path\\To\\Cert') ldap_conn.set_option(ldap.OPT_NETWORK_TIMEOUT, 30) ldap_domains = ['domain1', 'domain2', 'domain3', 'domain4', 'domain5', 'domain6'] for domain in ldap_domains: try: ldap_user = domain + "\\" + ldap_user ldap_conn.simple_bind_s(ldap_user, ldap_pass) ldap_who = ldap_conn.whoami_s().decode('unicode_escape').encode('iso8859-1').decode('utf8') if ldap_who.lower() == "u:" + ldap_user.lower(): sys.exit(0) except Exception, e: pass sys.exit(1) On Fri, Dec 7, 2012 at 5:39 PM, Tom Tucker wrote: > > If you figure this out, please let me know. ;-) > I check for credentials issues with 'except ldap.INVALID_CREDENTIALS' > after attempting an add, delete, etc activity. > > > On Fri, Dec 7, 2012 at 5:51 PM, Chris Gray wrote: > >> Hey everyone, I have a question with simple_bind_s. >> >> The code below, if passing in the wrong password, will return 1 as the >> exit code. It will return 0 if the bind is successful. That's pretty much >> all I need it to do. >> >> My problem is, if I just hit enter on the getpass() prompt, my exit code >> ends up being 0 anyway. >> >> Changing the bind line to ldap_conn.simple_bind_s(ldap_user, "") has the >> same effect, no exception thrown. That seems to do not even try to do the >> bind, but the lack of exception doesn't seem to be the right behavior >> either. >> >> Variable data is changed to protect... or some reason. >> >> Any suggestions? >> Thanks! >> Chris >> >> >> import sys >> import ldap >> import getpass >> >> >> ldap_user = sys.argv[1] >> ldap_pass = getpass.getpass() >> #if ldap_pass == "": >> # ldap_pass = "badpassword" >> >> ldap_conn = ldap.initialize('ldap://domaincontroller.fqdn') >> ldap_conn.protocol_version = 3 >> ldap_conn.set_option(ldap.OPT_REFERRALS, 0) >> >> ldap_domains = ['domain1', >> 'domain2', >> 'domain3', >> 'domain4', >> 'domain5', >> 'domain6', >> 'domain7'] >> >> for domain in ldap_domains: >> try: >> ldap_user += '@' + domain >> ldap_conn.simple_bind_s(ldap_user, ldap_pass) >> sys.exit(0) >> except Exception: >> pass >> >> sys.exit(1) >> >> _______________________________________________ >> python-ldap mailing list >> python-ldap at python.org >> http://mail.python.org/mailman/listinfo/python-ldap >> >> > -- Intelligence is a matter of opinion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From esiotrot at gmail.com Mon Dec 10 14:39:58 2012 From: esiotrot at gmail.com (Michael Wood) Date: Mon, 10 Dec 2012 15:39:58 +0200 Subject: [python-ldap] simple_bind_s, no exception on empty password In-Reply-To: References: Message-ID: On 8 December 2012 09:01, Chris Gray wrote: > > Hmm, that's handy info. And that seems to work: > > if ldap_conn.whoami_s().lower() == "u:" + ldap_user.lower(): > > This of course leads to new problems. > First, .lower() says it is to be considered deprecated. > http://docs.python.org/2/library/string.html > > After searching the webs, everything I see still uses .lower() or > .upper(), even if it says it's written for Python3. So, not really sure if I > should be concerned about that for now. No. The docs are perhaps not as clear as they could be, but what they are trying to say is this. The following is deprecated: import string string.lower("Something") The following is the recommended way (i.e. exactly what you're doing): "Something".lower() > And the second issue, [...] > I guess I would need a python3 version of the python-ldap library to solve > that, meaning I should wait for the unicode issue, or try something like > this: > ldap_conn.whoami_s().decode('unicode_escape').encode('iso8859-1').decode('utf8'), > which does set the type to unicode. This does work, just seems messy. That looks completely wrong to me. You can't assume that something that is valid ISO 8859-1 will also be valid UTF-8. >>> x = "\\u00a0" >>> x.decode("unicode_escape").encode("iso8859-1").decode("utf8") Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.6/encodings/utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeDecodeError: 'utf8' codec can't decode byte 0xa0 in position 0: unexpected code byte Anyway, the result of the .decode("unicode_escape") is already a unicode string, so why encode and decode it again? Does ldap_conn.whoami_s() return a string with \uNNNN escape sequences in it? -- Michael Wood From michael at stroeder.com Mon Dec 10 19:09:08 2012 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 10 Dec 2012 19:09:08 +0100 Subject: [python-ldap] simple_bind_s, no exception on empty password In-Reply-To: References: Message-ID: <50C62544.4050008@stroeder.com> Chris Gray wrote: > ldap_conn.whoami_s().decode('unicode_escape').encode('iso8859-1').decode('utf8') This looks flawed. LDAPv3 simply uses UTF-8. So if you want to get the true Unicode string just do: ldap_conn.whoami_s().decode('utf8') Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3883 bytes Desc: S/MIME Cryptographic Signature URL: From nyasha.chigwamba at voss-solutions.com Wed Dec 12 10:36:10 2012 From: nyasha.chigwamba at voss-solutions.com (Nyasha Chigwamba) Date: Wed, 12 Dec 2012 11:36:10 +0200 Subject: [python-ldap] Attribute syntax definitions In-Reply-To: <50BD15BD.6000202@stroeder.com> References: <50B7CECE.2050302@stroeder.com> <50BD15BD.6000202@stroeder.com> Message-ID: On Mon, Dec 3, 2012 at 11:12 PM, Michael Str?der wrote: > Nyasha Chigwamba wrote: > > What you do you want to do with LDAP syntaxes? > > > > I would like to I would like to validate input in my client when adding > or > > modifying new object instances. > > LDAP syntaxes are most times not sufficient for input validation of > attribute > values. Most times one needs more. In web2ldap I have plugin classes I can > register for LDAP syntaxes and attribute types. They have full access to > the > whole LDAP entry and the subschema. Very handy. > > > I would like to be able to create new instances of the various object > classes > > from my client with the correct attributes in the correct format. > > How generic should this be? > At the moment, I am only creating instances of a single object class that is defined on the server. Eg. In my AD server, I can create an instance of the user class. The inheritance hierarchy of the user class contains (person, organizationalPerson, top). I do not support multiple inheritance but it might become a requirement. Multiple inheritance being, for example, creating a instance of the user class that also inherits from the account class. > > Note that DIT content rules also influence the set of attributes usable in > an > entry. Some developers of a widely used LDAP client blame MS AD for not > having > LDAPv3 compliant subschema but they fail to evaluate the DIT content > rules... > I also discovered that I got a larger set of attributes when I included the ditContentRules in my result attributes. However, I noticed that ditStructureRules are not return by Active Directory (optional as per relevant RFC) > > Luckily python-ldap supports DIT content rules out-of-the-box. > > > The ideal > > would be to support the all CRUD functions but I can live with create, > read, > > and delete. In my client, I am doing the following: > > 1. Read the dn of the 'subschemaSubentry' from the root DSE (bearing in > mind > > that this might not be possible due to access restrictions). > > 'subschemaSubentry' is an operational attribute in every entry. Bear in > mind > that each part of the DIT could have its own subschema. > Do you mean in contexts where, for example, referrals are used? > > > 2. Read the schema by searching the dn retrieved in (1) for > 'objectClasses' > > and 'attributeTypes'. > > 3. Package the schema into a format that is compatible with the rest of > my > > application (pretty much the object classes and their attributes, > including > > data_formats of the attributes). [I should probably only restrict this > to the > > leaf nodes in the object class hierarchies] > > You should also implement subschema caching. > > > 4. The next task that I would like to tackle involves listing all the > > instances of each [structural?] object class under a given base dn. > > 5. If (4) works, I would like to start adding and deleting the instances. > > How generic is this meant to be? Do you aim to fully support all LDAP > servers? > Are you using python-ldap's module ldap.schema for that? > It would be great if I can support all LDAP servers. > > Ciao, Michael. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed Dec 12 20:09:10 2012 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 12 Dec 2012 20:09:10 +0100 Subject: [python-ldap] Attribute syntax definitions In-Reply-To: References: <50B7CECE.2050302@stroeder.com> <50BD15BD.6000202@stroeder.com> Message-ID: <50C8D656.2030600@stroeder.com> Nyasha Chigwamba wrote: > On Mon, Dec 3, 2012 at 11:12 PM, Michael Str?der wrote: > How generic should this be? > > At the moment, I am only creating instances of a single object class that is > defined on the server. Eg. In my AD server, I can create an instance of the > user class. The inheritance hierarchy of the user class contains (person, > organizationalPerson, top). I do not support multiple inheritance but it might > become a requirement. Multiple inheritance being, for example, creating a > instance of the user class that also inherits from the account class. Fortunately ldap.schema already does all that for you: http://www.python-ldap.org/doc/html/ldap-schema.html#ldap.schema.subentry.SubSchema.attribute_types I know that ldap.schema is not documented very well. Doc contributions welcome... > Note that DIT content rules also influence the set of attributes usable in an > entry. Some developers of a widely used LDAP client blame MS AD for not having > LDAPv3 compliant subschema but they fail to evaluate the DIT content rules... > > I also discovered that I got a larger set of attributes when I included the > ditContentRules in my result attributes. However, I noticed that > ditStructureRules are not return by Active Directory (optional as per relevant > RFC) AD does not have DIT structure rules and name forms. AD extensively uses DIT content rules though. > 'subschemaSubentry' is an operational attribute in every entry. Bear in mind > that each part of the DIT could have its own subschema. > > Do you mean in contexts where, for example, referrals are used? Nothing about referrals. If you want to implement a really schema-aware client this client has to query the subschema subentry for each entry! web2ldap does that except when displaying search results. Schema caching is needed to let this scale. > It would be great if I can support all LDAP servers. Good luck! It's gonna be much work. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3883 bytes Desc: S/MIME Cryptographic Signature URL: From nyasha.chigwamba at voss-solutions.com Thu Dec 13 00:34:44 2012 From: nyasha.chigwamba at voss-solutions.com (Nyasha Chigwamba) Date: Thu, 13 Dec 2012 01:34:44 +0200 Subject: [python-ldap] Attribute syntax definitions In-Reply-To: <50C8D656.2030600@stroeder.com> References: <50B7CECE.2050302@stroeder.com> <50BD15BD.6000202@stroeder.com> <50C8D656.2030600@stroeder.com> Message-ID: Hi Michael, Thank you for giving some insight into extent of work required to implement a complete schema aware client - I will only implement partial schema support for now and add new features as the need arises. Regarding documentation contributions, I found that the online documentation for class ldap.schema.models.ObjectClass(schema_element_str=None) defines the following: kind Kind of an object class: 0 = ABSTRACT, 1 = STRUCTURAL, 2 = AUXILIARY After fiddling a bit, I discovered that the following holds (note the swap between structural and abstract kind constants): kind Kind of an object class: 0 = *STRUCTURAL*, 1 = *ABSTRACT*, 2 = AUXILIARY Regards, Nyasha On Wed, Dec 12, 2012 at 9:09 PM, Michael Str?der wrote: > Nyasha Chigwamba wrote: > > On Mon, Dec 3, 2012 at 11:12 PM, Michael Str?der > wrote: > > How generic should this be? > > > > At the moment, I am only creating instances of a single object class > that is > > defined on the server. Eg. In my AD server, I can create an instance of > the > > user class. The inheritance hierarchy of the user class contains (person, > > organizationalPerson, top). I do not support multiple inheritance but it > might > > become a requirement. Multiple inheritance being, for example, creating a > > instance of the user class that also inherits from the account class. > > Fortunately ldap.schema already does all that for you: > > > http://www.python-ldap.org/doc/html/ldap-schema.html#ldap.schema.subentry.SubSchema.attribute_types > > I know that ldap.schema is not documented very well. Doc contributions > welcome... > > > Note that DIT content rules also influence the set of attributes > usable in an > > entry. Some developers of a widely used LDAP client blame MS AD for > not having > > LDAPv3 compliant subschema but they fail to evaluate the DIT content > rules... > > > > I also discovered that I got a larger set of attributes when I included > the > > ditContentRules in my result attributes. However, I noticed that > > ditStructureRules are not return by Active Directory (optional as per > relevant > > RFC) > > AD does not have DIT structure rules and name forms. > AD extensively uses DIT content rules though. > > > 'subschemaSubentry' is an operational attribute in every entry. Bear > in mind > > that each part of the DIT could have its own subschema. > > > > Do you mean in contexts where, for example, referrals are used? > > Nothing about referrals. > > If you want to implement a really schema-aware client this client has to > query > the subschema subentry for each entry! web2ldap does that except when > displaying search results. Schema caching is needed to let this scale. > > > It would be great if I can support all LDAP servers. > > Good luck! It's gonna be much work. > > Ciao, Michael. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu Dec 13 09:22:51 2012 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 13 Dec 2012 09:22:51 +0100 Subject: [python-ldap] Attribute syntax definitions In-Reply-To: References: <50B7CECE.2050302@stroeder.com> <50BD15BD.6000202@stroeder.com> <50C8D656.2030600@stroeder.com> Message-ID: <50C9905B.3090301@stroeder.com> Nyasha Chigwamba wrote: > After fiddling a bit, I discovered that the following holds (note the swap > between structural and abstract kind constants): > kind > Kind of an object class: 0 = *STRUCTURAL*, 1 = *ABSTRACT*, 2 = AUXILIARY Yes, you're right. ldap.schema.models.ObjectClass.__doc__ is wrong. I've committed the patch below. Ciao, Michael. =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Lib/ldap/schema/models.py,v retrieving revision 1.45 diff -u -r1.45 models.py --- Lib/ldap/schema/models.py 7 Mar 2012 19:07:15 -0000 1.45 +++ Lib/ldap/schema/models.py 13 Dec 2012 08:21:35 -0000 @@ -124,8 +124,8 @@ an entry of the object class may have kind Kind of an object class: - 0 = ABSTRACT, - 1 = STRUCTURAL, + 0 = STRUCTURAL, + 1 = ABSTRACT, 2 = AUXILIARY sup This list of strings contains NAMEs or OIDs of object classes -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3883 bytes Desc: S/MIME Cryptographic Signature URL: From ath at b-one.net Fri Dec 21 13:49:41 2012 From: ath at b-one.net (Anders Th=?iso-8859-1?Q?=F8?=gersen) Date: Fri, 21 Dec 2012 12:49:41 GMT Subject: [python-ldap] Decoding AttributeValues Message-ID: <1356094181299.1838.7536@webmail02> Hi, I ran into a problem when decoding AttributeValues while using ldif.py. Looking a bit at?http://tools.ietf.org/html/rfc4514#section-2.4 I came up with the attached patch which fixes my problem. Best Regards Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ldif.py.patch Type: text/x-patch Size: 1006 bytes Desc: not available URL: From michael at stroeder.com Fri Dec 21 14:43:02 2012 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 21 Dec 2012 14:43:02 +0100 Subject: [python-ldap] Decoding AttributeValues In-Reply-To: <1356094181299.1838.7536@webmail02> References: <1356094181299.1838.7536@webmail02> Message-ID: <50D46766.6040906@stroeder.com> Anders, (please subscribe to the mailing list so I don't have to approve your posting. For this time I've manually approved your posting though.) Anders Th?gersen wrote: > I ran into a problem when decoding AttributeValues while using ldif.py. > Looking a bit at http://tools.ietf.org/html/rfc4514#section-2.4 I came up > with the attached patch which fixes my problem. I'm not sure your patch does address your problem at the right level. You're citing RFC 4514 which is about generating a string representation of distinguished names. IMO in LDIF you're just using those string representations but you don't have to deal with generating or decoding them - or at least not within python-ldap's module ldif. Decoding the ASN.1 values should be definitely done outside module ldif. So your patch is not accepted. Giving more input including example data would help understanding which particular problem you want to solve. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3883 bytes Desc: S/MIME Cryptographic Signature URL: