Hi Michael,
hier ist ein funktionierender LDAP Eintrag von mir in einer reinen
LDAP Installation:
[root@pole ~]# ldapsearch -x ‘uid=ralf’ cn givenname sn uid uidNumber
entryuuid # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: uid=ralf # requesting: cn givenname sn uid uidNumber entryuuid #
dn: uid=ralf,ou=accounts,dc=outdoor-training,dc=de
entryUUID: e4b73f8c-a3ba-102a-99c7-dd9ffcd89628
uidNumber: 501
uid: ralf
givenName: Ralf
sn: Becker
cn: Ralf Becker
search result
search: 2
result: 0 Success
numResponses: 2 # numEntries: 1
Liebe Mitleserinnen,
Meist liegt das daran, dass der zugehörige Adressbucheintrag (in der
Datenbank) gelöscht wurde.
Man kann das auch daran erkennen das so ein Benutzer keine Vor- und
Nachname hat sondern immer als “Benutzer $benutzername” angezeigt wird.
Zum beheben muss man einen neuen Adressbucheintrag anlegen und den
wieder mit dem entsprechenden Benutzer in der Datenbank verknüpfen:
UPDATE egw_addressbook SET
contact_owner=0,contact_private=0,account_id=$account_id WHERE
contact_id=$contact_id
Dabei ist $account_id die nummerische I des Benutzers (aus der
egw_accounts Tabelle) und $contact_id die nummerische ID des neu
angelegten Adressbucheintrags.
Hmm bei mir (Authentifizierung per LDAP, Adressbücher in DB und LDAP nur lesend),
Ich denke hier liegt das Problem: Adressbücher in DB, LDAP nur lesend,
das habe ich zwar vor x Jahren eingebaut, ich habe aber seit Jahren
keine Instanz bei der das benutzt wird.
Was funktioniert und wir bei Kunden und selbst einsetzen:
- Authentifizierung gegen LDAP, Benutzer und Adressbücher in DB
- Benutzer in LDAP, Adressbücher (außer Benutzer) in DB
- Benutzer und Adressbücher in LDAP funktioniert auch, ist aber nicht
sehr performant bei großen Adressbüchern
Ich empfehle grundsätzlich 1. oder 2. und CardDAV um auf anderen Clients
EGroupware Adressbücher zur Verfügung zu stellen.
Was du im folgenden beschreibst sieht für mich nach einem Fehler in der
Implementierung aus.
Das ist was wir in der DB, im LDAP bzw. intern im Adressbuch verwenden:
- contact_uid ist in der DB eine UID sprich ein unique identifyer das
sind bei uns sowas wie
"addressbook-NNNN-4d0996b34d4c63f63eae79b6f1b177d5", kann aber auch von
einem CardDAV Client ganz beliebig gesetzt werden, wobei wir es im LDAP
nicht speichern können und die von LDAP automatisch generierte
entryUUID verwenden (ist nicht der Benutzername!)
- account_id ist die uidNumber des LDAP und muss die numerische
Benutzer-ID sein
- egw_accounts.account_lid ist der Benutzername oder “uid” im LDAP im
Benutzerkonten Adressbuch ist das die id
Ich vermute mal das da irgendwas für “SQL --> LDAP” nicht richtig gemapt
wird. Ich habe im Moment aber keine Zeit danach zu schauen.
Ralf
gibt es zwar nicht viele Benutzer, aber dafür drei unterschiedliche Arten. Sie lassen sich anhand der Fehlermeldung unterscheiden, die ich angezeigt bekomme wenn ich die Werte des Formulars für das Benutzerkonto speichern will:
- Es funktioniert.
Hier ist in der Spalte “contact_uid” der Tabelle “egw_addressbook” der korrekte Login-Name eingetragen, also die UID des entsprechenden LDAP-Eintrags (z.B. “fritz”).
- Fehlermeldung “Can’t find contact of just created account!”
“egw_addressbook” > “contact_uid”: Hier steht so etwas wie “addressbook-NNNN-4d0996b34d4c63f63eae79b6f1b177d5” wobei “NNNN” für den Wert im Feld “contact_id” der gleichen Zeile steht. Das Lustige ist, dass wenn ich den Wert korrigiere (also z.B. “fritz” in “contact_uid” eintrage), dann wird obiger Wert schon beim Öffnen des Formulars für das Benutzerkonto wieder eingetragen (wobei ich nicht überprüft habe ob der lange HEX-Wert jedes mal gleich ist).
- Fehlermeldung “Fehler beim Speichern des Kontakt !!! Object class violation: addressbook_ldap: 656”:
Dann gibt es in “egw_addressbook” keine passende Zeile mit “account_id” = uidNumber für das Benutzerkonto. In der Liste der Benutzerkonten wird es aber angezeigt (anders als bei Peters ursprünglicher Problembeschreibung). Mit diesem Problem habe ich mich noch nicht beschäftigt, ich möchte zuerst Punkt 2) lösen.
Eine kleine Anmerkung zu den verwendeten numerischen UIDs und GIDs: Aus historischen Gründen – das EGroupware-System läuft schon seit 2008 – gibt es Überlappungen bei den “uidNumber” und “gidNumber”, d.h. es gibt “uidNumber” die den gleichen Wert wie eine “gidNumber” haben. Das war vor EGroupware 14.1 kein Problem (weil GIDs in fast allen Datenbanktabellen als negative Zahl eingetragen werden).
Falls jemand einen Lösungsansatz weiß oder mich auf die Ursache des Problems stoßen kann wäre ich sehr dankbar. Ich möchte es vermeiden stundenlang für alle Benutzerkonten und Gruppen die “uidNumber” und “gidNumber” zu ändern, nur um dann festzustellen, dass dies doch nicht die Ursache meines Problems war.
Liebe Grüße
Michael
–
Ralf Becker
Director Software Development
Stylite AG
Morschheimer Strasse 15 | Tel. +49 6352 70629 0
D-67292 Kirchheimbolanden | Fax. +49 6352 70629 30
Email: rb@stylite.de
www.stylite.de | www.egroupware.org
Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer
VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany
