Hi Dieter, @Andreas, den nscd hab ich bislang noch laufen Am Di 30.Oktober 2007 15:07:07 schrieb Dieter Kluenter:

Falk Sauer writes:

...

hat irgendwer eine 10.3 mit LDAP Authentifizierung laufen? Ich hab schon alle Verdächtigen (nsswitch.conf, pam, ldap.conf) duchgesehen aber ein Problem bleibt hartnäckig:

welche ldap.conf? Für dieses Problem ist nur /etc/ldap.conf wichtig, nicht aber /etc/openldap/ldap.conf

nur die /etc/ldap.conf, der ldap server ist auf einer 10.0 und geht mit ebendieser ganz hervorragend.

...

1. getent group liefert mir alle gruppen. 2. id username liefert nur die haupt-gruppe des users, nicht die anderen Gruppenmitgliedschaften des users.

Das kann mehrere Ursachen haben, ich weiss nicht wie SuSE die Gruppenmitgliedschaften organisiert, als Attribut des Users oder der User als member Attribut der Gruppe. Wenn der User als member Attributwert verwaltet wird, ist ein zweiter Suchlauf notwendig.

ein 2. suchlauf? Die user stehen in ou=Users,dc=example,dc=de, die Gruppen in ou=Groups,dc=example,dc=de als memberUid Attribut in cn's - den gruppen. Wie stösst man denn da einen 2. suchlauf an? Wie gesagt bei der 10.0 geht das einfach so.

...

aus 1. schließe ich das der dn für die gruppen in der ldap.conf richtig angegeben ist. Wo aber der Unterschied zwischen 1 und 2 herrühren könnte kann ich mir derzeit nicht so recht erklären. Logfiles geben nichts her, ein Debug 9999 in der ldap.conf zeigt das bei beiden Abfragen (getent,id) die gruppeninfos vom ldap server anscheinend abgerufen werden.

Diesen Loglevel gibt es nicht und ein Eintrag in ldap.conf (egal welcher der beiden) wird nicht von slapd ausgelesen, die einzige Stelle ist slapd.conf, oder noch besser direkt in's config backend schreiben.

nein, der lokale client loggt dann wie ein wilder.

...

Die Konfiguration habe ich mit yast gemacht und anschließend an den besagten Stellen mehrfach kontrolliert, schaut alles sinnvoll und schlüssig aus.

Da hat Yast seine Grenzen.

das fürchte ich auch, aber ich hatte gehofft das das mittlerweile geht.

Mache doch einfach mal als rootdn ein ldapsearch auf den gesamten Inhalt (sofern du nicht einige Tausend Einträge hast) und sieh dir die Einträge an. ldapsearch -x -D "cn=<dein rootdn> -w <rootpw> -H ldap://localhost -b "<dein suffix> -s sub "*" +

ich denke das die Einträge im ldap ok sind weil es ja mit einer anderen 10.0 prima geht, und wie gesagt der getent group bringt alle gruppen, nur der id nicht. Gruss Falk -- MfG. Falk Sauer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hi Dieter, Am Di 30.Oktober 2007 19:50:35 schrieb Dieter Kluenter:

Falk Sauer writes:

OK, dann vergleiche mal beide ldap.conf genau, insbesondere die Werte für pam_groupdn, pam_member_attribute, nss_schema

mach ich, aber wie gesagt, nächste Woche.

...

...

...

1. getent group liefert mir alle gruppen. 2. id username liefert nur die haupt-gruppe des users, nicht die anderen Gruppenmitgliedschaften des users.

Möglicherweise muss da der Suchfilter in ldap.conf verändert Werden. Welcher Wert hat denn pam_filter.

schau ich nach

...

...

Das kann mehrere Ursachen haben, ich weiss nicht wie SuSE die Gruppenmitgliedschaften organisiert, als Attribut des Users oder der User als member Attribut der Gruppe. Wenn der User als member Attributwert verwaltet wird, ist ein zweiter Suchlauf notwendig.

zur Struktur siehe Antwort an Arno.

