python-ldap-dev — discussion among developers

Re: userPassword

[Hans A. <Han...@Ph...>]

On Wednesday, 3. April 2002 01:33, de...@il... wrote:
> Can someone give example code of setting a userPassword attribute to
> an encrypted password with python-ldap?

Hm, I dont know what exactly you want to do. Obviously, the encrypted 
password depends on the cryptographic hashing algorithmus you use 
(crypt, md5, sha1, etc). If you migrated your users from NIS, this is 
probably {crypt}. As far as I know, there exist different 
implementations of crypt, so that the result might be platform 
dependent.

Here comes the code:

import crypt
passwd = 'mysecret'
salt = "xy"
userPassword = '{crypt}' + crypt.crypt(passwd,salt)

And that's it. userPassword could then be used with the add() method of 
the ldap object. The salt string is a two character string and may be 
chosen at random (I'm not sure about this, anyway: sometimes it seems 
to be just the first two caracteres of the user name...). The salt is 
just the first two caracters of the encrypted password, so that it does 
not add security to the crypt algorithm.

Diclaimer: dealing with passwords (plaintext _and_ encrypted) is 
dangerous. Just be sure that you know what you are doing! Don't use 
ldap connections which are not protected by other means! 

Hope it helps,

Hans

-- 
Han...@Ph...

Re: userPassword

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

de...@il... wrote:
> Can someone give example code of setting a userPassword attribute to an 
> encrypted password with python-ldap?

Concerning userPassword attribute it's handy to read and understand the 
OpenLDAP FAQ-O-MATIC:

http://www.openldap.org/faq/data/cache/419.html

Once I've started to implement a module for doing the whole thing on various 
password attributes with different syntaxes but that's probably overkill for 
you.

Check the following files in tar.gz of http://www.web2ldap.de:
pylib/ldaputil/passwd.py
pylib/w2lapp/passwd.py

Ciao, Michael.

userPassword

[<de...@il...>]

Can someone give example code of setting a userPassword attribute to an 
encrypted password with python-ldap?

-- 
---
Dennis Sacks
de...@il...
"An idiot with a computer is a faster, better idiot." - Rick Julius

Re: How do do strong authentication on LDAP connection?

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

Dirksen Lau wrote:
>
> When I try the bind operation against our department LDAP server,
> I got this
> error: ldap.STRONG_AUTH_REQUIRED: {'desc': 'Strong authentication
> required',
> 'info': 'This LDAP server does not accept cleartext passwords'}

This means you have to authenticate by presenting a client certificate which
is done during establishing the SSL connection.

> How to do the strong authentication?

1. Make yourself familiar with concepts of SSL and client certificates.
2. Ask your LDAP server admin whether you have to use LDAP over SSL to
separate port or using StartTLS extended operation.
3. Look at Demo/initialize.py to get a idea of how to connect with
python-ldap using either one of the methods.
4. Have a client certificate and matching private key at
hand as "PEM files". You have to get a client certificate which validates
against a trusted root CA cert at the LDAP server. Ask your admin.
5. Use
ldap.set_option(ldap.OPT_X_TLS_CERTFILE,client_cert_file)
ldap.set_option(ldap.OPT_X_TLS_KEYFILE,client_key_file)
to point the python-ldap and OpenLDAP libs to the files to use for strong
authentication during opening the SSL connection.

Ciao, Michael.

Re: How do do strong authentication on LDAP connection?

[Jacek K. <ja...@bn...>]

On Sat, Mar 30, 2002 at 12:10:09PM +0800, Dirksen Lau wrote:
> How to do the strong authentication? 

There are two ways:

1. SSL/TLS
==========

Use thing like this (instead of your ldap_open or ldap_initialize):

l=ldap_initialize("ldaps://....");

This will work if your server listens on ldaps port.

If your server listens on ldap port only, but supports TLS, you use it:

l=ldap_initialize("ldap://....")
l.protocol_version=ldap.VERSION3
l.set_option(ldap.OPT_X_TLS,ldap.OPT_X_TLS_DEMAND)
l.start_tls_s()

2. SASL
========

