Verständnisfrage zu LDAP
Hallo, als LDAP-Novize versuche ich gerade, mir von der Konsole aus ein Verständnis von den Zugriffsrechten auf einen LDAP-Server zu verschaffen. Ich habe ein Adressbuch, auf das ich die Rechte wie nachfolgend dokumentiert verteilt habe. -------- slapd.conf ------------ access to dn=".*,ou=private-addressbook,uid=(.*),ou=auth_user,o=company.com" by dn="uid=$1,ou=auth_user,o=company.com" write by self write by dn="cn=Manager,o=company.com" write by * none # Setzen der Leserechte auf das Attribut im UserOrdner access to dn="uid=(.*),ou=auth_user,o=company.com" by dn="uid=$1,ou=auth_user,o=company.com" read by self write by dn="cn=Manager,o=company.com" write by * none -------------------------------- Die auth_user sind die Systembenutzer. Mit der Bindung an den LDAP-Administrator mittels ... # ldapadd -x -D "cn=Manager,o=company.com" -W -v -f test.ldif funktioniert alles. Die Struktur an sich ist also in Ordnung. Die Eingabe von ... # ldapadd -x -D "uid=michael,ou=auth_user,o=company.com" -W -v -f test.ldif führt jedoch zu der Meldung -------------------------------- adding new entry "cn=Eva,ou=private-addressbook,uid=michael,ou=auth_user,o=company.com" ldapadd: update failed: cn=Eva,ou=private-addressbook,uid=michael,ou=auth_user,o=company.com ldap_add: Insufficient access (50) additional info: no write access to entry -------------------------------- Was mache ich falsch? Gruß, Michael
Hallo,
"M. Schlegel"
Hallo,
als LDAP-Novize versuche ich gerade, mir von der Konsole aus ein Verständnis von den Zugriffsrechten auf einen LDAP-Server zu verschaffen. Ich habe ein Adressbuch, auf das ich die Rechte wie nachfolgend dokumentiert verteilt habe.
Da hast du dir ja einiges vorgenommen :-)
-------- slapd.conf ------------ access to dn=".*,ou=private-addressbook,uid=(.*),ou=auth_user,o=company.com" by dn="uid=$1,ou=auth_user,o=company.com" write by self write by dn="cn=Manager,o=company.com" write by * none # Setzen der Leserechte auf das Attribut im UserOrdner access to dn="uid=(.*),ou=auth_user,o=company.com" by dn="uid=$1,ou=auth_user,o=company.com" read by self write by dn="cn=Manager,o=company.com" write by * none --------------------------------
Wie soll denn die Struktur des Adressbuches aussehen? Ich will mal deine access Regel mit Fleisch füllen, um dir das zu deutlichen access to dn="cn=Eva,ou-privat-addressbook,uid=michael,ou=auth_user..." by dn="uid=cn=Eva,ou=auth_user,o=company.com" Das ist eine Regel die nicht funktionieren kann :-) was du möchtest wäre access to dn=.*,ou=privat-addressbook,uid=$2,ou=auth_user..." Die Regel 'by self write' besagt, daß 'Eva' ihren Eintrag schreibend verändern darf, ich denke mal, daß dies bei einem Adressbuch-Eintrag überflüssig ist. Deine Rechte im User Ordner sind auch nicht ganz in Ordnung. Du wirst nie deinen eigenen Eintrag schreibend verändern können, denn die Regel by dn="uid=$1,ou=auth_user ..." read wird beim Parsen der Regeln zuerst getroffen, wenn du versuchst, auf deinen Eintrag zuzugreifen, die Regel 'by self write' wird nicht mehr erkannt, da beim ersten Treffer das Parsen beendet wird. Was möchtest du denn mit dieser Regel bewirken? Du solltest wenigstens das Attribut userPasswd zur Authentifizierung freigeben, sonst kannn das System dich ja nicht verifizieren. Setze in slapd.conf 'loglevel 128', damit kannst du dann in /var/log/localmessages prüfen, ob deine access Regeln funktionieren. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Dieter Kluenter schrieb:
Hallo,
"M. Schlegel"
writes: Hallo,
als LDAP-Novize versuche ich gerade, mir von der Konsole aus ein Verständnis von den Zugriffsrechten auf einen LDAP-Server zu verschaffen. Ich habe ein Adressbuch, auf das ich die Rechte wie nachfolgend dokumentiert verteilt habe.
Da hast du dir ja einiges vorgenommen :-)
Meinst Du wirklich ? :-[
-------- slapd.conf ------------ access to dn=".*,ou=private-addressbook,uid=(.*),ou=auth_user,o=company.com" by dn="uid=$1,ou=auth_user,o=company.com" write by self write by dn="cn=Manager,o=company.com" write by * none # Setzen der Leserechte auf das Attribut im UserOrdner access to dn="uid=(.*),ou=auth_user,o=company.com" by dn="uid=$1,ou=auth_user,o=company.com" read by self write by dn="cn=Manager,o=company.com" write by * none --------------------------------
Wie soll denn die Struktur des Adressbuches aussehen? Ich will mal deine access Regel mit Fleisch füllen, um dir das zu deutlichen
access to dn="cn=Eva,ou-privat-addressbook,uid=michael,ou=auth_user..." by dn="uid=cn=Eva,ou=auth_user,o=company.com"
Das ist eine Regel die nicht funktionieren kann :-)
Ok! Ich glaube, so (!) gesehen kann ich das ziemlich leicht einsehen ;-) Ich erklär' mal kurz meine Absicht: nach allen Beispielen, die ich bisher durchgeackert habe, obliegt es dem LDAP-Manager, Datensätze hinzuzufügen. Das kann aber unmöglich sein, dann müsste ja jeder Client über vollen Zugang zum LDAP-Server verfügen. Oder nicht? Nun, ich bemühte mich also um eine Rechtevergabe, in der jeder Mitarbeiter neben dem zentralen Adressbuch sein privates Adressbuch füllen kann ohne über Manager-Rechte zu verfügen. Das ist es eigentlich schon. Dein Gedanke mit dem UserPassword ist natürlich bestechend, alleine mir ist nicht klar, wie ich das mache. Das UserPassword ist doch in einer anderen Tabelle? :-[
was du möchtest wäre access to dn=.*,ou=privat-addressbook,uid=$2,ou=auth_user..."
Die Regel 'by self write' besagt, daß 'Eva' ihren Eintrag schreibend verändern darf, ich denke mal, daß dies bei einem Adressbuch-Eintrag überflüssig ist.
Deine Rechte im User Ordner sind auch nicht ganz in Ordnung. Du wirst nie deinen eigenen Eintrag schreibend verändern können, denn die Regel by dn="uid=$1,ou=auth_user ..." read wird beim Parsen der Regeln zuerst getroffen, wenn du versuchst, auf deinen Eintrag zuzugreifen, die Regel 'by self write' wird nicht mehr erkannt, da beim ersten Treffer das Parsen beendet wird. Was möchtest du denn mit dieser Regel bewirken?
Das habe ich mir zwischenzeitlich auch schon gedacht und habe es geändert.
Du solltest wenigstens das Attribut userPasswd zur Authentifizierung freigeben, sonst kannn das System dich ja nicht verifizieren.
Setze in slapd.conf 'loglevel 128', damit kannst du dann in /var/log/localmessages prüfen, ob deine access Regeln funktionieren.
Habe ich getan, aber "tail -f /var/log/messages" bestätigt nur mein Dilemma :'(
-Dieter
Vielen Dank schon mal für Deine Unterstützung!! Grüße, Michael P.S. Sach mal, warum macht den Thunderbird nicht 72 Zeichen, wenn ich ihm das sage??
Hallo,
"M. Schlegel"
Dieter Kluenter schrieb:
Hallo,
"M. Schlegel"
writes: Hallo,
als LDAP-Novize versuche ich gerade, mir von der Konsole aus ein Verständnis von den Zugriffsrechten auf einen LDAP-Server zu verschaffen. Ich habe ein Adressbuch, auf das ich die Rechte wie nachfolgend dokumentiert verteilt habe.
Da hast du dir ja einiges vorgenommen :-)
Meinst Du wirklich ? :-[ [...] Ich erklär' mal kurz meine Absicht: nach allen Beispielen, die ich bisher durchgeackert habe, obliegt es dem LDAP-Manager, Datensätze hinzuzufügen. Das kann aber unmöglich sein, dann müsste ja jeder Client über vollen Zugang zum LDAP-Server verfügen. Oder nicht? Nun, ich bemühte mich also um eine Rechtevergabe, in der jeder Mitarbeiter neben dem zentralen Adressbuch sein privates Adressbuch füllen kann ohne über Manager-Rechte zu verfügen. Das ist es eigentlich schon. Dein Gedanke mit dem UserPassword ist natürlich bestechend, alleine mir ist nicht klar, wie ich das mache. Das UserPassword ist doch in einer anderen Tabelle? :-[
[access Regeln entfernt] Jede Verwendung einer Datenbank setzt erst einmal ein Konzept voraus, das klingt banal, aber speziell bei der Verwendung eines Verzeichnisdienstes sollte man schon einiges an Gedankenschmalz vorher investieren. 1. Prämisse: die Anwender sollen ihre Adressen selbst pflegen. OK, mit welchem Tool soll das gemacht werden? Outlook, Netscape, Kadressbook sind dazu nicht geeignet, diese Anwendungen können nur lesend auf einen Verzeichnisdienst zugreifen. 2. Bestimmung des Tools. Für ungeübte Anwender fallen alle LDAP-Administrations-Werkzeuge weg, wie z.B. GQ, ldapbrowser, phpLDAPAdmin usw., dann bleiben noch für Linux Evolution als GUI Tool und plattformunabhängige, webbasierte Anwendungen, wie z.B. rolodap und ldap-abook, Horde oder KDE-Kolab-PIM. 3. Beschreibung der Datenstruktur. Entweder ein zentrales Adressbuch, das von allen beteiligten gelesen und nur von einem ausgewählten Personenkreis beschrieben werden kann. Oder die zweite Möglichkeit, ein dezentrales Adressbuch, das nur von den Besitzern beschrieben und von ausgewählten Anwendern gelesen werden kann. 4. Definition des Inhaltes. Genügen die Attribute Name, Vorname, Telephonnummer, Straße, PLZ und Wohnort, oder sollen weitere Attribute hinzugefügt werden? Wenn weitere Attribute benötigt werden, müssen gegbenenfalls neue Objektklassen und Attribute definiert werden. 5. die bereitzustellende Kapazität. Wieviele Einträge werden erwartet, wieviele lesende und wieviele schreibende Zugriffe werden in einem zu defierenden Zeitraum erwartet? Jetzt möchte ich einmal zwei unterschiedliche Datenstrukturen beschreiben. Die erste Struktur beschreibt ein zetrales Adressbuch. dn: ou=Adressbuch,o=meine Firma,c=de objectClass: organizationalUnit ou: Adressbuch Dann gibt es noch eine Gruppe AdressAdmin, Mitglieder dieser Gruppe dürfen schreibend auf das Adressbuch zugreifen dn: cn=AdressAdmin,o=meine Firma,c=de objectClass: groupOfNames cn: AdressAdmin member: cn=franz meyer,ou=Verkauf,o=meine Firma,c=de member: uid=michael,ou=users,o=meine Firma,c=de Dann die access Regeln access to dn.subtree="ou=Adressbuch,o=meine Firma,c=de by group="cn=AdressAdmin,o=meine Firma,c=de write by users read by * none Hier sind 'users' authentifizierte Anwender, also kein anonymous bind. Die zweite Strukturmöglichkeit wäre dann, wie schon von dir angedacht, ein dezentrales Adressbuch dn: cn=Adressbuch,cn=franz meyer,ou=Verkauf,o=meine Firma,c=de objectClass: organizationalUnit ou: Adressbuch Jetzt noch die dazugehörende access Regel als Regulärer Ausdruck access to dn.regex="^(.+,)?cn=([^,]+),ou=Verkauf,o=meine Firma,c=de$$" by dn.exact,expand="cn=$1,ou=Verkauf,o=meine Firma,c=de" write by users read by * none Da sieht schlimmer aus, als es ist :-) Es beduetet nur, Jeder darf in seinem Subtree schreiben, was immer er möchte. Den RDN ou=Verkauf kann man auch noch als reglären Ausdruck definieren, ich wollte hier nur verdeutlichen, wie eine allgemeingültige Regel geschrieben werden könnte. Wenn du davon ausgehen kannst, daß als Ersatz für ou=Verkauf kein Eintrag mit einem Leerraum genommen wird, also nicht "ou=lokaler Verkauf", sondern immer nur ein Wort steht, dann könntest du statt des Eintrags auch "(.+)," verwenden das wird dann durch $2 expandiert, by dn.exact,expand="cn=$1,ou=$2,o=meine Firma,c=de" write Achte bitte darauf, das du den "relative distinguished name" entweder nur mit uid oder mit cn beschreibst, sonst funktioniert die Regel nicht.
P.S. Sach mal, warum macht den Thunderbird nicht 72 Zeichen, wenn ich ihm das sage??
Keine Ahnung, was ist Thunderbird? -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Hallo, vielen Dank, Dieter, für die sehr ausführliche und herausfordernde Antwort. Ich werde nun aber dennoch ins Bett gehen und mich morgen Abend auf Deine Antwort stürzen! Gute Nacht! Michael P.S. Thunderbird = Mozilla Thunderbird (-> Email-Client)
Hallo Dieter, hallo an alle, Dieter Kluenter schrieb: ...
Die zweite Strukturmöglichkeit wäre dann, wie schon von dir angedacht, ein dezentrales Adressbuch
dn: cn=Adressbuch,cn=franz meyer,ou=Verkauf,o=meine Firma,c=de objectClass: organizationalUnit ou: Adressbuch
Jetzt noch die dazugehörende access Regel als Regulärer Ausdruck
access to dn.regex="^(.+,)?cn=([^,]+),ou=Verkauf,o=meine Firma,c=de$$" by dn.exact,expand="cn=$1,ou=Verkauf,o=meine Firma,c=de" write by users read by * none
Da sieht schlimmer aus, als es ist :-) Es beduetet nur, Jeder darf in seinem Subtree schreiben, was immer er möchte. Den RDN ou=Verkauf kann man auch noch als reglären Ausdruck definieren, ich wollte hier nur verdeutlichen, wie eine allgemeingültige Regel geschrieben werden könnte. Wenn du davon ausgehen kannst, daß als Ersatz für ou=Verkauf kein Eintrag mit einem Leerraum genommen wird, also nicht "ou=lokaler Verkauf", sondern immer nur ein Wort steht, dann könntest du statt des Eintrags auch "(.+)," verwenden das wird dann durch $2 expandiert, by dn.exact,expand="cn=$1,ou=$2,o=meine Firma,c=de" write
Achte bitte darauf, das du den "relative distinguished name" entweder nur mit uid oder mit cn beschreibst, sonst funktioniert die Regel nicht.
P.S. Sach mal, warum macht den Thunderbird nicht 72 Zeichen, wenn ich ihm das sage??
Keine Ahnung, was ist Thunderbird?
-Dieter
nicht, dass der Eindruck entsteht, ich hätte kein Interesse mehr an dem von mir aufgerissenen Thema - keineswegs. Nach intensiver(!) Beschäftigung mit regulären Ausdrücken ;-) hänge ich nun wieder ziemlich fest. :-( Im Augenblick kämpfe ich einfach mit dem Zugriff auf die Datenbank. Ich habe gemäß Deiner Anleitung folgende Regel für das "private-addressbook" aufgenommen. access to dn.regex="^(.+,)?uid=([^,]+),ou=auth_user,o=ski-gmbh.com$$" by dn.exact,expand="uid=$1,ou=auth_user,o=ski-gmbh.com" write by users read by * none Das Ergebnis: Zugriff verweigert. Allerdings interpretiere ich nachfolgende Zeilen aus dem Logfile so, dass meine Anfrage zunächst "matched", aber dann einfach weitergegangen wird anstatt die Abarbeitung der Regel abzubrechen. Interpretiere ich das falsch? Feb 18 19:49:30 p2-350 slapd[6986]: => access_allowed: auth access to "uid=michael,ou=auth_user,o=ski-gmbh.com" "userPassword" requested Feb 18 19:49:30 p2-350 slapd[6986]: => dnpat: [1] ^(.+,)?uid=([^,]+),ou=auth_user,o=ski-gmbh.com$$ nsub: 2 Feb 18 19:49:30 p2-350 slapd[6986]: => acl_get: [1] matched Feb 18 19:49:30 p2-350 slapd[6986]: => acl_get: [1] check attr userPassword Feb 18 19:49:30 p2-350 slapd[6986]: <= acl_get: [1] acl uid=michael,ou=auth_user,o=ski-gmbh.com attr: userPassword Feb 18 19:49:30 p2-350 slapd[6986]: => acl_mask: access to entry "uid=michael,ou=auth_user,o=ski-gmbh.com", attr "userPassword" requested Feb 18 19:49:30 p2-350 slapd[6986]: => acl_mask: to all values by "", (=n) Feb 18 19:49:30 p2-350 slapd[6986]: <= check a_dn_pat: uid=$1,ou=auth_user,o=ski-gmbh.com Feb 18 19:49:30 p2-350 slapd[6986]: <= check a_dn_pat: users Feb 18 19:49:30 p2-350 slapd[6986]: <= check a_dn_pat: * Feb 18 19:49:30 p2-350 slapd[6986]: <= acl_mask: [3] applying none(=n) (stop) Feb 18 19:49:30 p2-350 slapd[6986]: <= acl_mask: [3] mask: none(=n) Feb 18 19:49:30 p2-350 slapd[6986]: => access_allowed: auth access denied by none(=n) Das nächste Problem, Schreiben dürfen als User, stellt sich vor dem Hintergrund dieses Problems derzeit leider noch nicht. Gruß, Michael
Hallo,
"M. Schlegel"
Hallo Dieter, hallo an alle,
Dieter Kluenter schrieb:
...
nicht, dass der Eindruck entsteht, ich hätte kein Interesse mehr an dem von mir aufgerissenen Thema - keineswegs. Nach intensiver(!) Beschäftigung mit regulären Ausdrücken ;-) hänge ich nun wieder ziemlich fest. :-(
Im Augenblick kämpfe ich einfach mit dem Zugriff auf die Datenbank. Ich habe gemäß Deiner Anleitung folgende Regel für das "private-addressbook" aufgenommen.
access to dn.regex="^(.+,)?uid=([^,]+),ou=auth_user,o=ski-gmbh.com$$" by dn.exact,expand="uid=$1,ou=auth_user,o=ski-gmbh.com" write by users read by * none
Das Ergebnis: Zugriff verweigert. Allerdings interpretiere ich nachfolgende Zeilen aus dem Logfile so, dass meine Anfrage zunächst "matched", aber dann einfach weitergegangen wird anstatt die Abarbeitung der Regel abzubrechen. Interpretiere ich das falsch?
Feb 18 19:49:30 p2-350 slapd[6986]: => access_allowed: auth access to "uid=michael,ou=auth_user,o=ski-gmbh.com" "userPassword" requested Feb 18 19:49:30 p2-350 slapd[6986]: => dnpat: [1] ^(.+,)?uid=([^,]+),ou=auth_user,o=ski-gmbh.com$$ nsub: 2
Der reuläre Ausdruck wird richtig übersetzt und dein Eintrag wird nun geprüft,
Feb 18 19:49:30 p2-350 slapd[6986]: => acl_get: [1] matched Feb 18 19:49:30 p2-350 slapd[6986]: => acl_get: [1] check attr userPassword
Hier wird das Attribut userPassword deines Eintrages gesucht,
Feb 18 19:49:30 p2-350 slapd[6986]: <= acl_get: [1] acl uid=michael,ou=auth_user,o=ski-gmbh.com attr: userPassword Feb 18 19:49:30 p2-350 slapd[6986]: => acl_mask: access to entry "uid=michael,ou=auth_user,o=ski-gmbh.com", attr "userPassword" requested Feb 18 19:49:30 p2-350 slapd[6986]: => acl_mask: to all values by "", (=n) Feb 18 19:49:30 p2-350 slapd[6986]: <= check a_dn_pat: uid=$1,ou=auth_user,o=ski-gmbh.com Feb 18 19:49:30 p2-350 slapd[6986]: <= check a_dn_pat: users Feb 18 19:49:30 p2-350 slapd[6986]: <= check a_dn_pat: * Feb 18 19:49:30 p2-350 slapd[6986]: <= acl_mask: [3] applying none(=n) (stop)
Das Attribut userpassword wird gefunden darf aber durch die Regel by * none nicht geprüft werden.
Feb 18 19:49:30 p2-350 slapd[6986]: <= acl_mask: [3] mask: none(=n) Feb 18 19:49:30 p2-350 slapd[6986]: => access_allowed: auth access denied by none(=n)
Das ist die Bestätigung, authentication access denied durch die Regel none. Deine gesamten access Regeln sollten also eine access Regel für das userPassword haben, mindestens access to attr=userPassword by anonymous auth Du kannst das auch granulierter machen, also je nach User oder Subtree, aber für den Anfang sollte das genügen. Wenn du restriktive Regeln für deinen Eintrag hast, dann öffne diese Regel für das Attribut userPasword. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
participants (2)
-
Dieter Kluenter
-
M. Schlegel