python-ldap-dev — discussion among developers

Re: SASL GSSAPI under Win32

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

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.

Re: SASL GSSAPI under Win32

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

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.

Re: SASL GSSAPI under Win32

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

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.

Re: SASL GSSAPI under Win32

[Torsten K. <pyt...@tk...>]

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.

Re: SASL GSSAPI under Win32

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

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.

Re: SASL GSSAPI under Win32

[Torsten K. <pyt...@tk...>]

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 -

Re: SASL GSSAPI under Win32

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

On Wed, Aug 19, 2009 at 11:25 AM, Torsten
Kurbad<pyt...@tk...> 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

Re: SASL GSSAPI under Win32

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

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.

Re: SASL GSSAPI under Win32

[Torsten K. <pyt...@tk...>]

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.

Re: Expired server certificate

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

> 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 <o=myorg,dc=net> 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

Re: SASL GSSAPI under Win32

[Torsten K. <pyt...@tk...>]

> 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

Re: SASL GSSAPI under Win32

[Torsten K. <pyt...@tk...>]

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

Re: SASL GSSAPI under Win32

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

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 "<pyshell#13>", line 1, in <module>
    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.

Re: SASL GSSAPI under Win32

[Torsten K. <pyt...@tk...>]

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

Re: python-ldap, modlist and base64

[Jens V. <je...@da...>]

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

python-ldap, modlist and base64

[Matias S. <mat...@gm...>]

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.

Re: Expired server certificate

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

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.

Expired server certificate

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

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

Re: SASL GSSAPI under Win32

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

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.

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

[Torsten K. <pyt...@tk...>]

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

Re: Internal Attributs

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

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.

Re: Internal Attributs

[Nicolas E. <ne...@li...>]

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 !!?????)

Re: Internal Attributs

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

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.

Internal Attributs

[Nicolas E. <ne...@li...>]

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.

Re: ldap.passwd_s with Active Direcory

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

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