This is not yet supported by python-ldap, but is being worked on.
SASL is a way of doing strong authentication even without encrypting the
whole sessions.

Greets,
        Jacek

How do do strong authentication on LDAP connection?

[Dirksen L. <dir...@po...>]

Hi,

When I try the bind operation against our department LDAP server, I got this error:
ldap.STRONG_AUTH_REQUIRED: {'desc': 'Strong authentication required', 'info': 'This LDAP server does not accept cleartext passwords'}

How to do the strong authentication? Do I need to encrypt the password befire calling bind_s? What encryption sheme? Does python have the relevant 
module? Please advice!

Cheers
Dirksen

Re: Error in LDAP Programming with Python v2.0.0pre04 PDF

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

Richard Holbert wrote:
> Now it looks like a problem in ldap_async.tex, and ldap_modlist.tex.
> 
> I deleted the \input{ldap_async} and \input{ldap_modlist} lines from 
> python-ldap.tex

Bingo!

Renamed ldap_async to ldap-async and ldap_modlist to ldap-modlist and it 
seems to work now.

I've commited the changes.

Ciao, Michael.

Re: Error in LDAP Programming with Python v2.0.0pre04 PDF

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

Jens Vagelpohl wrote:
> what i really like about the ZSI TeX sources is that they build with 
> just one small dependency on something created by the actual software 
> building process (version.tex), you don't have to execute any Makefiles 
> to create the docs.

I glanced over the ZSI doc sources and as far as I understand they are built 
  exactly the same way like the python-ldap docs. The Makefile looks 
somewhat cleaner.

\input{} is used to include the chapters (like also done in the Python docs).

 > that means i can load it into my favorite TeX
> editor/processor and build it in there without any problem.

Feel free to fix/clean-up the python-ldap TeX sources to make it loadable 
into your favorite TeX editor/processor.

Ciao, Michael.

Re: Error in LDAP Programming with Python v2.0.0pre04 PDF

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

what i really like about the ZSI TeX sources is that they build with just 
one small dependency on something created by the actual software building 
process (version.tex), you don't have to execute any Makefiles to create 
the docs. that means i can load it into my favorite TeX editor/processor 
and build it in there without any problem.

jens


On Friday, March 29, 2002, at 11:16 , Rich Salz wrote:

> I do not currently have convenient access to a Unix machine with the 
> Python source, but in a couple of days I should have my Linux box back 
> online.  I've written two python manuals -- for ZSI and wizard -- and 
> have basically got it down to a cookbook approach.  Take a look at those;
>  for example, you can find PS PDF and HTML for ZSI, generated from the 
> TeX input at http://www.zolera.com/opensrc/zsi
>
> If that's of interest, I can fix things up next week.
> 	/r$
>
>
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: Error in LDAP Programming with Python v2.0.0pre04 PDF

[Rich S. <r....@ve...>]

I do not currently have convenient access to a Unix machine with the 
Python source, but in a couple of days I should have my Linux box back 
online.  I've written two python manuals -- for ZSI and wizard -- and 
have basically got it down to a cookbook approach.  Take a look at 
those; for example, you can find PS PDF and HTML for ZSI, generated from 
the TeX input at http://www.zolera.com/opensrc/zsi

If that's of interest, I can fix things up next week.
	/r$

Re: Error in LDAP Programming with Python v2.0.0pre04 PDF

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

Richard Holbert wrote:
>>
>>>Still it does not compile. I'm lost with TeX...
>>
>>Uuumh, the problem is that my local ldap.tex gets overwritten after doing
>>make.
> 
> Mine too, I tried chmod 444 ldap.tex

It is not overwritten if I use \input{ldap}. What's the exact difference of 
\input{} and \include{}?

Ciao, Michael.

Re: Error in LDAP Programming with Python v2.0.0pre04 PDF

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

Michael Str=F6der wrote:
> Richard Holbert wrote:
>=20
>> I think we only need the includes for:
>>
>> ldap
>> ldap_async
>> ldap_modlist
>> ldif
>> and ldapurl
>=20
>  > The rest should remain as inputs.
>=20
> Ok, another commit.
 > [..]
