python-ldap-dev — discussion among developers

RE: ldap.passwd_s with Active Direcory

[<Mik...@op...>]

> -----Original Message-----
> From: Michael Ströder [mailto:mi...@st...]
> Sent: 06 August 2009 00:49
> To: Mike Peters
> Cc: pyt...@li...
> Subject: Re: ldap.passwd_s with Active Direcory
> 
> Mik...@op... wrote:
> > *** ldaps://ad01.demo.local:636 - SimpleLDAPObject.simple_bind
> ((u'user@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@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

Re: SASL GSSAPI under Win32

[Jeroen M. <jmi...@ya...>]

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 <wal...@gm...>
To: Michael Ströder <mi...@st...>
Cc: pyt...@li...
Sent: Thursday, 6 August, 2009 5:07:08
Subject: Re: SASL GSSAPI under Win32

2009/8/5 Michael Ströder <mi...@st...>:
> 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.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Python-LDAP-dev mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev



      

Re: SASL GSSAPI under Win32

[Waldemar O. <wal...@gm...>]

2009/8/5 Michael Ströder <mi...@st...>:
> 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.

Re: SASL GSSAPI under Win32

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

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.

Re: ldap.passwd_s with Active Direcory

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

Mik...@op... wrote:
> *** ldaps://ad01.demo.local:636 - SimpleLDAPObject.simple_bind ((u'user@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@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.

Re: SASL GSSAPI under Win32 (was: Connection to AD on windows)

[Waldemar O. <wal...@gm...>]

2009/8/5 Michael Ströder <mi...@st...>:
> 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

RE: ldap.passwd_s with Active Direcory

[<Mik...@op...>]

> -----Original Message-----
> From: Michael Ströder [mailto:mi...@st...]
> Sent: 05 August 2009 16:11
> To: Mike Peters
> Cc: pyt...@li...
> Subject: Re: ldap.passwd_s with Active Direcory
> 
> Mik...@op... 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@ADDEMO', u'secret')
*** ldaps://ad01.demo.local:636 - SimpleLDAPObject.simple_bind ((u'user@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))

---------------------------------------------------------------------------
UNWILLING_TO_PERFORM                      Traceback (most recent call last)

/home/django/pplace/<ipython console> in <module>()

/usr/lib/python2.5/site-packages/ldap/ldapobject.pyc in modify_s(self, dn, modlist)
    326   def modify_s(self,dn,modlist):
    327     msgid = self.modify(dn,modlist)
--> 328     return self.result(msgid,all=1,timeout=self.timeout)
    329 
    330   def modrdn(self,dn,newrdn,delold=1):

/usr/lib/python2.5/site-packages/ldap/ldapobject.pyc in result(self, msgid, all, timeout)
    426         polling (timeout = 0), in which case (None, None) is returned.
    427     """
--> 428     res_type,res_data,res_msgid = self.result2(msgid,all,timeout)
    429     return res_type,res_data
    430 

/usr/lib/python2.5/site-packages/ldap/ldapobject.pyc in result2(self, msgid, all, timeout)
    430 
    431   def result2(self,msgid=_ldap.RES_ANY,all=1,timeout=None):
--> 432     res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout)
    433     return res_type, res_data, res_msgid
    434 

/usr/lib/python2.5/site-packages/ldap/ldapobject.pyc in result3(self, msgid, all, timeout)
    436     if timeout is None:
    437       timeout = self.timeout
--> 438     ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout)
    439     if ldap_result is None:
    440       rtype, rdata, rmsgid, decoded_serverctrls = (None,None,None,None)

/usr/lib/python2.5/site-packages/ldap/ldapobject.pyc in _ldap_call(self, func, *args, **kwargs)
     94     try:
     95       try:
---> 96         result = func(*args,**kwargs)
     97       finally:
     98         self._ldap_object_lock.release()

UNWILLING_TO_PERFORM: {'info': '0000052D: SvcErr: DSID-031A0FC0, problem 5003 (WILL_NOT_PERFORM), data 0\n', 'desc': 'Server is unwilling to perform'}

Does the encoded password look right?

Thanks

Mike Peters

SASL GSSAPI under Win32 (was: Connection to AD on windows)

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

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 <module>
>     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.

Re: ldap.passwd_s with Active Direcory

[Russell J. <ra...@cs...>]

Mik...@op... wrote:
>> -----Original Message-----
>> From: Michael Ströder [mailto:mi...@st...]
>> Sent: 04 August 2009 18:23
>> To: Mike Peters
>> Cc: pyt...@li...
>> Subject: Re: ldap.passwd_s with Active Direcory
>>
>> Mik...@op... 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 <ra...@cs...>
Network Analyst
California State University, Bakersfield

Excellent day to have a rotten day.

Connection to AD on windows

[Jeroen M. <jmi...@ya...>]

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 <module>
    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!



      

Re: ldap.passwd_s with Active Direcory

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

Mik...@op... 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.

RE: ldap.passwd_s with Active Direcory

[<Mik...@op...>]

> -----Original Message-----
> From: Michael Ströder [mailto:mi...@st...]
> Sent: 04 August 2009 18:23
> To: Mike Peters
> Cc: pyt...@li...
> Subject: Re: ldap.passwd_s with Active Direcory
> 
> Mik...@op... 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

Re: How to verify server certificate

[Fredrik M. <mel...@df...>]

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.

Re: ldap.passwd_s with Active Direcory

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

Mik...@op... 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.

RE: ldap.passwd_s with Active Direcory

[<Mik...@op...>]

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:mi...@st...]
> Sent: 04 August 2009 17:29
> To: Mike Peters
> Cc: pyt...@li...
> Subject: Re: ldap.passwd_s with Active Direcory
> 
> Mik...@op... 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.

Re: ldap.passwd_s with Active Direcory

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

Mik...@op... 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.

Re: How to verify server certificate

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

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.

ldap.passwd_s with Active Direcory

[<Mik...@op...>]

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 

Re: How to verify server certificate

[Fredrik M. <mel...@df...>]

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

Re: How to verify server certificate

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

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.

How to verify server certificate

[Fredrik M. <mel...@df...>]

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

Re: Python-LDAP for Python 3.0

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

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/pyt...@li.../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.

Problem with md5_digest on MS AD

[Petr Z. <ze...@em...>]

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

Python-LDAP for Python 3.0

[David L. <le...@us...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
I have been looking at how to build the _ldap module for python3.x.
It's a pretty straightforward binary port except for one major headache
with strings. <br>
<br>
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. <br>
<br>
These are my goals with the _ldap module:<br>
<ul>
  <li>allow Python 2.x clients to keep working without changes</li>
  <li>dual environment support: both 2.x and 3.x build environments<br>
  </li>
</ul>
First, the easy one: int() is gone in 3.x. The _ldap module uses int
objects to return asynchronous message IDs, and to define a bunch of
constants. In Python 3.0 longs look and act just like old ints but with
more precision, so there should be few, if any, visible problem with
regard to this change in the _ldap API. (Unless you are relying on
overflow effects, which sounds suspicious anyway.)<br>
<br>
<blockquote><i>1. Python-ldap compiled for 2.x should continue to use
int for Message IDs and constants, but when compiled for 3.x will use
longs.</i><br>
</blockquote>
<br>
Next, and much harder to deal with is <a
 href="http://docs.python.org/dev/3.0/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit">the
loss of str()</a>. There is heavy reliance of str() objects by _ldap to
hold binary data, for attribute values. But, Python 3.0 does not have
an 8-bit str(). It has what 2.x used to called unicode(). For 8-bit
data we have a new type called bytes(). The issue is that conversion
between the two is not automatic.<br>
<br>
For existing LDAP applications, I expect this to open up a world of
porting pain. This is because lots of actual attribute values are ASCII
and having the values available in a string type has been a very handy
convenience. But, strictly, it is wrong. LDAP attribute values are
binary OCTET STRINGs, and in the unicode-only text world of Python 3.x,
applications that want text will need to decode these binary strings in
accordance with the attribute's <i>schema</i>. This problem is
something I'd like feedback on.<br>
<br>
Yet there is some good news. The text/binary problem appears to be
restricted just to attribute values and to some authentication
parameters like SASL passwords. Unaffected are attribute names, DNs and
search filters. This is because they are transmitted as the ASN.1
LDAPString type, which is a UTF-8 encoded OCTET STRING. So it makes
sense for the _ldap API to accept unicode strings for these. But,
attribute values (OCTET STRING) surely must become bytes().<br>
<br>
Using the bytes() type is going to cause much pain with potentially
lots of "<tt>TypeError: Can't convert 'bytes' object to str implicitly</tt>"
messages everywhere. But, it seems that this is part-and-parcel of
porting to Python 3.x. If you really need strings, learn the encoding
types of your attributes and call <tt>str(value, "UTF-8")</tt> or <tt>str(value,
"ASCII")</tt> to convert them.<br>
<br>
So, my other proposed API changes are:<br>
<br>
<blockquote><i>2. Python-ldap compiled for 2.x should continue to
accept and produce strings as before.<br>
3. When compiled for 3.x, </i><i>values that are UTF-8 LDAPString on
the wire (</i><i>attribute names, DNs, search filters, etc) should be
passed in and out as (unicode) strings. Attribute value data, and other
places where BER binary values are passed, should be passed in and out
as bytes(). There should be no automatic conversion between bytes() and
unicode str().<br>
  </i></blockquote>
<br>
A library class that automatically converts attribute values of type
bytes() into various python types via an attribute schema is possible,
but at the _ldap level this is not necessary. It may even be better for
an application tightly coupled to an LDAP schema to do this conversion
itself.<br>
<br>
In summary, python-ldap should have no API change visible to 2.x
clients. But, 3.x clients should need to use the bytes() type
explicitly for attribute values.<br>
<br>
d<br>
<br>
</body>
</html>

Re: Typo error in Demo/Lib/ldap/async/deltree.py (2.3.9)

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

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.