python-ldap-dev — discussion among developers

Re: Why LDAPObject.._ldap_object_lock around library calls?

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

Ken Key wrote:
> 
> I need to have two threads, a Producer and Consumer (relative to LDAP),
 > [..]
> translates the results into
> a form my proxy protocol and puts it on the work result Queue.

I probably don't understand what you're after. However I try to give some 
answers.

>>According to related postings on the OpenLDAP lists libldap_r is
>>re-entrant
>>on a per-connection basis. Therefore linking with libldap_r improves the
>>situation since a finer-grained locking is used in LDAPObject class (see
>>method _ldap_lock()).
> 
> However, the lock is still across all methods of an instance of the
> LDAPObject, and thus in force for all operations on the connection,
> across all threads.  That's the problem.

Your threads should use different LDAP connections thus LDAPObject instances.

> I was trying to determine if there were reasons beyond the
> underlying binary OpenLDAP client libraries that the locking was in
> place.

The OpenLDAP libs are the problem. Nothing in python-ldap requires the locks.

>  If not, I was thinking of overriding the _ldap_call() in
> my own class and eliminating it, since the ldap_r is a requirement
> for my proxy's environment.

Don't do this! The OpenLDAP libs are not re-entrant within one connection 
context. See OpenLDAP mailings list archives for details.

Ciao, Michael.

Re: Why LDAPObject.._ldap_object_lock around library calls?

[Ken K. <key...@KS...>]

Ah, I found the answer to my question.  Since we store the thread
state in the LDAPObject instance, the object cannot be shared between
my two threads.

I tossed together a prototype of the two-thread model I was thinking of.
With the LDAPObject._ldap_lock in place, I got the deadlock I was
afraid of.  When I removed the _ldap_lock.acquire/release in
_ldap_call() I got the "saving thread twice?" fatal error from the
LDAP_BEGIN_ALLOW_THREADS() when the second thread makes the second
function call.

This message may arrive out-of-order with my original reply, sorry
about that.  I forgot to reset my From: line.

Cheers,
K^2

Re: How to get msgid from ldap.result() call?

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

Michael Str=F6der wrote:
> Ken Key wrote:
>=20
>>  It is not a complete fix, as I still
>> need to go through the rest of the code to change the result()
>> return handling to deal with the 3 element tuple.
>> [..]
>> I'll work up a more complete patch in a couple of days.=20
>=20
> Don't worry. I'll work that out.

I've checked in your patch with modifications to ldap.ldapobject (see bel=
ow).

Modules/:
* New method result2() returns 3-tuple containing the msgid
   of the outstanding operation

ldap.ldapobject:
* LDAPObject.result2() (see above).
   LDAPObject.result() uses LDAPObject.result2().

Ciao, Michael.

Re: python-ldap

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

pn...@ma... wrote:
> 
> I then tried to compile it from the tar.gz file. However, that complains 
> of not finding a file that is suppose to be located within the directory 
> of the extracted python-ldap directory. Did you forget to include 
> Lib/ldap.py and schema.py in the Lib directory?

See item 6. on http://python-ldap.sourceforge.net/faq.shtml

> what is the long term support of LDAP within Python?

See item 1. on http://python-ldap.sourceforge.net/faq.shtml

You're welcome to join the mailing list (Cc:-ed - rather low-traffic).

Ciao, Michael.

Re: Why LDAPObject.._ldap_object_lock around library calls?

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

Ken Key wrote:
> 
>   I'm having a little trouble with the _ldap_object_lock in the
> LDAPObject around ldap library function calls.

Which trouble do you have?

>  Is the link
> to protect against threads making function calls when the _ldap
> module is linked against the non-reentrant version of the libldap?
> That is, wouldn't it be safe to get rid of the _ldap_object_lock
> references in LDAPObject._ldap_call() if the module is linked
> against libldap_r?  Or is there some other, non-threadsafe reason
> that I'm missing?