> Still it does not compile. I'm lost with TeX...

Uuumh, the problem is that my local ldap.tex gets overwritten after doing=
 make.

Ciao, Michael.

Re: Error in LDAP Programming with Python v2.0.0pre04 PDF

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

Richard Holbert wrote:
> 
> Change input{} to include{}...

I've commited a modified python-ldap.tex. However it does not compile (see 
attached python-ldap.how). Not sure whether it was ok before...

Ciao, Michael.

Re: SASL (part 3)

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

Hans Aschauer wrote:
 > On Wednesday, 27. March 2002 15:42, Michael Str=F6der wrote:
 >
 > Could someone please give me a hand with the distutil
 > stuff?

It's far less struggle to add a module to a DistUtils package than you
believe. Have a look at ext_modules and py_modules list in setup.py to ge=
t
the idea. I will happily extend setup.py.

 >>Make sure to place it in a different sub-module - at least the Python
 >>interface part for it.
 >
 > At the moment, I have no plans for an high-level python interface. Wha=
t
 > I plan to do (and have paritally done) is a simple wrapper for the C
 > functions in ldap_schema (i.e. str2objectclass and friends).

You can provide very primitive C wrapper functions in module _ldap and le=
ave
the Python parts up to me (applies to SASL and schema). I will start with=

the SASL stuff this weekend and check in what I believe the Python parts
should look like.

 > Is it ok to just plug these wrappers into function.c?

Please go for a separate C source schema.c. The C code is already kludgy
enough. Maybe take template.c as a start.

 > Probably it would be necessary to plug this into the
 > Lib/ldap/functions.py mechanism, right?

I'd suggest to write a new Python wrapper class in a separate module
ldap.schema (Lib/ldap/schema.py). The class methods could also contain so=
me
sanitizing (say Pythonizing ;-) which is more convenient to implement in
Python itself.

  > I am not really sure if the
  > underlying C functions are thread safe...

  From my knowledge about OpenLDAP I'm almost sure they're not. That's wh=
at
the module-wide thread lock is for.

Ciao, Michael.

Re: Error in LDAP Programming with Python v2.0.0pre04 PDF

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

Richard Holbert wrote:
> I hope this makes since.  It looks like there are three copies of the body of 
> the document in the document.

I know. I already asked for Latex support on the list.

> Maybe I can help.  Where can I find the tex source for this document?

Best bet is to directly check out from CVS:
http://sourceforge.net/cvs/?group_id=2072

Web-Interface:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Doc/

Your help's appreciated!

Ciao, Michael.

Error in LDAP Programming with Python v2.0.0pre04 PDF

[Richard H. <hol...@os...>]

I hope this makes since.  It looks like there are three copies of the body of 
the document in the document.

Maybe I can help.  Where can I find the tex source for this document?

Sincerely,

Rick

Re: SASL (part 3)

[Joe L. <jl...@op...>]

I'll be happy to package it up and do some rudimentary tests. I don't have
effective code at this point to use the schema stuff, and nothing in the wa=
y
of SASL support.=20

As to dist-utils.. I'm as uninitiated as the next fellow when it comes to
DistUtils.. but I'll help where I can.

On 3/27/02 7:34 AM, "Hans Aschauer" <Han...@Ph...>
wrote:

