LDAP security settings - self update, hide password

[warmerdam]

The following script does *not* have permission to update the cn field for it's own user (even when the cred is set properly). But I think it should.

#!/usr/bin/env python

import ldap
import ldap.filter
import sys
import md5
import base64

server = 'ldap.osgeo.org'
who = 'uid=warmerdam,ou=People,dc=osgeo,dc=org'
cred = 'xx'

l = ldap.open(server)
l.simple_bind_s(who,cred)

l.modify_s( who, [ (ldap.MOD_REPLACE,'cn','NF Warmerdam') ] )

The /etc/openldap/slapd.conf uses the following permissions:

 access to *
        by self write
        by users read
        by anonymous auth

As I read the docs at:

​http://www.openldap.org/doc/admin23/slapdconfig.html#Access%20Control

This should do what we want, but somehow it isn't.

I'd add our current ldap permissions allow any authenticated user to read everything in ldap, including everyone elses encrypted password which is sufficient to authenticate as these other users. We should really add a pre-rule something like:

access to attr=userPassword
            by self write
            by anonymous auth
            by dn.base="cn=Manager,dc=osgeo,dc=org" write
            by * none

[tmitchell]

For the record, we need this to work so that Drupal users can edit/manage their attribute values (ldapdata module).

[warmerdam]

The authoritative slapd.conf reference docs for access at are:

​http://www.openldap.org/software/man.cgi?query=slapd.access

[martin]

access to attr=userPassword

by self write by anonymous auth by dn="cn=Manager,dc=osgeo,dc=osgeo" write by * none

access to *

by self write by dn="cn=Manager,dc=osgeo,dc=osgeo" write by users read

[hobu]

Replying to martin:

 access to attr=userPassword
         by self write
         by anonymous auth
         by dn="cn=Manager,dc=osgeo,dc=osgeo" write
         by * none
 access to * 
         by self write
         by dn="cn=Manager,dc=osgeo,dc=osgeo" write
         by users read

[hobu]

I have implemented the changes Martin suggested and restarted our LDAP instance. Frank, if you get a chance, can you confirm things behave as they should now?

[warmerdam]

A quick test shows the same error still occuring with the test script.

[warmerdam@osgeo1 ~]$ python test1.py
Traceback (most recent call last):
  File "test1.py", line 16, in ?
    l.modify_s( who, [ (ldap.MOD_REPLACE,'cn','NF Warmerdam') ] )
  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 299, in modify_s
    self.result(msgid,all=1,timeout=self.timeout)
  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 392, in result
    res_type,res_data,res_msgid = self.result2(msgid,all,timeout)
  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 398, in result2
    return self._ldap_call(self._l.result2,msgid,all,timeout)
  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 94, in _ldap_call
    result = func(*args,**kwargs)
ldap.INSUFFICIENT_ACCESS: {'info': '', 'desc': 'Insufficient access'}

[hobu]

Something isn't right with the authentication... I just committed to the MapServer instance and it didn't require a login ​http://trac.osgeo.org/mapserver/changeset/6090

[martin]

Howard, what is the current state of LDAP server configuration ?
The last state _I_ was aware is that you added the leading spaces back into the two access directives in order to make Trac work.
I'm sorry to say it this way: Having these leading spaces is wrong, apparently it makes acces control to the LDAP service a bit unpredictable. If Trac doesn't authenticate correctly with the leading spaces removed, then the LDAP connector in Trac has to get adjusted accordingly.
I don't have the slightest idea how LDAP authentication is done in Trac, but I'd probably find out :-)

[crschmidt]

Old.