According to related postings on the OpenLDAP lists libldap_r is re-entrant 
on a per-connection basis. Therefore linking with libldap_r improves the 
situation since a finer-grained locking is used in LDAPObject class (see 
method _ldap_lock()).

Note that proper support for libldap_r also depends on the version of the 
OpenLDAP libs used.

Ciao, Michael.

Why LDAPObject.._ldap_object_lock around library calls?

[Ken K. <key...@KS...>]

Hi Folks,

  I'm having a little trouble with the _ldap_object_lock in the
LDAPObject around ldap library function calls.  Is the link
to protect against threads making function calls when the _ldap
module is linked against the non-reentrant version of the libldap?
That is, wouldn't it be safe to get rid of the _ldap_object_lock
references in LDAPObject._ldap_call() if the module is linked
against libldap_r?  Or is there some other, non-threadsafe reason
that I'm missing?

Thanks for any info,
K^2

Re: How to get msgid from ldap.result() call?

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

Ken Key wrote:
> 
> I've attached the diff below to the change I was testing in
> Modules/LDAPObject.c.

Thanks a lot.

>  It is not a complete fix, as I still
> need to go through the rest of the code to change the result()
> return handling to deal with the 3 element tuple.
> [..]
> I'll work up a more complete patch in a couple of days. 

Don't worry. I'll work that out.

> Honestly,
> I half expected this idea to be rejected.  Won't changing this
> return value break any 3rd party code that uses ldap.result()
> when they crack out the elements of the return tuple?

I will probably preserve result() as is and provide a second method 
result2() or similar with class ldap.ldapobject.LDAPObject which returns the 
complete 3-tuple.

Ciao, Michael.

Re: How to get msgid from ldap.result() call?

[Ken K. <key...@KS...>]

>>  In looking
>> through the sources, it appears the information is never preserved.
>> I locally hacked my copy of LDAPObject.c to make ldap.result()
>> return a 3-part tuple of (result_type, result_data, result_msgid),
>> where result_msgid = ldap_msgid(msg) after the msg was determined
>> to be good.
>
> Please provide a patch.

I've attached the diff below to the change I was testing in
Modules/LDAPObject.c.  It is not a complete fix, as I still
need to go through the rest of the code to change the result()
return handling to deal with the 3 element tuple.  The hack was just
a quick proof of concept change to see if I could get my proxy
server to work.

I'll work up a more complete patch in a couple of days.  Honestly,
I half expected this idea to be rejected.  Won't changing this
return value break any 3rd party code that uses ldap.result()
when they crack out the elements of the return tuple?  I must
confess that I am new to Python (and LDAP), so perhaps I'm
asking a stupid question.

>>  I need the message ID to match up the reply with the
>> originating request context.
>
> This would also be very handy for a completely async LDAPObject
> implementation which dispatches results to calling threads without having
> to
> use thread locks around each _ldap call.

I think I follow that, but it's a bit over my head. I'm just looking
for a way to lookup the client who's proxy request this reply was for.

Regards,
K^2

Re: How to get msgid from ldap.result() call?

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

Ken Key wrote:
> 
>     when calling ldap.result(msgid=ldap.RES_ANY) on several
> outstanding async client requests in python-ldap 2.0.0pre21, I
> cannot find a way to get the received message ID.

In current implementation the msgid is not passed to the calling application.

>  In looking
> through the sources, it appears the information is never preserved.
> I locally hacked my copy of LDAPObject.c to make ldap.result()
> return a 3-part tuple of (result_type, result_data, result_msgid),
> where result_msgid = ldap_msgid(msg) after the msg was determined
> to be good.

Please provide a patch.

>  I need the message ID to match up the reply with the
> originating request context.

This would also be very handy for a completely async LDAPObject 
implementation which dispatches results to calling threads without having to 
use thread locks around each _ldap call.

Ciao, Michael.

How to get msgid from ldap.result() call?

[Ken K. <key...@KS...>]

Hi Folks,

    when calling ldap.result(msgid=ldap.RES_ANY) on several