> On Wednesday, 27. March 2002 15:42, Michael Str=F6der wrote:
>=20
>> No problem to give you write access to the CVS tree. But please don't
>> check this in as is.
>=20
> Ack.
>=20
>> I need some time to comment. I hope to get back this easter weekend.
>> Up to now I just had the chance to glance over it. E.g. I'd like to
>> see an own class for SASL mechanisms in a separate sub-module
>> ldap.sasl.
>=20
> That's fine. Could someone please give me a hand with the distutil
> stuff? (Joe?)=20
>=20
> [...]
>=20
> [schema support]
>=20
>> Make sure to place it in a different sub-module - at least the Python
>> interface part for it.
>=20
> At the moment, I have no plans for an high-level python interface. What
> I plan to do (and have paritally done) is a simple wrapper for the C
> functions in ldap_schema (i.e. str2objectclass and friends). Is it ok
> to just plug these wrappers into function.c? Saves some hazzles with
> distutlis...=20
>=20
> Probably it would be necessary to plug this into the
> Lib/ldap/functions.py mechanism, right? I am not really sure if the
> underlying C functions are thread safe...
>=20
>=20
> For example:
>=20
> ------------------------------------------------------------------------
> import ldap
>=20
> a =3D ldap.str2objectclass("(2.5.6.4 NAME 'organization' SUP top
> STRUCTURAL MUST o MAY ( userPassword $ searchGuide $ seeAlso $
> businessCategory $ x121Address $ registeredAddress $
> destinationIndicator $ preferredDeliveryMethod $ telexNumber $
> teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $
> facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
> postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )")
>=20
> print a
> ------------------------------------------------------------------------
>=20
> returns
>=20
> ------------------------------------------------------------------------
> ['2.5.6.4', ['organization'], '', 0, ['top'], 1, ['o'],
> ['userPassword', 'searchGuide', 'seeAlso', 'businessCategory',
> 'x121Address', 'registeredAddress', 'destinationIndicator',
> 'preferredDeliveryMethod', 'telexNumber', 'teletexTerminalIdentifier',
> 'telephoneNumber', 'internationaliSDNNumber',
> 'facsimileTelephoneNumber', 'street', 'postOfficeBox', 'postalCode',
> 'postalAddress', 'physicalDeliveryOfficeName', 'st', 'l',
> 'description']]
> ------------------------------------------------------------------------
>=20
> The fields are=20
>=20
> 1. oid
> 2. List of names
> 3. Description string
> 4. Obsolete flag
> 5. List of SUP oid's
> 6. "kind" flag (0=3DABSTRACT, 1=3DSTRUCTURAL, 2=3DAUXILIARY)
> 7. list of "must" attributes
> 8. list of "may" attributes
>=20
> BTW. does anybody know what the LDAPSchemaExtensionItem is about?
>=20
> Hans

Re: SASL (part 3)

[Hans A. <Han...@Ph...>]

On Wednesday, 27. March 2002 15:42, Michael Ströder wrote:

> No problem to give you write access to the CVS tree. But please don't
> check this in as is.

Ack.

> I need some time to comment. I hope to get back this easter weekend.
> Up to now I just had the chance to glance over it. E.g. I'd like to
> see an own class for SASL mechanisms in a separate sub-module
> ldap.sasl.

That's fine. Could someone please give me a hand with the distutil 
stuff? (Joe?) 

[...]

[schema support]

> Make sure to place it in a different sub-module - at least the Python
> interface part for it.

At the moment, I have no plans for an high-level python interface. What 
I plan to do (and have paritally done) is a simple wrapper for the C 
functions in ldap_schema (i.e. str2objectclass and friends). Is it ok 
to just plug these wrappers into function.c? Saves some hazzles with 
distutlis... 

Probably it would be necessary to plug this into the 
Lib/ldap/functions.py mechanism, right? I am not really sure if the 
underlying C functions are thread safe...


For example:

------------------------------------------------------------------------
import ldap

a = ldap.str2objectclass("(2.5.6.4 NAME 'organization' SUP top 
STRUCTURAL MUST o MAY ( userPassword $ searchGuide $ seeAlso $ 
businessCategory $ x121Address $ registeredAddress $ 
destinationIndicator $ preferredDeliveryMethod $ telexNumber $ 
teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ 
facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ 
postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )")

print a
------------------------------------------------------------------------

returns

------------------------------------------------------------------------
['2.5.6.4', ['organization'], '', 0, ['top'], 1, ['o'], 
['userPassword', 'searchGuide', 'seeAlso', 'businessCategory', 
'x121Address', 'registeredAddress', 'destinationIndicator', 
'preferredDeliveryMethod', 'telexNumber', 'teletexTerminalIdentifier', 
'telephoneNumber', 'internationaliSDNNumber', 
'facsimileTelephoneNumber', 'street', 'postOfficeBox', 'postalCode', 
'postalAddress', 'physicalDeliveryOfficeName', 'st', 'l', 
'description']]
------------------------------------------------------------------------

The fields are 

1. oid
2. List of names
3. Description string
4. Obsolete flag
5. List of SUP oid's
6. "kind" flag (0=ABSTRACT, 1=STRUCTURAL, 2=AUXILIARY)
7. list of "must" attributes
8. list of "may" attributes

BTW. does anybody know what the LDAPSchemaExtensionItem is about?

Hans

-- 
Han...@Ph...

Re: SASL (part 3)

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

Hans Aschauer wrote:
 > On Tue, Mar 26, 2002 at 19:14, Jacek Konieczny wrote:
 >
 >>On Tue, Mar 26, 2002 at 02:34:49PM +0100, Hans Aschauer wrote:
 >
 > [...]
 >
 >
 >>>However, if you think it should go into 2.0, it is
 >>>fine for me and I will try my best ;-)

SASL should be in 2.0 final release.

  >>> Anyway: how would I get
 >>>write access to CVS?
 >>
 >>Ask Michael.
 >
 > Michael, would it be ok for you to give me write access to CVS?

No problem to give you write access to the CVS tree. But please don't check
this in as is.

I need some time to comment. I hope to get back this easter weekend. Up to
now I just had the chance to glance over it. E.g. I'd like to see an own
class for SASL mechanisms in a separate sub-module ldap.sasl.

 > If so:
 > should patches be announced on this list before submitting them to CVS?

Yes, I think so. People have the chance to glance over it and comment.
Development in CVS should not have much rough edges at the moment.

 > Somewhat related: I started writing a (simplistic) wrapper for
 > ldap_schema.h, which will do rootDSE schema string parsing. In fact,
 > the parsing of the schema description is done by libldap (so there is
 > no need for a home-brew parser which has to be tested). I think it will
 > be finished by the end of next week.

Great!

Make sure to place it in a different sub-module - at least the Python
interface part for it.

Ciao, Michael.

Re: SASL (part 3)

[Hans A. <Han...@Ph...>]

On Tue, Mar 26, 2002 at 19:14, Jacek Konieczny wrote:
> On Tue, Mar 26, 2002 at 02:34:49PM +0100, Hans Aschauer wrote:

[...]

> > However, if you think it should go into 2.0, it is
> > fine for me and I will try my best ;-) Anyway: how would I get
> > write access to CVS?
>
> Ask Michael.