...

ein 2. suchlauf? Die user stehen in ou=Users,dc=example,dc=de, die Gruppen in ou=Groups,dc=example,dc=de als memberUid Attribut in cn's - den gruppen.

Wie stösst man denn da einen 2. suchlauf an?

In simpel gesprochen macht id ein ldapsearch mit dem attribut uid=foo unter dem in ldap.conf definierten Zweig nss_base_passwd und nss_base_shadow und bekommt dann die entsprechenden Werte aus dem Eintrag von uid=foo zurückgeliefert, getent group sucht nach im ldap.conf definierten Zweig nss_base_group und sucht nach dem pam_member_attribute

Um beides zu verbinden, kann man in ldap.conf pam_filter einen entsprechenden Suchfilter definieren.

ok, jetzt kommen wir der Sache Verständismäßig gaanz langsam näher, was mir dabei nicht ganz klar ist, ist was zb. id von dem ldap genau für ein Ergebnis erwartet. Wenn zb. die Abfrage nach uid=foo Ergebnisse liefert für uidNumber=1234,gidNumber=5678 etc. sollten dann die Ergebnisse für weitere Gruppen also gleich mit kommen? Oder in simpel sprech: der getent group geht nur auf den nss_base_group los und kriegt von dem _nur_ Gruppen und der id will von dem nss_base_passwd alles für diesen User in einem haben und schaut selber nicht nach dem was in nss_base_group steht? das würde bedeuten das bei pam_filter praktisch sowas ähnliches mit drin stehen müsste: sub ?(&(objectClass=PosixGroup)(memberUid=foo)(gidNumber=*)) wobei mir noch völlig unklar ist wie ich den Teil der bis jetzt funktioniert (aus dem ou=Users,dc=example,dc=de) dazu packe und wie ich die Variable foo nach der aktuell gesucht wird an den Filter zu übergeben habe. Das was bei man ldap.conf kommt ist nicht mal ein bruchteil von dem was in einer /etc/ldap.conf schon von Haus aus drin steht, gibts irgendwo was zum Nachlesen mit Beispielen wo auch die Parameter drin stehen die du anführst?

...

...

Diesen Loglevel gibt es nicht und ein Eintrag in ldap.conf (egal welcher der beiden) wird nicht von slapd ausgelesen, die einzige Stelle ist slapd.conf, oder noch besser direkt in's config backend schreiben.

nein, der lokale client loggt dann wie ein wilder.

Das verstehe ich nicht, welcher lokale client loggt wohin und was

der lokale LDAP Client (nehme ich an) beim Ausführen von id oder getent auf stderr, das 'was' kann ich dir nächste Woche posten. Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hi Andreas, Am Mi 31.Oktober 2007 23:12:07 schrieb Andreas Koenecke:

* Mittwoch, 31. Oktober 2007 um 16:05 (+0100) schrieb Falk Sauer:

...

Am Di 30.Oktober 2007 19:50:35 schrieb Dieter Kluenter:

ok, jetzt kommen wir der Sache Verständismäßig gaanz langsam näher, was mir dabei nicht ganz klar ist, ist was zb. id von dem ldap genau für ein Ergebnis erwartet.

Wenn zb. die Abfrage nach uid=foo Ergebnisse liefert für uidNumber=1234,gidNumber=5678 etc. sollten dann die Ergebnisse für weitere Gruppen also gleich mit kommen?

AFAIK nein.

hmm

...

Oder in simpel sprech: der getent group geht nur auf den nss_base_group los und kriegt von dem _nur_ Gruppen und der id will von dem nss_base_passwd alles für diesen User in einem haben und schaut selber nicht nach dem was in nss_base_group steht?

Ebenfalls AFAIK nein: Wenn 'id' (über libnss_ldap) zuerst nach den Userdaten sucht, wird "nss_base_passwd" als Suchbasis benutzt und wenn es danach die Gruppendaten sucht, dann wird "nss_base_group" benutzt.

das würde ja heißen das das setting in Ordnung sein sollte.