outstanding async client requests in python-ldap 2.0.0pre21, I
cannot find a way to get the received message ID.  In looking
through the sources, it appears the information is never preserved.
I locally hacked my copy of LDAPObject.c to make ldap.result()
return a 3-part tuple of (result_type, result_data, result_msgid),
where result_msgid = ldap_msgid(msg) after the msg was determined
to be good.  I need the message ID to match up the reply with the
originating request context.

Am I missing something?  Is there already a way to retreive the
msgid that I missed?

Thanks for any info,
K^2

Re: referrals

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

Jerome Alet wrote:
> On Sat, Apr 10, 2004 at 12:10:49AM +0200, Michael Str=F6der wrote:
>=20
>>Think about these aspects:
>>
>>Which bind information (method, username or bind-DN, credentials) to us=
e at=20
>>the referred server?
>=20
> isn't the information returned a complete LDAP url with all necessary
> information ?

Nope.

1. There's nothing in a LDAP URL containing bind method or SASL auth=20
information.

2. It's probably not a good idea to put credentials (e.g. passwords) in a=
=20
LDAP URL.

Ciao, Michael.

Re: referrals

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

Jerome Alet wrote:
> 
 > I'd prefer my program to ignore the LDAP
 > architecture of the particular site, since it must work on
 > many different ones.

I can understand this goal (see web2ldap) but...

> I just want my software to deal with a single LDAP server at any 
> time, and if for a particular operation python-ldap receives 
> informations telling it that another server should be asked for this 
> operation instead, then I'd really like python-ldap to do all the 
> dirty work automatically for me,

Think about these aspects:

Which bind information (method, username or bind-DN, credentials) to use at 
the referred server?

Should the application continue to use the referred server after referral 
has been received or switch back to the original server?
(Hint: Think about referrals being knowledge references to other parts of 
the DIT vs. your master-slave scenario.)

You can believe me: I already thought about various aspects. I never came up 
with some ideas I was really confident it will work in a generic way.

Ciao, Michael.

Re: referrals

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

Jerome Alet wrote:
> 
> In my particular case, my application just binds to a slave server 
> and reads datas successfully, but whenever I do an add or a modify, 
> or a delete, I want to either have python-ldap rebind to the master 
> (as hinted by the slave server it seems) and do the modification 
> there instead of on the slave, or receive an exception with its 
> arguments containing the master server's url and any other 
> interesting information needed to have my own code do another bind 
> and the modifications I wanted to do in the first place. 
> 
> No sure it is very clear. Summarised it could be : do all reads from 
> the slave and all writes to the master.

Well, if your master providing write access is always the same server I 
don't see a need to use referrals at all. ;-)

Ciao, Michael.

Re: referrals

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

First note that your From: address did not match your subscriber address. 
Thus I had to manually approve your posting. Please post with your 
subscriber address as From:.

Derrick 'dman' Hudson wrote:
> 
> My experience, thus far, is that very few applications actually handle
> referrals.
> [..]
> It was a rather disappointing discovery when setting up the fallback
> server.

The point is that handling of referrals is not something you can solve in a 
generic way because referrals are used for achieving different goals. Unless 
you provide more information about what you want to achieve in *your* 
specific setup I can't give any real advice.

Ciao, Michael.

Re: ldap.sasl.gssapi example?

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

Gavin Doughtie wrote:
> Does the example below work on your system (or anybody else's on this 
> list?)

Yes, it simply works.

Due to my local setup without DNS I have to use kinit --no-addresses when 
obtaining the TGT.

After running the program I also have a ticket for the LDAP service.

$ klist
Credentials cache: FILE:/tmp/krb5cc_500
         Principal: mi...@ST...

   Issued           Expires          Principal
Apr  9 21:51:00  Apr 10 07:51:00  krbtgt/STR...@ST...
Apr  9 21:51:02  Apr 10 07:51:00  ldap/loc...@ST...

Ciao, Michael.

Re: ldap.sasl.gssapi example?

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

paul k wrote:
> Gavin Doughtie wrote:
> 
>> Does the example below work on your system (or anybody else's on this 
>> list?)
> 
> Your code looks strange to me

