LDAP Groups

Es ist grundsätzlich zu unterscheiden zwischen Authentifizierung (ist das Benutzer xyz?) und Authorisierung (darf der auch rein? z.B. weil Mitglied in Gruppe abc). Oft wird das durcheinandergebracht, insbesondere wenn man jeden authentifizierten Benutzer dem Zugriff gewährt.
Sowohl für die Authentifizierung als auch die Authorisierung gibt es mit LDAP grundsätzlich zwei verschiedene Möglichkeiten:
1. Bind mit den Credentials des Users (Bei Erfolg ist er authentifiziert) und anschließendem search (mit richtiger BaseDN und entsprechendem Filter, z.B. CN=%u (wobei %u für den Usernamen aus der Authentifizierung steht)), dann bekommst Du je nach LDAP-Schema die Gruppenmitgliedschaften des Users aufgelistet.
2. Bind mit einem Spezialaccount (manchmal auch anonymous bind, das sollte man aber lieber nicht erlauben) um dann (wieder mit richtiger BaseDN und Filter) die Informationen des Users auszulesen. Eines der Attriubte wäre dann auch das (gehashte) Passwort, dass Du mit dem Hash des vom User eingebenen Passwortes vergleichen könntest. Der Typ des Hashs (z.B. SHA1) und das Salt müssen natürlich übereinstimmen.

Der zweite Ansatz hat den Nachteil, dass man einen entsprechenden Account braucht aber auch gleichzeitig den Vorteil, dass nirgendwo das Klartextpasswort des Benutzers gebraucht wird, sondern nur ein Hash (je nach Quelle der Authentifizierung bekommt man manchmal nur einen Hash)

Die OUs geben nur eine Hierarchie wieder, ich weiß nicht wie das bei OpenLDAP (bzw Deinem Schema) ist, aber im AD ist das z.B. mit "memberOf" geregelt.

Es gibt mehrere Wege die nach Rom führen. Beispielsweise geht das so:
Du erzeugst dir für jeden Benutzer ein Objekt in deinem LDAP Baum. Also zb cn=HansDampf,cn=Users, dc=domain,dc=local. Dein Objekt hat nun Attribute, die mögliche Liste gibt dein Schema vor, oder alle auf einmal die du lädst. Um einen Benutzer sinnvoll abzubilden z.B inetorgperson. Nun hat dein Benutzerobjekt im LDAP-Baum Attribute die du setzen kannst und die du (deine Anwendungen) lesen kannst. In einer MS-Welt würdest du jetzt zum Beispiel dem Attribut memberOf einfach die Gruppennamen kommagetrennt hinzufügen in denen der Benutzer Mitglied sein soll. OpenLDAP nimmt da glaub ich einfach das Attribut groups, heisst anders, tut dasselbe.

Wenn deine Anwendung nun sehen will ob ein Benutzer hineindarf macht sie eine Suche auf den Baum. Man speichert dort in ihr also einen Benutzer der den Baum lesen darf und sagt: Such im Unterbaum cn=Users,dc=domain,dc=local nach dem Objekt mit dem Namen Benutzername. Wenn in diesem Obejekt im Attribut memberOf (die Gruppe) DarfinmeineAnwendung aufgelistet ist, lass den User rein.

Da hab ich n bisschen langsam getippt. Versuch nicht über den Ort wo sich ein Benutzerobjekt im Baum befindet zu regeln was der darf, tus über die Eigenschaften des Objekts.

Grüz!
Hibbelharry

Zitat von Hibbelharry

Es gibt mehrere Wege die nach Rom führen. Beispielsweise geht das so:
Du erzeugst dir für jeden Benutzer ein Objekt in deinem LDAP Baum. Also zb cn=HansDampf,cn=Users, dc=domain,dc=local. Dein Objekt hat nun Attribute, die mögliche Liste gibt dein Schema vor, oder alle auf einmal die du lädst. Um einen Benutzer sinnvoll abzubilden z.B inetorgperson. Nun hat dein Benutzerobjekt im LDAP-Baum Attribute die du setzen kannst und die du (deine Anwendungen) lesen kannst. In einer MS-Welt würdest du jetzt zum Beispiel dem Attribut memberOf einfach die Gruppennamen kommagetrennt hinzufügen in denen der Benutzer Mitglied sein soll. OpenLDAP nimmt da glaub ich einfach das Attribut groups, heisst anders, tut dasselbe.

