Hallo Dieter, trotz dass ich die ACL's in der gleichen Reihenfolge habe, bekomme ich wieder gleiche Logs. In den Logs fehlt meiner Meinung nach der Teil, der gelistet werden müsste, wenn ich versuche einen neuen Namen einzugeben, in den Logs tauchen immer nur die Einträge auf, (die meiner Meinung nach) die beim Lesen des Eintrags entstehen. Evolution reagiert ebenfalls nicht wie ich mir das vorstelle: Wenn ich versuche einen bestehenden Eintrag zu erweitern, weil z. B. die eMAil-Adresse noch fehlt, so kann ich im dazugehörigen Feld nichts eintragen. Bei neuen Einträgen sind alle Felder editierbar nur beim Speichern bekomme ich immernoch den Fehler: anderer Fehler. Dies nur wenn ich versuche auf LDAP auf dem Server zu schreiben, die lokale Adressdatenbank funktioniert. Ich fürchte fast mit meinem Evolution stimmt etwas nicht bzw. mit meinen Zugriffsrechten unter Linux --> Server. wenn ich : access to dn.base="" * by write by * read testhalber eingebe, haben dann alle Lese- und Schreibrechte? Überall? (oder wie sonst, nur für Test!) Oder liegt es an der Organisation meines Adressbuches? : --- o=kapune,ou=adressbuch,cn=Familie,cn=Christian Kapune Gruß Johannes
Ich lese in den log immer nur "access_allowed" ganz zum Schluß SAMBA und sshd ist ein "späteres Problem".
Da liest du nur einen Teil der Meldung :-) 'access allowed by read'
Ich entferne mal die meisten Logmeldungen, da hier Zeile für Zeile der Zugriff auf einzelne Attribute geprüft wird, und analysiere nur diese eine Meldung:
Nov 18 01:55:36 Server02 slapd[15930]: => access_allowed: search access to "ou=adressbuch,o=kapune,c=de" "mail" requested Nov 18 01:55:36 Server02 slapd[15930]: => dn: [1]
<>> Nov 18 01:55:36 Server02 slapd[15930]: => dn: [2] cn=subschema
Nov 18 01:55:36 Server02 slapd[15930]: => dn: [3] ou=adressbuch,o=kapune,c=de Nov 18 01:55:36 Server02 slapd[15930]: => acl_get: [3] matched Nov 18 01:55:36 Server02 slapd[15930]: => acl_get: [3] check attr mail Nov 18 01:55:36 Server02 slapd[15930]: <= acl_get: [3] acl ou=adressbuch,o=kapune,c=de attr: mail Nov 18 01:55:36 Server02 slapd[15930]: => acl_mask: access to entry "ou=adressbuch,o=kapune,c=de", attr "mail" requested Nov 18 01:55:36 Server02 slapd[15930]: => acl_mask: to all values by "", (=n) Nov 18 01:55:36 Server02 slapd[15930]: <= check a_dn_pat: cn=admanager,o=kapune,c=de Nov 18 01:55:36 Server02 slapd[15930]: <= check a_dn_pat: * Nov 18 01:55:36 Server02 slapd[15930]: <= acl_mask: [2] applying read(=rscx) (stop) Nov 18 01:55:36 Server02 slapd[15930]: <= acl_mask: [2] mask: read(=rscx) Nov 18 01:55:36 Server02 slapd[15930]: => access_allowed: search access granted by read(=rscx)
Zuerst wird der Zugang zu 'ou=adressbuch,o=kapune,c=de' geprüft, dazu muß die Sucherlaubnis gewährt sein, (access allowed: search). Dann wird die Zugangserlaubnis zum Attribut 'mail' geprüft. Es gibt 3 access Regeln in deiner slapd.conf und die dritte Regel, 'access to ou=adressbuch,o=kapune,c=de' trifft zu (acl_get: [3] matched). Danach wird geprüft, ob auch der Zugang zum Eintrag möglich ist, der das Attribut 'mail' enthält. Hierzu wird geprüft, ob dies der Identität 'cn=admanager,o=kapune,c=de' erlaubt wird. Das erste Suchmuster das zutriftt, ist die Regel 2 (acl_mask: [2] applying), diese Regel enthält das DN Muster * (check a_dn_pat: *) mit der Erlaubnis zu lesen (applying read (=rscx) Die letzte Zeie besagt dann, das der lesende Zugang zu den Einträgen unterhalb 'ou=adressbuch,o=kapune,c=de' für 'cn=admanager,o=kapune,c=de' gewährt wird.
Deine Access Regeln stimmen also nicht. Ich vermute mal, daß du durchaus Schreibrechte mit einer Regel gewährt hast, aber die Reihenfolge der Regeln nicht beachtet hast. Hier mal der relevante Auszug meiner Access Regeln in der richtigen Reihenfolge:
,----[ access Regeln ] | #globaler Teil# | access to dn.base="" by * read | access to dn.base="cn=Subschema" by * read | #database spezifische Regeln# | database bdb | access to dn.subtree="ou=adressbuch,o=avci,c=de" | by dn="cn=admanager,o=avci,c=de" write | by * read | access to dn.children="o=avci,c=de" | by group.exact="cn=administratoren,o=avci,c=de" write | by users read | by anonymous auth `----
Zur Erläuterung:
access to dn:base="" by * read bedeutet daß rootDSE ausgelesen werden kann. Das ist notwendig, damit Clients auch ohne vorherige Authentifizierung die Fähigkeiten des Servers prüfen können. Das kannst du selbst testen mit ldapsearch -b "" -s base + -x
access to dn.base=cn=subschema by * read erlaubt den Clients ohne Authentifizierung die verfügbaren Objektklassen und Attribute zu prüfen, der Selbsttest ldapsearch -b cn=subschema -s base + -x
Das Plus (+) ist die Wildcard für operationale Attribute, während ein Asteriks (*) die Wildcard für Objectattribute ist.
Als dritte Regel wir dann der Zugang zum Adressbuch definiert (dn.subtree) und als vierte Regel der Zugang zum restlichen Datensatz (dn.children).
Access Regeln werden aufsteigend berücksichtigt und nicht nur in der Reihenfolge der Deklarierung. Mit anderen Worten, die Regel die zuerst zutrifft wird genommen. Zum Beispiel die häufig anzutreffende fehlerhafte Konfiguration
access to * by * read access to dn=ou=blub,o=meine firma,c=de by users read by cn=foo,o=meine firma,c=de write access to dn=ou=bla,ou=blub,o=meine firma,c=de
Schon die erste Regel schließt alle andern Regeln ein, die zweite Regel schließt die dritte Regel ein, so daß der dritte Regelsatz nie zur Anwendung kommen wird. Selbst cn=foo wird nie Schreibrechte entsprechend des zweiten Regelsatzes erlangen, da schon vorher Leserechte für authentifizierte User gewährt wurden.
Ich hoffe, es ist jetzt einiges klarer geworden :-)