"pam_filter" hat mit den Gruppendaten nichts zu tun, es wird nur für die Suche nach den Userdaten verwendet. Wenn dort etwas falsch (oder in "pam_login_attribute") würde dir IMHO ein 'id' gar keine Daten ausgeben (bzw. ein "no such user").

...

Das was bei man ldap.conf kommt ist nicht mal ein bruchteil von dem was in einer /etc/ldap.conf schon von Haus aus drin steht, gibts irgendwo was zum Nachlesen mit Beispielen wo auch die Parameter drin stehen die du anführst?

'man ldap.conf' beschreibt "/etc/openldap/ldap.conf". Was du suchst, findest du mit 'man pam_ldap' und 'man nss_ldap'.

danke!

BTW: Mein Favorit für den Fehler ist immer noch der 'nscd'...

Der ist auf der funktionierenden 10.0 aber nicht abgestellt, das habe ich gerade eben nachgeschaut. ich halt euch auf jeden Fall auf dem Laufenden. Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hi Andreas, Am Di 30.Oktober 2007 20:06:07 schrieb Andreas Kyek:

Am Dienstag 30 Oktober 2007 schrieb Falk Sauer:

...

...

...

1. getent group liefert mir alle gruppen. 2. id username liefert nur die haupt-gruppe des users, nicht die anderen Gruppenmitgliedschaften des users.

[...]

Das klingt doch ganz genau wie der Fehler, der sich in der 10.2 durch ein clib-Update eingeschlichen hat (und AFAIK werden viele Fixes parallel in verschiedenen openSUSE Versionen eingespielt)

siehe http://lists.opensuse.org/opensuse-de/2007-10/msg01017.html oder http://lists.opensuse.org/opensuse-de/2007-10/msg01072.html

Ob's eine ähnliche Lösung für die 10.3 gibt, kann ich mangels 10.3 nicht sagen.

Das sind ja Aussichten ... Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hi Arno, Am Di 30.Oktober 2007 21:28:30 schrieb Arno Lehmann:

30.10.2007 16:58,, Falk Sauer wrote::

Im Moment habe ich einen SUSE 9.2 und einen 10.3 Server hier laufen. Beide beziehen die Benutzeraccounts per LDAP mit dem SUSE-Schema, d.h. in ou=group,dc=xxx,dc=de stehen Sachen wie dn: cn=its,ou=group,dc=xxx,dc=de cn: its gidNumber: 2001 member: uid=its-info,ou=people,dc=xxx,dc=de member: uid=its-admin,ou=people,dc=xxx,dc=de member: uid=arno,ou=people,dc=xxx,dc=de member: uid=its-al,ou=people,dc=xxx,dc=de objectClass: top objectClass: posixGroup objectClass: groupOfNames

für die Gruppen.

ok hier hätten wir schon einen Unterschied, ich verwende die Struktur die bei samba empfohlen wird: in ou=Groups,dc=excample,dc=de dn: cn=Gruppenname,ou=Groups,dc=example,dc=de cn: Gruppenname gidNumber: 0815 memberUid: falk memberUid: test usw. die objectClass hab ich jetzt nicht im Kopf

Hier nicht:

...

arno@elf:~> id uid=1000(arno) gid=100(users) Gruppen=100(users),1999(admins),2001(its) arno@elf:~> id weranders uid=1002(weranders) gid=100(users) Gruppen=100(users)

Exakt identische Ausgabe auf beiden Systemen; so solls ja auch sein, geht ja gegen das gleiche LDAP-Backend...

hab ich leider nur auf der 10.0 so

...

...

Wenn der User als member Attributwert verwaltet wird, ist ein zweiter Suchlauf notwendig.

ein 2. suchlauf?

Ja, zuerst wird der geforderte user im ou=people,...-Subtree gesucht und gefunden.

Dann werden im ou=group,...-Subtree alle Gruppen mit diesem Member gesucht.

...