His code is taken from Demo/sasl_bind.py and is correct.

> auth = ldap.sasl.gssapi("")

ldap.sasl.gssapi is just a primitive convenience wrapper class around 
ldap.sasl.sasl for GSSAPI.

Ciao, Michael.

Re: ldap.sasl.gssapi example?

[paul k <pa...@su...>]

Gavin Doughtie wrote:

> Does the example below work on your system (or anybody else's on this 
> list?)
Your code looks strange to me but I'm by no means an expert here. I can 
confirm that if I set my hostname and change digest-md5 to gssapi in the 
provided sasl_bind.py from the Demo directory, SASL GSSAPI binds work 
fine against Openldap 2.2.8 with SASL 2.1.17 and both MIT kerberos 1.3.1 
and a current heimdal snapshot from late march. Python Versions are 
2.2.3 and 2.3.3, python-ldap is pre19, system is linux 2.6

######### code from sasl_bind.py ##################
import ldap, ldap.sasl

l = ldap.initialize("ldap://localhost")
auth = ldap.sasl.gssapi("")
l.sasl_bind_s("", auth)


res = l.search_s("dc=nil,dc=b17",ldap.SCOPE_BASE,"(objectClass=*)")
print res

l.unbind()

#########    results     #########################
nil python-test # python sasl_bind.py
SASL/GSSAPI authentication started
SASL username: root@B17
SASL SSF: 56
SASL installing layers
[('dc=nil,dc=b17', {'objectClass': ['top', 'dcObject', 'domain', 
'domainRelatedObject'], 'associatedDomain': ['nil.b17'], 'dc': ['nil']})]

hth
  Paul

Re: ldap.sasl.gssapi example?

[Gavin D. <gdo...@an...>]

Does the example below work on your system (or anybody else's on this lis=
t?)

This is the example I've been using to test sasl_bind with a little clean=
up.
-------------------- 8< -----------------------------------
# For documentation, see comments in Module/LDAPObject.c and the
# ldap.sasl module documentation.

import traceback
import sys
import ldap,ldap.sasl

ldap.sasl._trace_level=3D0

ldap.set_option(ldap.OPT_DEBUG_LEVEL,0)

############### CHANGE THIS TO YOUR SERVER ##################
MY_LDAP_SERVER =3D "ldap://put.your.server.url.here/"

for ldap_uri,sasl_mech,sasl_cb_value_dict in [
     (
     MY_LDAP_SERVER,
     'GSSAPI',
     {
       ldap.sasl.CB_AUTHNAME    :'',
       ldap.sasl.CB_PASS        :'',
     }
     ),
]:
   sasl_auth =3D ldap.sasl.sasl(sasl_cb_value_dict,sasl_mech)
   print 20*'*',sasl_auth.mech,20*'*'
   # Open the LDAP connection
   l =3D ldap.initialize(ldap_uri,trace_level=3D1)
   # Set protocol version to LDAPv3 to enable SASL bind!
   l.protocol_version =3D ldap.VERSION3
   try:
     l.sasl_interactive_bind_s("", sasl_auth)
   except ldap.LDAPError,e:
     print 'Error using SASL mechanism ', sasl_auth.mech,str(e),=20
sys.exc_info()
     traceback.print_tb(sys.exc_info()[2])
   else:
     print 'Sucessfully bound using SASL=20
mechanism',sasl_auth.mech,'as',repr(l.whoami_s())
   l.unbind()


-------------------- 8< -----------------------------------

