python-ldap-dev

RE: Hanging during ldaps

[Goucher, A. <ada...@hp...>]

6360 is the correct port for this server (we have multiple servers using
various ports on that machine).

-adam

-----Original Message-----
From: charlie derr [mailto:cd...@si...]=20
Sent: Monday, January 05, 2004 1:22 PM
To: Goucher, Adam
Cc: pyt...@li...
Subject: Re: Hanging during ldaps


My first guess would be to use port 636 instead of 6360 -- if that=20
doesn't work, I'd next try leaving the port specification off entirely=20
(start_tls should encrypt traffic on port 389 if the server is=20
configured correctly).

	good luck,
		~c


Goucher, Adam wrote:
> I'm trying to use python-ldap to connect to an iplanet 5.1 ldap.=20
> Connecting via ldap:// works, but the script is hanging when=20
> connecting through ldaps://. Can anyone see what I am doing wrong?
>=20
> <script>
> import ldap
> ldap.set_option(ldap.OPT_DEBUG_LEVEL, 5)
>=20
> # build our uri
> uri =3D "ldaps://ldap_host:6360"
>=20
> # connect to the ldap server
> p_handle =3D ldap.initialize(uri)
> p_handle.protocol_version =3D ldap.VERSION3
>=20
> # bind
> p_handle.simple_bind("cn=3Ddirectory manager", "*****")
>=20
> # search so we know we are connected
> p_search =3D p_handle.search("", ldap.SCOPE_BASE, "objectclass=3D*")=20
> p_return =3D p_handle.result(p_search) res_type, res_values =3D =
p_return
> print res_values
> </script>
>=20
> <output>
> ldap_create
> ldap_url_parse_ext(ldaps://ldap_host:6360)
> ldap_bind
> ldap_simple_bind
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection
> ldap_int_open_connection
> ldap_connect_to_host: TCP ldap_host:6360
> ldap_new_socket: 1904
> ldap_prepare_socket: 1904
> ldap_connect_to_host: Trying ldap_ip:6360
> ldap_connect_timeout: fd: 1904 tm: -1 async: 0
> ldap_ndelay_on: 1904
> ldap_ndelay_off: 1904
> ldap_open_defconn: successful
> ldap_send_server_request
> ldap_search_ext
> put_filter: "objectclass=3D*"
> put_filter: default
> put_simple_filter: "objectclass=3D*"
> ldap_send_initial_request
> ldap_send_server_request
> ldap_result msgid 2
> ldap_chkResponseList for msgid=3D2, all=3D1
> ldap_chkResponseList for msgid=3D2, all=3D1
> ldap_int_select
> </ouput>
>=20
> I am using python 2.3.2 for windows, and the python-ldap module found=20
> at http://www.zope.org/Members/volkerw/LdapWin32.dsdfs
>=20
> ______________________________
> Adam Goucher
> Testing Group
> HP OpenView Select Access
> Hewlett-Packard
> 901 King St W.
> Toronto, Ontario
> M5V 3H5
>=20
> Phone: +1-416-309-5208
> Fax: +1-416-309-4406
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials. Become an=20
> expert in LINUX or just sharpen your skills.  Sign up for IBM's Free=20
> Linux Tutorials.  Learn everything from the bash shell to sys admin.=20
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> _______________________________________________
> Python-LDAP-dev mailing list Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>=20

RE: Hanging during ldaps

[Goucher, A. <ada...@hp...>]

> ># search so we know we are connected
> >p_search =3D p_handle.search("", ldap.SCOPE_BASE, "objectclass=3D*")
> > =20
> >
> This call looks strange to me: iPlanet has always wanted a real base=20
> there (i.e., no "" as you possibly could using Active=20
> Directory, but a=20
> correct search base for your server like "dc=3Dldapserver, dc=3Dacme,=20
> dc=3Dcom" or similar).
>=20
> If you say it does work using plain LDAP, however, this cannot be the=20
> reason for your script hanging, still I'm amazed it does, the RFC=20
> clearly states that you must explicitly set the search base=20
> and iPlanet=20
> have always prided themselves in being standards compliant (not like=20
> that other major software vendor ;-)

I have found that "" and an actual basename are two different items with
pretty much all directory servers I have used. Searching against "" will
return information about the server in general (such as the vendor and
version) whereas searching against a proper basename gives you site
specific information
=20
> I don't know this module, however you might want to give a try to my=20
> Win32 binary of Python-LDAP, you can find it at=20
> http://www.siosistemi.it/~mcicogni/ at the beginning of the=20
> page under=20
> "Python stuff".
> Beware, your mileage may vary.

Same problem, but a newer build, thanks. :)

> If this doesn't work, either, it *might* be that your server isn't=20
> configured correctly (i.e., TLS Certificates and such): do=20
> other LDAPS=20
> client work?

Yes, I can login with different client to the ssl port. Is there a TLS
FAQ kicking around somewhere? I keep seeing it used interchangeably with
SSL but don't know anything about it.

-adam

Re: Hanging during ldaps

[Mauro C. <mci...@li...>]

Goucher, Adam wrote:

>I have found that "" and an actual basename are two different items with
>pretty much all directory servers I have used. Searching against "" will
>return information about the server in general (such as the vendor and
>version) whereas searching against a proper basename gives you site
>specific information
>  
>
Aha. I'll try that.

>Yes, I can login with different client to the ssl port. Is there a TLS
>FAQ kicking around somewhere? I keep seeing it used interchangeably with
>SSL but don't know anything about it.
>
TLS and SSL are in fact different beasts, TLS being a superset of SSL 
but different enough to warrant a name change. Certificates should work 
interchangeably, since most of the differences should be in how the 
peers negotiate crypto algorithms for the asymmetric and symmetric 
parts. However, it's tricky stuff and I wouldn't be surprised that 
communication is stalling because client & server can't find a common 
algorithm or a cert isn't "right" or something.

I'm at a loss here, but I know there are some TLS/SSL tools that will 
allow you to kinda "debug" what's going on (I definitely saw a reference 
to one on the Netscape site).
You could also try firing up a Linux box, install Python and Python-LDAP 
and see what happens (the Linux build is much more solid and widely tested).