Die user stehen in ou=Users,dc=example,dc=de, die Gruppen in ou=Groups,dc=example,dc=de als memberUid Attribut in cn's - den gruppen.

...

...

Diesen Loglevel gibt es nicht und ein Eintrag in ldap.conf (egal welcher der beiden) wird nicht von slapd ausgelesen, die einzige Stelle ist slapd.conf, oder noch besser direkt in's config backend schreiben.

nein, der lokale client loggt dann wie ein wilder.

Zufall, bei dem Loglevel :-) Hier gilt nicht "viel hilft viel", sondern es geht um die richtigen Bits in der LogLevel-Zahl.

ok, dann probiere ich nächste woche mal ne sehr große hexzahl mit vielen einsen in dezimalschreibweise.

...

ich denke das die Einträge im ldap ok sind weil es ja mit einer anderen 10.0 prima geht, und wie gesagt der getent group bringt alle gruppen, nur der id nicht.

Hast du ein anderes System in greifbarere Nähe das du mal testhalber mit dem LDAP-Server als Backend ausprobieren könntest?

ich kann das unmodifizierte System was auf der gleichen VM liegt nächste woche mal duplizieren und nochmal einen jungfäulichen test anwerfen. Oder mal eine VM bauen die nur aus Files von der CD besteht, ohne updates, nicht das es wirklich das Problem mit der glibc ist ... Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hi Dieter, Dieter Kluenter schrieb:

Falk Sauer writes:

...

Am Di 30.Oktober 2007 21:28:30 schrieb Arno Lehmann:

...

30.10.2007 16:58,, Falk Sauer wrote::

Im Moment habe ich einen SUSE 9.2 und einen 10.3 Server hier laufen. Beide beziehen die Benutzeraccounts per LDAP mit dem SUSE-Schema, d.h. in ou=group,dc=xxx,dc=de stehen Sachen wie dn: cn=its,ou=group,dc=xxx,dc=de cn: its gidNumber: 2001 member: uid=its-info,ou=people,dc=xxx,dc=de member: uid=its-admin,ou=people,dc=xxx,dc=de member: uid=arno,ou=people,dc=xxx,dc=de member: uid=its-al,ou=people,dc=xxx,dc=de objectClass: top objectClass: posixGroup objectClass: groupOfNames

Da wird zwar posixGroup eingebunden, aber das Attribut member gehört zur Klasse groupOfNames, nur gidNumber ist der posixGroup Klasse entnommen.

...

...

für die Gruppen. ok hier hätten wir schon einen Unterschied, ich verwende die Struktur die bei samba empfohlen wird:

in ou=Groups,dc=excample,dc=de dn: cn=Gruppenname,ou=Groups,dc=example,dc=de cn: Gruppenname gidNumber: 0815 memberUid: falk memberUid: test usw.

die objectClass hab ich jetzt nicht im Kopf

Das ist posixGroup, eine auxiliary Klasse, da die entsprechende Samba Objektklasse sambaSamAccount ebenfalls auxiliary ist muss noch eine strukturelle Objektklasse eingebunden sein.

Ich hab mir das Problem nochmal vorgenommen, und nach dem intensiven Betrachten der alten ldap.conf und eurer tipps bin ich dann auf folgende funktionierende version gekommen. host ldapserver.example.de base dc=example,dc=de ldap_version 3 binddn cn=Manager,dc=example,dc=de bindpw gazfurchtbargeheim rootbinddn cn=Manager,dc=example,dc=de port 389 pam_filter objectclass=posixAccount pam_login_attribute uid pam_member_attribute memberuid pam_password exop nss_map_attribute uniqueMember member nss_base_passwd ou=Users,dc=example,dc=de?one nss_base_shadow ou=Users,dc=example,dc=de?one nss_base_group ou=Groups,dc=example,dc=de?one Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hi Dieter, Dieter Kluenter schrieb:

Falk Sauer writes:

...

Hi Dieter,

Dieter Kluenter schrieb:

...

Falk Sauer writes:

...

Am Di 30.Oktober 2007 21:28:30 schrieb Arno Lehmann:

