LDAP Anbindung

Question

Hallo,

nutzt jemand hier die Benutzer-Authentifizierung über LDAP? Benötige ich hierfür zusätzliche Pakete für den Apache oder spezielle Konfig (abgesehen von der /usr/lib/lx-office-erp/config/lx_office.conf)?

Bei mir erscheint nach der Umstellung auf LDAP leider nur "Internal Server Error 500" wenn ich auf die Anmeldeseite möchte...

Grüsse
Ivan

Answer 1

nutzt jemand hier die Benutzer-Authentifizierung über LDAP?

ja, feine Sache das.

Benötige ich hierfür zusätzliche Pakete für den Apache oder spezielle Konfig
(abgesehen von der /usr/lib/lx-office-erp/config/lx_office.conf)?

Ja, Du brauchst das perl ldap-modul Net::LDAP

aptitude install libnet-ldap-perl

das wird zur Zeit nicht geprueft, siehe: https://trac.kivitendo.de/ticket/1877

Bei mir erscheint nach der Umstellung auf LDAP leider nur "Internal Server Error 500"
wenn ich auf die Anmeldeseite möchte...

Das fehlende Modul wird in der Apache error.log angezeigt. Immer mal da reinschauen, bei Aerger.

bitte ein kurzes Feedback, wenn es danach ohne error 500 geht.

Wenn Du Uebung mit LDAP hast -> Wasser Marsch
Wenn nein, koennen wir hier auch mal einen Basic Baum aufbauen. Man kann da schicke Dinge tun, zum Beispiel einen Useraccount fuer viele kivitendo-Logins verwenden (ein Mensch hat unterschiedliche Logins wegen unterschiedlicher Datenbanken)

Answer 2

Hallo,

vielen Dank für den Hinweis!

Nach Installation des Paketes ist der Fehler 500 nun weg! Ich hatte nur in den LXO-Log geschaut und da wird im Moment so gut wie nichts geloggt.
Eine LDAP-Struktur habe ich bereits laufen. Nun bin ich dabei sämtliche Dienste auf LDAP umzustellen - das spart später wirklich viel Arbeit.

Die Anmeldeseite erscheint jetzt, aber nach dem Login erhalte ich folgende Fehlermeldung:

Can't locate IO/Socket/SSL.pm in @INC (@INC contains: modules/override /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr//lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl . modules/fallback) at /usr/share/perl5/Net/LDAP.pm line 1005.

Das hängt damit zusammen, daß eine SSL/TLS-Verbindung zum LDAP-Server notwendig ist und noch folgendes Paket gefehlt hat: libio-socket-ssl-perl
Eine LDAP-Verbindung zu einem anderen Host sollte niemals unverschlüsselt laufen ;-)

Nun heißt es aber:

Die Verbindung zum LDAP-Server kann nicht verschlüsselt werden (Fehler bei SSL/TLS-Initialisierung). Bitte überprüfen Sie die Angaben in config/lx_office.conf.

Hmm, da erd ich jetzt nochmal sehen müssen wo es jetzt hakt - Feedback folgt!

Vielen Dank schon mal! Falls Du noch einen Tipp hierzu hast - sehr willkommen!

Viele Grüsse
Ivan

Comments

Im Zweifelsfall klappt es wegen der Zertifikate nicht: z.B. der Server, auf dem Kivitendo läuft, kennt das CA-Zertifikat nicht, mit dem Zertifikat des LDAP-Servers unterzeichnet wurde. Da hilft es, in z.B. /etc/ldap/ldap.conf entsprechend mit TLS_CACERT und TLS_CACERTDIR zu hantieren. Siehe man ldap.conf.

Testen kann man das auch hervorragend mit ldapsearch aus dem Paket ldap-utils. Übergibt man ihm die Optionen -ZZ, so verschlüsselt es und verlangt ein gültiges Zertifikat. Klappt das schon nicht, so kann es mit Kivitendo praktisch nicht klappen. Ungefähr so: ldapsearch -x -h ip.des.ldap.servers -b '' -s BASE -ZZ.

---

Hallo,

Danke!

ich glaube das war gar nicht mein Problem, denn ich habe die TLS/SSL Konfig durcheinandergeworfen.

Im Abschnitt "host" hatte ich statt ldaps://ldapserver nur ldapserver eingetragen. "tls" habe ich wieder auf "0", jetzt klappts

host          = ldaps://ldapserver
port          = 636
tls           = 0
attribute     = uid
base_dn       = dc=mein,dc=ldap,dc=server
filter        =
bind_dn       = cn=ldapadmin,dc=mein,dc=ldap,dc=server
bind_password = geheim

