LDAP & Benutzergruppen

[Adrian_Dagurashibani]

Sali zämme!

Soweit so gut - ich kriege mein egw (wie erwähnt: svn trunk r23533) dazu,
die Benutzer gegen LDAP zu authentiesieren. In der Benutzerverwaltung sehe
ich alle Benutzer und auch alle Gruppen. Allerdings gehören die Benutzer
nicht in die Gruppen.

Das LDAP-Schema ist dasjenige von SLES9.3 / OpenXchange; die
Gruppenzugehörigkeiten sind im LDAP abgelegt als:
Primäre Gruppe: “gidNumber” im Userobjekt.
Weitere Gruppen: “member” im Gruppenobjekt (multivalue-Feld, enthält die dn
aller Benutzer in dieser Gruppe.)

Gibt’s da einen Weg, dass egw diese Gruppen erkennt? Die Gruppen kommen
soweit ich sehe aus dem Standardschema welches praktisch immer verwended
wird für Benutzer-storage in LDAP unter Linux (jedenfalls war die
Gruppenzugehörigkeit nie ein Problem wenn Debian-Clients gegen den SuSE
LDAP-Server authentisiert werden.)

Gruzzos
Adrian

–
preciousssssssssssssssssssssssssssssssssssssssssssssssssssss

---

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

[TheUnicorn]

Hallo Adrian,

Soweit so gut - ich kriege mein egw (wie erwähnt: svn trunk r23533) dazu, die Benutzer gegen LDAP zu authentiesieren. In der Benutzerverwaltung sehe ich alle Benutzer und auch alle Gruppen. Allerdings gehören die Benutzer nicht in die Gruppen. [/quote] Hmmmm.... Das LDAP-Schema ist dasjenige von SLES9.3 / OpenXchange; die Gruppenzugehörigkeiten sind im LDAP abgelegt als: Primäre Gruppe: "gidNumber" im Userobjekt. Weitere Gruppen: "member" im Gruppenobjekt (multivalue-Feld, enthält die dn aller Benutzer in dieser Gruppe.) [/quote] Da fehlt noch was. In den Gruppenobjekten brauchst Du noch ein Attribut memberUid, dass die reinen Namen der Benutzer, die zur Gruppe gehören, beinhaltet. Die Gruppenobjekte sind bei mir von den ObjectClass groupOfNames, posixGroup und Top abgeleitet. Structural sind sie von groupOfNames abgeleitet.

Mfg.
Stefan

[Adrian_Dagurashibani]

Adrian von Bidder wrote:

Das LDAP-Schema ist dasjenige von SLES9.3 / OpenXchange; die
Gruppenzugehörigkeiten sind im LDAP abgelegt als:
Primäre Gruppe: “gidNumber” im Userobjekt.
Weitere Gruppen: “member” im Gruppenobjekt (multivalue-Feld, enthält
die dn
aller Benutzer in dieser Gruppe.)

Da fehlt noch was.
In den Gruppenobjekten brauchst Du noch ein Attribut memberUid, dass die
reinen Namen der Benutzer, die zur Gruppe gehören, beinhaltet.
Die Gruppenobjekte sind bei mir von den ObjectClass groupOfNames,
posixGroup und Top abgeleitet. Structural sind sie von groupOfNames
abgeleitet.

Hmm.

D.h. dann müsste ich die Gruppenmitgliedschaften doppelt ablegen oder die
LDAP-DB umbauen? Macht für mich keinen Sinn. Hast Du eine Ahnung wie
komplex es währe, member anstatt memberUid auszuwerten? Aus der dn die uid
zu isolieren ist ja trivial…

Gruss
– vbi