...

30.10.2007 16:58,, Falk Sauer wrote:: [...] dn: cn=its,ou=group,dc=xxx,dc=de cn: its gidNumber: 2001 member: uid=its-info,ou=people,dc=xxx,dc=de member: uid=its-admin,ou=people,dc=xxx,dc=de member: uid=arno,ou=people,dc=xxx,dc=de member: uid=its-al,ou=people,dc=xxx,dc=de objectClass: top objectClass: posixGroup objectClass: groupOfNames

...

Ich hab mir das Problem nochmal vorgenommen, und nach dem intensiven Betrachten der alten ldap.conf und eurer tipps bin ich dann auf folgende funktionierende version gekommen.

host ldapserver.example.de base dc=example,dc=de ldap_version 3 binddn cn=Manager,dc=example,dc=de bindpw gazfurchtbargeheim rootbinddn cn=Manager,dc=example,dc=de port 389 pam_filter objectclass=posixAccount pam_login_attribute uid pam_member_attribute memberuid pam_password exop nss_map_attribute uniqueMember member nss_base_passwd ou=Users,dc=example,dc=de?one nss_base_shadow ou=Users,dc=example,dc=de?one nss_base_group ou=Groups,dc=example,dc=de?one

Darf ich dazu noch meinen persönlichen Senf hinzufügen? rootdn darf auf dem LDAP-Server einfach alles, ist also viel zu gefährlich diese Identität in einer unkontrollierten Anwendung zu konfigurieren. Zur Administration von Prozessen habe ich diverse Administratoren definiert, z.B. cn=mailadmin, cn=sambaAdmin, usw. und diesen Administratoren Schreibrechte auf den entsprechen Subtrees eingeräumt. Zur Erläuterung mal ein Muster:

cn=systemAdministrator,dc=example,dc=de objectclass: person cn: systemAdministrator sn: systemAdministrator userPassword: xxxx

access to dn.subtree="ou=Users,dc=example,dc=de by dn.exact="cn=systemAdministrator,dc=example,dc=de" write by users read acess to dn.subtree="ou=Groups,dc=example,dc=de by dn.exact="cn=systemAdministrator,dc=example,dc=de write by users read

und in ldap.conf

binddn cn=Manager,dc=example,dc=de bindpw gazfurchtbargeheim # rootbinddn cn=Manager,dc=example,dc=de

Das hab ich hier normalerweise auch so, aber ich wollte das Zwischenergebnis nicht länger zurückhalten, und für die Fehlersuche ist es imho besser nicht noch ein potentielles Problem zu haben. Es gibt für jeden produktiven dienst einen separaten user der jeweils in einer eigenen cn unter ou=Auth,dc=example,dc=de liegt. Auf der Samba Howto seite waren damals ein paar schöne Anleitungen genau dazu verlinkt. Nachdem der Betriebssystem Teil nun geht wollte ich dann mit cyrus weiter machen, aber ich fürchte das gibt noch einen weiteren Thread. :-/ Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Hi Dieter, Dieter Kluenter schrieb:

...

Nachdem der Betriebssystem Teil nun geht wollte ich dann mit cyrus weiter machen, aber ich fürchte das gibt noch einen weiteren Thread. :-/

Darf ich dich auf das SASL auxiliary property plugin ldapdb aufmerksam machen? Hervorragend für cyrus-imap und postfix geeignet.

das auxprop plugin? Da hatte ich schon mal mit gespielt und mich dann auf die andere(n) Variante(n) verlegt weil so gar kein Erfolg sichtbar war ... leider kann ich an dem Problem derzeit nicht durchgängig dran bleiben.

Eine etwas angestaubte und nicht ganz aktuelle Doku dazu findest du in meiner sig, oder warte bis Ende November und opfere € 39,-- :-)

Eigentlich hab ich diesen Opferstock heuer schon genug mit meiner schwer verdienten kohle bedacht, aber mal sehen was das Budget noch hergibt vor Weihnachten. ;-) Gruss Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org