[turba] LDAP uid not same as real uid

Mark Worsdall turba at worsdall.demon.co.uk
Fri Feb 17 16:44:30 PST 2006


In message <20060217151938.rz2o6j1bj4o8kowk at marina.horde.org>, Chuck
Hagenbuch <chuck at horde.org> writes
>Quoting Mark Worsdall <turba at worsdall.demon.co.uk>:
>
>> How can I stop turba doing this in the shared directory sources.php ldap
>> section?
>
>Turba needs the __uid field for tracking objects globally across vCard
>imports, Palm syncs, etc. You need to map that to a field in your LDAP
>server that is not your uid field.

So if I create a field in the LDAP server called uidhorde and the
original uid will remain the userid of the account?

I wiped the ldap 1st and recreated it and all has gone wrong.


The turba/config/source.php:

$cfgSources['localldap'] = array(
    'title' => _("Shared Directory (Address book:ldap)"),
    'type' => 'ldap',
    'params' => array(
        'server' => 'thoth.shadow.local',
        'tls' => false,
        'root' => 'dc=shadowrobot,dc=com',
        'bind_dn' => 'cn=admin,dc=shadowrobot,dc=com',
        'bind_password' => 'adminsecret',
        'sizelimit' => 200,
        'dn' => array('cn'),
        'objectclass' => array('top',
                               'person',
                               'organizationalPerson','inetOrgPerson'),
        'scope' => 'one',
        'charset' => 'iso-8859-1',
        'checkrequired' => false,
        'checkrequired_string' => ' ',
        'version' => 3
    ),
    'map' => array(
        '__key' => 'dn',
        '__uid' => 'uid',


and in the /etc/ldap/slapd.conf:

access to dn.children="ou=person,dc=shadowrobot,dc=com"
        attrs=entry,objectClass,mail,telephoneNumber,
        mobiletelephonenumber,title,organizationname,
        businesscategory,postaladdress,postalcode,
        telephonenumber,facsimiletelephonenumber,
        homepostaladdress,homephone,description,ou,displayName,
        labeledURI,calFBURL
        by dn="cn=admin,ou=DSA,dc=shadowrobot,dc=com" read
        by self read
        by * none



Added accounts, this one is for myself with addldap successfully:

dn: uid=jdw,dc=shadowrobot,dc=com
uid: jdw
cn: Mark Worsdall
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: secret
shadowLastChange: 13193
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1010
gidNumber: 1010
homeDirectory: /home/jdw



Trouble is they all show up in the shared ldap when they did not before.

So I added

'filter' => '(&(uid=*)(objectClass=posixAccount))',

But now I get nothing but 1 empty value and one with a Q none of which
do anything if you click on them.

So I rem'ed it out and the list of accounts is back. If I edit one of
these posixAccounts and save it I get the error:


There was an error updating this entry: Failed to change name: (65)
Object class violation; Old DN = uid=jg,dc=shadowrobot,dc=com, New DN =
cn=Mark Worsdall, Root = dc=shadowrobot,dc=com


I can add a new entry fine and the new entry has the uid problem, but
not worried about the remap just yet, more worried whats gone wrong?

M.
-- 
Mark Worsdall
http://www.shadowrobot.com/  need a hand??


More information about the turba mailing list