–
Available for key signing in Zürich and Basel, Switzerland
(what’s this? Look at http://fortytwo.ch/gpg/intro)

---

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

[TheUnicorn]

Hallo Adrian,

On Wednesday 21 March 2007 17:06, TheUnicorn wrote: > Da fehlt noch was. > In den Gruppenobjekten brauchst Du noch ein Attribut memberUid, dass die > reinen Namen der Benutzer, die zur Gruppe gehören, beinhaltet. > Die Gruppenobjekte sind bei mir von den ObjectClass groupOfNames, > posixGroup und Top abgeleitet. Structural sind sie von groupOfNames > abgeleitet.

Hmm.

D.h. dann müsste ich die Gruppenmitgliedschaften doppelt ablegen oder die
LDAP-DB umbauen? Macht für mich keinen Sinn. Hast Du eine Ahnung wie
komplex es währe, member anstatt memberUid auszuwerten? Aus der dn die uid
zu isolieren ist ja trivial…
[/quote]
Wem sagst Du das… ich habe nicht schlecht gestaunt, dass egroupware meine member aus den Gruppen gelöscht hat als die Zuordnung unter memberUid fehlte.
Es müssen beiden Einträge vorhanden sein, wieso das so implementiert wurde kann ich Dir nicht sagen. In meinen Augen absolut unnötig und fehlerbehaftet, da andere Programme das Attribut memberUid nicht kennen und die Daten damit doppelt abgelegt werden.
Aarbeitet man später mit verschiedenen Domänen wird es bestimmt Probleme geben wenn die uid gleich ist.

Im Moment hilft nur entweder egroupware zu patchen bzw. zu erweitern oder die Objekte umzubauen, so daß sie beide Attribute beinhalten.

Ich suche derzeit eine Möglichkeit den administrativen Teil der egroupware durch eigene Erweiterungen zu erweitern/ändern. eTemplate habe ich mir angeschaut, da aber auf Anhieb nichts gefunden.
Ich würde gerne die LDAP-Funktionalitäten sehr weit aufbohren, da ich in der Zwischenzeit auch die gesamten Email-Serverdaten userbezogen im LDAP ablege.

Mfg.
Stefan

[Christoph_Haas-3]

Hallo Stefan,

Es müssen beiden Einträge vorhanden sein, wieso das so implementiert wurde
kann ich Dir nicht sagen. In meinen Augen absolut unnötig und
fehlerbehaftet, da andere Programme das Attribut memberUid nicht kennen und
die Daten damit doppelt abgelegt werden.

ich denke, das hat seinen Ursprung darin, dass das nis.schema in vielen
LDAP-faehigen Anwendungen Standard ist und eben (noch) nicht das
rfc2307bis.schema. Die LDAP-Unterstuetzung ín eGroupWare wurde ja seit
v1.2, das ja das nis.schema und das phpgwapi.schema verwendete,
ziemlich aufgebohrt. Fuer die Gruppenadressbuecher sind aber
member-Attribute mit vollstaendiger cn notwendig.

Aarbeitet man später mit verschiedenen Domänen wird es bestimmt Probleme
geben wenn die uid gleich ist.

gut moeglich

Im Moment hilft nur entweder egroupware zu patchen bzw. zu erweitern oder
die Objekte umzubauen, so daß sie beide Attribute beinhalten.

Ich suche derzeit eine Möglichkeit den administrativen Teil der egroupware
durch eigene Erweiterungen zu erweitern/ändern. eTemplate habe ich mir
angeschaut, da aber auf Anhieb nichts gefunden.
Ich würde gerne die LDAP-Funktionalitäten sehr weit aufbohren, da ich in der
Zwischenzeit auch die gesamten Email-Serverdaten userbezogen im LDAP ablege.

ich verwende GOsa 2.5.8 (http://www.project-gosa.org) mit einem Patch
von Manuel Zach, der bewirkt, dass GOsa mit dem rfc2307bis.schema klar
kommt und in LDAP-Gruppen sowohl das memberUid-, als auch das
member-Attribut mit groupOfnames eintraegt.

HTH
Christoph.

Mit freundlichen Gruessen / Yours sincerely
Christoph Haas
Linux User #99546
GnuPG-/PGP-fingerprint: 944B D713 F72F 4398 B156 8089 DA8B 68F1 1543 51C3
GnuPG-/PGP-public-key:
http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0x154351C3

---

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

[TheUnicorn]

Hallo Christoph,

ich denke, das hat seinen Ursprung darin, dass das nis.schema in vielen LDAP-faehigen Anwendungen Standard ist und eben (noch) nicht das rfc2307bis.schema. Die LDAP-Unterstuetzung ín eGroupWare wurde ja seit v1.2, das ja das nis.schema und das phpgwapi.schema verwendete, ziemlich aufgebohrt. Fuer die Gruppenadressbuecher sind aber member-Attribute mit vollstaendiger cn notwendig. [/quote] Laut rfc2307bis.schema gibt es das Teil nur um PosixGoup zusammen mit groupOfNames einsetzen zu können. So steht es jedenfalls im Header. PosixGroup wird anscheinend nur aus Kompatibilitätszwecken (Attribut memberUid) verwendet und man könnte meines Erachtens darauf verzichten. > Arbeitet man später mit verschiedenen Domänen wird es bestimmt Probleme > geben wenn die uid gleich ist. gut moeglich [/quote] Genau deshalb sollte man darauf verzichten. Unabhängig davon wird ein LDAP-Verzeichnis ja nicht unbedingt nur für eGroupware verwendet. Schlimm dabei ist auch, dass eGroupware in einer Gruppe Einträge mit dem Attribut member rausschmeißt wenn das dazugehörige memberUid Attribut fehlt. Eine Syncronisierung wäre hier besser. Entweder beide sind vorhanden, das fehlende Attribut wird nachgetragen oder gar kein Eintrag ist vorhanden. > Ich würde gerne die LDAP-Funktionalitäten sehr weit aufbohren, da ich in der > Zwischenzeit auch die gesamten Email-Serverdaten userbezogen im LDAP ablege. ich verwende GOsa 2.5.8 (http://www.project-gosa.org) mit einem Patch von Manuel Zach, der bewirkt, dass GOsa mit dem rfc2307bis.schema klar kommt und in LDAP-Gruppen sowohl das memberUid-, als auch das member-Attribut mit groupOfnames eintraegt. [/quote] Habe es mir kurz angeschaut (übrigens https://www.gosa-project.org). Werde aber daraus nicht schlau, es wird nicht viel wichtiges erwähnt (Aufbau eines LDAP-Baums o.ä.) und um Features herauszubekommen ein komplettes Handbuch lesen ?!?.

Ich habe die gesamte Konfiguration, die für Filter und für das Abholen von einer beliebigen Anzahl von POP3/IMAP Postfächern samt verschicken per SMTP usw. pro User ins LDAP gehoben. Im Moment behelfe ich mir mit phpLDAPAdmin zur Administration, das ist aber nicht 100% das wahre

Mfg.
Stefan

[haary]

Hallo,

ich denke, das hat seinen Ursprung darin, dass das nis.schema in vielen LDAP-faehigen Anwendungen Standard ist und eben (noch) nicht das rfc2307bis.schema. Die LDAP-Unterstuetzung ín eGroupWare wurde ja seit v1.2, das ja das nis.schema und das phpgwapi.schema verwendete, ziemlich aufgebohrt. Fuer die Gruppenadressbuecher sind aber member-Attribute mit vollstaendiger cn notwendig. [/quote] Laut rfc2307bis.schema gibt es das Teil nur um PosixGoup zusammen mit groupOfNames einsetzen zu können. So steht es jedenfalls im Header. PosixGroup wird anscheinend nur aus Kompatibilitätszwecken (Attribut memberUid) verwendet und man könnte meines Erachtens darauf verzichten.

[/quote]

Ganz so einfach ist es selbst bei Frontends mit rfc2307bis.schema Unterstützung nicht. Wir verwenden hier z. B. LdapAdmin unter Windows, welches rfc2307bis.schema unterstützt. Jedoch verwendet LdapAdmin (und zahlreiche andere Frontends auch) als strukturelles Object für Gruppen nicht groupOfNames, sondern groupOfUniqueNames - und damit kann eGW nicht umgehen.

Tatsächlich scheint noch strittig, ob groupOfNames oder groupOfUniqueNames für Gruppen benutzt werden soll. Rfc2307bis ist ja auch noch kein verbindlicher Standard.

Damit haben wir jedoch den Inkompatibilitäts-GAU. Wenn man LDAP so verwendet, wie sich die eGW-Entwickler das vorstellen, werden viele LDAP-Tools und Frontends nicht mehr funktionieren. Wenn man LDAP nicht nur für eGW einsetzt, sondern z. B. auch als Backend für einen Samba-Domänencontroller ist es schlicht und einfach nicht empfehlenswert, eGW 1.4 einzusetzen.

Als Ausweg bleibt in dem Fall:

• LDAP nicht als Backend für eGW 1.4 zu benutzen (oder nur ausschließlich)
• Bei eGW 1.2 bleiben
• Einen Patch abwarten oder selbst schreiben, damit eGW 1.4 zusammen mit nis.schema benutzt werden kann.

Gruss,
Henry

[TheUnicorn]

Hi,

Ganz so einfach ist es selbst bei Frontends mit rfc2307bis.schema Unterstützung nicht. Wir verwenden hier z. B. LdapAdmin unter Windows, welches rfc2307bis.schema unterstützt. Jedoch verwendet LdapAdmin (und zahlreiche andere Frontends auch) als strukturelles Object für Gruppen nicht groupOfNames, sondern groupOfUniqueNames - und damit kann eGW nicht umgehen.

Tatsächlich scheint noch strittig, ob groupOfNames oder groupOfUniqueNames für Gruppen benutzt werden soll. Rfc2307bis ist ja auch noch kein verbindlicher Standard.

Damit haben wir jedoch den Inkompatibilitäts-GAU. Wenn man LDAP so verwendet, wie sich die eGW-Entwickler das vorstellen, werden viele LDAP-Tools und Frontends nicht mehr funktionieren. Wenn man LDAP nicht nur für eGW einsetzt, sondern z. B. auch als Backend für einen Samba-Domänencontroller ist es schlicht und einfach nicht empfehlenswert, eGW 1.4 einzusetzen.

Als Ausweg bleibt in dem Fall:

• LDAP nicht als Backend für eGW 1.4 zu benutzen (oder nur ausschließlich)
• Bei eGW 1.2 bleiben
• Einen Patch abwarten oder selbst schreiben, damit eGW 1.4 zusammen mit nis.schema benutzt werden kann.
  [/quote]

Wenn es danach ginge dürfte man eGW gar nicht mit LDAP verwenden, da die Gundlage der Guppenobjekte immer noch das Attribut member ist und die 1.4 Einträge im groupOfNames Attribut, die kein zugehörigen Eintrag im Attribut member haben, einfach gelöscht werden.

Eigentlich ist es für die Entwickler relativ einfach die von Dir geforderte Unterstützung einzubauen, da die Abfrage auf die Existenz des Attibutes groupOfNames schon existiert. Das Attribut member wird eigentlich gar nicht gebraucht, da die UID einfach zu extrahieren ist. Und dann müsste man nur noch konfigurieren können ob groupOfNames und/oder groupOfUniqueNames verwendet werden sollen. Wenn beide verwendet werden sollen muß definiert werden welches Attribut das Hauptattribut ist, das andere muß jedesmal entsprechend angepasst werden.

Ich beschäftige mich gerade mit diesem Thema in eGW, blicke aber noch kaum durch.

Wäre schön wenn sich einer der Entwickler hier beteiligen würde. Ev. kann man dann die notwendigen Änderungen besprechen um eGW zukünftig kompatibler zu gestalten.

Mfg.
Stefan

[TheUnicorn]

Ich beschäftige mich gerade mit diesem Thema in eGW, blicke aber noch kaum durch. [/quote]

So… langsam habe ich mich ein kleines bisschen eingearbeitet…
Da ich erheblich mehr Informationen im LDAP-Verzeichnis unterhalb eines Benutzerobjektes ablege ist es essentiell für mich, dass beim Löschen des Benutzers auch alle Objekte unterhalb des Benutzerobjektes gelöscht werden.

Hier eine Erweiterung für die Datei phpgwapi/inc/class.accounts_ldap.inc.php um beim Löschen eines Benutzers alle Objekte unterhalb des Benutzers rekursiv zu löschen:

    /*
     *
     * Change: Stefan Klatt, 24.03.2007
     *
     * Delete recursive LDAP-Trees
     *
     */
    function myldap_delete($dn)
    {
            $list=ldap_list($this->$ds,$dn,"objectClass=*",array(""));
            $entries = ldap_get_entries($this->$ds, $list);
            for($i=0;$i<$entries['count'];$i++)
            {
                    $result=$this->myldap_delete($this->ds,$entries[$i]['dn'],$recursive);
                    if(!$result) return($result);
            }
            return(ldap_delete($this->$ds,$dn));
    }

In der Funktion delete($account_id) muss die letzte Zeile mit dem return wie folgt geändert/ersetzt werden:

Original:

    return ldap_delete($this->ds,$allValues[0]['dn']);

Neu:

    return $this->myldap_delete($allValues[0]['dn']);

Kann mir irgendwer dabei helfen die Administration der Benutzer zu erweitern? Das ist noch ein Rätsel für mich.

Mfg.
Stefan

[TheUnicorn]

Ganz so einfach ist es selbst bei Frontends mit rfc2307bis.schema Unterstützung nicht. Wir verwenden hier z. B. LdapAdmin unter Windows, welches rfc2307bis.schema unterstützt. Jedoch verwendet LdapAdmin (und zahlreiche andere Frontends auch) als strukturelles Object für Gruppen nicht groupOfNames, sondern groupOfUniqueNames - und damit kann eGW nicht umgehen.

Tatsächlich scheint noch strittig, ob groupOfNames oder groupOfUniqueNames für Gruppen benutzt werden soll. Rfc2307bis ist ja auch noch kein verbindlicher Standard.
[/quote]
Hmm… interessanter Weise verwendet selbst openldap für ACLs (group.expand) groupOfNames. groupOfUniqueNames funktioniert hier nicht, habe ich eben sicherheitshalber ausprobiert. Für openldap macht es eGroupware wohl richtig.

Wie sieht das bei bei anderen LDAP-Servern aus?

Mfg.
Stefan