Michael Str=F6der wrote:
> Gavin Doughtie wrote:
>  > Here's the complete scoop:
>  > [..]
>  > Name        : krb5-workstation             Relocations: (not=20
> relocateable)
>  > [..]
>  > URL         : http://web.mit.edu/kerberos/www/
>=20
> It seems you're using the MIT Kerberos implementation which is known to=
=20
> have some issues with OpenLDAP (mainly cause it's not thread-safe). In=20
> opposite to that I'm using the heimdal implementation.
>=20
> http://www.pdc.kth.se/heimdal/
>=20
> As I said I do not have much experience with Kerberos. It simply works=20
> for me. It seems I can't really help with your setup.
>=20
> Ciao, Michael.
>=20

--=20
Gavin Doughtie
DreamWorks SKG
(818) 695-3821

Re: ldap.sasl.gssapi example?

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

Gavin Doughtie wrote:
 > Here's the complete scoop:
 > [..]
 > Name        : krb5-workstation             Relocations: (not relocateable)
 > [..]
 > URL         : http://web.mit.edu/kerberos/www/

It seems you're using the MIT Kerberos implementation which is known to have 
some issues with OpenLDAP (mainly cause it's not thread-safe). In opposite 
to that I'm using the heimdal implementation.

http://www.pdc.kth.se/heimdal/

As I said I do not have much experience with Kerberos. It simply works for 
me. It seems I can't really help with your setup.

Ciao, Michael.

Re: ldap.sasl.gssapi example?

[Gavin D. <gdo...@an...>]

Here's the complete scoop:

marlin [~/src/mod/python/users](SHARK)(90)> rpm -qi krb5-workstation
Name        : krb5-workstation             Relocations: (not relocateable=
)
Version     : 1.2.7                             Vendor: (none)
Release     : 14                            Build Date: Wed 13 Aug 2003=20
03:33:05 PM PDT
Install Date: Thu 25 Mar 2004 09:36:58 AM PST      Build Host:=20
tuna.anim.dreamworks.com
Group       : System Environment/Base       Source RPM:=20
krb5-1.2.7-14.src.rpm
Size        : 1229404                          License: MIT, freely=20
distributable.
Signature   : DSA/SHA1, Wed 12 Nov 2003 01:33:16 PM PST, Key ID=20
c4e64780ae5317ff
URL         : http://web.mit.edu/kerberos/www/
Summary     : Kerberos 5 programs for use on workstations.
Description :
Kerberos is a network authentication system. The krb5-workstation
package contains the basic Kerberos programs (kinit, klist, kdestroy,
kpasswd) as well as kerberized versions of Telnet and FTP. If your
network uses Kerberos, this package should be installed on every
workstation.
marlin [~/src/mod/python/users](SHARK)(91)> rpm -qi cyrus-sasl
Name        : cyrus-sasl                   Relocations: (not relocateable=
)
Version     : 2.1.15                            Vendor: Red Hat, Inc.
Release     : 3                             Build Date: Thu 21 Aug 2003=20
12:27:29 PM PDT
Install Date: Thu 25 Mar 2004 09:38:29 AM PST      Build Host:=20
daffy.perf.redhat.com
Group       : System Environment/Libraries   Source RPM:=20
cyrus-sasl-2.1.15-3.src.rpm
Size        : 534045                           License: Freely Distributa=
ble
Signature   : DSA/SHA1, Wed 24 Sep 2003 11:11:29 AM PDT, Key ID=20
219180cddb42a60e
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://asg.web.cmu.edu/sasl/sasl-library.html
Summary     : The Cyrus SASL library.
Description :
The cyrus-sasl package contains the Cyrus implementation of SASL.
SASL is the Simple Authentication and Security Layer, a method for
adding authentication support to connection-based protocols.
marlin [~/src/mod/python/users](SHARK)(92)> kinit --no-addresses
kinit: invalid option -- -
kinit: invalid option -- n
kinit: invalid option -- o
kinit: invalid option -- -
kinit: invalid option -- a
kinit: invalid option -- d
kinit: invalid option -- d
Bad lifetime value esses
Usage: kinit [-5] [-4] [-V] [-l lifetime] [-s start_time]
         [-r renewable_life] [-f | -F] [-p | -P] [-A]
         [-v] [-R] [-k [-t keytab_file]]
         [-c cachename] [-S service_name] [principal]

     options:                                          valid with Kerbero=
s:
         -5 Kerberos 5 (available)
         -4 Kerberos 4 (available)
            (Default behavior is to try Kerberos 5)
         -V verbose                                        Either 4 or 5
         -l lifetime                                       Either 4 or 5
         -s start time                                     5
         -r renewable lifetime                             5
         -f forwardable                                    5
         -F not forwardable                                5
         -p proxiable                                      5
         -P not proxiable                                  5
         -A do not include addresses                       5
         -v validate                                       5
         -R renew                                          5, or both 5=20
and 4
         -k use keytab                                     5, or both 5=20
and 4
         -t filename of keytab to use                      5, or both 5=20
and 4
         -c Kerberos 5 cache name                          5
         -S service                                        5, or both 5=20
and 4
marlin [~/src/mod/python/users](SHARK)(93)> kinit -A
Password for gdo...@AN...:
marlin [~/src/mod/python/users](SHARK)(94)> python sasl
sasl_bind.py~  sasl_bind.py
marlin [~/src/mod/python/users](SHARK)(94)> python sasl_bind.py
******************** GSSAPI ********************
*** ldap://etzadaat.anim.dreamworks.com:389/ -=20
SimpleLDAPObject.set_option ((17, 3),{})
*** ldap://etzadaat.anim.dreamworks.com:389/ -=20
SimpleLDAPObject.set_option ((17, 3),{})
*** ldap://etzadaat.anim.dreamworks.com:389/ -=20
SimpleLDAPObject.sasl_interactive_bind_s (('', <ldap.sasl.sasl instance=20
at 0xb6e8110c>, None, None),{})
Error using SASL mechanism  GSSAPI {'desc': 'Local error'} (<class=20
ldap.LOCAL_ERROR at 0xb73fa4dc>, <ldap.LOCAL_ERROR instance at=20
0xb6e811ec>, <traceback object at 0xb6e85f54>)
   File "sasl_bind.py", line 72, in ?
     l.sasl_interactive_bind_s("", sasl_auth)
   File "/usr/local/lib/python2.3/site-packages/ldap/ldapobject.py",=20
line 196, in sasl_interactive_bind_s
     return=20
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,serverctrls,clie=
ntctrls)
   File "/usr/local/lib/python2.3/site-packages/ldap/ldapobject.py",=20
line 94, in _ldap_call
     result =3D func(*args,**kwargs)
*** ldap://etzadaat.anim.dreamworks.com:389/ -=20
SimpleLDAPObject.unbind_ext ((None, None),{})


Michael Str=F6der wrote:
> Gavin Doughtie wrote:
>=20
>> OK, here's the result from running my modified sasl_bind.py (below):
>>
>> marlin [~/src/mod/python/users](SHARK)(55)> kinit
>> Password for gdo...@AN...:
>=20
>=20
> Could you please try with
>=20
> kinit --no-addresses
>=20
>> Error using SASL mechanism  GSSAPI {'desc': 'Local error'}
>=20
>=20
> Hmm, really no 'info' field?
>=20
> What Kerberos lib are you using?
>=20
> I'm using heimdal 0.6 and cyrus-sasl 2.1.15 shipped with my SuSE 9.0=20
> system.
>=20
> If anything goes wrong there's a message in the 'info' field containing=
=20
> also Kerberos-related text.
>=20
> Ciao, Michael.

--=20
Gavin Doughtie
DreamWorks SKG
(818) 695-3821

Re: ldap.sasl.gssapi example?

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

Gavin Doughtie wrote:
> OK, here's the result from running my modified sasl_bind.py (below):
> 
> marlin [~/src/mod/python/users](SHARK)(55)> kinit
> Password for gdo...@AN...:

Could you please try with

kinit --no-addresses

> Error using SASL mechanism  GSSAPI {'desc': 'Local error'}

Hmm, really no 'info' field?

What Kerberos lib are you using?

I'm using heimdal 0.6 and cyrus-sasl 2.1.15 shipped with my SuSE 9.0 system.

If anything goes wrong there's a message in the 'info' field containing also 
Kerberos-related text.

Ciao, Michael.

Re: ldap.sasl.gssapi example?

[Gavin D. <gdo...@an...>]

OK, here's the result from running my modified sasl_bind.py (below):

marlin [~/src/mod/python/users](SHARK)(55)> kinit
Password for gdo...@AN...:
marlin [~/src/mod/python/users](SHARK)(56)> klist
Ticket cache: FILE:/tmp/krb5cc_3501
Default principal: gdo...@AN...
=20
=20

Valid starting     Expires            Service principal
04/07/04 10:36:46  04/07/04 20:36:46=20
krbtgt/ANI...@AN...
=20
=20

=20
=20

Kerberos 4 ticket cache: /tmp/tkt3501
klist: You have no tickets cached
marlin [~/src/mod/python/users](SHARK)(57)> python ./sasl_bind.py
******************** GSSAPI ********************
*** ldap://etzadaat.anim.dreamworks.com:389/ -=20
SimpleLDAPObject.set_option ((17, 3),{})
*** ldap://etzadaat.anim.dreamworks.com:389/ -=20
SimpleLDAPObject.set_option ((17, 3),{})
*** ldap://etzadaat.anim.dreamworks.com:389/ -=20
SimpleLDAPObject.sasl_interactive_bind_s (('', <ldap.sasl.sasl instance=20
at 0xb6e8110c>, None, None),{})
Error using SASL mechanism  GSSAPI {'desc': 'Local error'} (<class=20
ldap.LOCAL_ERROR at 0xb73fa4dc>, <ldap.LOCAL_ERROR instance at=20
0xb6e811ec>, <traceback object at 0xb6e85f54>)
   File "./sasl_bind.py", line 72, in ?
     l.sasl_interactive_bind_s("", sasl_auth)
   File "/usr/local/lib/python2.3/site-packages/ldap/ldapobject.py",=20
line 196, in sasl_interactive_bind_s
     return=20
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,serverctrls,clie=
ntctrls)
   File "/usr/local/lib/python2.3/site-packages/ldap/ldapobject.py",=20
