Re: modifying problem
On Fri, Nov 30, 2007 at 12:26:34PM -0800, Anil Jangity wrote: > Okay, I was just introduced to "multi-valued RDN", didn't know about that. > > So, here's a quick question. Is there a easy way/code to modify these > kinds of RDN? Its a little bit of extra work to have to go figure out > that a RDN is being changed and then go use modrdn. I would try a modrdn_s() call. Never used it with a multi-valued RDN before, though. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: [PATCH] RFC 3876 control (return values filter)
On Monday 16 July 2007 07:50:30 Michael Ströder wrote: > Andreas Hasenack wrote: > > On Thu, May 31, 2007 at 07:23:36PM -0300, Andreas Hasenack wrote: > >> I will still see about the decode part and then post what I have. > > > > Attached is my current patch. Keep in mind I did this basically using > > the current code as a template. > > I've committed this patch to CVS. I'd appreciate if you could also > provide a small script for Demo/. Thanks, I'll get you such a script soon. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: Experiments with pyasn1 and preread control
On Thu, Jul 19, 2007 at 01:21:07PM +0200, Michael Ströder wrote: > Hello Andreas, > > I've added your demo script to python-ldap's CVS as > Demo/pyasn1/prereadcontrol.py. I'd appreciate if you could implement the > decodeControlValue() method with pyasn1. I think that would be more difficult, there are lots of classes that would need to be created, I guess almost the entire LDAP specification :) I'll try something with openldap's internal functions, but last time I hit a rock because I needed the connection object to do that, and it wasn't available. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: Experiments with pyasn1 and preread control
On Thu, Jul 19, 2007 at 05:03:12PM +0200, Michael Ströder wrote: > Andreas Hasenack wrote: > > On Thu, Jul 19, 2007 at 01:21:07PM +0200, Michael Ströder wrote: > >> Hello Andreas, > >> > >> I've added your demo script to python-ldap's CVS as > >> Demo/pyasn1/prereadcontrol.py. I'd appreciate if you could implement the > >> decodeControlValue() method with pyasn1. > > > > I think that would be more difficult, there are lots of classes that > > would need to be created, I guess almost the entire LDAP specification > > :) > > Hmm...do you really think so? That was my impression when I first tried it. Since the control result is exactly like the ldap search result value, it means it can hold a lot of things. > > I'll try something with openldap's internal functions, but last time I > > hit a rock because I needed the connection object to do that, and it > > wasn't available. > > I'd be interested to implement support for the post-read control in > web2ldap because if you add/modify entries to OpenLDAP's back-config the > DNs may be modified (due to X-ORDERED). Does web2ldap have any special handling of the back-config entries? I find that using a regular ldap client to handle these entries is cumbersome (didn't try web2ldap: only lyma and gq so far). - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: [PATCH] RFC 3876 control (return values filter)
On Mon, Jul 16, 2007 at 12:50:30PM +0200, Michael Ströder wrote: > Andreas Hasenack wrote: > > On Thu, May 31, 2007 at 07:23:36PM -0300, Andreas Hasenack wrote: > >> I will still see about the decode part and then post what I have. > > > > Attached is my current patch. Keep in mind I did this basically using > > the current code as a template. > > I've committed this patch to CVS. I'd appreciate if you could also > provide a small script for Demo/. Sorry for the long wait. I'll get to it this weekend (tm). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: [PATCH] RFC 3876 control (return values filter)
On Friday 03 August 2007 13:20:50 Andreas Hasenack wrote: > On Mon, Jul 16, 2007 at 12:50:30PM +0200, Michael Ströder wrote: > > Andreas Hasenack wrote: > > > On Thu, May 31, 2007 at 07:23:36PM -0300, Andreas Hasenack wrote: > > >> I will still see about the decode part and then post what I have. > > > > > > Attached is my current patch. Keep in mind I did this basically using > > > the current code as a template. > > > > I've committed this patch to CVS. I'd appreciate if you could also > > provide a small script for Demo/. > > Sorry for the long wait. I'll get to it this weekend (tm). Attached. matchedvalues.py Description: application/python - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
start_tls = 2 is ignored with LDAP URIs starting with LDAP://
Hi,
I've found a strange behaviour of python-ldap when working with TLS encrypted
connections. I'm not sure if this is a problem of the python bindings or of
libldap or in my head ;-)
In my first scenario I was trying to set up a TLS encrypted connection with a
specific CA certificate that was set in the ldap.conf file (TLS_CACERT).
>>> import ldap
>>> l =
ldap.ldapobject.SmartLDAPObject(uri='LDAP://qamaster.windom2008.univention.test:389',
who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention',
start_tls=2, tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem')
>>> l.started_tls
0
In that case the connection is not encrypted. When I replace LDAP:// with
ldap:// in the URI the connection is encrypted.
>>> l =
ldap.ldapobject.SmartLDAPObject(uri='ldap://qamaster.windom2008.univention.test:389',
who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention',
start_tls=2, tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem')
>>> l.started_tls
1
It look likes a TLS connection is not set up if the URI starts with LDAP://
In the second scenario I've tried to set up a TLS encrypted connection with a
CA certificate that was not set in the ldap.conf file.
>>> l =
ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univention.test:389',
who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention',
start_tls=2,
tls_cacertfile='/etc/univention/connector/ad/ad_cert_20091221_153053.pem')
...
ldap.CONNECT_ERROR: {'info': 'error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed', 'desc': 'Connect error'}
It seems that the argument tls_cacertfile is ignored, because if I set the CA
certificate file with the set_option function the connection works and is
encrypted.
ldap.set_option(
ldap.OPT_X_TLS_CACERTFILE,
'/etc/univention/connector/ad/ad_cert_20091221_153053.pem' )
l =
ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univention.test:389',
who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention',
start_tls=2 )
>>> l.started_tls
1
software versions:
python 2.4.6
libldap 2.4.15
python-ldap 2.3.5
Is there any mistake in my reasoning or is this a known behaviour?
best regards
Andreas
--
Andreas Büsching
Open Source Software Engineer
Univention GmbH
Linux for your business
Mary-Somerville-Str.1
28359 Bremen
Tel. : +49 421 22232-0
Fax : +49 421 22232-99
http://www.univention.de
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876
signature.asc
Description: This is a digitally signed message part.
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Python-LDAP-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: start_tls = 2 is ignored with LDAP URIs starting with LDAP://
Hi,
Has anyone an idea?
thanx in advance
Andreas
Am Freitag 08 Januar 2010 09:39:40 schrieb Andreas Büsching:
> I've found a strange behaviour of python-ldap when working with TLS
> encrypted connections. I'm not sure if this is a problem of the python
> bindings or of libldap or in my head ;-)
>
> In my first scenario I was trying to set up a TLS encrypted connection with
> a specific CA certificate that was set in the ldap.conf file (TLS_CACERT).
>
> >>> import ldap
> >>> l =
>
> ldap.ldapobject.SmartLDAPObject(uri='LDAP://qamaster.windom2008.univention.
>test:389',
> who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='
>univention', start_tls=2,
> tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem')
>
> >>> l.started_tls
>
> 0
>
> In that case the connection is not encrypted. When I replace LDAP:// with
> ldap:// in the URI the connection is encrypted.
>
> >>> l =
>
> ldap.ldapobject.SmartLDAPObject(uri='ldap://qamaster.windom2008.univention.
>test:389',
> who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='
>univention', start_tls=2,
> tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem')
>
> >>> l.started_tls
>
> 1
>
> It look likes a TLS connection is not set up if the URI starts with LDAP://
>
> In the second scenario I've tried to set up a TLS encrypted connection with
> a CA certificate that was not set in the ldap.conf file.
>
> >>> l =
>
> ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univ
>ention.test:389',
> who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='u
>nivention', start_tls=2,
> tls_cacertfile='/etc/univention/connector/ad/ad_cert_20091221_153053.pem')
> ...
> ldap.CONNECT_ERROR: {'info': 'error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed', 'desc': 'Connect error'}
>
> It seems that the argument tls_cacertfile is ignored, because if I set the
> CA certificate file with the set_option function the connection works and
> is encrypted.
>
> ldap.set_option(
> ldap.OPT_X_TLS_CACERTFILE,
> '/etc/univention/connector/ad/ad_cert_20091221_153053.pem' ) l =
> ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univ
>ention.test:389',
> who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='u
>nivention', start_tls=2 )
>
> >>> l.started_tls
>
> 1
>
> software versions:
>
> python 2.4.6
> libldap 2.4.15
> python-ldap 2.3.5
>
> Is there any mistake in my reasoning or is this a known behaviour?
>
> best regards
> Andreas
--
Andreas Büsching
Open Source Software Engineer
Univention GmbH
Linux for your business
Mary-Somerville-Str.1
28359 Bremen
Tel. : +49 421 22232-0
Fax : +49 421 22232-99
http://www.univention.de
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876
Besuchen Sie uns auf der KOMCOM NORD in Hannover
vom 9.-10.02.2010 in der Eilenriedehalle, Stand H 03
signature.asc
Description: This is a digitally signed message part.
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Python-LDAP-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
Re: ldap.ldapobject.SmartLDAPObject removed
Hi Michael, Am Freitag 05 Februar 2010 13:34:32 schrieb Michael Ströder: > Michael Ströder wrote: > > Well, SmartLDAPObject is not well tested nor documented and should > > probably be removed anyway... > > [..] > > Well, tls_cacertfile is simply not used in SmartLDAPObject.__init__(). > > The reason is that OpenLDAP libs 2.3 were not able to set > > connection-specific SSL options. It should work with OpenLDAP 2.4 under > > some circumstances but I never got it working. > > > > => please either don't use SmartLDAPObject or contribute fixes for it > > Personally I'd vote for removing it. > > In CVS HEAD I've removed the untested and undocumented wrapper class > ldap.ldapobject.SmartLDAPObject completely. Upcoming release 2.3.11 will > not contain it anymore. It never worked robustly like intended and it's not > worth the effort to fix it. Thanx for the information. We will replace in SmartLDAPObject in one of our next releases of the software. best regards Andreas -- Andreas Büsching Open Source Software Engineer Univention GmbH Linux for your business Mary-Somerville-Str.1 28359 Bremen Tel. : +49 421 22232-0 Fax : +49 421 22232-99 http://www.univention.de Geschäftsführer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876 Besuchen Sie uns auf der KOMCOM NORD in Hannover vom 9.-10.02.2010 in der Eilenriedehalle, Stand H 03 signature.asc Description: This is a digitally signed message part. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Python-LDAP-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