Funktioniert!

Sehe ich das richtig, das der User trotzdem zuvor im LXO-Admin-Backend angelegt sein muß?
Schon oder, sonst hat LXO ja keine Ahnung über die Zugriffsrechte, persönliches Layout etc...

Danke nochmal!

Grüsse
Ivan

---

Ja, die Benutzerverwaltung muss weiterhin in Kivitendo erfolgen. Gegen das LDAP wird lediglich das Passwort geprüft.

Wulf hatte irgendwann aber auch mal erzählt, dass er gewisse Gruppenzugehörigkeit oder so mit dem LDAP-Filter abgebildet hat. Also z.B. sowas wie "darf überhaupt auf Kivitendo zugreifen".

---

Ja, die Benutzerverwaltung muss weiterhin in Kivitendo erfolgen. Gegen
das LDAP wird lediglich das Passwort geprüft.

OK, macht ja irgendwie auch Sinn falls man nicht die komplette LXO-User-Konfig ins LDAP pusten möchte ;-)

Wulf hatte irgendwann aber auch mal erzählt, dass er gewisse
Gruppenzugehörigkeit oder so mit dem LDAP-Filter abgebildet hat. Also
z.B. sowas wie "darf überhaupt auf Kivitendo zugreifen".

Ja das geht, habe ich mit OTRS mal gehabt.
Aber generell bleiben User die zwar im LDAP eingetragen sind, jedoch keinen entsprechenden Benutzer im LXO haben ausgesperrt - hab's gerade getestet.

---

ich glaube das war gar nicht mein Problem, denn ich habe die TLS/SSL Konfig durcheinandergeworfen.
ImI Abschnitt "host" hatte ich statt ldaps://ldapserver nur ldapserver eingetragen. "tls"
habe ich wieder auf "0", jetzt klappts

kann man machen, allerdings sind die ssl-Ports bei den meisten Protokollen deprecated.
Der Trend geht da also in Richtung port 389 (ldap) und starttls.

bind_dn = cn=ldapadmin,dc=mein,dc=ldap,dc=server
bind_password = geheim

das braucht man eigentlich nur, wenn Filter zum Einsatz kommen, die der eigentliche User nicht lesen darf. Intern findet einfach ein Bind gegen den betroffenen User statt, wenn der klappt, alles gut, wenn nein ist die Authentifikation gescheitert. Ein Admin Bind ist also in der Regel nicht noetig.

>> zum Beispiel einen Useraccount fuer viele kivitendo-Logins verwenden
>> (ein Mensch hat unterschiedliche Logins wegen unterschiedlicher Datenbanken)

Wulf hatte irgendwann aber auch mal erzählt, dass er gewisse Gruppenzugehörigkeit oder so mit dem LDAP-Filter
abgebildet hat. Also z.B. sowas wie "darf überhaupt auf Kivitendo zugreifen".

nein, nicht mit Gruppen, das war der auch hier erwaehnte Fall. Also:

• ldif example

    uid=wulf,ou=users,dc=coulmann,dc=de 
    objectClass: top 
    objectClass: person 
    objectClass: CourierMailAccount 
    uid: wulf 
    cn: Wulf Coulmann 
    sn: Coulmann 
    userPassword: {SSHA}unlesbarespasswort 
    homeDirectory: /home/wulf 
    description: wulf_mandant_1
    description: wulf_mandant_1_test
    description: wulf_mandant_2
    description: wulf_mandant_2_test
    Mail: ....

• kivitendo Config (die nicht aufgefuehrten Werte bleiben auf der defaut Einstellung und werden aus lx_office.conf.default eingelesen)

    [authentication]
    module = LDAP
    
    [authentication/ldap]
    host          = 10.6.1.44
    attribute     = description
    base_dn       = ou=users,dc=coulmann,dc=de

Hier kann ich mich also mit den entsprechenden Benutzernamen (wulf_mandant_1, wulf_mandant_1_test, usw.)
und meinem Standard-ldap Passwort jeweils einloggen. Zum einen habe ich nur ein pw fuer alle Kivitendo-Accounts,
zum Anderen bin ich das Theater mit den pw-Speicher-Automatismen los, wenn ich als Admin in admion.pl Useraccounts bearbeite.

Diese Loesung ist nicht ganz sauber, da ich das Attribut "Description" (in diesem Fall aus objectClass Person) missbrauche. Der saubere Weg waere einen Namespace bei Iana.org zu registrieren und dann ein Schema zu erstellen mit einem Feld, z.B. "kivitendoUserName"