line 94, in _ldap_call
     result =3D func(*args,**kwargs)
*** ldap://etzadaat.anim.dreamworks.com:389/ -=20
SimpleLDAPObject.unbind_ext ((None, None),{})
marlin [~/src/mod/python/users](SHARK)(58)>

------------------------------------------------- code ----------
# For documentation, see comments in Module/LDAPObject.c and the
# ldap.sasl module documentation.

import traceback
import sys
import ldap,ldap.sasl

ldap.sasl._trace_level=3D0

ldap.set_option(ldap.OPT_DEBUG_LEVEL,0)

for ldap_uri,sasl_mech,sasl_cb_value_dict in [
     (
     "ldap://etzadaat.anim.dreamworks.com:389/",
     'GSSAPI',
     {
       ldap.sasl.CB_AUTHNAME    :'',
       ldap.sasl.CB_PASS        :'',
     }
     ),
#   (
#     "ldap://localhost:1390/",
#     'CRAM-MD5',
#     {
#       ldap.sasl.CB_AUTHNAME    :'fred',
#       ldap.sasl.CB_PASS        :'secret',
#     }
#   ),
#   (
#     "ldap://localhost:1390/",
#     'PLAIN',
#     {
#       ldap.sasl.CB_AUTHNAME    :'fred',
#       ldap.sasl.CB_PASS        :'secret',
#     }
#   ),
#   (
#     "ldap://localhost:1390/",
#     'LOGIN',
#     {
#       ldap.sasl.CB_AUTHNAME    :'fred',
#       ldap.sasl.CB_PASS        :'secret',
#     }
#   ),
#   (
#     "ldapi://%2Ftmp%2Fopenldap-socket/",
#     'EXTERNAL',
#     { }
#   ),
#   (
#     "ldap://localhost:1390/",
#     'GSSAPI',
#     { }
#   ),
#   (
#     "ldap://localhost:1390/",
#     'DIGEST-MD5',
#     {
#       ldap.sasl.CB_AUTHNAME    :'fred',
#       ldap.sasl.CB_PASS        :'secret',
#     }
#   ),
]:
   sasl_auth =3D ldap.sasl.sasl(sasl_cb_value_dict,sasl_mech)
   print 20*'*',sasl_auth.mech,20*'*'
   # Open the LDAP connection
   l =3D ldap.initialize(ldap_uri,trace_level=3D1)
   # Set protocol version to LDAPv3 to enable SASL bind!
   #l.protocol_version =3D 3
   l.protocol_version =3D ldap.VERSION3
   try:
     l.sasl_interactive_bind_s("", sasl_auth)
   except ldap.LDAPError,e:
     print 'Error using SASL mechanism ', sasl_auth.mech,str(e),=20
