So ganz auf die Schnelle wird das schwierig, aber vielleicht kommen wir schrittweise weiter. Wenn ich bei qdPM nachsehe, finde ich folgendes Screen-Shot der Konfigurationsmaske für die LDAP-Anbindung:
Einige Felder dort finde ich selbst auch nicht selbsterklärend, die msiten sollten wir aber in der Lage sein korrekt zu setzen. Kryptisch: „Use LDAP Login“ und „Default Group“. Die erklären sich evtl. eher, wenn man nachschaut, wofür qdPM das LDAP verwendet.
Die anderen Felder legen fest, wie qdPM das LDAP abfragt:
LDAP Server Name: das wäre der Name, unter dem der LDAP-Server via TCP angesprochen werden soll. Könnte auch „localhost“ sein, wenn auf der gleichen VM wie qdPM.
LDAP server port: Der TCP-Port auf den der Server horcht, im Default meist 389.
LDAP base DN: wird bei der Einrichtung des LDAP-Servers festgelegt. Das ist der Pfad zu dem Verzeichnisteil, in welches Du Deine User einträgst. Die Pfade sind hierarchisch aufgebaut. Im Beispiel „o=MyCompany, c=US“ steht das c für Country, also das Land, in dem Deine Organisation beheimatet ist, das o steht für Organization, und oft gibt es drunter, also hier davor, noch ein ou=… für eine Organizational Unit, also eine Abteilung in der Organisation. Das DN steht für Distinguished Name. Ein Distinguished Name ist ein solcher Pfad im Vereichnis. Hier konkret ist es nicht der name eines Users, sondern der oberste Pfad unter dem irgandwo alle Deine user zu finden sein werden. Die Anwendung wird beim Suchen von Usern den gesamten Baum unterhalb des angegebenen DN durchsuchen.
LDAP uid: uid steht für User Identity. Hier wird aber gar keine user identity angegeben, sondern wie das Attribut im LDAP heißt, in welches Du die id einträgst, für die bei der Anmeldung der Eintrag im LDAP gesucht wird. Häufig wird dort wirklich „uid“ einzutragen sein. Beispiel: Der User will sich mit dem Usernamen kurt anmelden, dann ist die Frage, in welches Attribut (Feld) Du das kurt bei der Useranlage im LDAP einträgst. Wie gesagt, meistens „uid“. Man kann das in LDAp alles ändern, aber das macht die Konfig der nutzenden Clients schwer. Deshalb hält man sich lieber erst mal an einfache Beispiele.
LDAP user filter: ein LDAP-Verzeichnis kann groß sein und evtl. gibt es dort ganz viele Objekte, die ein Attribut „uid“ haben, aber gar keine user in Deinem Sinne sind. Deshalb kann man weitere Bedingungen (Filter-Ausdrücke) angeben, um die Suche einzugrenzen. Das Beispiel objectClass=posixGroup schränkt die Suche nach Objekten ein, die vom Typ posixGroup sind (also Gruppen-Einträge). Ich hätte allerdings eher objectClass=posixAccount erwartet. Bei einem einfachen Verzeichnis kannst Du das aber wohl erst mal leer lassen, also die Suche nicht weiter einschränken.
LDAP email attribute: hier geht es wieder nur darum, wie das Attribut heißt, in dem Du für die user deren email-Adresse im LDAP-Server eingetragen hast. Das qdPM holst sich dann wenn es einen user gefunden hat aus diesem Attribut (Feld) die Emailadresse des Users.
LDAP user dn: damit qdPM überhaupt einen User im LDAP-Server suchen kann muss es sich selbst am LDAP-Server anmelden. Man kann entweder zulassen, dass der LDAP-Server anonym durchsucht wird. Das ist unsicherer aber zunächst einmal einfahcer aufzusetzen. Ich würde das empfehlen um erst mal zu sehen, ob Du die anderen felder richtig hinbekommst. Das anonyme durchsuchen (anonymous bind) muss beim Konfigurieren des LDAP-Servers erlaubt werden. Soll qdPM das dann benutzen, bleibt „LDAP user dn“ und „LDAP password“ leer. Das anonymous bind erlaubt in der Regel nur die User-Suche, die Abfrage der wichtigsten Attribute der User und die Prüfung des Passworts. bei der Passwort-Prüfung ist wichtig zu wissen, dass es nicht um das Auslesen des Passworts aus dem LDAp-Server geht, sondern der Client (qdPM) schickt dem LDAP-Server das Passwort (was der User zum beispiel gerade eingetippt hat) zur Überprüfung, und der LDAP-Server sagt, ob es korrekt war oder nicht.
Die Alternative zum anonymous bind ist das Einrichten eines LDAP-Users für technischen Zugriff, also zum Bespiel ein LDAP-User qdpm, der diese rechte bekommt und den Du mit Seinem Passwort dann unter LDAP User dn und LDAP password einträgst. Dabei wird der User mit vollem dn=Distinguished Name eingetragen, also zum Beispiel „uid=qdpm,ou=Free Chicken,o=Save The World,st=Nordrhein Westfalia,c=DE“. Es muss halt der richtige Pfad zu diesem User-Objekt sein, also dorthin zeigen, wo Du es im LDAP-Baum angelegt hast. Weil das leicht schief gehen kann, vielleicht erst mal mit anonymous bind anfangen.
Ich höre jetzt erst mal auf, aber es kann natürlich auch sein, dass Du schon beim Anlegen des LDAp-Servers Schwierigkeiten hattest. Dann müsstest Du mal berichten, was das für ein LDAp-Server ist, und was Du schon getan hast.
Falls zugriff auf ldap nicht klappt, lohnt es in dessen Doku zu suchen, wie man das Logging geschwätzig machen kann. Dann sieht man, welche Anfragen ankommen und kann evtl. erkennen, was an diesen nicht richtig ist.
Viel Erfolg wünscht,
Rainer
Und die Tür steht offen für alle Initiativen, die ein lokales Forum brauchen.