Egroupware 1.6 LDAP Authentifizierung

[agrobles]

Hallo Ralf Becker,

folgende Konstellation.

egroupware Installation 1.6.002 auf Redhat Server 5.5

Die Authentifizierung wird mittels LDAP zu einem separaten LDAP-Server durchgeführt, die Benutzerkonten werden dann in der egroupware in SQL abgespeichert.

Konstellation:

LDAP Settings in
Wenn Sie LDAP verwenden: (der egroupware)

LDAP-Host: ldap.domain.de
LDAP-Kontext für Benutzerkonten: ou=users, dc=domain, dc=de
LDAP Suchfilter für Benutzerkonten, Vorgabe “(uid=%user)”, %domain=eGW Domain: Leer

LDAP-Kontext für Gruppe: Leer

LDAP rootdn Benutzerkonten suchen und Passwörter ändern): Eintrag
LDAP-Root-Passwort: Eintrag

LDAP-Verschlüsselungstyp: DES

Die übrigen LDAP Setup Felder sind frei.

Funktion:

Es ist möglich sich mit LDAP zu authentifizieren und bei erster Anmeldung wird der Account in der SQL Datenbank generiert.

Weitere Anmeldungen sind weiterhin möglich.

Problembeschreibung:

Es soll jetzt zusätzlich zur Verifikation des Benutzers und Passwort in Users (Alle Benutzer werden hier geführt) abgefragt werden, ob besagter Benutzer zusätzlich Mitglied in einer Gruppe xyz ist.

Hierzu habe ich die zusätzliche Information:
cn=Gruppe1,OU=groups,dc=domain,dc=de

Trage ich diese Zeile in “LDAP-Kontext für Gruppe:” ein, bleibt das Verhalten beim alten, es können sich weiterhin alle Mitglieder von Users, auch wenn sie nicht in der Gruppe1 sind anmelden.

Also lasse ich diese Zeile leer und verwende die Zeile
"LDAP Suchfilter für Benutzerkonten, Vorgabe “(uid=%user)”, %domain=eGW Domain:"

Hier habe ich Suchfilter eingestellt, und erhalte in den Logs “Bad search filter”, nach Korrektur der selbigen erhalte ich dann keine solche Meldung, jedoch scheitert die Authentifizierung für Benutzer der Gruppe1 und von denen die nicht in der Gruppe1 sind, also für Alle.

Komplette Meldung zu bad serach filter:
"PHP Warning: ldap_search() [function.ldap-search]: Search: Bad search filter in … /phpgwapi/inc/class.auth_ldap.inc.php on line 58 "

Frage:

Wie erwartet egroupware die Angabe der Suchfilter hinsichtlich der Mitgliedschaft in Gruppe1 und des Attributs (hier uniquemember)?
Was benötigst du noch an Information?

Gruß,

Toni

–
GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl.
Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl

---

This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first – http://p.sf.net/sfu/sprint-com-first

---

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

[Ralf_Becker_Stylite]

EGroupware erwartet da gar nichts bestimmtes.

(&(uid=%user)(gidNumber=123))

Im obigen Beispiel könnten sich nur noch Benutzer deren primäre Gruppe
die numerische id 123 hat einlogen.

Hast Du evtl. das (uid=%user) in Deinem Filter vergessen?

Ralf

Hallo Ralf Becker,

folgende Konstellation.

egroupware Installation 1.6.002 auf Redhat Server 5.5

Die Authentifizierung wird mittels LDAP zu einem separaten LDAP-Server durchgeführt, die Benutzerkonten werden dann in der egroupware in SQL abgespeichert.

Konstellation:

LDAP Settings in
Wenn Sie LDAP verwenden: (der egroupware)

LDAP-Host: ldap.domain.de
LDAP-Kontext für Benutzerkonten: ou=users, dc=domain, dc=de
LDAP Suchfilter für Benutzerkonten, Vorgabe “(uid=%user)”, %domain=eGW Domain: Leer

LDAP-Kontext für Gruppe: Leer

LDAP rootdn Benutzerkonten suchen und Passwörter ändern): Eintrag
LDAP-Root-Passwort: Eintrag

LDAP-Verschlüsselungstyp: DES

Die übrigen LDAP Setup Felder sind frei.

Funktion:

Es ist möglich sich mit LDAP zu authentifizieren und bei erster Anmeldung wird der Account in der SQL Datenbank generiert.

Weitere Anmeldungen sind weiterhin möglich.

Problembeschreibung:

Es soll jetzt zusätzlich zur Verifikation des Benutzers und Passwort in Users (Alle Benutzer werden hier geführt) abgefragt werden, ob besagter Benutzer zusätzlich Mitglied in einer Gruppe xyz ist.

Hierzu habe ich die zusätzliche Information:
cn=Gruppe1,OU=groups,dc=domain,dc=de