sys.exc_info()
     traceback.print_tb(sys.exc_info()[2])
   else:
     print 'Sucessfully bound using SASL=20
mechanism',sasl_auth.mech,'as',repr(l.whoami_s())
   l.unbind()

--------------------------------------------- end code ----------

Michael Str=F6der wrote:
> Gavin Doughtie wrote:
>  > ldap.LOCAL_ERROR: {'desc': 'Local error'}
>=20
> Can you please catch the exception and display it using str()? See=20
> Demo/sasl_bind.py.
>=20
> I'm experimenting with GSSAPI right now but currently I'm getting:
>=20
> Error using SASL mechanism GSSAPI {'info': 'SASL(-1): generic failure:=20
> GSSAPI Error:  Miscellaneous failure (see text) (Incorrect net=20
> address)', 'desc': 'Local error'}
>=20
> Ciao, Michael.

--=20
Gavin Doughtie
DreamWorks SKG
(818) 695-3821

Re: referrals

[Derrick 'd. H. <dma...@dm...>]

On Wed, Apr 07, 2004 at 09:52:44AM +0200, Michael Str=C3=B6der wrote:

| >>Jerome Alet wrote:
| >>>Is there some code example somewhere on how to deal with them ?

| You could try to let the OpenLDAP libs handle the referral by setting:
|=20
| ldap.set_option(ldap.OPT_REFERRALS,1)

I tried this.

(actually, I wrote
    ldap.set_option(ldap.OPT_REFERRALS, ldap.LDAP_OPT_ON)
 instead of using a literal integer.)

| Note that referral handling in OpenLDAP libs is considered to be broken.

Indeed, it didn't work.


My experience, thus far, is that very few applications actually handle
referrals.=20
    gq:         no
    web2ldap:   yes
    imp/horede: no
    python-ldap/libldap2:   no      (not automatically, as noted above)

It was a rather disappointing discovery when setting up the fallback
server.

-D

--=20
"He is no fool who gives up what he cannot keep to gain what he cannot lose=
=2E"
    --Jim Elliot
=20
www: http://dman13.dyndns.org/~dman/            jabber: dm...@dm....=
org

Re: ldap.sasl.gssapi example?

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

Michael Str=F6der wrote:
>=20
> I'm experimenting with GSSAPI right now=20

It seems to work for me. Since I'm not a Kerberos expert I can't provide =

more detailed help.

It seems to also depend on the interface's IP address. I succeeded by=20
fetching the TGT with

kinit --no-addresses michael

Note that you should really dig into the issues with your local=20
configuration! Simply doing copy&paste of such a kinit command above coul=
d=20
lead to security issues!

Anyone else here who has more insights?

Ciao, Michael.

Re: ldap.sasl.gssapi example?

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

Gavin Doughtie wrote:
 > ldap.LOCAL_ERROR: {'desc': 'Local error'}

Can you please catch the exception and display it using str()? See 
Demo/sasl_bind.py.

I'm experimenting with GSSAPI right now but currently I'm getting:

Error using SASL mechanism GSSAPI {'info': 'SASL(-1): generic failure: 
GSSAPI Error:  Miscellaneous failure (see text) (Incorrect net address)', 
'desc': 'Local error'}

Ciao, Michael.