Michael, would it be ok for you to give me write access to CVS? If so: 
should patches be announced on this list before submitting them to CVS? 

Somewhat related: I started writing a (simplistic) wrapper for 
ldap_schema.h, which will do rootDSE schema string parsing. In fact, 
the parsing of the schema description is done by libldap (so there is 
no need for a home-brew parser which has to be tested). I think it will 
be finished by the end of next week.

Hans

-- 
Han...@Ph...

Re: SASL (part 3)

[Jacek K. <ja...@bn...>]

On Tue, Mar 26, 2002 at 02:34:49PM +0100, Hans Aschauer wrote:
> Jacek,
> 
> > Seems very nice. I hope it will be soon commited to CVS, as we really
> > need SASL support.
> 
> I am not sure if this should be commited before 2.0. You know, this is 
> first time I do something SASL related, and first time that I hack 
> python-C bindings. 
The SASL code doesn't seem to break anything else. It an be IMHO marked
as "experimental" even in official release if required. But I think it's
Michael who should decide. He did most of the work recently, so he is
the boss here :-) And the stable and working relase of python-ldap is
also a think we need very much.

> However, if you think it should go into 2.0, it is 
> fine for me and I will try my best ;-) Anyway: how would I get write 
> access to CVS? 
Ask Michael.

> > But there are some things, that should be fixed:
> >
> > - it seems comments about SASL support in LDAPObject.c are outdated
> >   they still describe "callback-function" interface
> >
> > - I found now way to set realm for my bind so I wasn't able to bind
> > to my server. Realms are important feature of SASL, so there should
> > be an easy way to set them. Probably as another optional argument to
> > sasl_digest_md5
This is not true. CB_GETREALM works as it should. I don't know why it
didn't worked for me the first time I tried this.