Trage ich diese Zeile in “LDAP-Kontext für Gruppe:” ein, bleibt das Verhalten beim alten, es können sich weiterhin alle Mitglieder von Users, auch wenn sie nicht in der Gruppe1 sind anmelden.

Also lasse ich diese Zeile leer und verwende die Zeile
"LDAP Suchfilter für Benutzerkonten, Vorgabe “(uid=%user)”, %domain=eGW Domain:"

Hier habe ich Suchfilter eingestellt, und erhalte in den Logs “Bad search filter”, nach Korrektur der selbigen erhalte ich dann keine solche Meldung, jedoch scheitert die Authentifizierung für Benutzer der Gruppe1 und von denen die nicht in der Gruppe1 sind, also für Alle.

Komplette Meldung zu bad serach filter:
"PHP Warning: ldap_search() [function.ldap-search]: Search: Bad search filter in … /phpgwapi/inc/class.auth_ldap.inc.php on line 58 "

Frage:

Wie erwartet egroupware die Angabe der Suchfilter hinsichtlich der Mitgliedschaft in Gruppe1 und des Attributs (hier uniquemember)?
Was benötigst du noch an Information?

Gruß,

Toni

–
Ralf Becker
Director Software Development

Stylite GmbH
[open style of IT]

Morschheimer Strasse 15
67292 Kirchheimbolanden

fon +49 (0) 6352 70629-0
fax +49 (0) 6352 70629-30
mailto: rb@stylite.de

www.stylite.de
www.egroupware.org

---

Geschäftsführer Andre Keller,
Gudrun Müller, Ralf Becker
Registergericht Kaiserslautern HRB 30575
Umsatzsteuer-Id / VAT-Id: DE214280951

---

This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first – http://p.sf.net/sfu/sprint-com-first

---

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

[agrobles]

Hallo Ralf Becker,

Ausgangslage:

1. Authentifizierung mit gesetztem “LDAP-Kontext für Benutzerkonten” war möglich.
2. Authentifizierung mit gesetztem “LDAP-Kontext für Benutzerkonten” und zusätzlich gesetztem “LDAP-Kontext für Gruppe” war nicht möglich.

Hintergrund:

Alle LDAP Benutzer können sich an einer egroupware xyz über 1. anmelden und werden in einer “tempGruppe” erstellt und der Account deaktiviert sofern der Administrator den Benutzer nicht aktiviert und in die Gruppe xyz verschiebt.

Aktueller Status:
2. Ist jetzt möglich:
Es gibt LDAP Gruppen, die separat gepflegt werden und die Anmeldung an der zugehörigen egroupware ist nur möglich, wenn der Benutzer in der zugehörigen LDAP Gruppe ist.

Geänderte Dateien:

class.accounts.inc.php

Zeile 732

Beginn Ergaenzung

Bei vorhandener ldap_group_context wird das expires Datum auf never gesetzt

            if (isset($GLOBALS['egw_info']['server']['ldap_group_context']))
            {
                    $expires = "-1";
            }

Bei nicht vorhandenem ldap_group_context, der Benutzer trotz gesetzter default_group_lid in die Default Gruppe

            if (!isset($GLOBALS['egw_info']['server']['ldap_group_context']))
            {
                    $default_group_id = $this->name2id('Default');
            }

Ende Ergaenzung

class.auth_ldap.inc.php

Zeile 61

Beginn Ergaenzung

##Zusatz zur Pruefung ob der Benutzer in der Gruppe ist
$ldapDNuser=$allValues[0][‘dn’];
$sri2 = ldap_search($ldap,$GLOBALS[‘egw_info’][‘server’][‘ldap_group_context’],"(uniquemember=$ldapDNuser)" , $attributes);
$allValues2 = ldap_get_entries($ldap, $sri2);

##Definition Variable aus uniqmember Abfrage
$inGroup=$allValues2[0][‘dn’];

##Ende Ergaenzung

Zeile 86

Beginn Ergaenzung

##Auswertung ob die uniquemember Abfrage ein Ergebnis ergab und zuvor ob ldap_group_context gesetzt ist
if (isset($GLOBALS[‘egw_info’][‘server’][‘ldap_group_context’]))
{
if (!isset($inGroup))
{
return false; // UID ist nicht in der Gruppe
}
}

##Ende Ergaenzung

Da im Admin setup webinterface der ldap_group_context entfernt werden kann, habe ich den Mechanismus eingebaut, dass dann die authentifizierten Benutzer sicherheitshalber in die “tempGruppe” gelangen.

Diese Änderungen habe ich bei mir eingepflegt, laß mir/uns ein Feedback zukommen, ob und ab wann diese Änderung in die Standard Files neuer Versionen eingebunden werden bzw. es als Pacth nachgezogen werden kann.

Gruß,

Toni