Mauro

Re: Hanging during ldaps

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

Mauro Cicognini wrote:
> 
> I'm at a loss here, but I know there are some TLS/SSL tools that will 
> allow you to kinda "debug" what's going on

openssl s_client -connect ldap_host:6360 ...

Ciao, Michael.

RE: Hanging during ldaps

[Goucher, A. <ada...@hp...>]

> Just guessing since you did not mention what "is hanging"=20
> means and you did=20
> not provide a Python traceback: You have to tell where to=20
> find the CA's=20
> certificate by calling
>=20
> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,path_to_cacert_file) or=20
> ldap.set_option(ldap.OPT_X_TLS_CACERTDIR,path_of_cacert_dir).

Using openssl's s_client it shows that the connection is doing TLS 1.0. =
Consequently, I tried to do exactly as is suggested and received the =
following.

Traceback (most recent call last):
  File "c:\temp\ads.py", line 3, in ?
    ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, "c:\temp\unicert.cer")
  File "C:\Python23\Lib\site-packages\ldap\functions.py", line 104, in =
set_option
    _ldap_function_call(_ldap.set_option,option,invalue)
  File "C:\Python23\Lib\site-packages\ldap\__init__.py", line 62, in =
_ldap_function_call
    result =3D apply(func,args,kwargs)
ldap.LDAPError: {'errnum': -1}

And the cert itself is pem encoded.

-adam

Re: Hanging during ldaps

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

Goucher, Adam wrote:
> 
> ldap.LDAPError: {'errnum': -1}

Hmm, I'm clueless here. Might be the Win32 binary of python-ldap.
Sorry, can't say anything about that.

Ciao, Michael.