[Zimbra LDAP] secundaire groepen?

[teigetjuh]

Ik ben bezig met een zimbra-implementatie en de ldap die bij zimbra meegeinstalleerd wordt, moet tevens ook voor een andere server dienst gaan doen. Een van de dingen die vanuit de ldap geregeld moet gaan worden is de mogelijkheid tot sudo. Dit is mij al eerder wel gelukt, maar op de een of andere manier gaat er nu iets niet zoals het hoort.
Als ik een gebruiker in 2 of meer groepen plaats, krijg ik enkel en alleen de primaire groep te zijn met id of met id -a.

code:

id -a test
uid=2003(test) gid=2001(personeel) groups=2001(personeel)

als ik een getent group doe, zie ik wel de uid bij de juiste groepen.

code:

personeel:*:2001:
webadmin:*:2002:
serveradmin:*:2003:2003

Ik krijg geen usernames te zien vanuit de ldap. (Dit verbaast mij eigenlijk wel een beetje)
Ik kan met de gebruiker wel inloggen, maar die krijgt dus niet de secundaire groepen mee.
Iemand enig idee waar dit probleem ontstaat?
Ik heb al gezocht, maar de meeste zimbra en ldap problemen lijken voor te komen uit de koppeling met samba. Iets wat niet zal gebeuren. Mogelijk dat ik verkeerd zoek....

Nog wat info:
OS: Ubuntu 8.04 LTS 64-bit
Software: Zimbra CS 6.0.2 Open Source editie

[_JGC_]

Hoe plaats je een gebruiker in meerdere groepen, wil ik die ldap objects daarvan wel eens zien. Wat betreft je getent group: die vind ik er maar vreemd uitzien, voor een group in /etc/passwd zie ik bijvoorbeeld deze output:

storage:x:95:hal,jan
Ik zie nergens uidNumbers opgegeven worden.

[teigetjuh]

Voor de groepen en gebruiker die in passwd staan zie ik dus ook de namen en niet de nummers.
De ldap objecten? als in met een ldapsearch:

code:

$ /opt/zimbra/openldap/bin/ldapsearch -b "ou=groups,dc=<bedrijf>,dc=nl" -v -x -H ldap://mail.<bedrijf>.nl -D cn=config -W

ldap_initialize( ldap://mail.<bedrijf>.nl:389/??base )
Enter LDAP Password:
filter: (objectclass=*)
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base <ou=groups,dc=<bedrijf>,dc=nl> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# groups, <bedrijf>.nl
dn: ou=groups,dc=<bedrijf>,dc=nl
ou: groups
objectClass: organizationalRole
cn: groups

# personeel, groups, <bedrijf>.nl
dn: cn=personeel,ou=groups,dc=<bedrijf>,dc=nl
gidNumber: 2001
objectClass: posixGroup
description: Iedereen
cn: personeel

# webadmin, groups, <bedrijf>.nl
dn: cn=webadmin,ou=groups,dc=<bedrijf>,dc=nl
gidNumber: 2002
objectClass: posixGroup
cn: webadmin
description: Website administrators
memberUid: 2001

# serveradmin, groups, <bedrijf>.nl
dn: cn=serveradmin,ou=groups,dc=<bedrijf>,dc=nl
gidNumber: 2003
objectClass: posixGroup
cn: serveradmin
description: Gebruikers die root moegen worden via sudo
memberUid: 2001
memberUid: 2003

# search result
search: 2
result: 0 Success

# numResponses: 5
# numEntries: 4

Ik heb enkel de bedrijfsnaam uitgefilterd. Als er iets anders tevoorschijn moet komen hoor ik het graag.
Zou het kunnen dat er misschien iets tussen ldap en pam/nss niet lekker loopt?

[_JGC_]

Probeer eens met namen ipv nummers bij MemberUid. Een uid is een gebruikersnaam, een uidNumber is het ID wat daarbij hoort.

[Rainmaker]

En verander je "root" username even.

cn=config is niet handig, omdat dat ook een base is.

cn=Manager oid is wat unieker.

En bij mij is memberUid inderdaad ook de naam van de gebruiker, niet de uid. Eigenlijk best verwarrend Maar als ik in de schemas kijk (openldap 2.3), zie ik inderdaad dat memberUid een "IA5 String" is in plaats van een integer.

[teigetjuh]

_JGC_ schreef op maandag 26 oktober 2009 @ 15:56:
Probeer eens met namen ipv nummers bij MemberUid. Een uid is een gebruikersnaam, een uidNumber is het ID wat daarbij hoort.

Dat klinkt wel heel erg logisch... Overigens is dat ook de oplossing. Vanuit de zimbra beheer-console staat er memberUid en ik was er (heel stom) vanuit gegaan dat het het nummer was ipv de naam. Tnx

Rainmaker schreef op maandag 26 oktober 2009 @ 17:40:
En verander je "root" username even.

cn=config is niet handig, omdat dat ook een base is.

cn=Manager oid is wat unieker.

En bij mij is memberUid inderdaad ook de naam van de gebruiker, niet de uid. Eigenlijk best verwarrend Maar als ik in de schemas kijk (openldap 2.3), zie ik inderdaad dat memberUid een "IA5 String" is in plaats van een integer.

Zimbra 6.0 gebruikt openldap 2.4.18 en helaas (voor mij) geen slapd.conf meer. Ik zou dus niet direct weten hoe ik dit zo eenvoudig kan wijzigen en welke effecten dit op zimbra heeft. Ik ben met cn=config ook niet helemaal gelukkig.....