> > - SASL_CB_... constants should probably be defined in constants.c
> > file, as other constants. The only problem is that these constants
> > are sasl-related, not ldap-related, but I cannot think about any
> > better place. When implemented them in C they are defined from the
> > good source: C header files
> >
> > - classes sasl... should be moved out of the demo to ldap package,
> > maybe to separate module
> 
> I think that I will have a few hours mid next-week in order to 
> fix/change/modify these things. Thanks!

Great :-)

Greets,
        Jacek

PS.
  I Cc to the list and didn't cut quotes, because these are parts of my
original message, which was intended to go here, but by my mistake it
was only sent to Hans.

SASL (part 3)

[Hans A. <Han...@Ph...>]

Its me again :-)

I have something usable now, as I think. The interface looks like this:
-------------------------8<----------------------------
import ldap
# from sasl import sasl_digest_md5  # XXX  

l = ldap.initialize("ldap://localhost/")
auth = sasl_digest_md5("aschauer","secret")
l.sasl_bind_s("", auth)
res = l.search_s("dc=myorg,dc=com", ldap.SCOPE_ONELEVEL,
                 "objectclass=*")
print res
l.unbind()
-------------------------8<-------------------------

Comments?

The interesting part is the sasl_digest_md5 class, that handles the 
SASL callbacks (source attached, also for sasl_gssapi and, as a base 
class, a generic sasl class). 

The diff is against cvs (made with "cvs diff"). 

If anybody wants to test it and needs assistance with setting things 
up, feel free to contact me.

Hans

-- 
Han...@Ph...

SASL binds (part 2)

[Hans A. <Han...@Ph...>]

Hi all,

Ooops, the sources I sent last time did not even compile. Sorry. I 
should really try if things complile after adding comments ;-)

I think I am getting closer to something usable. SASL binds should work 
now for different mechanisms. A short demo:

----------------------------8<-------------------------------
import ldap

# For documentation, see Module/LDAPObject.c
def callback(id, challenge, prompt, defresult):
    print "id=%d, challenge=%s, prompt=%s, defresult=%s" % \
          (id, challenge, prompt, defresult)
    if id == 16386: # XXX these constants are defined in sasl.h 
        return "aschauer"
    
    if id == 16388:
        return "secret" # this is the sasl password in sasldb
    return ""

l = ldap.initialize("ldap://localhost/")


l.sasl_bind_s("","DIGEST-MD5", callback)
res = l.search_s("dc=theorie,dc=physik,dc=uni-muenchen,dc=de",
                 ldap.SCOPE_SUBTREE,
                 "objectclass=*")

print res

l.unbind()
----------------------------8<-------------------------------

I do not like the callback interface. Should use something more clever 
(perhaps an instance of a sasl object should be passed, which handles 
the callback internally, and also defines the mechanism string).


Hans

-- 
Han...@Ph...

Re: SASL binds

[Hans A. <Han...@Ph...>]

Am Montag, 11. März 2002 12:43 schrieb Michael Ströder:
Ooops, forgot the attachment...


-- 
Han...@Ph...

Re: SASL binds

[Hans A. <Han...@Ph...>]

Am Montag, 11. März 2002 12:43 schrieb Michael Ströder:

> Best bet is that you send your patches to the list and we'll see...

Ok, I'm sending the modified files (not patches since I'm not sure if I 
still have the originals around). Still a mess, but I removed the 
dependency on liblutil.a (makes it simpler to compile, as you don't 
need the sources for openldap). Works only with gssapi, as the requirde 
callbacks for other mechanisms are not really implemented: for other 
mechanisms, you see only printf's, and the program segfaults 
afterwards, because interact->reslut and so on is filled with rubbish. 
The mechanisms which one can try depend on the installation of sasl 
(have a look at /usr/lib/sasl/).

In order to compile it, you will need the sasl and sasl-devel packages. 
setup.cfg takes care of the libsasl linking.

Hans

-- 
Han...@Ph...