Bei openldap ist es best current practice LDAP Gruppen der Okjektklasse "groupOfNames" anzulegen. Diese Klasse ist im core.schema definiert:

objectclass ( 2.5.6.9 NAME 'groupOfNames'
        DESC 'RFC2256: a group of names (DNs)'
        SUP top STRUCTURAL
        MUST ( member $ cn )
        MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )

Irgendwo im Baum legt man eine ou für gruppen an, in der alle Gruppenobjekte liegen. Hier ein Beispiel eines solchen Objekts:

dn: cn=checkmkAdmins,ou=groups,dc=kokelnet,dc=de
cn: checkmkAdmins
member: uid=tobias.hachmer,ou=users,dc=kokelnet,dc=de
objectClass: groupOfNames
objectClass: top

Alle Mitglieder werden im Attribut "member" mit dem vollen DN geführt.

Das alleine macht allerdings noch nicht viel Spaß, denn wie schon gesagt wurde ist es schöner die Gruppenzugehörigkeit auch/ zusätzlich im Userobjekt selbst in einem extra Attribut zu speichern. Dafür gibt es das overlay "memberof" Link! Dieses Overlay sorgt dafür, dass immer dann wenn man ein Objekt einer Gruppe hinzufügt im Objekt selbst ein Attribut mit dem DN der Gruppe hinzugefügt wird. Kümmert sich also um das Rückwärtsmapping, um die referentielle Integrität aufrecht zu erhalten. Im obigen Beispiel also:

dn: uid=tobias.hachmer,ou=users,dc=kokelnet,dc=de
structuralObjectClass: inetOrgPerson
memberOf: cn=checkmkAdmins,ou=groups,dc=kokelnet,dc=de

Hier wird standardmäßig auch das memberOf Attribut verwendet. Das ist wohlgemerkt ein operational attribute, wird also nicht beim normalen ldapsearch angezeigt, es sei denn man fordert es explizit an oder fordert die operational attributes an(+).

Beispiel Konfiguration des memberOf Overlays (slapd.conf):

overlay memberof
memberof-dangling error
memberof-refint true
memberof-dn cn=memberof-overlay

Dann kann man auch in den Anwendungen entsprechende Suchfilter benutzen, um Gruppenmitgliedsschaften abzufragen, wie z.B. (&(objectClass=inetOrgPerson)(memberOf=cn=checkmkAdmins,ou=groups,dc=kokelnet,dc=de))

Gruß, Kokel

Hab ich auch noch wieder was gelernt. Mein letztes mal OpenLDAP ist etwas her

Grüz!
Hibbelharry

Hallo gigadevil,

Zitat von gigadevil

kokel:
cool, ich glaub ich habs jetzt verstanden. leider hab ich noch ein problem. ich hab keine slapd.conf, in den conf-files steht überall ich soll ldapmodify verwenden. ich hab

Gut, dann verwendet dein openldap server statt der slapd.conf Konfiguration die neue Online Konfiguration (olcDatabase). Dabei wird die gesamte Konfiguration in einer extra Datenbank verwaltet, also auch in Objekten.
Diese bearbeitest du genau wie die normale Datenbank auch mit den ldap utils. Wenn du jetzt also deine Konfiguration anzeigen lassen willst machst du ein ldapsearch mit dem basedn "cn=config".

Zitat von gigadevil

gibts eine möglichkeit zu überprüfen, welche overlays ldap geladen hat?

führe ein ldapsearch mit dem basedn cn=config aus oder verbinde dich mit dem apacheds studio eben mit dieser Datenbank statt dem "richtigen" DIT.

Zitat von gigadevil

EDIT:
wenn ich versuche mal manuell auf einem user (object-class: inetOrgPerson) das attribute 'memberOf' anzulegen, sagt er, dass das attribut nicht im schema definiert ist.

Das Attribut kennt openldap erst, wenn das overlay geladen ist.

Dokumentation zur Online Konfiguration: http://www.openldap.org/doc/admin24/slapdconf2.html

Gruß, Kokel