Re: Benutzer-Authentifizierung über LDAP
Markus Hubig [EMAIL PROTECTED] writes: Hi, Das heisst Du hast *KEIN* libpam-ldap auf deinem Laptop, und kannst dich trozdem mit Benutzernamen anmelden die *NUR* im LDAP existieren und nicht in /etc/passwd usw. ... ?! Das würde ja dann beweissen das libpam-ldap unnötig ist ... aber ich denke dass geht nicht! Wenn ich z.B. in /etc/pam.d/ssh die pam_ldap.so Einträge entferne kann ich mich per ssh *NICHT* mehr mit LDAP-Only Usernamen einloggen ... tja, ich habe gar kein libpam-ldap :)) und funktionieren tut es natürlich sonst wäre ich unglücklich. Ich werde trotzdem mir die Tage etwas in die PAM einlesen wielleicht ist das ein Zuffal (BUG) Pozdrawiam/Gruß/Regards Robert Rakowicz -- Robert Rakowicz E-Mail: [EMAIL PROTECTED] URL:www.rjap.de -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Benutzer-Authentifizierung über LDAP
On Fri, 06 Sep 2002, Robert Rakowicz wrote: Markus Hubig [EMAIL PROTECTED] writes: [..] ... dass zuerst versucht wird, die Informationen von einem LDAP-Server zu bekommen und nur wenn das nicht klappt die Befragung von /etc/* vorgenommen wird. Der NSSWITCH ist IMHO dafür zuständig dass Systemaufrufe wie gethostbyname usw. ihre Infos (auch?) vom LDAP-Server bekommen. Also wird beides benötigt ... bist Dir ganz sicher ? Ich habe nur das Paket libnss-ldap installiert und ensprechend meine /etc/ldap/ldap.conf und /etc/libnss-ldap.conf /etc/nsswitch.conf verändert. Jetzt wenn Ich z.B mit dem Laptop unterwegs bin kann ich mich trotzdem anmelden. Das heisst Du hast *KEIN* libpam-ldap auf deinem Laptop, und kannst dich trozdem mit Benutzernamen anmelden die *NUR* im LDAP existieren und nicht in /etc/passwd usw. ... ?! Das würde ja dann beweissen das libpam-ldap unnötig ist ... aber ich denke dass geht nicht! Wenn ich z.B. in /etc/pam.d/ssh die pam_ldap.so Einträge entferne kann ich mich per ssh *NICHT* mehr mit LDAP-Only Usernamen einloggen ... Gruß, Markus -- Life is a sexually transmitted disease. msg18068/pgp0.pgp Description: PGP signature
Re: Benutzer-Authentifizierung über LDAP
Markus Hubig [EMAIL PROTECTED] writes: [...] Wenn ich mich als normaler User eingeloggt habe liefert | getent passwd username Den Eintrag aus /etc/passwd oder nichts, wenn der abgefragte Username nur im LDAP existiert. Wenn ich mich dagegen als root einlogge liefert | getent passwd username Zuverlässig den Eintrag aus dem LDAP (wenn _ldap_ vor _file_ in der nsswitch.conf). Jetzt ist nur die Frage: Liegt es an der libnss-ldap (/etc/libnss-ldap.conf unverändert) oder an den ACL-Settings in slapd.conf? Zum Zugriff auf den LDAP benutzen NSS und PAM die Einstellungen von /etc/ldap.conf, unabhängig vom Nutzer, der z.B. getent aufruft. Falls du nscd zu laufen hast, schalte den mal testweise ab. Ansonsten habe ich leider keine Idee, was bei dir schieflaufen könnte. Wenn du ein bißchen probieren willst, rufe beide getent (als Root und als normaler Nutzer) mit strace auf und vergleiche die Ergebnisse. Vielleicht gibt es ja irgendwo eine Datei, die nicht gelesen werden darf. Torsten -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Benutzer-Authentifizierung über LDAP
Markus Hubig schrieb:
Ich dachte eigentlich ich nutze hier Passwörter im MD5 Format. Aber
es scheint mit {crypt} zu funzen ... ;-)
MD5 Passwörter kannst Du daran erkennen, dass Sie mit $1$ beginnen.
--
[EMAIL PROTECTED]
--
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Benutzer-Authentifizierung über LDAP
On Fri, 06 Sep 2002, Torsten Hilbrich wrote: [...] Wenn du ein bißchen probieren willst, rufe beide getent (als Root und als normaler Nutzer) mit strace auf und vergleiche die Ergebnisse. Vielleicht gibt es ja irgendwo eine Datei, die nicht gelesen werden darf. Genau daran hat es gelegen! Die Datei /etc/libnss-ldap.conf hatte die Rechte 0600 und konnte dadurch natürlich nicht von normalen Usern gelesen werden. Ein chmod 0644 hat das Problem behoben. ;-) Scheinbar setzt Debian die Rechte dieser Datei auf 0600 sobald der nscd installiert ist ... es gibt nämlich die Möglichkeit in dieser Datei ein bindpw Bind-Passwort abzulegen. Dass ist bei mir aber nicht der Fall, ausserdem musste jetzt nscd gehen. | getent passwd username Liefert jetzt auch als normaler User Ergebnisse aus dem LDAP. Soweit also alles in Butter. Wenn ich jetzt allerdings versuche mich mit einer UserID einzuloggen, die es nur im LDAP gibt (die entsprechende ID habe ich mit ldapadd angelegt und das Passwort mit passwd erfolgreich gesetzt) geht das immer schief mit der Meldung ... | $ ssh test@wrack | | test@wrack's password: | Permission denied, please try again. | test@wrack's password: | Permission denied, please try again. | test@wrack's password: | Permission denied (publickey,password,keyboard-interactive). Ideen? Gruß, Markus -- Ich habe einen Drachen und werde ihn benutzen! msg17995/pgp0.pgp Description: PGP signature
Re: Benutzer-Authentifizierung über LDAP
Markus Hubig [EMAIL PROTECTED] writes: [...] Wenn ich jetzt allerdings versuche mich mit einer UserID einzuloggen, die es nur im LDAP gibt (die entsprechende ID habe ich mit ldapadd angelegt und das Passwort mit passwd erfolgreich gesetzt) geht das immer schief mit der Meldung ... | $ ssh test@wrack | | test@wrack's password: | Permission denied, please try again. | test@wrack's password: | Permission denied, please try again. | test@wrack's password: | Permission denied (publickey,password,keyboard-interactive). Ideen? Inhalt von /etc/pam.d/ssh? Torsten -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Benutzer-Authentifizierung über LDAP
On Fri, 06 Sep 2002, Torsten Hilbrich wrote: Markus Hubig [EMAIL PROTECTED] writes: Wenn ich jetzt allerdings versuche mich mit einer UserID einzuloggen, die es nur im LDAP gibt (die entsprechende ID habe ich mit ldapadd angelegt und das Passwort mit passwd erfolgreich gesetzt) geht das immer schief mit der Meldung ... | $ ssh test@wrack | | test@wrack's password: | Permission denied, please try again. | test@wrack's password: | Permission denied, please try again. | test@wrack's password: | Permission denied (publickey,password,keyboard-interactive). Ideen? Inhalt von /etc/pam.d/ssh? Müsste OK sein ... | auth required pam_nologin.so | auth required pam_env.so | auth sufficient pam_ldap.so | auth required pam_unix.so | | accountsufficient pam_ldap.so | accountrequired pam_unix.so | | sessionsufficient pam_ldap.so | sessionrequired pam_unix.so | sessionrequired pam_limits.so | sessionoptional pam_lastlog.so | sessionoptional pam_motd.so | sessionoptional pam_mail.so standard noenv | | password sufficient pam_ldap.so | password required pam_unix.so Bin extra in den Keller gegangen um zu testen ob ein Consolenlogin direckt an der Maschiene mit einem LDAP-only-Account geht - funzt! Scheint also ein ssh Problem zu sein ... Gruß, Markus -- In theory there's no difference between theory and practice, but in practice... msg18005/pgp0.pgp Description: PGP signature
[SOLVED] Benutzer-Authentifizierung über LDAP
On Fri, 06 Sep 2002, Markus Hubig wrote: Bin extra in den Keller gegangen um zu testen ob ein Consolenlogin direckt an der Maschiene mit einem LDAP-only-Account geht - funzt! Scheint also ein ssh Problem zu sein ... ... das recht komplex zu Lössen war: | /etc/init.d/ssh restart Linux verändert scheinbar mit der Zeit die Erwartungen die man in Software setzt! Noch vor ein paar Jahren währe das (restart) mein erster Lösungsansatz gewesen ... ;-) Gruß und Dank an alle, Markus -- Unser Kopf ist rund, damit das Denken die Richtung wechseln kann! msg18041/pgp0.pgp Description: PGP signature
Re: Benutzer-Authentifizierung über LDAP
Markus Hubig [EMAIL PROTECTED] writes: Und nimm pam_unix vor pam_ldap, sonst könnte es Probleme z.B. mit dem Samba-Root Account geben (für Samba/LDAP muß ein User im LDAP die uidNumber 0 und die uid root haben). Das verstehe ich nicht? Wenn ich pam_unix (required) vor pam_ldap (sufficient) nehme, dann habe ich ein ähnliches Kuttel-Muddel wie mit 2x required! Und root ist bei mir auch im LDAP. Samba selbst benutzt kein PAM, sondern geht direkt zum LDAP. Obigen Punkt mußt du auch nur beachten, falls du wirklich Samba einsetzen willst. übrigens hatte Redhat 7.2 bei der Auswahl von LDAP großen Schwachsinn in /etc/pam.d/system-auth reingeschrieben, ohne laufenden LDAP-Server war kein Login mehr möglich (und da der LDAP-Server nicht automatisch gestartet wurde, ging es nicht mehr ohne single user mode weiter). Aber bei Debian gibt es ja zum Glück dieses Problem nicht. Bei mir steht überall pam_ldap mit sufficient vor pam_unix mit required. Wenn ich den LDAP-Server abschalte gibt dass aber _keine_ Probleme, pam_ldap wird dann einfach übersprungen und stattdessen pam_unix genutzt. Bei Redhat standen pam_unix *und* pam_ldap mit required drin. Den Effekt bei nicht erreichbaren LDAP-Server kannst du dir sicher gut vorstellen. Ein sufficient muß als letztes stehen. Scheinbar nicht. Siehe oben. Ein erfolgreiches sufficient in einer Kategory verhindert, daß danach stehende required der gleichen Kategorie ausgeführt werden. Hmm, weder | passwd: compat ldap | group:compat ldap noch | passwd: ldap compat | group:ldap compat bewirken da etwas ... *grübel* Was liefert getent passwd username? Interessant ist, das mir chsh als default-Shell-Vorschlag immer die Shell präsentiert welche im LDAP eingetragen ist. Benutzt (login auf der Console und über ssh) wird aber was in /etc/passwd steht!? Wer startet den nach dem Login die Shell? Vielleicht kann ich ja da ansetzen ... Leider kann ich erst wieder ab Woche 39 an meine damals vorgenommene PAM-Konfiguration ran. Dort wurden loginShell (in diesem Fall /bin/false, um ein Login zu verhindern) und homeDirectory aus dem LDAP gelesen. Ich kann mich aber daran erinnern, die RedHat 7.2 Default-Konfiguration genommen zu haben und jedes Auftreten von pam_unix um pam_ldap (beide natürlich sufficient statt required) ergänzt zu haben. Torsten -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Benutzer-Authentifizierung über LDAP
On Thu, 05 Sep 2002, Torsten Hilbrich wrote: [...] OK, ich Denke ich habe jetzt die Quelle meines loginShell-Problems herausgefunden. Und zwar ist es wohl ein Rechte Problem! Was liefert getent passwd username? Wenn ich mich als normaler User eingeloggt habe liefert | getent passwd username Den Eintrag aus /etc/passwd oder nichts, wenn der abgefragte Username nur im LDAP existiert. Wenn ich mich dagegen als root einlogge liefert | getent passwd username Zuverlässig den Eintrag aus dem LDAP (wenn _ldap_ vor _file_ in der nsswitch.conf). Jetzt ist nur die Frage: Liegt es an der libnss-ldap (/etc/libnss-ldap.conf unverändert) oder an den ACL-Settings in slapd.conf? | # /etc/ldap/slapd.conf | [...] | access to attribute=userPassword | by dn=cn=admin,dc=thoregon,dc=int write | by anonymous auth | by self write | by * none | | # The admin dn has full write access | access to * | by dn=cn=admin,dc=thoregon,dc=int write | by * read | [...] Ich Tippe ja auf libnss-ldap, habe aber im Moment keine Idee was ich da ändern könnte ... Gruß, Markus -- This is Linux Country. On a quiet night, you can hear Windows NT reboot! msg17971/pgp0.pgp Description: PGP signature
Re: Benutzer-Authentifizierung über LDAP
On Wed, 04 Sep 2002, Markus Hubig wrote: [... ldap server ...] Jo, es funzt !! Nachdem ich es jetzt geschafft habe den OpenLDAP Server ans Laufen zu bekommen und die DBs unter /etc/* integriert habe, möchte ich jetzt den LDAP-Server auch nutzen. Ich habe /etc/nsswitch.conf mit der Version aus dem libnss-ldap Packet ersetzt. Auch habe ich alles unter /etc/pam.d/* mit den Beispielen aus libpam-ldap abgeglichen. Dazu gleich mal 2 Fragen: 1. Ist es besser den password LDAP-Eintrag in /etc/pam.d/login und /etc/pam.d/passwd mit sufficient oder mit required zu machen ?? Wie habt ihr das? 2. Ein Eintrag wie: | auth requiredpam_env.so wird Ja IMHO nur ausgewertet wenn er *for* einem evtl. vorhandenen sufficient Eintrag steht. Allerdings habe ich pam_env.so in den Original /etc/pam.d/*-Configs immer *nach* einem | auth requiredpam_unix.so Eintrag gefunden. Beeinträchtigt das jetzt die Funktion von pam_env.so? Außerdem ist mir aufgefallen, wenn ich mittels gq meine Login-Shell von bash - csh ändere bewirkt das genau garnichts ... 8-( Welches PAM-Modul bzw. welcher PAM-Service ist den dafür zuständig? Session? Unterstützt pam_ldap.so den session-Service? Gruß, Markus BTW.: Kennt jemand eine gute Docu zu den PAM-Modulen? Habe schon ein wenig gegoogelt, leider wahren die Ergebnisse recht bruchstückhaft. -- To those who understand, no explanation is necessary, to those who will not understand, no explanation is possible. msg17827/pgp0.pgp Description: PGP signature
Re: Benutzer-Authentifizierung über LDAP
Markus Hubig [EMAIL PROTECTED] writes: [...] 1. Ist es besser den password LDAP-Eintrag in /etc/pam.d/login und /etc/pam.d/passwd mit sufficient oder mit required zu machen ?? Wie habt ihr das? Ich empfehle sufficient. Bei required müssen alle angegebenen Module zustimmen, bei pam_unix und pam_ldap nicht so sinnvoll. Und nimm pam_unix vor pam_ldap, sonst könnte es Probleme z.B. mit dem Samba-Root Account geben (für Samba/LDAP muß ein User im LDAP die uidNumber 0 und die uid root haben). übrigens hatte Redhat 7.2 bei der Auswahl von LDAP großen Schwachsinn in /etc/pam.d/system-auth reingeschrieben, ohne laufenden LDAP-Server war kein Login mehr möglich (und da der LDAP-Server nicht automatisch gestartet wurde, ging es nicht mehr ohne single user mode weiter). Aber bei Debian gibt es ja zum Glück dieses Problem nicht. 2. Ein Eintrag wie: | authrequiredpam_env.so wird Ja IMHO nur ausgewertet wenn er *for* einem evtl. vorhandenen sufficient Eintrag steht. Allerdings habe ich pam_env.so in den Original /etc/pam.d/*-Configs immer *nach* einem | authrequiredpam_unix.so Eintrag gefunden. Beeinträchtigt das jetzt die Funktion von pam_env.so? Ein sufficient muß als letztes stehen. Außerdem ist mir aufgefallen, wenn ich mittels gq meine Login-Shell von bash - csh ändere bewirkt das genau garnichts ... 8-( Welches PAM-Modul bzw. welcher PAM-Service ist den dafür zuständig? Session? Unterstützt pam_ldap.so den session-Service? Eigentlich sollte dies über /etc/nsswitch.conf (passwd) festgelegt werden (einfach ldap hinter dem vorherigen compat ergänzen), das zugehörige Modul ist /usr/lib/libnss_ldap.so . Torsten BTW.: Kennt jemand eine gute Docu zu den PAM-Modulen? Habe schon ein wenig gegoogelt, leider wahren die Ergebnisse recht bruchstückhaft. Schon http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html gelesen? Insbesondere Abschnitt 4.1. -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Benutzer-Authentifizierung über LDAP
On Wed, 04 Sep 2002, Torsten Hilbrich wrote: Markus Hubig [EMAIL PROTECTED] writes: 1. Ist es besser den password LDAP-Eintrag in /etc/pam.d/login und /etc/pam.d/passwd mit sufficient oder mit required zu machen ?? Wie habt ihr das? Ich empfehle sufficient. Bei required müssen alle angegebenen Module zustimmen, bei pam_unix und pam_ldap nicht so sinnvoll. Kommt darauf an. Wenn man gerne hätte dass /etc/shadow und LDAP synchron sind, dann macht das schon Sinn. Allerdings gibt das ein ziemliches Kuttel-Muddel bei der Passworteingabe ... Da muss man sich wohl etwas anderes einfallen lassen um /etc/passwd zu synchronisieren. Und nimm pam_unix vor pam_ldap, sonst könnte es Probleme z.B. mit dem Samba-Root Account geben (für Samba/LDAP muß ein User im LDAP die uidNumber 0 und die uid root haben). Das verstehe ich nicht? Wenn ich pam_unix (required) vor pam_ldap (sufficient) nehme, dann habe ich ein ähnliches Kuttel-Muddel wie mit 2x required! Und root ist bei mir auch im LDAP. übrigens hatte Redhat 7.2 bei der Auswahl von LDAP großen Schwachsinn in /etc/pam.d/system-auth reingeschrieben, ohne laufenden LDAP-Server war kein Login mehr möglich (und da der LDAP-Server nicht automatisch gestartet wurde, ging es nicht mehr ohne single user mode weiter). Aber bei Debian gibt es ja zum Glück dieses Problem nicht. Bei mir steht überall pam_ldap mit sufficient vor pam_unix mit required. Wenn ich den LDAP-Server abschalte gibt dass aber _keine_ Probleme, pam_ldap wird dann einfach übersprungen und stattdessen pam_unix genutzt. 2. Ein Eintrag wie: | auth requiredpam_env.so wird Ja IMHO nur ausgewertet wenn er *for* einem evtl. vorhandenen sufficient Eintrag steht. Allerdings habe ich pam_env.so in den Original /etc/pam.d/*-Configs immer *nach* einem | auth requiredpam_unix.so Eintrag gefunden. Beeinträchtigt das jetzt die Funktion von pam_env.so? Ein sufficient muß als letztes stehen. Scheinbar nicht. Siehe oben. Außerdem ist mir aufgefallen, wenn ich mittels gq meine Login-Shell von bash - csh ändere bewirkt das genau garnichts ... 8-( Welches PAM-Modul bzw. welcher PAM-Service ist den dafür zuständig? Session? Unterstützt pam_ldap.so den session-Service? Eigentlich sollte dies über /etc/nsswitch.conf (passwd) festgelegt werden (einfach ldap hinter dem vorherigen compat ergänzen), das zugehörige Modul ist /usr/lib/libnss_ldap.so . Hmm, weder | passwd: compat ldap | group:compat ldap noch | passwd: ldap compat | group:ldap compat bewirken da etwas ... *grübel* Interessant ist, das mir chsh als default-Shell-Vorschlag immer die Shell präsentiert welche im LDAP eingetragen ist. Benutzt (login auf der Console und über ssh) wird aber was in /etc/passwd steht!? Wer startet den nach dem Login die Shell? Vielleicht kann ich ja da ansetzen ... BTW.: Kennt jemand eine gute Docu zu den PAM-Modulen? Habe schon ein wenig gegoogelt, leider wahren die Ergebnisse recht bruchstückhaft. Schon http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html gelesen? Insbesondere Abschnitt 4.1. Jetzt ja! ;-) Gruß, Markus -- Always remember you're unique, just like everyone else. msg17842/pgp0.pgp Description: PGP signature
Benutzer-Authentifizierung über LDAP
Hi Liste, ich habe gerade angefangen einen LDAP-Server aufzusetzen, mit dem Ziel in Zukunft die Benutzer-Authentifizierung unter Linux und unter Windows (samba) darüber laufen zu lassen. Die Doku's dir ich bis jetzt dazu gelesen habe, wahren allerdings nicht wirklich hilfreich um dies unter Debian zu erreichen. Was bis jetzt geschah: Ich habe (mehr oder weniger auf Verdacht hin) folgende Pakete aus Testing installiert: | Package: slapdVersion: 2.0.23-6 | Package: nscd Version: 2.2.5-11.1 | Package: libldap2 Version: 2.0.23-9 | Package: ldap-utils Version: 2.0.23-6 | Package: libpam-ldap Version: 140-1 | Package: libnss-ldap Version: 186-1 Während der Installation habe ich zu ein paar dieser Pakete Fragen beantworten sollen: | libnss-ldap: | | distinguished Name = dn=thoregon,dn=int | LDAP Version = 3 | Wuss man sich einloggen | um den LDAP Server abzufragen? = Nein | Darf das libnss-ldap Config File | von jedem gelesen werden = Yes | | Libpam-ldap | === | Make local root Database admin = Yes | Wuss man sich einloggen | um den LDAP Server abzufragen? = No | Root login account = cn=manager,dc=thoregon,dc=int | Root Passwort= X | Passortverschlüsselung = crypt | | Open-LDAP | = | Initialisierungsmethode = auto | Verzeichnis Suffix-Stil = Domain oder Host | Domainnahmen = thoregon.int | Admin-Passwort = X | Änderungen an einen anderen Server | weitergeben = nein Ich möchte jetzt erst einmal so weit kommen dass die Benutzer-Authentifizierung unter Linux über LDAP funzt. Dabei ergeben sich 2 Probleme (die wahrscheinlich zusammenhängen): 1. Wie konvertiere ich /etc/passwd und Konsorten nach LDAP. Die Migration-Tools haben leider nicht funktioniert. Weder automatisch: | sudo ./migrate_all_online.sh | [ ... ] | Importing into LDAP... | adding new entry ou=People,dc=thoregon,dc=int | ldap_add: Already exists | | ldif_record() = 68 | /usr/bin/ldapadd: returned non-zero exit status Noch manuell: | ./migrate_services.pl /etc/services LDIF/services.ldif | | sudo ldapadd -v -D dn=uid=admin,dc=thoregon,dc=int\ |-w X -f LDIF/services.ldif | ldap_initialize( DEFAULT ) | ldap_sasl_interactive_bind_s: No such attribute 2. Ich habe wie empfohlen für libnss-ldap die LDAP Version 3 ausgewählt. Das heißt ja IMHO dass die Kommunikation und die Authentifizierung mit dem LDAP-Server Verschlüsselt abläuft. IMHO mit SASL?! Muss ich da noch irgendwas einstellen damit das funktioniert? Konnte darüber leider gar keine Infos finden. Was danach kommt ist mir relativ klar: 3. /etc/nsswitch.conf mit /usr/share/doc/libnss-ldap/examples/nsswitch.ldap ersetzen. 4. /etc/pam.d/* mit den Versionen aus /usr/share/doc/libpam-ldap/examples/pam.d/* ersetzen ... Jetzt sollte ich unter Linux den LDAP Server zur Authentifizierung nutzen können. Oder habe ich etwas vergessen? Gruß, Markus -- ### QUESTIONS ### Why doesn't glue stick to the inside of the bottle? Why do you need a driver's license to buy liquor when you can't drink and drive? msg17701/pgp0.pgp Description: PGP signature
Re: Benutzer-Authentifizierung über LDAP
Hi Markus, Markus Hubig schrieb: Ich habe (mehr oder weniger auf Verdacht hin) folgende Pakete aus Testing installiert: | Package: slapd Version: 2.0.23-6 | Package: nscd Version: 2.2.5-11.1 | Package: libldap2 Version: 2.0.23-9 | Package: ldap-utils Version: 2.0.23-6 | Package: libpam-ldapVersion: 140-1 | Package: libnss-ldapVersion: 186-1 Sieht soweit ganz gut aus. Während der Installation habe ich zu ein paar dieser Pakete Fragen beantworten sollen: [...] Also ich gehe mal davon aus das thoregon.int dein Domainname ist, welcher zum DN dc=thoregon,dc=int wird . Der cn=manager,dc=thoregon,dc=int ist dein root account auf den LDAP-Server. Pruefe mal in /etc/ldap/slapd.conf ob alle schema's included werden, wenn nicht, so sollte es aussehen include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/samba.schema Das samba.schema liegt in /usr/share/doc/samba-doc/examples/examples/LDAP/samba.schema.gz Ich möchte jetzt erst einmal so weit kommen dass die Benutzer-Authentifizierung unter Linux über LDAP funzt. Dabei ergeben sich 2 Probleme (die wahrscheinlich zusammenhängen): Ich würde erst mal sagen du probierst erst mal den ldap-connect. Anonymous-Bind = ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts Root-Bind = ldapsearch -x -D cn=manager,dc=thoregon,dc=int -W \ -b '' -s base '(objectclass=*)' namingContexts Wenn beides klappt kannst du mit den Migration-Tools beginnen. Das mit den migrate_all* hat bei mir auch nie funktioniert. Ich mach lieber eins nach dem anderen. 1. Wie konvertiere ich /etc/passwd und Konsorten nach LDAP. Die Migration-Tools haben leider nicht funktioniert. ./migrate_base.pl | ldapadd -x -D cn=manager,dc=thoregon,dc=int -W ./migrate_passwd.pl ./migrate_group.pl 2. Ich habe wie empfohlen für libnss-ldap die LDAP Version 3 ausgewählt. Das heißt ja IMHO dass die Kommunikation und die Authentifizierung mit dem LDAP-Server Verschlüsselt abläuft. IMHO mit SASL?! Muss ich da noch irgendwas einstellen damit das funktioniert? Konnte darüber leider gar keine Infos finden. Das heisst soviel, wie die Verbindung kann verschluesselt laufen. Im Moment haben alle ldap-,libnss-ldap- sowie libpam-ldap-debs keine SSL-Verschluesselung , was sich aber laut Aussage der Paket-Betreuer demnaechst aendern wird. Was danach kommt ist mir relativ klar: 3. /etc/nsswitch.conf mit /usr/share/doc/libnss-ldap/examples/nsswitch.ldap ersetzen. 4. /etc/pam.d/* mit den Versionen aus /usr/share/doc/libpam-ldap/examples/pam.d/* ersetzen ... Vom Prinzip her schon. Ich empfehle dir gq zu installieren, damit hast du einen guten Ueberblick ueber dein LDAP-Verzeichnis und kannst kleinere Aenderungen gleich durchfuehren. -- Gruss Jens Stark -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Benutzer-Authentifizierung über LDAP
On Tue, 03 Sep 2002, Jens Stark wrote:
Markus Hubig schrieb:
Während der Installation habe ich zu ein paar dieser Pakete Fragen
beantworten sollen:
[...]
Also ich gehe mal davon aus das thoregon.int dein Domainname ist,
welcher zum DN dc=thoregon,dc=int wird .
Genau!
Der cn=manager,dc=thoregon,dc=int ist dein root account auf den
LDAP-Server.
Bei mir cn=admin,dc=thoregon,dc=int
Pruefe mal in /etc/ldap/slapd.conf ob alle schema's included werden,
wenn nicht, so sollte es aussehen
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/samba.schema
Das samba.schema liegt in
/usr/share/doc/samba-doc/examples/examples/LDAP/samba.schema.gz
Habe ich hinzugefügt ...
Ich möchte jetzt erst einmal so weit kommen dass die
Benutzer-Authentifizierung unter Linux über LDAP funzt. Dabei ergeben
sich 2 Probleme (die wahrscheinlich zusammenhängen):
Ich würde erst mal sagen du probierst erst mal den ldap-connect.
Anonymous-Bind =
ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
| ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
|
| version: 2
|
| #
| # filter: (objectclass=*)
| # requesting: namingContexts
| #
|
| #
| dn:
| namingContexts: dc=thoregon,dc=int
|
| # search result
| search: 2
| result: 0 Success
|
| # numResponses: 2
| # numEntries: 1
Sieht gut aus, oder?
Root-Bind =
ldapsearch -x -D cn=manager,dc=thoregon,dc=int -W \
-b '' -s base '(objectclass=*)' namingContexts
| ldapsearch -x -D cn=admin,dc=thoregon,dc=int -W -b '' \
| -s base '(objectclass=*)' namingContexts
| Enter LDAP Password:
|
| version: 2
|
| #
| # filter: (objectclass=*)
| # requesting: namingContexts
| #
|
| #
| dn:
| namingContexts: dc=thoregon,dc=int
|
| # search result
| search: 2
| result: 0 Success
|
| # numResponses: 2
| # numEntries: 1
Sieht auch gut aus (oder?)!
1. Wie konvertiere ich /etc/passwd und Konsorten nach LDAP. Die
Migration-Tools haben leider nicht funktioniert.
./migrate_base.pl | ldapadd -x -D cn=manager,dc=thoregon,dc=int -W
| ./migrate_base.pl | ldapadd -x -D cn=admin,dc=thoregon,dc=int -W
| Enter LDAP Password:
| adding new entry dc=thoregon,dc=int
| ldap_add: Already exists
|
| ldif_record() = 68
Hmm, ich habe zwar nicht genau rausfinden können was migrate_base
machen will, ich denke aber dass das nicht wirklich ein Problem ist,
da hier wohl schon das normale Debian Setup Vorarbeit geleistet
hatt.
./migrate_passwd.pl
[ ... ]
| adding new entry uid=alias,ou=People,dc=thoregon,dc=int
| adding new entry uid=qmaild,ou=People,dc=thoregon,dc=int
| adding new entry uid=qmaill,ou=People,dc=thoregon,dc=int
| adding new entry uid=qmailp,ou=People,dc=thoregon,dc=int
| adding new entry uid=qmailq,ou=People,dc=thoregon,dc=int
| adding new entry uid=qmailr,ou=People,dc=thoregon,dc=int
| adding new entry uid=qmails,ou=People,dc=thoregon,dc=int
Scheint zu funzen ... ;-)
./migrate_group.pl
und der Rest auch!! ;-)
2. Ich habe wie empfohlen für libnss-ldap die LDAP Version 3
ausgewählt. Das heißt ja IMHO dass die Kommunikation und die
Authentifizierung mit dem LDAP-Server Verschlüsselt abläuft. IMHO
mit SASL?! Muss ich da noch irgendwas einstellen damit das
funktioniert? Konnte darüber leider gar keine Infos finden.
Das heisst soviel, wie die Verbindung kann verschluesselt laufen.
Im Moment haben alle ldap-,libnss-ldap- sowie libpam-ldap-debs keine
SSL-Verschluesselung , was sich aber laut Aussage der Paket-Betreuer
demnaechst aendern wird.
Was danach kommt ist mir relativ klar:
3. /etc/nsswitch.conf mit
/usr/share/doc/libnss-ldap/examples/nsswitch.ldap ersetzen.
4. /etc/pam.d/* mit den Versionen aus
/usr/share/doc/libpam-ldap/examples/pam.d/* ersetzen ...
Vom Prinzip her schon.
OK, soweit so gut. Ich habe jetzt alle /etc/* Dateien in meinen
LDAP-Server aufgenommen. Allerdings steht bei den Usern als Passwort
überall nur {crypt}x. Wie setze ich jetzt die Passörter der User?
Ich empfehle dir gq zu installieren, damit hast du einen guten
Ueberblick ueber dein LDAP-Verzeichnis und kannst kleinere Aenderungen
gleich durchfuehren.
Guter Tipp, nettes Programm.
Gruss, Markus
--
Tell me: Why is a Win-PC called Win-PC?
Oh, just look at someone using this. You'll see:
The PC always wins, the user is always losing...
msg17726/pgp0.pgp
Description: PGP signature
Re: Benutzer-Authentifizierung über LDAP
Markus Hubig schrieb:
[...]
Sieht soweit alles gut aus.
OK, soweit so gut. Ich habe jetzt alle /etc/* Dateien in meinen
LDAP-Server aufgenommen. Allerdings steht bei den Usern als Passwort
überall nur {crypt}x. Wie setze ich jetzt die Passörter der User?
Normalerweise werden die Passwoerter vom migrate_passwd.pl mit
konvertiert, indem einfach das verschluesselte Passwort in das
LDAP-attribut userPassword kopiert wird und vorher noch ein {crypt}
eigefuegt wird.
z.B.
Unix-User test mit Passwort test
/etc/passwd - test:x:1006:1006:,,,:/home/test:/bin/bash
/etc/shadow - test:ohmtn6Js0KsOA:11933:0:9:7:::
^
konvertiert ins ldif-format enspricht das
dn: uid=test,ou=People,dc=test,dc=de
uid: test
cn: test
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}ohmtn6Js0KsOA
^
shadowLastChange: 11933
shadowMax: 9
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1006
gidNumber: 1006
homeDirectory: /home/test
gecos: ,,,
Ich kann das Problem mit den {crypt}x nicht nachvollzeihen, aber ich
tippe mal auf MD5-Passwoerter???. Wenn nicht probier mal die Passwoerter
einfach haendisch mit gq einzufuegen. Wenn nichts geht kopier einfach
das obige passwort rein und probier mal einen Bind mit dem user den du
das passwort zugewiesen hast
ldapsearch -x -D uid=$USER,ou=People,dc=thoregon,dc=int -W (uid=$USER)
--
Gruss
Jens Stark
--
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Benutzer-Authentifizierung über LDAP
On Tue, 03 Sep 2002, Jens Stark wrote:
Markus Hubig schrieb:
[...]
Sieht soweit alles gut aus.
OK, soweit so gut. Ich habe jetzt alle /etc/* Dateien in meinen
LDAP-Server aufgenommen. Allerdings steht bei den Usern als Passwort
überall nur {crypt}x. Wie setze ich jetzt die Passörter der User?
Normalerweise werden die Passwoerter vom migrate_passwd.pl mit
konvertiert, indem einfach das verschluesselte Passwort in das
LDAP-attribut userPassword kopiert wird und vorher noch ein {crypt}
eigefuegt wird.
*Hüstel* funzt auch problemlos, wenn man das Recht hat /etc/shadow zu lesen!
| sudo ./migrate_passwd.pl /etc/passwd | \
| ldapmodify -x -D cn=admin,dc=thoregon,dc=int -W
Sudo hat die Sache bereinigt. ;-)
Ich kann das Problem mit den {crypt}x nicht nachvollzeihen, aber ich
tippe mal auf MD5-Passwoerter???.
Ich dachte eigentlich ich nutze hier Passwörter im MD5 Format. Aber es
scheint mit {crypt} zu funzen ... ;-)
Wenn nicht probier mal die Passwoerter einfach haendisch mit gq
einzufuegen. Wenn nichts geht kopier einfach das obige passwort rein
und probier mal einen Bind mit dem user den du das passwort
zugewiesen hast
| ldapsearch -x -D uid=$USER,ou=People,dc=thoregon,dc=int -W (uid=$USER)
| Enter LDAP Password:
| version: 2
|
| #
| # filter: (uid=markus)
| # requesting: ALL
| #
|
| # search result
| search: 2
| result: 32 No such object
|
| # numResponses: 1
Jo, es funzt !!
Gruß und vielen Dank für deine Hilfe, Markus
--
Always remember you're unique, just like everyone else.
msg17746/pgp0.pgp
Description: PGP signature
