From anilj at entic.net Mon Jul 6 05:28:49 2009 From: anilj at entic.net (Anil) Date: Sun, 05 Jul 2009 20:28:49 -0700 Subject: server sort Message-ID: <4A516F71.9030301@entic.net> I am having a bit of a problem trying to setup the controlValue in LDAPControl for doing server sorting. My LDAP server supports this control, but I keep getting back Not supported error. Clearly this is a problem on my end with how I am passing in controlValue. I am not that familiar with BER encoding. So, from what I've found, I tried doing something like this: from pyasn1.type import univ, namedtype from pyasn1.codec.ber import encoder seq = univ.Sequence( componentType=namedtype.NamedTypes(namedtype.NamedType('attributeType', univ.OctetString("uid"))) ) control = [ldap.controls.LDAPControl('1.2.840.113556.1.4.473',True,seq)] I then pass control to LDAPObject.search_ext(). That doesn't work, and I am sure I massacred my intepretation of using the pyasn1 module. Unfortunately, the documentation for it is not clear to me. Any tips? Thanks From michael at stroeder.com Mon Jul 6 15:14:13 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 06 Jul 2009 15:14:13 +0200 Subject: server sort In-Reply-To: <4A516F71.9030301@entic.net> References: <4A516F71.9030301@entic.net> Message-ID: <4A51F8A5.7040405@stroeder.com> Anil wrote: > I am having a bit of a problem trying to setup the controlValue in > LDAPControl for doing server sorting. My LDAP server supports this > control, but I keep getting back Not supported error. Clearly this is a > problem on my end with how I am passing in controlValue. > > I am not that familiar with BER encoding. > > So, from what I've found, I tried doing something like this: > > from pyasn1.type import univ, namedtype > from pyasn1.codec.ber import encoder > > seq = univ.Sequence( > componentType=namedtype.NamedTypes(namedtype.NamedType('attributeType', > univ.OctetString("uid"))) > ) > > control = [ldap.controls.LDAPControl('1.2.840.113556.1.4.473',True,seq)] > > > I then pass control to LDAPObject.search_ext(). > > That doesn't work, and I am sure I massacred my intepretation of using > the pyasn1 module. Unfortunately, the documentation for it is not clear > to me. Never did this myself but here are some hints: 1. You have to actually encode the ASN.1 data structure represented in pyasn1 as BER. So you would have to call pyasn1.codec.ber.encoder(seq) somewhere. 2. You should more carefully read RFC 2891: SortKeyList is SEQUENCE OF SEQUENCE { .. }. I don't see the nested SEQUENCE in your code snipped above. 3. The python-ldap way of implementing a LDAP control would be deriving a new class for this control and implement the methods encodeControlValue() and decodeControlValue() as needed. Ciao, Michael. From michael at stroeder.com Tue Jul 7 16:57:14 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 07 Jul 2009 16:57:14 +0200 Subject: Egg news :-) In-Reply-To: <20090707145649.7f30df3c@atalante.iwm-kmrc.de> References: <20090707145649.7f30df3c@atalante.iwm-kmrc.de> Message-ID: <4A53624A.6080601@stroeder.com> Torsten Kurbad wrote: > @Michael: Can you please Please check http://www.python-ldap.org/download.shtml whether that's ok. Ciao, Michael. From python-ldap at tk-webart.de Tue Jul 7 14:56:49 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Tue, 7 Jul 2009 14:56:49 +0200 Subject: Egg news :-) Message-ID: <20090707145649.7f30df3c@atalante.iwm-kmrc.de> Hi list, it's been a while, but I finally managed to build some fresh Python-LDAP 2.3.8 eggs. In particular: - Win32 (Statically linked to OpenLDAP 2.4.16 and OpenSSL 0.9.8k, no further DLLs necessary.) - MacOS X 10.3 through 10.5 (Statically linked to OpenLDAP 2.4.16 and dynamically bound to the Cyrus-SASL and OpenSSL libs that ship with OS X 10.5.7 - only tested on 10.5.7 Intel - testers welcome!!!) - Linux x86 and x86_64 (aka amd64) (Built on Gentoo Linux, dynamically linked to OpenLDAP 2.4.16, Cyrus-SASL 2.1.23, OpenSSL 0.9.8k, all compiled with glibc-2.10.1) All eggs are available for Python versions 2.4 through 2.6 and can be downloaded via http://svn.kmrc.de/download/distribution/contrib/ @Michael: Can you please add the '/contrib/' subdir to the download link on the webpage and replace the HTML snippet beginning with "For the .egg files to work [...]" up to "[...] from the same directory as the .egg files" by the following lines (provided you have no objections to them, of course. ;-) --- snip --- Prerequisites: --- snap --- Btw.: Earlier today I sent the same mail to the list, but tried to send the snippet as an attachment. That didn't seem to work, probably due to SF list restrictions... Best regards, Torsten -- Anyone can do any amount of work provided it isn't the work he is supposed to be doing at the moment. -- Robert Benchley From plone at alopes.com Tue Jul 7 16:56:43 2009 From: plone at alopes.com (Alberto Lopes) Date: Tue, 7 Jul 2009 11:56:43 -0300 Subject: Egg news :-) In-Reply-To: <20090707145649.7f30df3c@atalante.iwm-kmrc.de> References: <20090707145649.7f30df3c@atalante.iwm-kmrc.de> Message-ID: Torsten, That's excellent news for Windows users - the dll management was an extra chore I am glad to get rid of! :-) Congrats, Alberto On Tue, Jul 7, 2009 at 9:56 AM, Torsten Kurbad wrote: > Hi list, > > it's been a while, but I finally managed to build some fresh > Python-LDAP 2.3.8 eggs. In particular: > > - Win32 (Statically linked to OpenLDAP 2.4.16 and OpenSSL 0.9.8k, no > further DLLs necessary.) > - MacOS X 10.3 through 10.5 (Statically linked to OpenLDAP 2.4.16 and > dynamically bound to the Cyrus-SASL and OpenSSL libs that ship with > OS X 10.5.7 - only tested on 10.5.7 Intel - testers welcome!!!) > - Linux x86 and x86_64 (aka amd64) (Built on Gentoo Linux, dynamically > linked to OpenLDAP 2.4.16, Cyrus-SASL 2.1.23, OpenSSL 0.9.8k, all > compiled with glibc-2.10.1) > > All eggs are available for Python versions 2.4 through 2.6 and can be > downloaded via > > http://svn.kmrc.de/download/distribution/contrib/ > > @Michael: Can you please add the '/contrib/' subdir to the download > link on the webpage and replace the HTML snippet beginning with > "For the .egg files to work [...]" up to "[...] from the same directory > as the .egg files" by the following lines (provided you have no > objections to them, of course. ;-) > > --- snip --- > > Prerequisites: > > > > --- snap --- > > Btw.: Earlier today I sent the same mail to the list, but tried to send > the snippet as an attachment. That didn't seem to work, probably due to > SF list restrictions... > > Best regards, > Torsten > -- > Anyone can do any amount of work provided it isn't the work he is > supposed to be doing at the moment. > -- Robert Benchley > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/blackberry > _______________________________________________ > Python-LDAP-dev mailing list > Python-LDAP-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From python-ldap at tk-webart.de Tue Jul 7 17:01:03 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Tue, 7 Jul 2009 17:01:03 +0200 Subject: Egg news :-) In-Reply-To: <4A53624A.6080601@stroeder.com> References: <20090707145649.7f30df3c@atalante.iwm-kmrc.de> <4A53624A.6080601@stroeder.com> Message-ID: <20090707170103.0f45bf7a@atalante.iwm-kmrc.de> Hi Michael, > Please check http://www.python-ldap.org/download.shtml > whether that's ok. that's excellent! Thanks for the fast reply. Torsten -- Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de The best cure for insomnia is to get a lot of sleep. -W.C. Fields From python-ldap at tk-webart.de Tue Jul 7 12:27:30 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Tue, 7 Jul 2009 12:27:30 +0200 Subject: Egg news :-) Message-ID: <20090707122730.6f1a796f@atalante.iwm-kmrc.de> Hi list, it's been a while, but I finally managed to build some fresh Python-LDAP 2.3.8 eggs. In particular: - Win32 (Statically linked to OpenLDAP 2.4.16 and OpenSSL 0.9.8k, no further DLLs necessary.) - MacOS X 10.3 through 10.5 (Statically linked to OpenLDAP 2.4.16 and dynamically bound to the Cyrus-SASL and OpenSSL libs that ship with OS X 10.5.7 - only tested on 10.5.7 Intel - testers welcome!!!) - Linux x86 and x86_64 (aka amd64) (Built on Gentoo Linux, dynamically linked to OpenLDAP 2.4.16, Cyrus-SASL 2.1.23, OpenSSL 0.9.8k, all compiled with glibc-2.10.1) All eggs are available for Python versions 2.4 through 2.6 and can be downloaded via http://svn.kmrc.de/download/distribution/contrib/ @Michael: Can you please add the '/contrib/' subdir to the download link on the webpage and replace the HTML snippet beginning with "For the .egg files to work [...]" up to "[...] from the same directory as the .egg files" by the one attached (provided you have no objections to it, of course. ;-) Best regards, Torsten -- Anyone can do any amount of work provided it isn't the work he is supposed to be doing at the moment. -- Robert Benchley -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Mon Jul 13 11:20:44 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 13 Jul 2009 11:20:44 +0200 Subject: Apache DS ignores attrsonly In-Reply-To: References: Message-ID: <4A5AFC6C.2030805@stroeder.com> Thorsten Kampe wrote: > [4]>>> connection.search_s('ou=system', ldap.SCOPE_SUBTREE, > filterstr='(cn=*)', attrlist = ['cn'], attrsonly = True) Just a wild guess: Could you please try again with attrsonly=1. Note that this API has its roots in Python 1.x times where there was no Boolean True/False type. It would be worth handling that gracefully though. Ciao, Michael. From thorsten at thorstenkampe.de Mon Jul 13 11:07:53 2009 From: thorsten at thorstenkampe.de (Thorsten Kampe) Date: Mon, 13 Jul 2009 11:07:53 +0200 Subject: Apache DS ignores attrsonly Message-ID: [Python 2.6.2, python-ldap 2.3.8, Apache DS 1.5.4] Hi, not sure whether this is an Apache DS or Python-LDAP bug: Apache DS replies with values although I specifically request it not to: [1]>>> import ldap [2]>>> connection = ldap.initialize('ldap://') [3]>>> connection.simple_bind_s('uid=admin,ou=system', 'secret') [3] (97, []) [4]>>> connection.search_s('ou=system', ldap.SCOPE_SUBTREE, filterstr='(cn=*)', attrlist = ['cn'], attrsonly = True) [4] [('uid=admin,ou=system', {'cn': ['system administrator']}), ('cn=Administrators,ou=groups,ou=system', {'cn': ['Administrators']})] But: ~/.ldaprc BASE ou=system BINDDN uid=admin,ou=system URI ldap:// thorsten at tkampe[~]> ldapsearch -x -w secret -LLL -A "(cn=*)" cn dn: uid=admin,ou=system cn: dn: cn=Administrators,ou=groups,ou=system cn: The same query works (does not return values) if I query an Active Directory or eDirectory server. Thorsten From michael at stroeder.com Mon Jul 13 11:51:29 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 13 Jul 2009 11:51:29 +0200 Subject: Apache DS ignores attrsonly In-Reply-To: <4A5AFC6C.2030805@stroeder.com> References: <4A5AFC6C.2030805@stroeder.com> Message-ID: <4A5B03A1.2020501@stroeder.com> Michael Str?der wrote: > Thorsten Kampe wrote: >> [4]>>> connection.search_s('ou=system', ldap.SCOPE_SUBTREE, >> filterstr='(cn=*)', attrlist = ['cn'], attrsonly = True) > > Just a wild guess: Could you please try again with attrsonly=1. Note > that this API has its roots in Python 1.x times where there was no > Boolean True/False type. It would be worth handling that gracefully though. Which versions of Python and python-ldap are you using? I've tested it with my local OpenLDAP server with Python 2.6 and python-ldap 2.3.8 built against OpenLDAP RE24 libs: >>> l.search_ext_s('dc=stroeder,dc=de',0,'(objectclass=*)',attrsonly=0) [('dc=stroeder,dc=de', {'description': ['Wurzeleintrag f\xc3\xbcr lokales Adressbuch von Michael Str\xc3\xb6der'], 'labeledURI': ['http://www.stroeder.de', 'http://www.block-floete.de'], 'objectClass': ['domain', 'labeledURIObject', 'domainRelatedObject'], 'associatedDomain': ['stroeder.com'], 'dc': ['stroeder'], 'o': ['Michaels'], 'seeAlso': ['dc=stroeder,dc=com']})] >>> l.search_ext_s('dc=stroeder,dc=de',0,'(objectclass=*)',attrsonly=1) [('dc=stroeder,dc=de', {'description': [], 'labeledURI': [], 'objectClass': [], 'associatedDomain': [], 'dc': [], 'o': [], 'seeAlso': []})] >>> l.search_ext_s('dc=stroeder,dc=de',0,'(objectclass=*)',attrsonly=True) [('dc=stroeder,dc=de', {'description': [], 'labeledURI': [], 'objectClass': [], 'associatedDomain': [], 'dc': [], 'o': [], 'seeAlso': []})] So it seems that it simply works. Ciao, Michael. From thorsten at thorstenkampe.de Mon Jul 13 12:17:22 2009 From: thorsten at thorstenkampe.de (Thorsten Kampe) Date: Mon, 13 Jul 2009 12:17:22 +0200 Subject: Apache DS ignores attrsonly References: <4A5AFC6C.2030805@stroeder.com> Message-ID: * Michael Str?der (Mon, 13 Jul 2009 11:20:44 +0200) > Thorsten Kampe wrote: > > [4]>>> connection.search_s('ou=system', ldap.SCOPE_SUBTREE, > > filterstr='(cn=*)', attrlist = ['cn'], attrsonly = True) > > Just a wild guess: Could you please try again with attrsonly=1. Note > that this API has its roots in Python 1.x times where there was no > Boolean True/False type. It would be worth handling that gracefully though. Same result. Thorsten From michael at stroeder.com Mon Jul 13 13:23:26 2009 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Mon, 13 Jul 2009 13:23:26 +0200 Subject: Apache DS ignores attrsonly In-Reply-To: References: <4A5AFC6C.2030805@stroeder.com> <4A5B03A1.2020501@stroeder.com> Message-ID: <4A5B192E.3010005@stroeder.com> Thorsten Kampe wrote: > It does work against eDirectory and Active Directory (as mentioned). ...and OpenLDAP. So the likelihood is very high that python-ldap does not have a bug. > "ldapsearch -A" also works against Apache DS. The question is still: is > that a Python-LDAP or Apache DS bug? It's a ApacheDS bug. > Could you install Apache Directory Server or Apache Directory Studio? Hmm, you're very generous with my spare time. > Both allow you to create that directory that I queried in about one > minute. I did and watching the LDAP traffic with Wireshark shows that ApacheDS returns the attribute values although searchRequest::typesOnly is True on the wire. In opposite to that OpenLDAP's slapd does not return any attribute values in this case. I suspect ldapsearch -A also changes the way how found entries are displayed. Please next time use Wireshark to track things down. Ciao, Michael. From thorsten at thorstenkampe.de Mon Jul 13 12:22:45 2009 From: thorsten at thorstenkampe.de (Thorsten Kampe) Date: Mon, 13 Jul 2009 12:22:45 +0200 Subject: Apache DS ignores attrsonly References: <4A5AFC6C.2030805@stroeder.com> <4A5B03A1.2020501@stroeder.com> Message-ID: * Michael Str?der (Mon, 13 Jul 2009 11:51:29 +0200) > Which versions of Python and python-ldap are you using? Python 2.6.2, python-ldap 2.3.8, Apache DS 1.5.4 > I've tested it with my local OpenLDAP server with Python 2.6 and > python-ldap 2.3.8 built against OpenLDAP RE24 libs: > > >>> l.search_ext_s('dc=stroeder,dc=de',0,'(objectclass=*)',attrsonly=0) > [('dc=stroeder,dc=de', {'description': ['Wurzeleintrag f\xc3\xbcr > lokales Adressbuch von Michael Str\xc3\xb6der'], 'labeledURI': > ['http://www.stroeder.de', 'http://www.block-floete.de'], 'objectClass': > ['domain', 'labeledURIObject', 'domainRelatedObject'], > 'associatedDomain': ['stroeder.com'], 'dc': ['stroeder'], 'o': > ['Michaels'], 'seeAlso': ['dc=stroeder,dc=com']})] > >>> l.search_ext_s('dc=stroeder,dc=de',0,'(objectclass=*)',attrsonly=1) > [('dc=stroeder,dc=de', {'description': [], 'labeledURI': [], > 'objectClass': [], 'associatedDomain': [], 'dc': [], 'o': [], 'seeAlso': > []})] > >>> l.search_ext_s('dc=stroeder,dc=de',0,'(objectclass=*)',attrsonly=True) > [('dc=stroeder,dc=de', {'description': [], 'labeledURI': [], > 'objectClass': [], 'associatedDomain': [], 'dc': [], 'o': [], 'seeAlso': > []})] > > So it seems that it simply works. It does work against eDirectory and Active Directory (as mentioned). "ldapsearch -A" also works against Apache DS. The question is still: is that a Python-LDAP or Apache DS bug? Could you install Apache Directory Server or Apache Directory Studio? Both allow you to create that directory that I queried in about one minute. Thorsten From thorsten at thorstenkampe.de Mon Jul 13 13:43:57 2009 From: thorsten at thorstenkampe.de (Thorsten Kampe) Date: Mon, 13 Jul 2009 13:43:57 +0200 Subject: Apache DS ignores attrsonly References: <4A5AFC6C.2030805@stroeder.com> <4A5B03A1.2020501@stroeder.com> <4A5B192E.3010005@stroeder.com> Message-ID: * Michael Str?der (Mon, 13 Jul 2009 13:23:26 +0200) > Thorsten Kampe wrote: > > It does work against eDirectory and Active Directory (as mentioned). > > ...and OpenLDAP. So the likelihood is very high that python-ldap does > not have a bug. > > > "ldapsearch -A" also works against Apache DS. The question is still: is > > that a Python-LDAP or Apache DS bug? > > It's a ApacheDS bug. > > > Could you install Apache Directory Server or Apache Directory Studio? > > Hmm, you're very generous with my spare time. > > Both allow you to create that directory that I queried in about one > > minute. > > I did and watching the LDAP traffic with Wireshark shows that ApacheDS > returns the attribute values although searchRequest::typesOnly is True > on the wire. In opposite to that OpenLDAP's slapd does not return any > attribute values in this case. > > I suspect ldapsearch -A also changes the way how found entries are > displayed. > > Please next time use Wireshark to track things down. I would have done it if that would be an option. Apart from the fact that my Apache DS runs on my local host and winpcap not being able to capture packets on the looback interface (on Windows) I am not familiar with LDAP enough to be able to judge what "searchRequest::typesOnly" is or means. Nevertheless thanks, I'm going to open a bug with the Apache DS team. Thorsten From michael at stroeder.com Wed Jul 15 13:28:27 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 15 Jul 2009 13:28:27 +0200 Subject: Minor changes/improvements for 2.3.9 Message-ID: <4A5DBD5B.3010907@stroeder.com> HI! I'm going to release python-ldap 2.3.9 soon. Are there any suggestions for minor changes/improvements which should be added to this release? Ciao, Michael. From michael at stroeder.com Wed Jul 22 18:03:59 2009 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Wed, 22 Jul 2009 18:03:59 +0200 Subject: License for python-ldap In-Reply-To: References: Message-ID: <4A67386F.8030908@stroeder.com> David, David Gotz wrote: > I could not find any mention of a license in the > documentation for python-ldap. Can you tell me how > python-ldap is opensourced? Is it covered by the Python > license? OpenLDAP license? GPL? It's definitely not GPL. There's a file LICENCE in python-ldap's source distribution tar.gz. Basically the intention is that whatever you can do with Python or whereever you're allowed to deploy Python the same applies to python-ldap. This could change in the future in such a way that we can integrate python-ldap into the Python standard lib. Which means: The license will be probably even more liberal. You should definitely ask those questions on the python-ldap-dev mailing list (Cc:-ed). Ciao, Michael. From michael at stroeder.com Sun Jul 26 15:20:22 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 26 Jul 2009 15:20:22 +0200 Subject: To do: LDAPv3 response controls / ldap.LDAPError exceptions Message-ID: <4A6C5816.3020705@stroeder.com> HI! In some situations there are controls attached to a LDAP response also in the case if LDAPResult::resultCode is not success(0). python-ldap just generates an exception in this case with resultCode, diagnosticMessage etc. But a calling application might also need to have access to the controls which might indicate more details why the operation failed. One important example for this behaviour are password policy controls and the bind operation (see [1] and [2]). The response controls define why the operation failed (e.g. password soon to expire, password reset needed). Could somebody with C programming skills please look into how to return these controls to the calling application via exception? Also we should look at how response controls can be returned to the application in case of intermediate responses. E.g. this is needed for implementing syncrepl in searchAndPersist mode with search requests. Ciao, Michael. [1] http://tools.ietf.org/draft/draft-behera-ldap-password-policy/ [2] http://tools.ietf.org/draft/draft-vchu-ldap-pwd-policy/ From python-ldap at tk-webart.de Mon Jul 13 16:14:16 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Mon, 13 Jul 2009 16:14:16 +0200 Subject: Egg news :-) In-Reply-To: <20090707145649.7f30df3c@atalante.iwm-kmrc.de> References: <20090707145649.7f30df3c@atalante.iwm-kmrc.de> Message-ID: <20090713161416.560d791b@atalante.iwm-kmrc.de> Hi list, JFI: during the weekend I had the opportunity to confirm that the statically linked Mac OS X egg for Python 2.6 works perfectly on a freshly installed OS X 10.4.11 PPC. Not even XCode is needed. Now I'm still trying to figure how to get cyrus-sasl working properly for the Win32 eggs. Waldemar already gave me some hints, but there must be a clean way to do it without building all of cyrus' dependencies (how else would the subversion folks manage to survive... ;-) Best regards Torsten -- It's more than magnificent-it's mediocre. -Samuel Goldwyn From michael at stroeder.com Sun Jul 26 16:59:42 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 26 Jul 2009 16:59:42 +0200 Subject: ANN: python-ldap-2.3.9 Message-ID: <4A6C6F5E.2090409@stroeder.com> Find a new release of python-ldap: http://www.python-ldap.org/ python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema). Ciao, Michael. -- Michael Str?der E-Mail: michael at stroeder.com http://www.stroeder.com From michael at stroeder.com Fri Jul 31 10:05:49 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 31 Jul 2009 10:05:49 +0200 Subject: version 2.3.8 In-Reply-To: <4A5607AD.9080003@examiner.ie> References: <4A5607AD.9080003@examiner.ie> Message-ID: <4A72A5DD.1010007@stroeder.com> Larry, please note that non-subscriber postings to python-ldap-dev are deferred. Larry kavanagh wrote: > Triying to install python-ldap-2.3.8 using the EXE on a server (windows > 2000) that has python 2.4.4 installed (or so the plone site tells me) > > however it won't install and tells me that "python 2.4 required which > was not found in the registry" Which EXE files did you use? It has to exactly match the Python version used. So for using python-ldap 2.3.8 with Python 2.4 under Win32 it would be this installer: http://pypi.python.org/packages/2.4/p/python-ldap/python-ldap-2.3.8.win32-py2.4.exe#md5=35da547711280c18bd4ccd6e637cdf9b Ciao, Michael. From larrykavanagh at examiner.ie Thu Jul 9 17:07:25 2009 From: larrykavanagh at examiner.ie (Larry kavanagh) Date: Thu, 09 Jul 2009 16:07:25 +0100 Subject: version 2.3.8 Message-ID: <4A5607AD.9080003@examiner.ie> Hi .. Triying to install python-ldap-2.3.8 using the EXE on a server (windows 2000) that has python 2.4.4 installed (or so the plone site tells me) however it won't install and tells me that "python 2.4 required which was not found in the registry" is there some registry setting and / or environment variable that I need to set for installation to run correctly Thanks Larry Please consider the environment before printing this email. Examiner Publications (Cork) Ltd Directors: G. A. Crosbie (Chairman), Thomas J. Murphy (Chief Executive), A.W. Dinan (Secretary), T.P. Crosbie. Registered In Dublin, Ireland. Registered number: 73385. Registered Office: City Quarter, Lapps Quay, Cork. From waldemar.osuch at gmail.com Fri Jul 31 16:52:56 2009 From: waldemar.osuch at gmail.com (Waldemar Osuch) Date: Fri, 31 Jul 2009 08:52:56 -0600 Subject: version 2.3.8 In-Reply-To: <4A5607AD.9080003@examiner.ie> References: <4A5607AD.9080003@examiner.ie> Message-ID: <6fae95540907310752k53da92bdx9f15ac4f83c4d19d@mail.gmail.com> On Thu, Jul 9, 2009 at 9:07 AM, Larry kavanagh wrote: > Hi .. > Triying to install python-ldap-2.3.8 using the EXE on a server (windows > 2000) ?that has python 2.4.4 installed (or so the plone site tells me) > > however it won't install and tells me that "python 2.4 required which > was not found in the registry" > I think this is related to how Plone gets installed this days. Googling found this: http://plone.org/documentation/faq/on-windows-xp-i-get-no-python-installation-found-in-the-registry-when-installing-certain-products-1 it seems to be relevant. Waldemar From michael at stroeder.com Fri Jul 31 16:57:01 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 31 Jul 2009 16:57:01 +0200 Subject: version 2.3.8 In-Reply-To: <6fae95540907310752k53da92bdx9f15ac4f83c4d19d@mail.gmail.com> References: <4A5607AD.9080003@examiner.ie> <6fae95540907310752k53da92bdx9f15ac4f83c4d19d@mail.gmail.com> Message-ID: <4A73063D.4090103@stroeder.com> Waldemar Osuch wrote: > On Thu, Jul 9, 2009 at 9:07 AM, Larry kavanagh wrote: >> Hi .. >> Triying to install python-ldap-2.3.8 using the EXE on a server (windows >> 2000) that has python 2.4.4 installed (or so the plone site tells me) >> >> however it won't install and tells me that "python 2.4 required which >> was not found in the registry" >> > I think this is related to how Plone gets installed this days. > Googling found this: > http://plone.org/documentation/faq/on-windows-xp-i-get-no-python-installation-found-in-the-registry-when-installing-certain-products-1 > it seems to be relevant. Waldemar, thanks for pointing us to that issue. It seems to me the Windows installer for Plone should be fixed. Ciao, Michael. From michael at stroeder.com Sat Aug 1 10:51:33 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 01 Aug 2009 10:51:33 +0200 Subject: Typo error in Demo/Lib/ldap/async/deltree.py (2.3.9) In-Reply-To: References: Message-ID: <4A740215.5040007@stroeder.com> Zhang Huangbin wrote: > > There's an incorrect module name in Demo/Lib/ldap/async/deltree.py, it > seems 'ldap.async.SearchHandler' should be replaced by > 'ldap.async.AsyncSearchHandler'. Thanks for pointing this out. Fixed in HEAD. Please test. Ciao, Michael. From zhbmaillistonly at gmail.com Sat Aug 1 03:48:11 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Sat, 1 Aug 2009 09:48:11 +0800 Subject: Typo error in Demo/Lib/ldap/async/deltree.py (2.3.9) Message-ID: Hi, developers. There's an incorrect module name in Demo/Lib/ldap/async/deltree.py, it seems 'ldap.async.SearchHandler' should be replaced by 'ldap.async.AsyncSearchHandler'. python-ldap version: 2.3.9. Thanks for your hard work :) -- Best Regards. Zhang Huangbin - Open Source Mail Server Solution for Red Hat(R) Enterprise Linux, CentOS, Debian, Ubuntu: + http://code.google.com/p/iredmail/ + http://www.iredmail.org/forum/ From michael at stroeder.com Tue Aug 4 09:18:10 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 04 Aug 2009 09:18:10 +0200 Subject: Python-LDAP for Python 3.0 In-Reply-To: References: Message-ID: <4A77E0B2.8010808@stroeder.com> David, David Leonard wrote: > > I have been looking at how to build the _ldap module for python3.x. I'm glad you're again working on python-ldap! Several months ago I tried to raise a discussion about this: http://www.mail-archive.com/python-ldap-dev at lists.sourceforge.net/msg00394.html > So, here I'd like to propose and explain some API changes Python 3.x > users. I'm focused on the _ldap module right now, but the (pure python) > library modules will experience carry-on effects. > > These are my goals with the _ldap module: > > * allow Python 2.x clients to keep working without changes > * dual environment support: both 2.x and 3.x build environments I'm not sure whether we should maintain backwards compability. Given the amount of code you're currently changing it's worth to think more about an incompatible change. Before going into technical details I'd like to discuss the goals from a very high-level view. We should discuss these ideas before going any further (slightly updated compared to the old posting mentioned above): Move away from SourceForge New GIT-based(?) repository (distributed VCS) Wrap libldap (and libber?) with built-in ctypes Distinct classes for LDAP search results, continuation references, entries etc. Better exception classes for errors with resultCode, diagnosticMessage etc. being class members. Also return diagnosticMessage upon success in search results. Receive LDAPv3 extended controls in intermediate search responses. Compability layers for mozldap, OpenLDAP and winldap? Partial rewrite of ldap.schema with some API changes Class library for LDAP syntaxes and matching rules Full Unicode support maybe with schema-aware LDAP operations I'd prefer python-ldap to be part of the Python standard lib in the long run. New code would make it possible to meet the licensing prerequisites of the PSF for this from the very beginning. Ciao, Michael. From zeli at email.cz Mon Aug 3 09:33:01 2009 From: zeli at email.cz (=?us-ascii?Q?Petr=20Zelenka?=) Date: Mon, 03 Aug 2009 09:33:01 +0200 (CEST) Subject: =?us-ascii?Q?Problem=20with=20md5=5Fdigest=20on=20MS=20AD?= Message-ID: <5509.13782-24182-146479980-1249284781@email.cz> Hello, i am using python-ldap package on debian-lenny. Stable version 2.3.5-1 and I have the same problem which is described here: http://sourceforge.net/mailarchive/forum.php?thread_name=505240.15748.qm%40web30702.mail.mud.yahoo.com&forum_name=python-ldap-dev First request is OK and second INVALID_CREDENTIALS. Do you have any suggestion? I also use ldap on MS AD. Petr From michael at stroeder.com Tue Aug 4 16:50:48 2009 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Tue, 04 Aug 2009 16:50:48 +0200 Subject: How to verify server certificate In-Reply-To: <4A7845AB.5050901@dfn-cert.de> References: <4A7845AB.5050901@dfn-cert.de> Message-ID: <4A784AC8.7070103@stroeder.com> Fredrik Melander wrote: > Short question: when negotiating TLS with the LDAP server with > start_tls_s(), can I use python-ldap to follow the certificate chain and > verify the server certificate? If so, how? The OpenLDAP libs are doing that for you (with the help of an underlying lib like OpenSSL, GnuTLS or NSS). Same for CRL checking available in recent versions of OpenLDAP libs. For the most common case with OpenLDAP C libs linked to OpenSSL libs see script Demo/initialize.py: ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,'/etc/httpd/ssl.crt/myCA-cacerts.pem') Ciao, Michael. From melander at dfn-cert.de Tue Aug 4 16:28:59 2009 From: melander at dfn-cert.de (Fredrik Melander) Date: Tue, 04 Aug 2009 16:28:59 +0200 Subject: How to verify server certificate Message-ID: <4A7845AB.5050901@dfn-cert.de> Hi, list! Short question: when negotiating TLS with the LDAP server with start_tls_s(), can I use python-ldap to follow the certificate chain and verify the server certificate? If so, how? Best regards, Fredrik -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5927 bytes Desc: S/MIME Cryptographic Signature URL: From melander at dfn-cert.de Tue Aug 4 18:20:49 2009 From: melander at dfn-cert.de (Fredrik Melander) Date: Tue, 04 Aug 2009 18:20:49 +0200 Subject: How to verify server certificate In-Reply-To: <4A784AC8.7070103@stroeder.com> References: <4A7845AB.5050901@dfn-cert.de> <4A784AC8.7070103@stroeder.com> Message-ID: <4A785FE1.9040805@dfn-cert.de> Michael Str?der schrieb: > Fredrik Melander wrote: >> Short question: when negotiating TLS with the LDAP server with >> start_tls_s(), can I use python-ldap to follow the certificate chain and >> verify the server certificate? If so, how? > > The OpenLDAP libs are doing that for you (with the help of an underlying lib > like OpenSSL, GnuTLS or NSS). Same for CRL checking available in recent > versions of OpenLDAP libs. > > For the most common case with OpenLDAP C libs linked to OpenSSL libs see > script Demo/initialize.py: > > ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,'/etc/httpd/ssl.crt/myCA-cacerts.pem') > > Ciao, Michael. > Hi, Michael Thanks for the very fast reply! I've been playing around with a certificate that should be broken without having my script complain the least. I would have expected python-ldap to throw an exception or similar but for the time being it seems to be pretending that everything's alright. Here's my connect-method in the class that's using ldap: def get_connection(self, connection_string): "Connect to ldap and return the handle" conn = ldap.initialize(connection_string) conn.protocol_version = ldap.VERSION3 conn.set_option(ldap.OPT_REFERRALS, 0) conn.set_option(ldap.OPT_X_TLS_CACERTFILE, "etc/openldap/ssl/cacert.pem") conn.set_option(ldap.OPT_X_TLS, ldap.OPT_X_TLS_DEMAND) conn.start_tls_s() conn.simple_bind_s(self.ldap_user, self.ldap_password) return conn What is it that I'm misunderstanding here? Best regards, Fredrik -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5927 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Tue Aug 4 18:25:11 2009 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Tue, 04 Aug 2009 18:25:11 +0200 Subject: How to verify server certificate In-Reply-To: <4A785FE1.9040805@dfn-cert.de> References: <4A7845AB.5050901@dfn-cert.de> <4A784AC8.7070103@stroeder.com> <4A785FE1.9040805@dfn-cert.de> Message-ID: <4A7860E7.7060602@stroeder.com> Fredrik Melander wrote: > Michael Str?der schrieb: >> Fredrik Melander wrote: >>> Short question: when negotiating TLS with the LDAP server with >>> start_tls_s(), can I use python-ldap to follow the certificate chain and >>> verify the server certificate? If so, how? >> The OpenLDAP libs are doing that for you (with the help of an underlying lib >> like OpenSSL, GnuTLS or NSS). Same for CRL checking available in recent >> versions of OpenLDAP libs. >> >> For the most common case with OpenLDAP C libs linked to OpenSSL libs see >> script Demo/initialize.py: >> >> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,'/etc/httpd/ssl.crt/myCA-cacerts.pem') > > Thanks for the very fast reply! > > I've been playing around with a certificate that should be broken > without having my script complain the least. Why should it be broken? > I would have expected > python-ldap to throw an exception or similar but for the time being it > seems to be pretending that everything's alright. If the cert or hostname validation fails ldap.SERVER_DOWN is raised. > Here's my connect-method in the class that's using ldap: > > def get_connection(self, connection_string): > "Connect to ldap and return the handle" > > conn = ldap.initialize(connection_string) > conn.protocol_version = ldap.VERSION3 > conn.set_option(ldap.OPT_REFERRALS, 0) > conn.set_option(ldap.OPT_X_TLS_CACERTFILE, "etc/openldap/ssl/cacert.pem") > conn.set_option(ldap.OPT_X_TLS, ldap.OPT_X_TLS_DEMAND) > > conn.start_tls_s() > conn.simple_bind_s(self.ldap_user, self.ldap_password) > return conn > > What is it that I'm misunderstanding here? Well, there's a reason why in Demo/initialize.py the TLS-related options are set globally. Only in recent versions of OpenLDAP you can set these options per connection. And libldap might also use TLS-related configuration in a .ldaprc or /etc/ldap.conf if available. Ciao, Michael. From Mike.Peters at opengi.co.uk Tue Aug 4 18:24:46 2009 From: Mike.Peters at opengi.co.uk (Mike.Peters at opengi.co.uk) Date: Tue, 4 Aug 2009 17:24:46 +0100 Subject: ldap.passwd_s with Active Direcory Message-ID: Hi, I'm not sure if this is the right place for this query, but I couldn't find a python-LDAP-Users list. I'm trying to modify a user's password on an Windows 2003 Active directory using passwd_s, however the server is returning the following error: {'info': '0000203D: LdapErr: DSID-0C090C7D, comment: Unknown extended request OID, data 0, vece', 'desc': 'Protocol error'} I realise this is a server configuration thing as opposed to a python-ldap issue, but google hasn't been any help so far. Does anyone here know what it is I need to enable/change in order to get it to work? The connection is using ldaps:// on port 636 and I can search the AD and modify other values eg givenName etc, just not passwords, and I'm binding as domain administrator. Thanks Mike Peters "This message is intended for the named recipient only and may be privileged and/or confidential. If you are not the intended or named recipient or have received this email in error then you should not copy forward or disclose it to any other persons. If you have received this email in error you should destroy it and contact the sender so that we may take appropriate action. The views and opinions expressed in this email may not represent the views and opinions of Open International Limited or any of its subsidiaries and are made without prejudice and subject to contract. The Company Reserves the right to intercept and review all email communications." Open International Limited. Registered Office: Buckholt Drive, Warndon, Worcester, WR4 9SR. Registered in England. Registered No: 05716519 From michael at stroeder.com Tue Aug 4 18:28:57 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 04 Aug 2009 18:28:57 +0200 Subject: ldap.passwd_s with Active Direcory In-Reply-To: References: Message-ID: <4A7861C9.7050400@stroeder.com> Mike.Peters at opengi.co.uk wrote: > > I'm not sure if this is the right place for this query, but I couldn't > find a python-LDAP-Users list. > > I'm trying to modify a user's password on an Windows 2003 Active > directory using passwd_s, however the server is returning the following > error: > > {'info': '0000203D: LdapErr: DSID-0C090C7D, comment: Unknown extended > request OID, data 0, vece', 'desc': 'Protocol error'} > > I realise this is a server configuration thing as opposed to a > python-ldap issue, but google hasn't been any help so far. Does anyone > here know what it is I need to enable/change in order to get it to work? This is because Windows 2003 AD does not support the LDAP Password Modify Extended Operation (see RFC 3062). > The connection is using ldaps:// on port 636 and I can search the AD and > modify other values eg givenName etc, just not passwords, and I'm > binding as domain administrator. There's a MSDN article about how to set attribute unicodePwd via LDAP in AD. Ciao, Michael. From Mike.Peters at opengi.co.uk Tue Aug 4 18:47:52 2009 From: Mike.Peters at opengi.co.uk (Mike.Peters at opengi.co.uk) Date: Tue, 4 Aug 2009 17:47:52 +0100 Subject: ldap.passwd_s with Active Direcory In-Reply-To: <4A7861C9.7050400@stroeder.com> References: <4A7861C9.7050400@stroeder.com> Message-ID: Michael, Thanks for the quick response, much appreciated. I guess I've been barking up the wrong tree then :) If I try the alternative method however: mod_attrs = [( ldap.MOD_REPLACE, 'unicodePwd', 'password' )] dn = 'CN=Barney Rubble,OU=Users,DC=mydomain,dc=local' r = l.modify_s(dn, mod_attrs) I get: {'info': '0000001F: SvcErr: DSID-031A0FC0, problem 5003 (WILL_NOT_PERFORM), data 0\n', 'desc': 'Server is unwilling to perform'} I guess I'm still missing something :( One thing which may be relevant is if I use l.start_tls_s() before simple_bind_s, the login fails although without start_tls_s Wireshark shows the connection to be encrypted. Thanks again Mike Peters > -----Original Message----- > From: Michael Str?der [mailto:michael at stroeder.com] > Sent: 04 August 2009 17:29 > To: Mike Peters > Cc: python-ldap-dev at lists.sourceforge.net > Subject: Re: ldap.passwd_s with Active Direcory > > Mike.Peters at opengi.co.uk wrote: > > > > I'm not sure if this is the right place for this query, but I > couldn't > > find a python-LDAP-Users list. > > > > I'm trying to modify a user's password on an Windows 2003 Active > > directory using passwd_s, however the server is returning the > following > > error: > > > > {'info': '0000203D: LdapErr: DSID-0C090C7D, comment: Unknown extended > > request OID, data 0, vece', 'desc': 'Protocol error'} > > > > I realise this is a server configuration thing as opposed to a > > python-ldap issue, but google hasn't been any help so far. Does > anyone > > here know what it is I need to enable/change in order to get it to > work? > > This is because Windows 2003 AD does not support the LDAP Password > Modify > Extended Operation (see RFC 3062). > > > The connection is using ldaps:// on port 636 and I can search the AD > and > > modify other values eg givenName etc, just not passwords, and I'm > > binding as domain administrator. > > There's a MSDN article about how to set attribute unicodePwd via LDAP > in AD. > > Ciao, Michael. From michael at stroeder.com Tue Aug 4 19:23:23 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 04 Aug 2009 19:23:23 +0200 Subject: ldap.passwd_s with Active Direcory In-Reply-To: References: <4A7861C9.7050400@stroeder.com> Message-ID: <4A786E8B.6010404@stroeder.com> Mike.Peters at opengi.co.uk wrote: > >> There's a MSDN article about how to set attribute unicodePwd via LDAP >> in AD. > > If I try the alternative method however: > > mod_attrs = [( ldap.MOD_REPLACE, 'unicodePwd', 'password' )] > dn = 'CN=Barney Rubble,OU=Users,DC=mydomain,dc=local' > r = l.modify_s(dn, mod_attrs) > > I get: > > {'info': '0000001F: SvcErr: DSID-031A0FC0, problem 5003 (WILL_NOT_PERFORM), data 0\n', 'desc': 'Server is unwilling to perform'} > > I guess I'm still missing something :( Did you search for the MSDN article? The value has to be in your case above: '"password"'.encode('utf-16-le') Note the quotes and the UTF-16 low-endian encoding. > One thing which may be relevant is if I use l.start_tls_s() before > simple_bind_s, the login fails although without start_tls_s Wireshark shows > the connection to be encrypted. With AD the connection has to be encrypted for write access to unicodePwd but that can also be done with ldaps:// on port 636. Ciao, Michael. From Mike.Peters at opengi.co.uk Wed Aug 5 16:55:38 2009 From: Mike.Peters at opengi.co.uk (Mike.Peters at opengi.co.uk) Date: Wed, 5 Aug 2009 15:55:38 +0100 Subject: ldap.passwd_s with Active Direcory In-Reply-To: <4A786E8B.6010404@stroeder.com> References: <4A7861C9.7050400@stroeder.com> <4A786E8B.6010404@stroeder.com> Message-ID: > -----Original Message----- > From: Michael Str?der [mailto:michael at stroeder.com] > Sent: 04 August 2009 18:23 > To: Mike Peters > Cc: python-ldap-dev at lists.sourceforge.net > Subject: Re: ldap.passwd_s with Active Direcory > > Mike.Peters at opengi.co.uk wrote: > > > >> There's a MSDN article about how to set attribute unicodePwd via > LDAP > >> in AD. > > > > If I try the alternative method however: > > > > mod_attrs = [( ldap.MOD_REPLACE, 'unicodePwd', 'password' )] > > dn = 'CN=Barney Rubble,OU=Users,DC=mydomain,dc=local' > > r = l.modify_s(dn, mod_attrs) > > > > I get: > > > > {'info': '0000001F: SvcErr: DSID-031A0FC0, problem 5003 > (WILL_NOT_PERFORM), data 0\n', 'desc': 'Server is unwilling to > perform'} > > > > I guess I'm still missing something :( > > Did you search for the MSDN article? The value has to be in your case > above: > > '"password"'.encode('utf-16-le') > > Note the quotes and the UTF-16 low-endian encoding. > Thanks again for your help. I tried that but to no avail. I still get the same error. Do you know if the fact I'm accessing the server over a VPN would make any difference? Mike Peters From michael at stroeder.com Wed Aug 5 17:11:21 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 05 Aug 2009 17:11:21 +0200 Subject: ldap.passwd_s with Active Direcory In-Reply-To: References: <4A7861C9.7050400@stroeder.com> <4A786E8B.6010404@stroeder.com> Message-ID: <4A79A119.6010409@stroeder.com> Mike.Peters at opengi.co.uk wrote: > Michael Str?der wrote: >> Did you search for the MSDN article? The value has to be in your case >> above: >> >> '"password"'.encode('utf-16-le') >> >> Note the quotes and the UTF-16 low-endian encoding. > > Thanks again for your help. I tried that but to no avail. I still get the > same error. It should work. It's the way I've implemented it in web2ldap. You must use either LDAPS or StartTLS ext.op. You might wanna look what's going on by setting trace_level=2 when calling ldap.initialize(). > Do you know if the fact I'm accessing the server over a VPN > would make any difference? AD enforces that to work solely over an encrypted connection. A VPN is outside the connection handling of AD so this won't work. Ciao, Michael. From raj at csub.edu Wed Aug 5 17:18:07 2009 From: raj at csub.edu (Russell Jackson) Date: Wed, 05 Aug 2009 08:18:07 -0700 Subject: ldap.passwd_s with Active Direcory In-Reply-To: References: <4A7861C9.7050400@stroeder.com> <4A786E8B.6010404@stroeder.com> Message-ID: <4A79A2AF.7090900@csub.edu> Mike.Peters at opengi.co.uk wrote: >> -----Original Message----- >> From: Michael Str?der [mailto:michael at stroeder.com] >> Sent: 04 August 2009 18:23 >> To: Mike Peters >> Cc: python-ldap-dev at lists.sourceforge.net >> Subject: Re: ldap.passwd_s with Active Direcory >> >> Mike.Peters at opengi.co.uk wrote: >>>> There's a MSDN article about how to set attribute unicodePwd via >> LDAP >>>> in AD. >>> If I try the alternative method however: >>> >>> mod_attrs = [( ldap.MOD_REPLACE, 'unicodePwd', 'password' )] >>> dn = 'CN=Barney Rubble,OU=Users,DC=mydomain,dc=local' >>> r = l.modify_s(dn, mod_attrs) >>> >>> I get: >>> >>> {'info': '0000001F: SvcErr: DSID-031A0FC0, problem 5003 >> (WILL_NOT_PERFORM), data 0\n', 'desc': 'Server is unwilling to >> perform'} >>> I guess I'm still missing something :( >> Did you search for the MSDN article? The value has to be in your case >> above: >> >> '"password"'.encode('utf-16-le') >> >> Note the quotes and the UTF-16 low-endian encoding. >> > > Thanks again for your help. I tried that but to no avail. I still get the same error. Do you know if the fact I'm accessing the server over a VPN would make any difference? > For what it's worth, this is the working code I use to set the password. I didn't realize you could use the -le suffix to get an encoding without the byte order mark which I've just been stripping off. The example posted above should be equivalent. ldap_conn.modify_s(dn, [ ( ldap.MOD_REPLACE, 'unicodePwd', ''.join(('"', pwd, '"')).encode('utf-16').lstrip('\377\376'), ) ]) Another thing to note is that the connection must be under a TLS layer. -- Russell A. Jackson Network Analyst California State University, Bakersfield Excellent day to have a rotten day. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From jmichiel at yahoo.com Wed Aug 5 17:23:28 2009 From: jmichiel at yahoo.com (Jeroen Michiel) Date: Wed, 5 Aug 2009 08:23:28 -0700 (PDT) Subject: Connection to AD on windows Message-ID: <917832.52986.qm@web65515.mail.ac4.yahoo.com> Hi, I'm trying to get python-ldap working on a windows machine to authenticate users against an Active Directory server. However, I'm getting the weirdest things... This is what I'm trying: import ldap, ldap.sasl conn = ldap.initialize('ldap://blabla') conn.set_option(ldap.OPT_PROTOCOL_VERSION, ldap.VERSION3) conn.set_option(ldap.OPT_REFERRALS,0) sasl = ldap.sasl.gssapi() conn.sasl_interactive_bind_s('', sasl) upon the sasl_interactive_bind_s, I get the following traceback: Traceback (most recent call last): File "D:\Projects\Python\ldap\src\ldaptest.py", line 12, in conn.sasl_interactive_bind_s('', sasl) File "c:\python25\lib\site-packages\python_ldap-2.3.9-py2.5-win32.egg\ldap\ldapobject.py", line 219, in sasl_interactive_bind_s return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls),sasl_flags) File "c:\python25\lib\site-packages\python_ldap-2.3.9-py2.5-win32.egg\ldap\ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) ldap.SUCCESS: {'desc': 'Success'} so apparently an exception of type ldap.SUCCESS seems to be thrown, which doesn't make much sense... What's going on? I'm totally clueless... Im using the 2.3.9 release I got here: http://svn.kmrc.de/download/distribution/contrib/ Thanks in advance for any ideas! From michael at stroeder.com Wed Aug 5 17:36:05 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 05 Aug 2009 17:36:05 +0200 Subject: SASL GSSAPI under Win32 (was: Connection to AD on windows) In-Reply-To: <917832.52986.qm@web65515.mail.ac4.yahoo.com> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> Message-ID: <4A79A6E5.9040603@stroeder.com> Jeroen Michiel wrote: > > I'm trying to get python-ldap working on a windows machine to authenticate > users against an Active Directory server. However, I'm getting the weirdest > things... > > This is what I'm trying: > > import ldap, ldap.sasl > > conn = ldap.initialize('ldap://blabla') > conn.set_option(ldap.OPT_PROTOCOL_VERSION, ldap.VERSION3) > conn.set_option(ldap.OPT_REFERRALS,0) > sasl = ldap.sasl.gssapi() > conn.sasl_interactive_bind_s('', sasl) I'm pretty sure SASL bind with GSSAPI mech is not supported with the Win32 builds. Therefore I changed the subject line to trigger attention of the relevant readers. The OpenLDAP libs are usually compiled against heimdal or MIT Kerberos which both have nothing to do with the Kerberos ticket store of your Windows session. David tried another approach which would help for this situation. His experimental attempts to build with wldap32.dll can be found here: http://sourceforge.net/tracker/?func=detail&aid=1698443&group_id=2072&atid=352072 Any takers? Personally I have some doubts though because especially regarding SASL the APIs are incompatible. > upon the sasl_interactive_bind_s, I get the following traceback: > > Traceback (most recent call last): > File "D:\Projects\Python\ldap\src\ldaptest.py", line 12, in > conn.sasl_interactive_bind_s('', sasl) > File "c:\python25\lib\site-packages\python_ldap-2.3.9-py2.5-win32.egg\ldap\ldapobject.py", line 219, in sasl_interactive_bind_s > return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls),sasl_flags) > File "c:\python25\lib\site-packages\python_ldap-2.3.9-py2.5-win32.egg\ldap\ldapobject.py", line 96, in _ldap_call > result = func(*args,**kwargs) > ldap.SUCCESS: {'desc': 'Success'} Raising ldap.SUCCESS in this case is clearly a bug. > Im using the 2.3.9 release I got here: > http://svn.kmrc.de/download/distribution/contrib/ These are .egg files built by Torsten. Not sure what he did regarding Kerberos. Maybe Torsten or Waldemar can comment on the Win32 builds. Ciao, Michael. From michael at stroeder.com Thu Aug 6 01:49:01 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 06 Aug 2009 01:49:01 +0200 Subject: ldap.passwd_s with Active Direcory In-Reply-To: References: <4A7861C9.7050400@stroeder.com> <4A786E8B.6010404@stroeder.com> <4A79A119.6010409@stroeder.com> Message-ID: <4A7A1A6D.8060305@stroeder.com> Mike.Peters at opengi.co.uk wrote: > *** ldaps://ad01.demo.local:636 - SimpleLDAPObject.simple_bind ((u'user at ADDEMO', u'secret', None, None),{}) First of all you should not pass Unicode strings to python-ldap. That's not a problem for the actual values you used though in this example but in general up to now python-ldap only receives raw strings as arguments. > In [4]: mod_attrs = [( ldap.MOD_REPLACE, 'unicodePwd', '"password"'.encode('utf-16-le') )] > In [5]: dn = 'CN=Barney Rubble,OU=Users,OU=ADDEMO,DC=demo,DC=local' > > In [6]: r = l.modify_s(dn, mod_attrs)*** ldaps://ad01.demo.local:636 - SimpleLDAPObject.modify_ext (('CN=Barney Rubble,OU=Users,OU=ADDEMO,DC=demo,DC=local', [(2, 'unicodePwd', '"\x00p\x00a\x00s\x00s\x00w\x00o\x00r\x00d\x00"\x00')], None, None),{}) Unfortunately I can't tell whether user at ADDEMO and CN=Barney Rubble,OU=Users,OU=ADDEMO,DC=demo,DC=local are the same AD user entry. I vaguely remember that when setting your own password you have to explicitly delete the old one and add the new one. Dig for the MSDN article. Ciao, Michael. From michael at stroeder.com Thu Aug 6 02:18:43 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 06 Aug 2009 02:18:43 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> Message-ID: <4A7A2163.4030406@stroeder.com> Waldemar Osuch wrote: > I have made a couple attempts to support SASL in the Win32 builds. > One user even reported a success using it but it never worked for me. > I will give it one more go but I can not make any promises. I tried to bind with SASL DIGEST-MD5 to MS AD W2K3SP2 and to OpenLDAP 2.4.x but that did not work: AUTH_UNKNOWN: {'info': 'SASL(-4): no mechanism available: Unable to find a callback: 2', 'desc': 'Unknown authentication method'} Hmm, are the SASL mechs modules available at all? Ciao, Michael. From Mike.Peters at opengi.co.uk Wed Aug 5 18:09:22 2009 From: Mike.Peters at opengi.co.uk (Mike.Peters at opengi.co.uk) Date: Wed, 5 Aug 2009 17:09:22 +0100 Subject: ldap.passwd_s with Active Direcory In-Reply-To: <4A79A119.6010409@stroeder.com> References: <4A7861C9.7050400@stroeder.com> <4A786E8B.6010404@stroeder.com> <4A79A119.6010409@stroeder.com> Message-ID: > -----Original Message----- > From: Michael Str?der [mailto:michael at stroeder.com] > Sent: 05 August 2009 16:11 > To: Mike Peters > Cc: python-ldap-dev at lists.sourceforge.net > Subject: Re: ldap.passwd_s with Active Direcory > > Mike.Peters at opengi.co.uk wrote: > > Michael Str?der wrote: > >> Did you search for the MSDN article? The value has to be in your > case > >> above: > >> > >> '"password"'.encode('utf-16-le') > >> > >> Note the quotes and the UTF-16 low-endian encoding. > > > > Thanks again for your help. I tried that but to no avail. I still get > the > > same error. > > It should work. It's the way I've implemented it in web2ldap. You must > use > either LDAPS or StartTLS ext.op. > > You might wanna look what's going on by setting trace_level=2 when > calling > ldap.initialize(). > With trace_level=2 I get the following: In [1]: import ldap In [2]: l = ldap.initialize("ldaps://ad01.demo.local:636", trace_level=2) *** ldaps://ad01.demo.local:636 - SimpleLDAPObject.set_option ((17, 3),{}) In [3]: l.simple_bind_s(u'user at ADDEMO', u'secret') *** ldaps://ad01.demo.local:636 - SimpleLDAPObject.simple_bind ((u'user at ADDEMO', u'secret', None, None),{}) => result: 1 *** ldaps://ad01.demo.local:636 - SimpleLDAPObject.result3 ((1, 1, -1),{}) => result: (97, [], 1, []) Out[3]: (97, []) In [4]: mod_attrs = [( ldap.MOD_REPLACE, 'unicodePwd', '"password"'.encode('utf-16-le') )] In [5]: dn = 'CN=Barney Rubble,OU=Users,OU=ADDEMO,DC=demo,DC=local' In [6]: r = l.modify_s(dn, mod_attrs)*** ldaps://ad01.demo.local:636 - SimpleLDAPObject.modify_ext (('CN=Barney Rubble,OU=Users,OU=ADDEMO,DC=demo,DC=local', [(2, 'unicodePwd', '"\x00p\x00a\x00s\x00s\x00w\x00o\x00r\x00d\x00"\x00')], None, None),{}) => result: 2 *** ldaps://ad01.demo.local:636 - SimpleLDAPObject.result3 ((2, 1, -1),{}) => LDAPError - UNWILLING_TO_PERFORM: {'info': '0000052D: SvcErr: DSID-031A0FC0, problem 5003 (WILL_NOT_PERFORM), data 0\n', 'desc': 'Server is unwilling to perform'} ERROR: An unexpected error occurred while tokenizing input The following traceback may be corrupted or invalid The error message is: ('EOF in multi-line statement', (134, 0)) From waldemar.osuch at gmail.com Wed Aug 5 19:32:27 2009 From: waldemar.osuch at gmail.com (Waldemar Osuch) Date: Wed, 5 Aug 2009 11:32:27 -0600 Subject: SASL GSSAPI under Win32 (was: Connection to AD on windows) In-Reply-To: <4A79A6E5.9040603@stroeder.com> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> Message-ID: <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> 2009/8/5 Michael Str?der : > Jeroen Michiel wrote: >> > > I'm pretty sure SASL bind with GSSAPI mech is not supported with the Win32 > builds. Therefore I changed the subject line to trigger attention of the > relevant readers. > > The OpenLDAP libs are usually compiled against heimdal or MIT Kerberos which > both have nothing to do with the Kerberos ticket store of your Windows session. > > David tried another approach which would help for this situation. His > experimental attempts to build with wldap32.dll can be found here: > > http://sourceforge.net/tracker/?func=detail&aid=1698443&group_id=2072&atid=352072 > > Any takers? Personally I have some doubts though because especially regarding > SASL the APIs are incompatible. > > >> Im using the 2.3.9 release I got here: >> http://svn.kmrc.de/download/distribution/contrib/ > > These are .egg files built by Torsten. Not sure what he did regarding Kerberos. > > Maybe Torsten or Waldemar can comment on the Win32 builds. > I have made a couple attempts to support SASL in the Win32 builds. One user even reported a success using it but it never worked for me. I will give it one more go but I can not make any promises. Waldemar From Mike.Peters at opengi.co.uk Thu Aug 6 17:14:23 2009 From: Mike.Peters at opengi.co.uk (Mike.Peters at opengi.co.uk) Date: Thu, 6 Aug 2009 16:14:23 +0100 Subject: ldap.passwd_s with Active Direcory In-Reply-To: <4A7A1A6D.8060305@stroeder.com> References: <4A7861C9.7050400@stroeder.com> <4A786E8B.6010404@stroeder.com> <4A79A119.6010409@stroeder.com> <4A7A1A6D.8060305@stroeder.com> Message-ID: > -----Original Message----- > From: Michael Str?der [mailto:michael at stroeder.com] > Sent: 06 August 2009 00:49 > To: Mike Peters > Cc: python-ldap-dev at lists.sourceforge.net > Subject: Re: ldap.passwd_s with Active Direcory > > Mike.Peters at opengi.co.uk wrote: > > *** ldaps://ad01.demo.local:636 - SimpleLDAPObject.simple_bind > ((u'user at ADDEMO', u'secret', None, None),{}) > > First of all you should not pass Unicode strings to python-ldap. That's > not a > problem for the actual values you used though in this example but in > general > up to now python-ldap only receives raw strings as arguments. OK, thanks. I'll bear that in mind. > > > In [4]: mod_attrs = [( ldap.MOD_REPLACE, 'unicodePwd', > '"password"'.encode('utf-16-le') )] > > In [5]: dn = 'CN=Barney Rubble,OU=Users,OU=ADDEMO,DC=demo,DC=local' > > > > In [6]: r = l.modify_s(dn, mod_attrs)*** ldaps://ad01.demo.local:636 > - SimpleLDAPObject.modify_ext (('CN=Barney > Rubble,OU=Users,OU=ADDEMO,DC=demo,DC=local', [(2, 'unicodePwd', > '"\x00p\x00a\x00s\x00s\x00w\x00o\x00r\x00d\x00"\x00')], None, None),{}) > > Unfortunately I can't tell whether > user at ADDEMO and CN=Barney Rubble,OU=Users,OU=ADDEMO,DC=demo,DC=local > are the same AD user entry. > > I vaguely remember that when setting your own password you have to > explicitly > delete the old one and add the new one. Dig for the MSDN article. > No, I'm using a different user. I've tried a couple of different users including Administrator in case it is user permissions. I've looked at the MSDN article and can't see anything in there different. Thanks Mike Peters From michael at stroeder.com Thu Aug 6 17:20:18 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 06 Aug 2009 17:20:18 +0200 Subject: ldap.passwd_s with Active Direcory In-Reply-To: References: <4A7861C9.7050400@stroeder.com> <4A786E8B.6010404@stroeder.com> <4A79A119.6010409@stroeder.com> <4A7A1A6D.8060305@stroeder.com> Message-ID: <4A7AF4B2.7010203@stroeder.com> Mike.Peters at opengi.co.uk wrote: > No, I'm using a different user. I've tried a couple of different users > including Administrator in case it is user permissions. I've looked at the > MSDN article and can't see anything in there different. Strange enough exactly this works just fine with my web2ldap which uses python-ldap. Ciao, Michael. From neisen at linbox.com Mon Aug 10 17:27:38 2009 From: neisen at linbox.com (Nicolas EISEN) Date: Mon, 10 Aug 2009 17:27:38 +0200 Subject: Internal Attributs Message-ID: <4A803C6A.2030508@linbox.com> Hi, I use OpenLDAP, python-ldap with python2.5. I need to get internal attributs (createTimeStamp, modifyTimestamp, ...). In many tutorial, I found script some like this ( http://jfgiraud.free.fr/programmation/ldap/ ): #!/usr/local/bin/python import sys, ldap try: l = ldap.open('localhost', 389) l.simple_bind_s("uid=LDAP Admin,ou=System Accounts,dc=toph,dc=com", "toto") except: print "Erreur n?", l.errno sys.exit(1) res = l.search_s("dc=toph,dc=com", ldap.SCOPE_SUBTREE, "objectclass=*", None, 0); for dn,hash in res: print "dn:", dn for attr in hash.keys(): print "attr %s: %s" % (attr, hash[attr]) print '-'*80 And the tutorial output containt createTimestamp &Co ... I try this script on my system, and I don't have this attributs. But with phpLDAPadmin or in command line, I can get it : ldapsearch -D "uid=LDAP Admin,ou=System Accounts,dc=toph,dc=com" -W -b "dc=toph,dc=com" "uid=user1" '*' '+' Why ? Thanks. From michael at stroeder.com Mon Aug 10 17:57:22 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 10 Aug 2009 17:57:22 +0200 Subject: Internal Attributs In-Reply-To: <4A803C6A.2030508@linbox.com> References: <4A803C6A.2030508@linbox.com> Message-ID: <4A804362.9020709@stroeder.com> Nicolas EISEN wrote: > I need to get internal attributs (createTimeStamp, modifyTimestamp, > ...). You mean operational attributes. With OpenLDAP server you have to either explicitly request them or use '+' in the attribute list. > res = l.search_s("dc=toph,dc=com", ldap.SCOPE_SUBTREE, "objectclass=*", None, 0); ^^^^ None implies attrs=['*'] but should be attrs=['*','+'] or attrs=['*','createTimeStamp','modifyTimestamp'] > I try this script on my system, and I don't have this attributs. But > with phpLDAPadmin or in command line, I can get it : > > ldapsearch -D "uid=LDAP Admin,ou=System Accounts,dc=toph,dc=com" -W -b "dc=toph,dc=com" "uid=user1" '*' '+' So why didn't you try to exactly implement this search in python-ldap? Ciao, Michael. From neisen at linbox.com Mon Aug 10 18:03:33 2009 From: neisen at linbox.com (Nicolas EISEN) Date: Mon, 10 Aug 2009 18:03:33 +0200 Subject: Internal Attributs In-Reply-To: <4A804362.9020709@stroeder.com> References: <4A803C6A.2030508@linbox.com> <4A804362.9020709@stroeder.com> Message-ID: <4A8044D5.1010402@linbox.com> Michael Str?der a ?crit : > Nicolas EISEN wrote: > >> I need to get internal attributs (createTimeStamp, modifyTimestamp, >> ...). >> > > You mean operational attributes. With OpenLDAP server you have to either > explicitly request them or use '+' in the attribute list. > > >> res = l.search_s("dc=toph,dc=com", ldap.SCOPE_SUBTREE, "objectclass=*", None, 0); >> > ^^^^ > None implies attrs=['*'] but should be > attrs=['*','+'] or attrs=['*','createTimeStamp','modifyTimestamp'] > > >> I try this script on my system, and I don't have this attributs. But >> with phpLDAPadmin or in command line, I can get it : >> >> ldapsearch -D "uid=LDAP Admin,ou=System Accounts,dc=toph,dc=com" -W -b "dc=toph,dc=com" "uid=user1" '*' '+' >> > > So why didn't you try to exactly implement this search in python-ldap? > > Ciao, Michael. > Great !!! It's work ! I spend the day to found, I'm idiot ... ^^ I'm probationer and I must implement web interface of LDAP Password Policies. Thanks, Ciao. (But it's strange : the tutorial exemple run with this attrs !!?????) From michael at stroeder.com Mon Aug 10 18:12:39 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 10 Aug 2009 18:12:39 +0200 Subject: Internal Attributs In-Reply-To: <4A8044D5.1010402@linbox.com> References: <4A803C6A.2030508@linbox.com> <4A804362.9020709@stroeder.com> <4A8044D5.1010402@linbox.com> Message-ID: <4A8046F7.8060807@stroeder.com> Nicolas EISEN wrote: > I'm probationer and I must implement web interface of LDAP Password > Policies. Interesting. What's it for exactly? Define the policy objects or set the password policy attrs in the user entries? Ciao, Michael. From michael at stroeder.com Mon Aug 10 20:51:52 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 10 Aug 2009 20:51:52 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <701710681.20090810194902@tk-webart.de> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <701710681.20090810194902@tk-webart.de> Message-ID: <4A806C48.4060502@stroeder.com> Torsten Kurbad wrote: >>> Im using the 2.3.9 release I got here: >>> http://svn.kmrc.de/download/distribution/contrib/ > >> These are .egg files built by Torsten. Not sure what he did regarding Kerberos. > > Sorry for my late reply. > > To be honest, I did nothing regarding Kerberos. I just compiled a very > stripped down version of cyrus-sasl (following the guide on > https://wiki.mozilla.org/LDAP_C_SDK_SASL_Windows) and then linked it > statically to the python-ldap build, leaving out all plugin DLLs. I'd strongly prefer if SASL would be either functional at least of the password based mechs or not compiled into the Win32 builds at all. Note that some implementations (like web2ldap) might look at the ldap.SASL_AVAIL variable and change the behaviour accordingly. > Theoretically it should be possible to statically link in the plugin > libs, too - I'll try that tomorrow, if I find the time. Anyway, that > would just give very basic functionality like MD5, It'll be great if at least the password-based mechs would be supported. I?d appreciate if Waldemar and you could bring your builds in line. > but no Kerberos, since cyrus only builds against Heimdal or MIT, which are > not (yet) available for Windows (and most probably never will be). There is MIT Kerberos for Windows but it uses its own ticket cache which does not make sense at all. > Michael, can you think of any LDAP-SASL-Kerberos combination that we > still might try to build on Windows? Well, this was the reason why David started his experiments with linking against winldap.dll which makes use of the native Windows Kerberos implementation. Ciao, Michael. From python-ldap at tk-webart.de Mon Aug 10 19:49:02 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Mon, 10 Aug 2009 19:49:02 +0200 Subject: SASL GSSAPI under Win32 (was: Connection to AD on windows) In-Reply-To: <4A79A6E5.9040603@stroeder.com> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> Message-ID: <701710681.20090810194902@tk-webart.de> Hi list, >> Im using the 2.3.9 release I got here: >> http://svn.kmrc.de/download/distribution/contrib/ > These are .egg files built by Torsten. Not sure what he did regarding Kerberos. Sorry for my late reply. To be honest, I did nothing regarding Kerberos. I just compiled a very stripped down version of cyrus-sasl (following the guide on https://wiki.mozilla.org/LDAP_C_SDK_SASL_Windows) and then linked it statically to the python-ldap build, leaving out all plugin DLLs. Theoretically it should be possible to statically link in the plugin libs, too - I'll try that tomorrow, if I find the time. Anyway, that would just give very basic functionality like MD5, but no Kerberos, since cyrus only builds against Heimdal or MIT, which are not (yet) available for Windows (and most probably never will be). Michael, can you think of any LDAP-SASL-Kerberos combination that we still might try to build on Windows? I once tried building cyrus against KfW from the MIT site, hoping it would share enough common code with the "real" MIT-Kerberos, but it seems to be a completely different codebase... Best regards, Torsten From waldemar.osuch at gmail.com Thu Aug 6 05:07:08 2009 From: waldemar.osuch at gmail.com (Waldemar Osuch) Date: Wed, 5 Aug 2009 21:07:08 -0600 Subject: SASL GSSAPI under Win32 In-Reply-To: <4A7A2163.4030406@stroeder.com> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> Message-ID: <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> 2009/8/5 Michael Str?der : > Waldemar Osuch wrote: >> I have made a couple attempts to support SASL in the Win32 builds. >> One user even reported a success using it but it never worked for me. >> I will give it one more go but I can not make any promises. > > I tried to bind with SASL DIGEST-MD5 to MS AD W2K3SP2 and to OpenLDAP 2.4.x > but that did not work: > > AUTH_UNKNOWN: {'info': 'SASL(-4): no mechanism available: Unable to find a > callback: 2', 'desc': 'Unknown authentication method'} > > Hmm, are the SASL mechs modules available at all? > That is the error I am getting too. My understanding of how it is supposed to work is that _ldap.pyd calls into libsasl.dll first (this part works) but then libsasl.dll has to find and load the requested auth mechanism. Unfortunately I did not find a way of telling libsasl where the auth plugin dlls are located. Dropping them into the same directory and hoping it will find them does not seem to work. From jmichiel at yahoo.com Thu Aug 6 09:19:36 2009 From: jmichiel at yahoo.com (Jeroen Michiel) Date: Thu, 6 Aug 2009 00:19:36 -0700 (PDT) Subject: SASL GSSAPI under Win32 In-Reply-To: <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> Message-ID: <4923.28131.qm@web65504.mail.ac4.yahoo.com> I also had that same error trying digest-md5. I still find it strange that with gssapi a SUCCESS exception is raised: it smells like a bug, or like a mismatch of libraries somehow. The strange thing is that the version I use is supposed to be statically linked to the necessary libs, so that you won't have the DLL lookup issues. For dynamically linked versions one can always copy the dlls to system32, but that's fishy at best... But I found a way to get it working without sasl at last with simple_bind_s and the ldap.OPT_REFERRALS option. I had already read about this option, but it didn't help, until it turned out I had to supply valid account data to simple_bind_s (the so-called 'Bind DN and password', I guess). I had already tried all sorts of combinations, but not that one... (I'm new to LDAP as you might guess) Thanks for your time! ----- Original Message ---- From: Waldemar Osuch To: Michael Str?der Cc: python-ldap-dev at lists.sourceforge.net Sent: Thursday, 6 August, 2009 5:07:08 Subject: Re: SASL GSSAPI under Win32 2009/8/5 Michael Str?der : > Waldemar Osuch wrote: >> I have made a couple attempts to support SASL in the Win32 builds. >> One user even reported a success using it but it never worked for me. >> I will give it one more go but I can not make any promises. > > I tried to bind with SASL DIGEST-MD5 to MS AD W2K3SP2 and to OpenLDAP 2.4.x > but that did not work: > > AUTH_UNKNOWN: {'info': 'SASL(-4): no mechanism available: Unable to find a > callback: 2', 'desc': 'Unknown authentication method'} > > Hmm, are the SASL mechs modules available at all? > That is the error I am getting too. My understanding of how it is supposed to work is that _ldap.pyd calls into libsasl.dll first (this part works) but then libsasl.dll has to find and load the requested auth mechanism. Unfortunately I did not find a way of telling libsasl where the auth plugin dlls are located. Dropping them into the same directory and hoping it will find them does not seem to work. ------------- From melander at dfn-cert.de Wed Aug 5 15:43:55 2009 From: melander at dfn-cert.de (Fredrik Melander) Date: Wed, 05 Aug 2009 15:43:55 +0200 Subject: How to verify server certificate In-Reply-To: <4A7860E7.7060602@stroeder.com> References: <4A7845AB.5050901@dfn-cert.de> <4A784AC8.7070103@stroeder.com> <4A785FE1.9040805@dfn-cert.de> <4A7860E7.7060602@stroeder.com> Message-ID: <4A798C9B.2050007@dfn-cert.de> Hi again, > Why should it be broken? It's deliberately broken to test the program, and thanks to your reply I've been able to catch this exception: CONNECT_ERROR: {'info': 'TLS: hostname does not match CN in peer certificate', 'desc': 'Connect error'} What I've so far *not* been able to provoke is an error because of an expired certificate. Is there some way to do this? > If the cert or hostname validation fails ldap.SERVER_DOWN is raised. ehm.. I caught a CONNECT_ERROR (see above)... ? > Well, there's a reason why in Demo/initialize.py the TLS-related options are > set globally. Only in recent versions of OpenLDAP you can set these options > per connection. Thanks, didn't know this. The thing is that I want to verify some certificates and accept others no matter what, but I've been (what seems to be) successfully to toggle this with ldap.OPT_X_TLS_NEVER and ldap.OPT_X_TLS_DEMAND respectively. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5927 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Tue Aug 11 13:05:00 2009 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Tue, 11 Aug 2009 13:05:00 +0200 Subject: Expired server certificate In-Reply-To: <4A814DC8.6010602@dfn-cert.de> References: <4A814DC8.6010602@dfn-cert.de> Message-ID: <4A81505C.8080400@stroeder.com> Fredrik Melander wrote: > I've given my LDAP server an expired cert for testing, but when calling > start_tls_s() the script just proceeds as were nothing wrong. Hmm, there's nothing you can do at the python-ldap level. AFAIK cert validation is completely done within the OpenSSL libs, except the host name checking. Could you please test with OpenLDAP's command-line tool ldapsearch. This is important: Please use the tool which uses the very same libldap also used for python-ldap. If ldapsearch fails this would be something to raise on the openldap-software mailing list together with information about your build of libldap and the SSL/TLS libs used. Note that libldap could be build with GnuTLS or today even with Mozilla's libnss. Ciao, Michael. From melander at dfn-cert.de Tue Aug 11 12:54:00 2009 From: melander at dfn-cert.de (Fredrik Melander) Date: Tue, 11 Aug 2009 12:54:00 +0200 Subject: Expired server certificate Message-ID: <4A814DC8.6010602@dfn-cert.de> Hi Michael and the list, sorry to bother you again, but since I think my last mail drowned in the unusually high traffic that day, I'm posting my question again. I've done some research since then I really can't figure this one out. This relates to my previous question about server certificates. Simply put: how do I get python-ldap to throw an exception when the server certificate is expired? I've given my LDAP server an expired cert for testing, but when calling start_tls_s() the script just proceeds as were nothing wrong. Wading through the source code and google results unfortunately didn't get me any further either. Thankful for any advice! Cheers, Fredrik -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5927 bytes Desc: S/MIME Cryptographic Signature URL: From matiassurdi at gmail.com Fri Aug 14 13:24:46 2009 From: matiassurdi at gmail.com (Matias Surdi) Date: Fri, 14 Aug 2009 13:24:46 +0200 Subject: python-ldap, modlist and base64 Message-ID: <720ff42b0908140424j42bf0eabi8cb2b0b031c2f962@mail.gmail.com> Hi! I'm wondering if there is any example or documentation on how to add or modify ldap objects whose values contains non-ascii characters, such as accents, and so on. As far as I understand, those values should be encoded using base64, but if I do that, I don't know how to indicate in the modlist that this is the encoded value and not the value itself. Any help will be bery appreciated. -- Matias Emanuel Surdi. From jens at dataflake.org Fri Aug 14 13:57:20 2009 From: jens at dataflake.org (Jens Vagelpohl) Date: Fri, 14 Aug 2009 13:57:20 +0200 Subject: python-ldap, modlist and base64 In-Reply-To: <720ff42b0908140424j42bf0eabi8cb2b0b031c2f962@mail.gmail.com> References: <720ff42b0908140424j42bf0eabi8cb2b0b031c2f962@mail.gmail.com> Message-ID: <19CF2D0C-9ED7-4D4B-B3F2-B281D165FFF6@dataflake.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 14, 2009, at 13:24 , Matias Surdi wrote: > Hi! > > I'm wondering if there is any example or documentation on how to add > or modify ldap objects whose values contains non-ascii characters, > such as accents, and so on. As far as I understand, those values > should be encoded using base64, but if I do that, I don't know how to > indicate in the modlist that this is the encoded value and not the > value itself. You do not have to base64-encode the values. Make sure they are UTF-8, and it should work just fine. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkqFUSAACgkQRAx5nvEhZLLOFgCfULPkkbO0hT/jV4m2DRZKBhX5 ACYAnRYhS3JBcK9V7WZAy4zoORNemO1T =s+nu -----END PGP SIGNATURE----- From python-ldap at tk-webart.de Mon Aug 17 11:13:09 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Mon, 17 Aug 2009 11:13:09 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> Message-ID: <20090817111309.1dc96f22@atalante.iwm-kmrc.de> Hi list, sorry for getting back to this so late, but I've been away from my Windows development machine for a while... > My understanding of how it is supposed to work is that _ldap.pyd > calls into libsasl.dll first (this part works) but then libsasl.dll > has to find and load the requested auth mechanism. > Unfortunately I did not find a way of telling libsasl where the > auth plugin dlls are located. > Dropping them into the same directory and hoping it will find them > does not seem to work. Waldemar, I now tried a differente approach: I used our "patented" pexports method to statically link in the following sasl auth plugins: - ANONYMOUS - CRAMMD5 - DIGESTMD5 - LOGIN - PLAIN But telling from the size of the .egg file, gcc most probably dropped all the additional symbols. :-( Could someone with an appropriate setup please check out http://svn.kmrc.de/download/distribution/contrib/python_ldap-2.3.9-py2.6-win32.egg try one or more of the above auth mechanisms and report back here? Thanks in advance Torsten -- I am a deeply superficial person. -Andy Warhol From michael at stroeder.com Mon Aug 17 15:14:18 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 17 Aug 2009 15:14:18 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <20090817111309.1dc96f22@atalante.iwm-kmrc.de> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> <20090817111309.1dc96f22@atalante.iwm-kmrc.de> Message-ID: <4A8957AA.6030909@stroeder.com> Torsten, first thanks for trying to get that working. Torsten Kurbad wrote: >> My understanding of how it is supposed to work is that _ldap.pyd >> calls into libsasl.dll first (this part works) but then libsasl.dll >> has to find and load the requested auth mechanism. Yes, that's my superficial understanding too. > Waldemar, I now tried a differente approach: I used our "patented" > pexports method to statically link in the following sasl auth plugins: > > - ANONYMOUS > - CRAMMD5 > - DIGESTMD5 > - LOGIN > - PLAIN > > But telling from the size of the .egg file, gcc most probably dropped > all the additional symbols. :-( Yes, I guess so. > Could someone with an appropriate setup please check out > > http://svn.kmrc.de/download/distribution/contrib/python_ldap-2.3.9-py2.6-win32.egg > > try one or more of the above auth mechanisms and report back here? Unfortunately it does not seem to work: --------------------------- snip --------------------------- >>> sasl_cb_value_dict = { ldap.sasl.CB_AUTHNAME :'fred', ldap.sasl.CB_PASS :'secret', } >>> sasl_auth=ldap.sasl.sasl(sasl_cb_value_dict,'DIGEST-MD5') >>> l.sasl_interactive_bind_s("", sasl_auth) Traceback (most recent call last): File "", line 1, in l.sasl_interactive_bind_s("", sasl_auth) File "C:\Python26\lib\site-packages\ldap\ldapobject.py", line 219, in sasl_interactive_bind_s return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls),sasl_flags) File "C:\Python26\lib\site-packages\ldap\ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) SUCCESS: {'desc': 'Success'} >>> l.whoami_s() '' >>> --------------------------- snip --------------------------- Ciao, Michael. From python-ldap at tk-webart.de Mon Aug 17 15:23:30 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Mon, 17 Aug 2009 15:23:30 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <4A8957AA.6030909@stroeder.com> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> <20090817111309.1dc96f22@atalante.iwm-kmrc.de> <4A8957AA.6030909@stroeder.com> Message-ID: <20090817152330.10639840@atalante.iwm-kmrc.de> Hi Michael, thanks for testing the new .egg so quickly. > Unfortunately it does not seem to work: That's really unfortunate. I'll try now to dig into the configure scripts of Cyrus-SASL to get rid of most of the dependencies (as the Mozilla guys did with the NTMakefile). Then it should be possible to do a "real" static build of library and plugins using MinGW. Regards, Torsten -- His honour rooted in dishonour stood, And faith unfaithful kept him falsely true. -Alfred Lord Tennyson From python-ldap at tk-webart.de Mon Aug 17 19:05:40 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Mon, 17 Aug 2009 19:05:40 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <20090817152330.10639840@atalante.iwm-kmrc.de> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> <20090817111309.1dc96f22@atalante.iwm-kmrc.de> <4A8957AA.6030909@stroeder.com> <20090817152330.10639840@atalante.iwm-kmrc.de> Message-ID: <20090817190540.37104a58@atalante.iwm-kmrc.de> > I'll try now to dig into the configure > scripts of Cyrus-SASL to get rid of most of the dependencies (as the > Mozilla guys did with the NTMakefile). Then it should be possible to > do a "real" static build of library and plugins using MinGW. I think, I'm almost there. I have a static libsasl and several static plugin libs, but when I try to link one of the plugins with _ldap.pyd, I get: e:\projects\prereq\built\cyrus-sasl\lib\sasl2\libcrammd5.a(plugin_common.o): In function `plug_ipfromstring': e:/projects/prereq/src/cyrus-sasl-2.1.23/plugins/plugin_common.c:150: undefined reference to `sasl_getaddrinfo' e:/projects/prereq/src/cyrus-sasl-2.1.23/plugins/plugin_common.c:157: undefined reference to `sasl_freeaddrinfo' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 Should be a matter of proper includes. I'll track that down tomorrow... Regards, Torsten -- It's more than magnificent-it's mediocre. -Samuel Goldwyn From python-ldap at tk-webart.de Wed Aug 19 19:25:18 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Wed, 19 Aug 2009 19:25:18 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <20090817190540.37104a58@atalante.iwm-kmrc.de> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> <20090817111309.1dc96f22@atalante.iwm-kmrc.de> <4A8957AA.6030909@stroeder.com> <20090817152330.10639840@atalante.iwm-kmrc.de> <20090817190540.37104a58@atalante.iwm-kmrc.de> Message-ID: <20090819192518.3cd7d8e7@atalante.iwm-kmrc.de> Hi list, > I think, I'm almost there. I have a static libsasl and several static > plugin libs, but when I try to link one of the plugins with > _ldap.pyd, I get: > > e:\projects\prereq\built\cyrus-sasl\lib\sasl2\libcrammd5.a(plugin_common.o): > In function `plug_ipfromstring': > e:/projects/prereq/src/cyrus-sasl-2.1.23/plugins/plugin_common.c:150: > undefined reference to `sasl_getaddrinfo' > e:/projects/prereq/src/cyrus-sasl-2.1.23/plugins/plugin_common.c:157: > undefined reference to `sasl_freeaddrinfo' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Should be a matter of proper includes. I'll track that down > tomorrow... in fact, it was a bit more than just proper includes, that's why it took me so long. ;-) But anyway, here's a new .egg for testing: http://svn.kmrc.de/download/distribution/contrib/python_ldap-2.3.9-py2.6-win32.egg Good luck and best regards, Torsten PS: Waldemar, in case it still doesn't work: Do you have IRC, ICQ, Skype or the like? -- Happiness is a positive cash flow. From michael at stroeder.com Wed Aug 19 20:54:59 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 19 Aug 2009 20:54:59 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <20090819192518.3cd7d8e7@atalante.iwm-kmrc.de> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> <20090817111309.1dc96f22@atalante.iwm-kmrc.de> <4A8957AA.6030909@stroeder.com> <20090817152330.10639840@atalante.iwm-kmrc.de> <20090817190540.37104a58@atalante.iwm-kmrc.de> <20090819192518.3cd7d8e7@atalante.iwm-kmrc.de> Message-ID: <4A8C4A83.7010305@stroeder.com> Torsten Kurbad wrote: >> I think, I'm almost there. I have a static libsasl and several static >> plugin libs, but when I try to link one of the plugins with >> _ldap.pyd, I get: >> >> e:\projects\prereq\built\cyrus-sasl\lib\sasl2\libcrammd5.a(plugin_common.o): >> In function `plug_ipfromstring': >> e:/projects/prereq/src/cyrus-sasl-2.1.23/plugins/plugin_common.c:150: >> undefined reference to `sasl_getaddrinfo' >> e:/projects/prereq/src/cyrus-sasl-2.1.23/plugins/plugin_common.c:157: >> undefined reference to `sasl_freeaddrinfo' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 >> >> Should be a matter of proper includes. I'll track that down >> tomorrow... > > in fact, it was a bit more than just proper includes, that's why it took > me so long. ;-) > > But anyway, here's a new .egg for testing: > > http://svn.kmrc.de/download/distribution/contrib/python_ldap-2.3.9-py2.6-win32.egg Sorry, still does not work. This is the console output: U:\Proj\python-ldap\python-ldap\Demo>c:\Python26\python.exe sasl_bind.py ******************** CRAM-MD5 ******************** Error using SASL mechanism CRAM-MD5 {'desc': 'Success'} ******************** PLAIN ******************** Error using SASL mechanism PLAIN {'desc': 'Success'} ******************** LOGIN ******************** Error using SASL mechanism LOGIN {'desc': 'Success'} ******************** EXTERNAL ******************** Error using SASL mechanism EXTERNAL {'desc': 'Success'} ******************** GSSAPI ******************** Error using SASL mechanism GSSAPI {'desc': 'Success'} ******************** NTLM ******************** Error using SASL mechanism NTLM {'desc': 'Success'} ******************** DIGEST-MD5 ******************** Error using SASL mechanism DIGEST-MD5 {'desc': 'Success'} BTW: You could test yourself e.g. against MS AD but take the FQDN in the LDAP URI then. Are there any options in cyrus-sasl to turn on debug logs? (Aargh! Tried to use mod_auth_kerb today and the debugging also pretty much sucks with MIT Kerberos.) Ciao, Michael. From michael at stroeder.com Thu Aug 20 11:01:41 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 20 Aug 2009 11:01:41 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <1003844487.20090820092848@tk-webart.de> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> <20090817111309.1dc96f22@atalante.iwm-kmrc.de> <4A8957AA.6030909@stroeder.com> <20090817152330.10639840@atalante.iwm-kmrc.de> <20090817190540.37104a58@atalante.iwm-kmrc.de> <20090819192518.3cd7d8e7@atalante.iwm-kmrc.de> <6fae95540908191303t49309cbi220ed666ff7c5ba7@mail.gmail.com> <1003844487.20090820092848@tk-webart.de> Message-ID: <4A8D10F5.5040204@stroeder.com> Torsten Kurbad wrote: > But here's my idea: I'll put up a documentation today on what I did to > get cyrus-sasl compiling successfully using MinGW. I'd appreciate to have this in the official docs in a separate section under http://www.python-ldap.org/doc/html/installing.html#building-and-installing Ciao, Michael. From michael at stroeder.com Sun Aug 23 11:46:48 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 23 Aug 2009 11:46:48 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <6fae95540908191303t49309cbi220ed666ff7c5ba7@mail.gmail.com> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> <20090817111309.1dc96f22@atalante.iwm-kmrc.de> <4A8957AA.6030909@stroeder.com> <20090817152330.10639840@atalante.iwm-kmrc.de> <20090817190540.37104a58@atalante.iwm-kmrc.de> <20090819192518.3cd7d8e7@atalante.iwm-kmrc.de> <6fae95540908191303t49309cbi220ed666ff7c5ba7@mail.gmail.com> Message-ID: <4A911008.7010803@stroeder.com> Waldemar Osuch wrote: > My build is not static anymore. Now I put all the required *.dll(s) > into site-packages\ldap directory. > I also put the _ldap.pyd in there too so the extension can find them. > This approach work for all the dlls except the SASL plugins. > > If I put the SASL plugin dlls into into "C:\CMU\bin\sasl2" then they > will be found. It's the same on Linux. If you install into a non-standard localtion "make install" outputs the following text: ******************************************************** * WARNING: * Plugins are being installed into /opt/cyrus-sasl/lib/sasl2, * but the library will look for them in /usr/lib/sasl2. * You need to make sure that the plugins will eventually * be in /usr/lib/sasl2 -- the easiest way is to make a * symbolic link from /usr/lib/sasl2 to /opt/cyrus-sasl/lib/sasl2, * but this may not be appropriate for your site, so this * installation procedure won't do it for you. * * If you don't want to do this for some reason, you can * set the location where the library will look for plugins * by setting the environment variable SASL_PATH to the path * the library should use. ******************************************************** Well, symbolic links are not an option. But how about setting the SASL_PATH env var? We could even try to add a os.env['SASL_PATH']=... to Lib/ldap/sasl.py. Could you please provide a ZIP file or something which contains the python-ldap build and the SASL plugin DLLs and I will play around a little bit. > In my environment only DIGEST-MD5 and NTLM got loaded but NTLM did not work. > I have got 'Authentication method not supported' error. > > Now the question is, should I continue to pretend that SASL mechanisms > are supported? If there's no way to load at least one SASL plugin it ldap.SASL_AVAIL should be 0. > Are the 2 or rather 1.5 available mechanisms worth the effort? DIGEST-MD5 would be worth the effort. > Unless Torsten is successful, the 2.3.9 build will not have it. Waldemar, I can fully understand your frustration. And I really appreciate your and Torsten's efforts. Please let's try another round. If setting SASL_HOME is not successful it would be a good idea to raise this issue on the OpenLDAP and Cyrus-SASL mailing lists and request a new feature. Cyrus SASL 2.1.24 RC1 was released to public a couple of days ago. Maybe it would be possible to have another SASL option passed through libldap to cyrus-sasl lib which sets the path where to locate the SASL plugins. Ciao, Michael. From waldemar.osuch at gmail.com Wed Aug 19 22:03:45 2009 From: waldemar.osuch at gmail.com (Waldemar Osuch) Date: Wed, 19 Aug 2009 14:03:45 -0600 Subject: SASL GSSAPI under Win32 In-Reply-To: <20090819192518.3cd7d8e7@atalante.iwm-kmrc.de> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> <20090817111309.1dc96f22@atalante.iwm-kmrc.de> <4A8957AA.6030909@stroeder.com> <20090817152330.10639840@atalante.iwm-kmrc.de> <20090817190540.37104a58@atalante.iwm-kmrc.de> <20090819192518.3cd7d8e7@atalante.iwm-kmrc.de> Message-ID: <6fae95540908191303t49309cbi220ed666ff7c5ba7@mail.gmail.com> On Wed, Aug 19, 2009 at 11:25 AM, Torsten Kurbad wrote: > Hi list, > > > But anyway, here's a new .egg for testing: > > http://svn.kmrc.de/download/distribution/contrib/python_ldap-2.3.9-py2.6-win32.egg > Unfortunately it did not work for me either but your dedication to the cause prompted me to test my version of the build some more :) My build is not static anymore. Now I put all the required *.dll(s) into site-packages\ldap directory. I also put the _ldap.pyd in there too so the extension can find them. This approach work for all the dlls except the SASL plugins. If I put the SASL plugin dlls into into "C:\CMU\bin\sasl2" then they will be found. In my environment only DIGEST-MD5 and NTLM got loaded but NTLM did not work. I have got 'Authentication method not supported' error. Now the question is, should I continue to pretend that SASL mechanisms are supported? Are the 2 or rather 1.5 available mechanisms worth the effort? I hope Torsten will be successful but I feel ready to give up on SASL support in my builds. They never really worked out of the box anyway. If you are depending on existing SASL support in my builds it is time to speak up. Unless Torsten is successful, the 2.3.9 build will not have it. Waldemar From michael at stroeder.com Sun Aug 23 11:50:13 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 23 Aug 2009 11:50:13 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <1003844487.20090820092848@tk-webart.de> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> <20090817111309.1dc96f22@atalante.iwm-kmrc.de> <4A8957AA.6030909@stroeder.com> <20090817152330.10639840@atalante.iwm-kmrc.de> <20090817190540.37104a58@atalante.iwm-kmrc.de> <20090819192518.3cd7d8e7@atalante.iwm-kmrc.de> <6fae95540908191303t49309cbi220ed666ff7c5ba7@mail.gmail.com> <1003844487.20090820092848@tk-webart.de> Message-ID: <4A9110D5.2000808@stroeder.com> Torsten Kurbad wrote: > Hi Waldemar, > >> My build is not static anymore. Now I put all the required *.dll(s) >> into site-packages\ldap directory. >> I also put the _ldap.pyd in there too so the extension can find them. >> This approach work for all the dlls except the SASL plugins. > > unfortunately, .dlls are relatively useless in conjunction with .eggs, > since there seems to be no proper way to bundle the two. That was the > reason for my static approach. I'm not familiar with the .egg stuff. But .egg files seem to be ZIP files. Isn't there any chance to add the DLLs to this ZIP file? How to make SASL libs locate the plugin DLLs would be another issue. Ciao, Michael. From python-ldap at tk-webart.de Thu Aug 20 09:28:48 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Thu, 20 Aug 2009 09:28:48 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <6fae95540908191303t49309cbi220ed666ff7c5ba7@mail.gmail.com> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> <20090817111309.1dc96f22@atalante.iwm-kmrc.de> <4A8957AA.6030909@stroeder.com> <20090817152330.10639840@atalante.iwm-kmrc.de> <20090817190540.37104a58@atalante.iwm-kmrc.de> <20090819192518.3cd7d8e7@atalante.iwm-kmrc.de> <6fae95540908191303t49309cbi220ed666ff7c5ba7@mail.gmail.com> Message-ID: <1003844487.20090820092848@tk-webart.de> Hi Waldemar, > My build is not static anymore. Now I put all the required *.dll(s) > into site-packages\ldap directory. > I also put the _ldap.pyd in there too so the extension can find them. > This approach work for all the dlls except the SASL plugins. unfortunately, .dlls are relatively useless in conjunction with .eggs, since there seems to be no proper way to bundle the two. That was the reason for my static approach. But here's my idea: I'll put up a documentation today on what I did to get cyrus-sasl compiling successfully using MinGW. Some minor modifications to that method should get us .dlls again instead of static libs. When configuring the build, you can provide a prospective location of the plugin .dlls, e.g. C:\sasl2. Perhaps that would help to find all of the mechanisms. If you have the time and nerves, we could do some 'conferencing' in Google talk on the way... Best regards, Torsten -- Never make anything simple and efficient when a way can be found to make it complex and wonderful. - Murphy's Law No. 13 - From michael at stroeder.com Sun Aug 23 11:55:03 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 23 Aug 2009 11:55:03 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <20090820151609.0603fa88@atalante.iwm-kmrc.de> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> <20090817111309.1dc96f22@atalante.iwm-kmrc.de> <4A8957AA.6030909@stroeder.com> <20090817152330.10639840@atalante.iwm-kmrc.de> <20090817190540.37104a58@atalante.iwm-kmrc.de> <20090819192518.3cd7d8e7@atalante.iwm-kmrc.de> <6fae95540908191303t49309cbi220ed666ff7c5ba7@mail.gmail.com> <1003844487.20090820092848@tk-webart.de> <4A8D10F5.5040204@stroeder.com> <20090820151609.0603fa88@atalante.iwm-kmrc.de> Message-ID: <4A9111F7.4060608@stroeder.com> Torsten Kurbad wrote: > >> I'd appreciate to have this in the official docs in a separate >> section under >> >> http://www.python-ldap.org/doc/html/installing.html#building-and-installing > > that would be great indeed. > > I had very little time this morning (the internet link of our institute > was broken and I had to track down the failure). But I managed to put > some basic documentation online under > > http://svn.kmrc.de/download/distribution/contrib/doc/Minimal-Cyrus-SASL-Win32-HowTo.txt Many thanks for this! I don't know how persistent this link will be. So do you mind if I add this as-is to python-ldap's source distribution? In the long run we can add this in file Doc/installing.rst. Ciao, Michael. From python-ldap at tk-webart.de Thu Aug 20 15:16:09 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Thu, 20 Aug 2009 15:16:09 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <4A8D10F5.5040204@stroeder.com> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> <20090817111309.1dc96f22@atalante.iwm-kmrc.de> <4A8957AA.6030909@stroeder.com> <20090817152330.10639840@atalante.iwm-kmrc.de> <20090817190540.37104a58@atalante.iwm-kmrc.de> <20090819192518.3cd7d8e7@atalante.iwm-kmrc.de> <6fae95540908191303t49309cbi220ed666ff7c5ba7@mail.gmail.com> <1003844487.20090820092848@tk-webart.de> <4A8D10F5.5040204@stroeder.com> Message-ID: <20090820151609.0603fa88@atalante.iwm-kmrc.de> Hi Michael, > I'd appreciate to have this in the official docs in a separate > section under > > http://www.python-ldap.org/doc/html/installing.html#building-and-installing that would be great indeed. I had very little time this morning (the internet link of our institute was broken and I had to track down the failure). But I managed to put some basic documentation online under http://svn.kmrc.de/download/distribution/contrib/doc/Minimal-Cyrus-SASL-Win32-HowTo.txt Feedback is more than welcome! :-) Best regards, Torsten -- McDonald's -- Because you're worth it. From l.mierzwa at gmail.com Mon Sep 7 22:20:14 2009 From: l.mierzwa at gmail.com (=?utf-8?q?=C5=81ukasz_Mierzwa?=) Date: Mon, 7 Sep 2009 22:20:14 +0200 Subject: hello everybody Message-ID: <200909072220.14777.l.mierzwa@gmail.com> Hi list, I'm writing LDAP library (ORM without R as I call it) for python, it's using python-ldap to do the hard work and let You manage LDAP entries in more ORM style. It's still missing many things and there are probably plenty of bugs but it's mostly working. I'm not much of a programmer and this is really a way to learn python so I would love some tips about what I'm doing wrong before I get too far. If anyone is interested You could find it at: docs: http://pumpkin.prymitive.com get source: git clone http://git.prymitive.com/pumpkin redmine project: http://redmine.prymitive.com/projects/show/pumpkin ?ukasz Mierzwa From michael at stroeder.com Tue Sep 8 11:24:44 2009 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Tue, 08 Sep 2009 11:24:44 +0200 Subject: hello everybody In-Reply-To: <200909072220.14777.l.mierzwa@gmail.com> References: <200909072220.14777.l.mierzwa@gmail.com> Message-ID: <4AA622DC.6030007@stroeder.com> ?ukasz, ?ukasz Mierzwa wrote: > > I'm writing LDAP library (ORM without R as I call it) for python, it's using > python-ldap to do the hard work and let You manage LDAP entries in more ORM > style. I don't have the spare time to look more closely at it not to speak of really contributing to it. So just a few general hints: 1. You're not the first one implementing such a module on top of python-ldap. You might want to dig the mailing list's archive to find others. 2. Most implementations of higher-level APIs fall short with mapping attribute type descriptors (OIDs or NAME) to Python class attribute names since they ignore the fact that there are sub-types defined in LDAP (;binary and language sub-types such as ;de-DE). Also there does not have to be a NAME in an attribute type description. So raw OIDs might be returned in a LDAP search result. 3. No implementation is dealing correctly with attribute type descriptor aliasing with OIDs and several values for NAME. You might want to look at ldap.schema.models.Entry to get an idea. Ciao, Michael. From ychsiao at gmail.com Tue Sep 1 16:37:47 2009 From: ychsiao at gmail.com (Yuan-Chung Hsiao) Date: Tue, 1 Sep 2009 22:37:47 +0800 Subject: Modify windows ad password Message-ID: <59e4fc130909010737q32cde637w53bf577894e7074d@mail.gmail.com> Hi I use python-ldap(2.3.8) to modify AD's user password. When I run it, the password change done, it always show traceback message. Traceback (most recent call last): File "ldapauth.py", line 141, in modifyAD('userid','passwordblah') File "ldapauth.py", line 105, in modifyAD conn.modify_s(dn, attr) File "c:\lang\python\lib\site-packages\ldap\ldapobject.py", line 327, in modify_s msgid = self.modify(dn,modlist) File "c:\lang\python\lib\site-packages\ldap\ldapobject.py", line 324, in modify return self.modify_ext(dn,modlist,None,None) File "c:\lang\python\lib\site-packages\ldap\ldapobject.py", line 297, in modify_ext return self._ldap_call(self._l.modify_ext,dn,modlist,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls)) File "c:\lang\python\lib\site-packages\ldap\ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) TypeError: argument 1 must be string, not None snippets code: def modifyAD(username, password): LDAP_SERVER = 'ldaps://myad:636' LDAP_ADMIN = admin at myad' LDAP_PASSWD = '' BASE_DN = '' searchScope = ldap.SCOPE_SUBTREE conn = ldap.initialize(LDAP_SERVER) ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, '-ad.pem') ldap.set_option(ldap.OPT_REFERRALS,0) conn.protocol_version = ldap.VERSION3 conn.bind_s(LDAP_ADMIN, LDAP_PASSWD) searchFilter = 'cn='+username attrs = ['unicodePwd'] ldap_result_id = conn.search_s(BASE_DN, searchScope, searchFilter, attrs) if (ldap_result_id == []): print 'user not found' else: newPassword = ('"%s"' % password).encode('utf-16-le') for dn,entry in ldap_result_id: attr = [( ldap.MOD_REPLACE, 'unicodePwd', newPassword)] try: conn.modify_s(dn, attr) except ldap.LDAPError, error: print 'error',error conn.unbind_s() Does anybody known how to solve? Best regards, ychsiao From jamesa at daa.com.au Wed Sep 9 06:35:13 2009 From: jamesa at daa.com.au (James Andrewartha) Date: Wed, 09 Sep 2009 12:35:13 +0800 Subject: hello everybody In-Reply-To: <4AA622DC.6030007@stroeder.com> References: <200909072220.14777.l.mierzwa@gmail.com> <4AA622DC.6030007@stroeder.com> Message-ID: <4AA73081.3050100@daa.com.au> Michael Str?der wrote: > ?ukasz Mierzwa wrote: >> I'm writing LDAP library (ORM without R as I call it) for python, it's using >> python-ldap to do the hard work and let You manage LDAP entries in more ORM >> style. > > 1. You're not the first one implementing such a module on top of python-ldap. > You might want to dig the mailing list's archive to find others. Yes, I started one, then someone developed it further at https://launchpad.net/python-ldap-om > 2. Most implementations of higher-level APIs fall short with mapping attribute > type descriptors (OIDs or NAME) to Python class attribute names since they > ignore the fact that there are sub-types defined in LDAP (;binary and language > sub-types such as ;de-DE). Also there does not have to be a NAME in an > attribute type description. So raw OIDs might be returned in a LDAP search result. > > 3. No implementation is dealing correctly with attribute type descriptor > aliasing with OIDs and several values for NAME. You might want to look at > ldap.schema.models.Entry to get an idea. I'm aware of these and chose to ignore them - my library wasn't meant to be general purpose, it was for scenarios where you have control of the LDAP server and can make these things can't happen. In fact my ultimate idea was to upload user-defined model schema to the LDAP server via cn=config. -- James Andrewartha From lukasz.mierzwa at redefine.pl Wed Sep 9 10:31:14 2009 From: lukasz.mierzwa at redefine.pl (=?utf-8?q?=C5=81ukasz_Mierzwa?=) Date: Wed, 9 Sep 2009 10:31:14 +0200 Subject: hello everybody In-Reply-To: <4AA622DC.6030007@stroeder.com> References: <200909072220.14777.l.mierzwa@gmail.com> <4AA622DC.6030007@stroeder.com> Message-ID: <200909091031.14309.lukasz.mierzwa@redefine.pl> Dnia wtorek, 8 wrze?nia 2009 o 11:24:44 Michael Str?der napisa?(a): > ?ukasz, > > ?ukasz Mierzwa wrote: > > I'm writing LDAP library (ORM without R as I call it) for python, it's > > using python-ldap to do the hard work and let You manage LDAP entries in > > more ORM style. > > I don't have the spare time to look more closely at it not to speak of > really contributing to it. So just a few general hints: > > 1. You're not the first one implementing such a module on top of > python-ldap. You might want to dig the mailing list's archive to find > others. > > 2. Most implementations of higher-level APIs fall short with mapping > attribute type descriptors (OIDs or NAME) to Python class attribute names > since they ignore the fact that there are sub-types defined in LDAP > (;binary and language sub-types such as ;de-DE). Also there does not have > to be a NAME in an attribute type description. So raw OIDs might be > returned in a LDAP search result. > > 3. No implementation is dealing correctly with attribute type descriptor > aliasing with OIDs and several values for NAME. You might want to look at > ldap.schema.models.Entry to get an idea. > > Ciao, Michael. I think that my approach is a little bit different than others, I'm not trying to make a tool that will automatically map LDAP object with all its attributes to a python object, I'm aiming at solution where: 1. there is no magic, nothing happens without You knowing it, no auto mapping attributes from LDAP to python 2. we assume that user know what schema is defined on the server, it's not designed for cases where You first discover what is stored on server side and then adapt 3. server stores standardized data, this means that if You store user 300 accounts, all of them are using the same set of object classes 4. user to writes models and he describes what object classes and attributes he is going to use in those models 5. user models needs to follow server schema, if they don't he is going to get exception before anything happens I don't need a solution for browsing LDAP data and dealing with every type of attribute that can be defined, I need a tool to easily work with large set of unified objects (like user accounts), creating user model with set of methods to deal with user accounts seems to me like a good way of doing this. -- ?ukasz Mierzwa From zhbmaillistonly at gmail.com Wed Sep 9 07:32:44 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Wed, 9 Sep 2009 13:32:44 +0800 Subject: What's the best way to replace value of attribute which can handle multiple values? Message-ID: Hi, all. What's the best way to 'replace' value of attribute which can handle multiple values? Such as: dn: uid=myuid,dc=example,dc=com cn: cn1 cn: cn2 cn: cn3 My purpose is to get ldif like this (no cn=cn2 any more): dn: uid=myuid,dc=example,dc=com cn: cn1 cn: cn3 cn: cn4 I want to replace cn=cn2 by cn=cn4 if it exist, or add cn=cn4 directly if 'cn=cn2' donesn't exist. If cn=cn2 is not exist, [(ldap.MOD_DELETE, 'cn', 'cn2')] will raise an error. If cn=cn2 is not exist, [(ldap.MOD_ADD, 'cn', 'cn4')] will add cn=cn4, but can't delete 'cn=cn2'. Thanks very much. :) -- Best Regards. Zhang Huangbin - Open Source Mail Server Solution for Red Hat(R) Enterprise Linux, CentOS, Debian, Ubuntu: http://www.iredmail.org/ From zhbmaillistonly at gmail.com Wed Sep 9 08:03:03 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Wed, 9 Sep 2009 14:03:03 +0800 Subject: What's the best way to replace value of attribute which can handle multiple values? Message-ID: On Sep 9, 2009, at 1:32 PM, Zhang Huangbin wrote: > > I want to replace cn=cn2 by cn=cn4 if it exist, or add cn=cn4 > directly if 'cn=cn2' donesn't exist. > > If cn=cn2 is not exist, [(ldap.MOD_DELETE, 'cn', 'cn2')] will raise > an error. > If cn=cn2 is not exist, [(ldap.MOD_ADD, 'cn', 'cn4')] will add > cn=cn4, but can't delete 'cn=cn2'. Oops, forget to mention that i will modify more attributes every time, not only 'cn'. Such as: ---- mod_attrs = [ (ldap.MOD_XXX, attr1, value1), (ldap.MOD_XXX, attr2, [value2]), ... ] self.conn.modify_s(dn, mod_attrs) ---- Is there a better way to modify it except using several 'try:...except:...' block? -- Best Regards. Zhang Huangbin - Open Source Mail Server Solution for Red Hat(R) Enterprise Linux, CentOS, Debian, Ubuntu: http://www.iredmail.org/ From michael at stroeder.com Wed Sep 9 10:54:43 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 09 Sep 2009 10:54:43 +0200 Subject: What's the best way to replace value of attribute which can handle multiple values? In-Reply-To: References: Message-ID: <4AA76D53.4080104@stroeder.com> Zhang Huangbin wrote: > What's the best way to 'replace' value of attribute which can handle > multiple values? > > Such as: > > dn: uid=myuid,dc=example,dc=com > cn: cn1 > cn: cn2 > cn: cn3 > > My purpose is to get ldif like this (no cn=cn2 any more): > > dn: uid=myuid,dc=example,dc=com > cn: cn1 > cn: cn3 > cn: cn4 > > I want to replace cn=cn2 by cn=cn4 if it exist, or add cn=cn4 directly > if 'cn=cn2' donesn't exist. > > If cn=cn2 is not exist, [(ldap.MOD_DELETE, 'cn', 'cn2')] will raise an > error. Could you please post the error raised and mention with which server you're testing? I'd try [(ldap.MOD_DELETE, 'cn',['cn2'])] > If cn=cn2 is not exist, [(ldap.MOD_ADD, 'cn', 'cn4')] will add cn=cn4, > but can't delete 'cn=cn2'. Try this: [(ldap.MOD_ADD, 'cn',['cn4'])] In general for this to work the server has to have an EQUALITY matching rule defined for the attribute type in question and implement this matching rule. This should be the case for 'cn' alias 'commonName' but one never knows for sure. In web2ldap I have implemented a variant of the function ldap.modlist.modifyModlist() which looks at the schema to determine use of EQUALITY matching rule and generate the diff accordingly. Ciao, Michael. From michael at stroeder.com Wed Sep 9 12:02:30 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 09 Sep 2009 12:02:30 +0200 Subject: What's the best way to replace value of attribute which can handle multiple values? In-Reply-To: <6C75856F-D7A2-4C0B-89D6-4C34EBF8BB04@gmail.com> References: <4AA76D53.4080104@stroeder.com> <6C75856F-D7A2-4C0B-89D6-4C34EBF8BB04@gmail.com> Message-ID: <4AA77D36.80202@stroeder.com> Zhang Huangbin wrote: > On Sep 9, 2009, at 4:54 PM, Michael Str?der wrote: >>> If cn=cn2 is not exist, [(ldap.MOD_DELETE, 'cn', 'cn2')] will raise >>> an >>> error. >> Could you please post the error raised and mention with which server >> you're >> testing? >> >> I'd try [(ldap.MOD_DELETE, 'cn',['cn2'])] > > The same error if cn=cn2 not exist: ldap.NO_SUCH_ATTRIBUTE. And how about the diagnostic message? I'd test the code with trace_level=2. Ciao, Michael. From zhbmaillistonly at gmail.com Wed Sep 9 11:22:07 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Wed, 9 Sep 2009 17:22:07 +0800 Subject: What's the best way to replace value of attribute which can handle multiple values? In-Reply-To: <4AA76D53.4080104@stroeder.com> References: <4AA76D53.4080104@stroeder.com> Message-ID: <6C75856F-D7A2-4C0B-89D6-4C34EBF8BB04@gmail.com> Thanks for your reply, Michael. :) On Sep 9, 2009, at 4:54 PM, Michael Str?der wrote: >> If cn=cn2 is not exist, [(ldap.MOD_DELETE, 'cn', 'cn2')] will raise >> an >> error. > > Could you please post the error raised and mention with which server > you're > testing? > > I'd try [(ldap.MOD_DELETE, 'cn',['cn2'])] The same error if cn=cn2 not exist: ldap.NO_SUCH_ATTRIBUTE. > >> If cn=cn2 is not exist, [(ldap.MOD_ADD, 'cn', 'cn4')] will add >> cn=cn4, >> but can't delete 'cn=cn2'. > > Try this: [(ldap.MOD_ADD, 'cn',['cn4'])] It can't delete cn=cn2. And same error raised while cn=cn4 exists: ldap.TYPE_OR_VALUE_EXISTS. I created a function to perform similar request moment ago, but still looking for a better way: ------- class LDAPWrap: def __init__(self): ... skip some lines ... self.conn = ldap.initialize(xxx) ... skip some lines ... def addOrDelAttrValue(self, dn, attr, value, type): """Used to add or replace value of attribute which can handle multiple values. @type: add, delete. """ self.dn = ldap.filter.escape_filter_chars(dn) if type == 'add': try: self.conn.modify_s(self.dn, [(ldap.MOD_ADD, attr, value)]) return (True, 'SUCCESS') except ldap.TYPE_OR_VALUE_EXISTS: return (True, 'SUCCESS') except Exception, e: return (False, str(e)) elif type == 'delete': try: self.conn.modify_s(self.dn, [(ldap.MOD_DELETE, attr, value)]) return (True, 'SUCCESS') except ldap.NO_SUCH_ATTRIBUTE: return (True, 'SUCCESS') except Exception, e: return (False, str(e)) ----- Thanks very much :) -- Best Regards. Zhang Huangbin - Open Source Mail Server Solution for Red Hat(R) Enterprise Linux, CentOS, Debian, Ubuntu: http://www.iredmail.org/ From zhbmaillistonly at gmail.com Wed Sep 9 14:08:23 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Wed, 9 Sep 2009 20:08:23 +0800 Subject: What's the best way to replace value of attribute which can handle multiple values? In-Reply-To: <4AA77D36.80202@stroeder.com> References: <4AA76D53.4080104@stroeder.com> <6C75856F-D7A2-4C0B-89D6-4C34EBF8BB04@gmail.com> <4AA77D36.80202@stroeder.com> Message-ID: On Sep 9, 2009, at 6:02 PM, Michael Str?der wrote: > Zhang Huangbin wrote: >> On Sep 9, 2009, at 4:54 PM, Michael Str?der wrote: >>>> If cn=cn2 is not exist, [(ldap.MOD_DELETE, 'cn', 'cn2')] will raise >>>> an >>>> error. >>> Could you please post the error raised and mention with which server >>> you're >>> testing? >>> >>> I'd try [(ldap.MOD_DELETE, 'cn',['cn2'])] >> >> The same error if cn=cn2 not exist: ldap.NO_SUCH_ATTRIBUTE. > > And how about the diagnostic message? I'd test the code with > trace_level=2. bind dn: cn=vmailadmin,dc=iredmail,dc=org operation: [(ldap.MOD_DELETE, 'enabledService', 'forward')] ldif: ---- dn: mail=test22 at a.cn,ou=Users,domainName=a.cn,o=domains,dc=iredmail,dc=org enabledService: smtp enabledService: imap enabledService: pop3 enabledService: deliver ---- Below is console log with 'trace_level=2': ------------ *** ldap://127.0.0.1:389 - SimpleLDAPObject.set_option ((17, 3),{}) *** ldap://127.0.0.1:389 - SimpleLDAPObject.set_option ((17, 3),{}) *** ldap://127.0.0.1:389 - SimpleLDAPObject.simple_bind (('cn=vmailadmin,dc=iredmail,dc=org', 'passwd', None, None),{}) => result: 1 *** ldap://127.0.0.1:389 - SimpleLDAPObject.result3 ((1, 1, -1),{}) => result: (97, [], 1, []) *** ldap://127.0.0.1:389 - SimpleLDAPObject.modify_ext (('mail=test22 at a.cn ,ou=Users,domainName=a.cn,o=domains,dc=iredmail,dc=org', [(1, 'enabledService', 'forward')], None, None),{}) => result: 3 *** ldap://127.0.0.1:389 - SimpleLDAPObject.result3 ((3, 1, -1),{}) => LDAPError - NO_SUCH_ATTRIBUTE: {'info': 'modify/delete: enabledService: no such value', 'desc': 'No such attribute'} Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/web.py-0.32-py2.4.egg/web/ application.py", line 242, in process return self.handle() File "/usr/lib/python2.4/site-packages/web.py-0.32-py2.4.egg/web/ application.py", line 233, in handle return self._delegate(fn, self.fvars, args) File "/usr/lib/python2.4/site-packages/web.py-0.32-py2.4.egg/web/ application.py", line 412, in _delegate return handle_class(cls) File "/usr/lib/python2.4/site-packages/web.py-0.32-py2.4.egg/web/ application.py", line 387, in handle_class return tocall(*args) File "/var/www/iredadmin/controllers/ldap/base.py", line 23, in proxyfunc return func(self, *args, **kw) File "/var/www/iredadmin/controllers/ldap/user.py", line 106, in POST data=i, File "/var/www/iredadmin/libs/ldaplib/core.py", line 149, in proxyfunc return func(self, *args, **kw) File "/var/www/iredadmin/libs/ldaplib/user.py", line 165, in update self.conn.modify_s(self.dn, [(ldap.MOD_DELETE, 'enabledService', 'forward')]) File "/usr/lib/python2.4/site-packages/python_ldap-2.3.9-py2.4- linux-x86_64.egg/ldap/ldapobject.py", line 328, in modify_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.4/site-packages/python_ldap-2.3.9-py2.4- linux-x86_64.egg/ldap/ldapobject.py", line 428, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File "/usr/lib/python2.4/site-packages/python_ldap-2.3.9-py2.4- linux-x86_64.egg/ldap/ldapobject.py", line 432, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3 (msgid,all,timeout) File "/usr/lib/python2.4/site-packages/python_ldap-2.3.9-py2.4- linux-x86_64.egg/ldap/ldapobject.py", line 438, in result3 ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/lib/python2.4/site-packages/python_ldap-2.3.9-py2.4- linux-x86_64.egg/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) NO_SUCH_ATTRIBUTE: {'info': 'modify/delete: enabledService: no such value', 'desc': 'No such attribute'} *** ldap://127.0.0.1:389 - SimpleLDAPObject.unbind_ext ((None, None),{}) 192.168.6.1:49306 - - [28/Jun/2009 14:42:21] "HTTP/1.1 POST /profile/user/forwarding/test22 at a.cn " - 500 Internal Server Error ---------- -- Best Regards. Zhang Huangbin - Open Source Mail Server Solution for Red Hat(R) Enterprise Linux, CentOS, Debian, Ubuntu: http://www.iredmail.org/ From michael at stroeder.com Wed Sep 9 15:32:23 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 09 Sep 2009 15:32:23 +0200 Subject: What's the best way to replace value of attribute which can handle multiple values? In-Reply-To: References: <4AA76D53.4080104@stroeder.com> <6C75856F-D7A2-4C0B-89D6-4C34EBF8BB04@gmail.com> <4AA77D36.80202@stroeder.com> Message-ID: <4AA7AE67.5080403@stroeder.com> Zhang Huangbin wrote: > NO_SUCH_ATTRIBUTE: {'info': 'modify/delete: enabledService: no such > value', 'desc': 'No such attribute'} This means the attribute 'enabledService' is not available in the entry at all. So you can't remove a certain attribute value from it. Ciao, Michael. From michael at stroeder.com Wed Sep 9 15:48:32 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 09 Sep 2009 15:48:32 +0200 Subject: What's the best way to replace value of attribute which can handle multiple values? In-Reply-To: <92FDF535-A969-45F5-BD9C-4115DEA91147@gmail.com> References: <4AA76D53.4080104@stroeder.com> <6C75856F-D7A2-4C0B-89D6-4C34EBF8BB04@gmail.com> <4AA77D36.80202@stroeder.com> <4AA7AE67.5080403@stroeder.com> <92FDF535-A969-45F5-BD9C-4115DEA91147@gmail.com> Message-ID: <4AA7B230.5060106@stroeder.com> Zhang Huangbin wrote: > > On Sep 9, 2009, at 9:32 PM, Michael Str?der wrote: > >> Zhang Huangbin wrote: >>> NO_SUCH_ATTRIBUTE: {'info': 'modify/delete: enabledService: no such >>> value', 'desc': 'No such attribute'} >> >> This means the attribute 'enabledService' is not available in the >> entry at >> all. So you can't remove a certain attribute value from it. >> > Attribute is present, but not contains value 'forwrad'. Then it will simply fail. If you have to handle such optional cases you probably have to sort that out at the client side in some way. I'd read the whole attribute value list, tweak it and replace it. BTW: That's why ldap.modlist.modifyModlist() was implemented. Ciao, Michael. From zhbmaillistonly at gmail.com Wed Sep 9 15:36:34 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Wed, 9 Sep 2009 21:36:34 +0800 Subject: What's the best way to replace value of attribute which can handle multiple values? In-Reply-To: <4AA7AE67.5080403@stroeder.com> References: <4AA76D53.4080104@stroeder.com> <6C75856F-D7A2-4C0B-89D6-4C34EBF8BB04@gmail.com> <4AA77D36.80202@stroeder.com> <4AA7AE67.5080403@stroeder.com> Message-ID: <92FDF535-A969-45F5-BD9C-4115DEA91147@gmail.com> On Sep 9, 2009, at 9:32 PM, Michael Str?der wrote: > Zhang Huangbin wrote: >> NO_SUCH_ATTRIBUTE: {'info': 'modify/delete: enabledService: no such >> value', 'desc': 'No such attribute'} > > This means the attribute 'enabledService' is not available in the > entry at > all. So you can't remove a certain attribute value from it. > > Ciao, Michael. Attribute is present, but not contains value 'forwrad'. As i posted in previous mail, the ldif data before we invoke .modify_s () is: ---- dn: xxx enabledService: mail enabledService: smtp enabledService: pop3 enabledService: imap enabledService: deliver ---- -- Best Regards. Zhang Huangbin - Open Source Mail Server Solution for Red Hat(R) Enterprise Linux, CentOS, Debian, Ubuntu: http://www.iredmail.org/ From zhbmaillistonly at gmail.com Wed Sep 9 15:53:33 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Wed, 9 Sep 2009 21:53:33 +0800 Subject: What's the best way to replace value of attribute which can handle multiple values? In-Reply-To: <4AA7B230.5060106@stroeder.com> References: <4AA76D53.4080104@stroeder.com> <6C75856F-D7A2-4C0B-89D6-4C34EBF8BB04@gmail.com> <4AA77D36.80202@stroeder.com> <4AA7AE67.5080403@stroeder.com> <92FDF535-A969-45F5-BD9C-4115DEA91147@gmail.com> <4AA7B230.5060106@stroeder.com> Message-ID: <7554B073-4E27-4D74-8580-665C9D140BBA@gmail.com> On Sep 9, 2009, at 9:48 PM, Michael Str?der wrote: > BTW: That's why > ldap.modlist.modifyModlist() was implemented. Any example? There is no example in official python-ldap document: http://www.python-ldap.org/doc/html/ldap-modlist.html?highlight=modifymodlist#ldap.modlist.modifyModlist Thanks very much. :) -- Best Regards. Zhang Huangbin - Open Source Mail Server Solution for Red Hat(R) Enterprise Linux, CentOS, Debian, Ubuntu: http://www.iredmail.org/ From michael at stroeder.com Wed Sep 9 15:58:26 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 09 Sep 2009 15:58:26 +0200 Subject: What's the best way to replace value of attribute which can handle multiple values? In-Reply-To: <7554B073-4E27-4D74-8580-665C9D140BBA@gmail.com> References: <4AA76D53.4080104@stroeder.com> <6C75856F-D7A2-4C0B-89D6-4C34EBF8BB04@gmail.com> <4AA77D36.80202@stroeder.com> <4AA7AE67.5080403@stroeder.com> <92FDF535-A969-45F5-BD9C-4115DEA91147@gmail.com> <4AA7B230.5060106@stroeder.com> <7554B073-4E27-4D74-8580-665C9D140BBA@gmail.com> Message-ID: <4AA7B482.5070808@stroeder.com> Zhang Huangbin wrote: > > On Sep 9, 2009, at 9:48 PM, Michael Str?der wrote: > >> BTW: That's why >> ldap.modlist.modifyModlist() was implemented. > > Any example? > > There is no example in official python-ldap document: > http://www.python-ldap.org/doc/html/ldap-modlist.html?highlight=modifymodlist#ldap.modlist.modifyModlist >>> import ldap.modlist >>> ldap.modlist.modifyModlist({'cn':'Mike'},{'cn':'Michael Stroeder','mail':'michael at stroeder.com'}) [(0, 'mail', 'michael at stroeder.com'), (1, 'cn', None), (0, 'cn', 'Michael Stroeder')] So basically you read the old_entry dict with an search operation, derive a new_entry dict from it, tweak that and pass old_entry and new_entry to this function. Ciao, Michael. From yo at brunoaguirre.com Wed Sep 9 16:36:55 2009 From: yo at brunoaguirre.com (Bruno Aguirre) Date: Wed, 9 Sep 2009 11:36:55 -0300 Subject: Python3 and LDAP Message-ID: Hi to all, I'd like to know if there's a version (alpha, beta or stable) to use ldap in python 3. Thanks for your time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed Sep 9 16:53:10 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 09 Sep 2009 16:53:10 +0200 Subject: Python3 and LDAP In-Reply-To: References: Message-ID: <4AA7C156.1030605@stroeder.com> Bruno Aguirre wrote: > > Hi to all, I'd like to know if there's a version (alpha, beta or stable) > to use ldap in python 3. There are still some things to consider. Please dig the mailing list's archive for some discussion. Would you personally be willing to put some effort into the C extension module part? Ciao, Michael. From michael at stroeder.com Mon Sep 14 15:08:00 2009 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Mon, 14 Sep 2009 15:08:00 +0200 Subject: Expired server certificate In-Reply-To: <4A8BEA23.40905@dfn-cert.de> References: <4A814DC8.6010602@dfn-cert.de> <4A81505C.8080400@stroeder.com> <4A8BEA23.40905@dfn-cert.de> Message-ID: <4AAE4030.5050502@stroeder.com> Fredrik, I've learned the hard way now that settings in .ldaprc and ldap.conf have precedence over what you set in your Python code via ldap.set_option() or LDAPObject.set_option(). Best thing is to use this code-line to completely switch off processing of .ldaprc and ldap.conf in libldap: os.environ['LDAPNOINIT']='1' Ciao, Michael. Fredrik Melander wrote: >> Hmm, there's nothing you can do at the python-ldap level. AFAIK cert >> validation is completely done within the OpenSSL libs, except the host name >> checking. >> >> Could you please test with OpenLDAP's command-line tool ldapsearch. This is >> important: Please use the tool which uses the very same libldap also used for >> python-ldap. >> >> If ldapsearch fails this would be something to raise on the openldap-software >> mailing list together with information about your build of libldap and the >> SSL/TLS libs used. Note that libldap could be build with GnuTLS or today even >> with Mozilla's libnss. >> >> Ciao, Michael. >> > > > > Hi, Michael. > Thanks for your reply. I've been looking into this, trying stuff on > different machines and once again it's the frustrating issue of > different OpenLDAP versions. > You might not remember this but I posted a question to this list a > couple of mounths ago about the chase referrals flag which also turned > out to be treated differently depending on OpenLDAP version. > > One of my machines here has (let's call it A) the RPM > openldap2-client-2.3.37-20.8 installed. While as another one (B) has > openldap2-client-2.4.9-7.4 (libldap-2.3.so.0 and libldap-2.4.so.2 > respectively). > > Of course you're right that python-ldap has nothing to do with this, > since ldapsearch gives the same results: > > Computer A: > ldapsearch -x -h "host.domain.de" -b "o=myorg,dc=net" -ZZ > > ldap_start_tls: Connect error (-11) > additional info: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > > Computer B: > ldapsearch -x -h "host.domain.de" -b "o=myorg,dc=net" -ZZ > > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > > I'm posting this in case somebody runs into similar issues and also in > the hope that somebody has a suggestion on how to solve this. I might > also need to point out that it isn't about these two computers only. > That would be trivial. The application is going to be distributed in a > fairly big organization and I can't possibly demand that everybody has > the same OpenLDAP version. > > The most frustrating thing is perhaps that it is the old version that > has the desired behaviour. I know this is a bit off topic, but surely > there must be a way to check this also in later versions? It'd be much > appreciated if anybody could point me in the right direction here. > > Best regards, > Fredrik From melander at dfn-cert.de Wed Aug 19 14:03:47 2009 From: melander at dfn-cert.de (Fredrik Melander) Date: Wed, 19 Aug 2009 14:03:47 +0200 Subject: Expired server certificate In-Reply-To: <4A81505C.8080400@stroeder.com> References: <4A814DC8.6010602@dfn-cert.de> <4A81505C.8080400@stroeder.com> Message-ID: <4A8BEA23.40905@dfn-cert.de> > Hmm, there's nothing you can do at the python-ldap level. AFAIK cert > validation is completely done within the OpenSSL libs, except the host name > checking. > > Could you please test with OpenLDAP's command-line tool ldapsearch. This is > important: Please use the tool which uses the very same libldap also used for > python-ldap. > > If ldapsearch fails this would be something to raise on the openldap-software > mailing list together with information about your build of libldap and the > SSL/TLS libs used. Note that libldap could be build with GnuTLS or today even > with Mozilla's libnss. > > Ciao, Michael. > Hi, Michael. Thanks for your reply. I've been looking into this, trying stuff on different machines and once again it's the frustrating issue of different OpenLDAP versions. You might not remember this but I posted a question to this list a couple of mounths ago about the chase referrals flag which also turned out to be treated differently depending on OpenLDAP version. One of my machines here has (let's call it A) the RPM openldap2-client-2.3.37-20.8 installed. While as another one (B) has openldap2-client-2.4.9-7.4 (libldap-2.3.so.0 and libldap-2.4.so.2 respectively). Of course you're right that python-ldap has nothing to do with this, since ldapsearch gives the same results: Computer A: ldapsearch -x -h "host.domain.de" -b "o=myorg,dc=net" -ZZ ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Computer B: ldapsearch -x -h "host.domain.de" -b "o=myorg,dc=net" -ZZ # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # I'm posting this in case somebody runs into similar issues and also in the hope that somebody has a suggestion on how to solve this. I might also need to point out that it isn't about these two computers only. That would be trivial. The application is going to be distributed in a fairly big organization and I can't possibly demand that everybody has the same OpenLDAP version. The most frustrating thing is perhaps that it is the old version that has the desired behaviour. I know this is a bit off topic, but surely there must be a way to check this also in later versions? It'd be much appreciated if anybody could point me in the right direction here. Best regards, Fredrik -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5927 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Mon Sep 14 22:00:53 2009 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Mon, 14 Sep 2009 22:00:53 +0200 Subject: StartTLS with errors on 2.4.17 In-Reply-To: <200909141653.05126.rhafer@suse.de> References: <4AAD1D0C.1060109@stroeder.com> <200909141441.06909.rhafer@suse.de> <4AAE3E2D.3090900@stroeder.com> <200909141653.05126.rhafer@suse.de> Message-ID: <4AAEA0F5.4000700@stroeder.com> Hallo Ralf, erst mal vielen Dank f?r Deine Analyse. Sorry for the noise... Ralf Haferkamp wrote: > LDAP_OPT_X_TLS macht was ganz anderes. Damit kann man soweit ich das sehe tls > aktivieren ohne explizit start_tls() aufzurufen. > > Wenn ich jetzt in dem Testskript, vor dem ldap.initialize Aufruf das hier > setze: > ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT,ldap.OPT_X_TLS_DEMAND) > Dann schl?gt der start_tls_s-Aufruf wie erwartet fehl. Hmmpf! Ok, in 2.4.18 sind die ganzen Konstanten ja endlich dokumentiert. > Das funktioniert aber nur als globale Option. AFAIK ist das so, weil die > Bibliothek den TLS context nur einmal global initialisiert, und nicht pro > Verbindung. Das ist f?r mein multi-threaded web2ldap ziemlich Scheisse. Hatte ich schon immer als offene Baustelle im Hinterkopf. > In C kann man den TLS context ?ber LDAP_OPT_X_TLS_NEWCTX neu > erzeugen lassen, kann sein, dass es damit auch nach dem ldap_initialize > funktionieren w?rde. Auch als globale Option? Habe jetzt mal in python-ldap die Unterst?tzung f?r ldap.OPT_X_TLS_NEWCTX eingebaut. Funktioniert leider nicht, der Return-Code von ldap_set_option() ist nicht Null. Kann auf die Schnelle nicht sagen, woran das liegt. Hast Du das in C schon mal ausprobiert? >> Spricht etwas dagegen in der ldap.conf Deiner Packages den Default-Wert so >> zu setzen? >> >> TLS_REQCERT hard > Der Testaufwand. Wahrscheinlich machen danach einige YaST Module Probleme. > Aber prinzipiell w?re es am besten die Option TLS_REQCERT ganz rauszulassen > (der default ist ja "hard"). Ja, am besten weglassen, da es ja so viele Komponenten betrifft. Ciao, Michael. From rhafer at suse.de Mon Sep 14 16:53:05 2009 From: rhafer at suse.de (Ralf Haferkamp) Date: Mon, 14 Sep 2009 16:53:05 +0200 Subject: StartTLS with errors on 2.4.17 In-Reply-To: <4AAE3E2D.3090900@stroeder.com> References: <4AAD1D0C.1060109@stroeder.com> <200909141441.06909.rhafer@suse.de> <4AAE3E2D.3090900@stroeder.com> Message-ID: <200909141653.05126.rhafer@suse.de> Am Monday 14 September 2009 14:59:25 schrieben Sie: > Ralf Haferkamp wrote: > > Am Monday 14 September 2009 12:21:36 schrieben Sie: > >> Hallo Ralf, > >> > >> Ralf Haferkamp wrote: > >>> Are you able to reproduce it using > >>> ldapsearch (that's what I used as I don't have your test code): > >> > >> Nein, leider nicht. Bzw. Dieter Kl?nter hat das getestet. > >> > >> Es kann auch durchaus an python-ldap liegen. Aber warum funktioniert es > >> dann mit 2.4.18 libldap? Und wie sieht es mit den Backport-Packages > >> von OpenSSL aus? > > > > Welche Backport-Packages von OpenSSL meinst du? > > > >> Vielleicht irgendwelche subtilen Abh?ngigkeiten? > >> > >>> LDAPNOINIT=1 \ > >>> LDAPTLS_CACERT=/etc/ssl/certs/Wells_Fargo_Root_CA.pem \ > >>> ldapsearch -x -b "" -H ldap://dkluenter.dyndns.org -ZZ -d -1 > >> > >> Ich habe mal das Test-Skript und CA-Cert angeh?ngt. > > > > Ok, Ich habe das gerade mal ausprobiert. Bei mir funktioniert das wie > > erwartet. Lediglich, wenn ich in TLS_REQCERT=allow > > /etc/openldap/ldap.conf setze wird der Fehler ignoriert. > > Hmm, das scheint tats?chlich der Fehler zu sein. Danke. Phew, da bin ich ein wenig erleichert ;) > Mein 2.4.18-Build schaut in einer anderen ldap.conf nach, da anderer > prefix. Ich dachte eigentlich, diese Code-Zeile h?tte Vorrang vor > TLS_REQCERT allow in der ldap.conf. > > l.set_option(ldap.OPT_X_TLS,ldap.OPT_X_TLS_DEMAND) > > Noch nicht mal global gesetzt hilft: > > ldap.set_option(ldap.OPT_X_TLS,ldap.OPT_X_TLS_DEMAND) Ich glaube du setzt die falsche Option. Korrekt w?re: LDAP_OPT_X_TLS_REQUIRE_CERT bzw. ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT,ldap.OPT_X_TLS_DEMAND) LDAP_OPT_X_TLS macht was ganz anderes. Damit kann man soweit ich das sehe tls aktivieren ohne explizit start_tls() aufzurufen. Wenn ich jetzt in dem Testskript, vor dem ldap.initialize Aufruf das hier setze: ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT,ldap.OPT_X_TLS_DEMAND) Dann schl?gt der start_tls_s-Aufruf wie erwartet fehl. Das funktioniert aber nur als globale Option. AFAIK ist das so, weil die Bibliothek den TLS context nur einmal global initialisiert, und nicht pro Verbindung. In C kann man den TLS context ?ber LDAP_OPT_X_TLS_NEWCTX neu erzeugen lassen, kann sein, dass es damit auch nach dem ldap_initialize funktionieren w?rde. > Es hilft tats?chlich nur im Skript (oder wie von Dir gesagt auf > Shell-Ebene): > > os.environ['LDAPNOINIT']='1' > > Spricht etwas dagegen in der ldap.conf Deiner Packages den Default-Wert so > zu setzen? > > TLS_REQCERT hard Der Testaufwand. Wahrscheinlich machen danach einige YaST Module Probleme. Aber prinzipiell w?re es am besten die Option TLS_REQCERT ganz rauszulassen (der default ist ja "hard"). -- Gru?, Ralf From michael at stroeder.com Mon Sep 14 22:35:03 2009 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Mon, 14 Sep 2009 22:35:03 +0200 Subject: SSS und VLV in Python In-Reply-To: <87tyz5few6.fsf@rubin.avci.de> References: <87tyz5few6.fsf@rubin.avci.de> Message-ID: <4AAEA8F7.3020304@stroeder.com> Hallo Dieter, Dieter Kluenter wrote: > f?r das D2 Sandbox-Modell versuche ich SSS und VLV zu modellieren. Mit > Perl kann ich SSS erfolgreich demonstrieren, nicht aber VLV, das liegt > wohl an einem Bug in Net::LDAP::Control::VLV, denn die R?ckgabewerte > des Control Response werden nicht in die Iteration der nachfolgenden > Searches ?bernommen. Warum fixt Du das nicht? Oder kontaktierst die Entwickler? > Hast du m?glicherweise ein funktionierendes Beispiel in Python? Hatte aufgrund Deiner Postings auf der OpenLDAP-Liste schon vermutet, dass Du danach fragen wirst. Nee, das gibt's noch nicht in Python. Es gibt nur ein Demo mit Simple Paged Results Control. > Ich k?mpfe hier gegen eine Java-Fraktion, die haben es aber bisher > auch noch nicht geschafft. Warum k?mpfst Du gegen eine Java-Fraktion? Ciao, Michael. From lgp171188 at gmail.com Sun Sep 20 16:02:14 2009 From: lgp171188 at gmail.com (Guruprasad) Date: Sun, 20 Sep 2009 19:32:14 +0530 Subject: KeyError while performing 'ldapsearch' operation and processing the result data Message-ID: <7c956f0c0909200702hb45a6fs51950086c3f19365@mail.gmail.com> Hi, I have been trying to write a function to search a LDAP directory by using the python-ldap APIs. Here is the code I have written: def getNextUid(): uidList=[] try: l=ldap.initialize(ldap_host) l.bind_s(ldap_admin_dn,ldap_admin_pass) ldap_result=l.search(ldap_base_dn,ldap.SCOPE_SUBTREE,'cn=*',['uidNumber']) while 1: result_type, result_data=l.result(ldap_result,0) if (result_data == []): break a=result_data[0][1]['uidNumber'] print a except ldap.SERVER_DOWN: print "LDAP server down" What I am trying to do in this piece of code is get the list of the values of 'uidNumber' attribute. The search operation returns a list containing a tuple. The tuple contains the DN as one value and a dictionary with uidNumber and its value. I am trying to extract the value of the uidNumber. I found that result_data was a dictionary having a key 'uidNumber', but when I try to print its value, I get a KeyError. Strangely, when I print result_data.keys(), 'uidNumber' is present. Thank you. Regards, Guruprasad. From melander at dfn-cert.de Mon Sep 14 17:58:41 2009 From: melander at dfn-cert.de (Fredrik Melander) Date: Mon, 14 Sep 2009 17:58:41 +0200 Subject: Expired server certificate In-Reply-To: <4AAE4030.5050502@stroeder.com> References: <4A814DC8.6010602@dfn-cert.de> <4A81505C.8080400@stroeder.com> <4A8BEA23.40905@dfn-cert.de> <4AAE4030.5050502@stroeder.com> Message-ID: <4AAE6831.2060909@dfn-cert.de> Hey Michael, thanks for remembering! I will it out! Best, Fredrik Michael Str?der schrieb: > Fredrik, > > I've learned the hard way now that settings in .ldaprc and ldap.conf have > precedence over what you set in your Python code via ldap.set_option() or > LDAPObject.set_option(). Best thing is to use this code-line to completely > switch off processing of .ldaprc and ldap.conf in libldap: > > os.environ['LDAPNOINIT']='1' > > Ciao, Michael. > > Fredrik Melander wrote: >>> Hmm, there's nothing you can do at the python-ldap level. AFAIK cert >>> validation is completely done within the OpenSSL libs, except the host name >>> checking. >>> >>> Could you please test with OpenLDAP's command-line tool ldapsearch. This is >>> important: Please use the tool which uses the very same libldap also used for >>> python-ldap. >>> >>> If ldapsearch fails this would be something to raise on the openldap-software >>> mailing list together with information about your build of libldap and the >>> SSL/TLS libs used. Note that libldap could be build with GnuTLS or today even >>> with Mozilla's libnss. >>> >>> Ciao, Michael. >>> >> >> >> Hi, Michael. >> Thanks for your reply. I've been looking into this, trying stuff on >> different machines and once again it's the frustrating issue of >> different OpenLDAP versions. >> You might not remember this but I posted a question to this list a >> couple of mounths ago about the chase referrals flag which also turned >> out to be treated differently depending on OpenLDAP version. >> >> One of my machines here has (let's call it A) the RPM >> openldap2-client-2.3.37-20.8 installed. While as another one (B) has >> openldap2-client-2.4.9-7.4 (libldap-2.3.so.0 and libldap-2.4.so.2 >> respectively). >> >> Of course you're right that python-ldap has nothing to do with this, >> since ldapsearch gives the same results: >> >> Computer A: >> ldapsearch -x -h "host.domain.de" -b "o=myorg,dc=net" -ZZ >> >> ldap_start_tls: Connect error (-11) >> additional info: error:14090086:SSL >> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >> >> >> Computer B: >> ldapsearch -x -h "host.domain.de" -b "o=myorg,dc=net" -ZZ >> >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # >> >> >> I'm posting this in case somebody runs into similar issues and also in >> the hope that somebody has a suggestion on how to solve this. I might >> also need to point out that it isn't about these two computers only. >> That would be trivial. The application is going to be distributed in a >> fairly big organization and I can't possibly demand that everybody has >> the same OpenLDAP version. >> >> The most frustrating thing is perhaps that it is the old version that >> has the desired behaviour. I know this is a bit off topic, but surely >> there must be a way to check this also in later versions? It'd be much >> appreciated if anybody could point me in the right direction here. >> >> Best regards, >> Fredrik > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5927 bytes Desc: S/MIME Cryptographic Signature URL: From python-ldap at tk-webart.de Mon Jul 27 13:46:17 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Mon, 27 Jul 2009 13:46:17 +0200 Subject: ANN: python-ldap-2.3.9 In-Reply-To: <4A6C6F5E.2090409@stroeder.com> References: <4A6C6F5E.2090409@stroeder.com> Message-ID: <20090727134617.67934f14@atalante.iwm-kmrc.de> Hi list, hi Michael, first of all: Michael, thanks for the new release! Eggs for 2.3.9 are available at http://svn.kmrc.de/download/distribution/contrib In addition to the information given in the section ".egg builds" on http://www.python-ldap.org/download.shtml the following changes apply: - MacOS X / Linux -> no change in prerequisites - MacOS X fat eggs have been successfully tested on a freshly installed MacOS X 10.4 PPC System. - The Windows eggs are now statically linked against libsasl2. To accomplish this, I used the method described at https://wiki.mozilla.org/LDAP_C_SDK_SASL_Windows to build the .DLL and then converted it into a static MinGW compatible lib by executing (thanks for the hint, Waldemar ;-) # pexports.exe -v \ -h ../include/sasl/sasl.h libsasl.dll >libsasl.def # dlltool.exe --input-def libsasl.def \ --dllname libsasl.dll --output-lib libsasl2.a -k As always, testers are very welcome, especially for the Win32 SASL setup! Best regards, Torsten -- Executive ability is deciding quickly and getting somebody else to do the work. -- John G. Pollard From brunoaguirrerissio at gmail.com Thu Sep 10 00:59:30 2009 From: brunoaguirrerissio at gmail.com (Bruno Aguirre) Date: Wed, 9 Sep 2009 19:59:30 -0300 Subject: Python3 and LDAP In-Reply-To: <4AA7C156.1030605@stroeder.com> References: <4AA7C156.1030605@stroeder.com> Message-ID: <432EE74C-F7A4-43CD-8FA5-4B2444BE5166@gmail.com> My hability to code a Python module is limited. But im glad to give a hand. Looking in the list i saw that someone said that the actual Python- ldap can be build for Python 3 modifying some lines. Is this possible? Ar? there alternatives? El 09/09/2009, a las 11:53, Michael Str?der escribi?: > Bruno Aguirre wrote: >> >> Hi to all, I'd like to know if there's a version (alpha, beta or >> stable) >> to use ldap in python 3. > > There are still some things to consider. Please dig the mailing > list's archive > for some discussion. > > Would you personally be willing to put some effort into the C > extension module > part? > > Ciao, Michael. > From d at adaptive-enterprises.com Sun Sep 13 02:06:30 2009 From: d at adaptive-enterprises.com (David Leonard) Date: Sat, 12 Sep 2009 18:06:30 -0600 Subject: Python3 and LDAP In-Reply-To: References: <4AA7C156.1030605@stroeder.com> Message-ID: An HTML attachment was scrubbed... URL: From leonard at users.sourceforge.net Mon Aug 3 06:57:26 2009 From: leonard at users.sourceforge.net (David Leonard) Date: Sun, 02 Aug 2009 22:57:26 -0600 Subject: Python-LDAP for Python 3.0 Message-ID: An HTML attachment was scrubbed... URL: From python-ldap at tk-webart.de Mon Aug 24 11:37:18 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Mon, 24 Aug 2009 11:37:18 +0200 Subject: SASL GSSAPI under Win32 In-Reply-To: <4A9111F7.4060608@stroeder.com> References: <917832.52986.qm@web65515.mail.ac4.yahoo.com> <4A79A6E5.9040603@stroeder.com> <6fae95540908051032h31e1e7cdo300ac9b90dd56af8@mail.gmail.com> <4A7A2163.4030406@stroeder.com> <6fae95540908052007i34e7ff31x7c851c2d3c55de05@mail.gmail.com> <20090817111309.1dc96f22@atalante.iwm-kmrc.de> <4A8957AA.6030909@stroeder.com> <20090817152330.10639840@atalante.iwm-kmrc.de> <20090817190540.37104a58@atalante.iwm-kmrc.de> <20090819192518.3cd7d8e7@atalante.iwm-kmrc.de> <6fae95540908191303t49309cbi220ed666ff7c5ba7@mail.gmail.com> <1003844487.20090820092848@tk-webart.de> <4A8D10F5.5040204@stroeder.com> <20090820151609.0603fa88@atalante.iwm-kmrc.de> <4A9111F7.4060608@stroeder.com> Message-ID: <20090824113718.0c36c9fd@atalante.iwm-kmrc.de> Hi Michael, > > http://svn.kmrc.de/download/distribution/contrib/doc/Minimal-Cyrus-SASL-Win32-HowTo.txt > > Many thanks for this! I don't know how persistent this link will be. > So do you mind if I add this as-is to python-ldap's source > distribution? In the long run we can add this in file > Doc/installing.rst. yes, please do so. As for the .dll inclusion in .eggs: You are right, .eggs are indeed simply .zip files. But they are "enriched" by an internal directory and file structure that has to be recorded during build. There is an option (IMHO extra_data) to include .dlls and other "extras" in a subdirectory called DATA. I didn't use that option so far, since I'd still prefer a completely static solution. Anyway, I'll try to build a combined solution (static libsasl2, plugin .dlls) now. If I succeed building a static libsasl2 that loads its plugins from the standard location, and also to include the plugin .dlls into the .egg somehow, we could take it from there. What do you think? Best regards, Torsten -- Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de Keep your boss's boss off your boss's back.