PädML5 Update: Keine LDAP-Authentifizierung

[Rüdiger Kupper]

Nach dem Update funktioniert die LDAP-Authentifizierung nicht (außer für lokale Dienste).

[Rüdiger Kupper]

@bau

Hier siehst Du die Änderungen an der slapd.conf, die während des Updates gemacht wurden:

diff:/keplertools/etc/tags/paedml4/ldap/slapd.conf//keplertools/etc/trunk/ldap/slapd.conf

Ist da irgendwas dabei, was die Ursache sein könnte? Vielleicht Zeile 61 (wurde entfernt)?

[bau]

Hallo Rüdiger,

ein Login von den LTSP-Servern aus geht aber - oder sehe ich das falsch?

linadmin@ltsp118:~$ su bau
Password:
bau@ltsp118:/localhome/linadmin$

Grüße
Jens

[Rüdiger Kupper]

Aha!

su geht:

linadmin@LTServer128c:~$ su kup
Password: 
kup@LTServer128c:/localhome/linadmin$ 

aber ssh geht nicht:

linadmin@LTServer128c:~$ ssh kup@10.32.1.245
kup@10.32.1.245's password: 
Permission denied, please try again.
kup@10.32.1.245's password: 
Permission denied, please try again.
kup@10.32.1.245's password: 
Permission denied (publickey,password).

Und genau das hatten wir schonmal, nämlich hier: comment:19:ticket:340. Kann es wieder ein Problem sein, dass das sophomorix irgendwelche Passwortänderungen nicht mitbekommen hat?

[Rüdiger Kupper]

Ah, vielleicht ist es auch nur ein Folgeproblem der nicht funktionierendes PostgreSQL-Datenbank. Im Hilfstext zu sophomorix-passwd steht:

sophomorix-passwd modifies users in the sophomorix database and the authentification system (see also sophomorix-usermod)

Und ein Aufruf führt zu

/usr/sbin/sophomorix-passwd
print() on closed filehandle LOG at /usr/share/perl5/Sophomorix/SophomorixBase.pm line 3157, <DATA> line 253.
#### No connection to postgresql!                                         ####

Wahrscheinlich sollten wir uns also erst darauf konzentrieren, das PostgreSQL-Problem zu lösen, vielleicht erledigt sich das LDAP-Problem dann automatisch mit.

[bau]

Ich habe die Postgres-Datenbank heute wiederbelebt - sophomorix-check und import_workstations gehen jetzt wieder (Die notwendigen User waren nicht angelegt!).

Komisch, ich habe grade sophomorix-passwd aufgerufen und es hat geklappt:

sophomorix-passwd -u bau --pass [PASS]

[bau]

Jetzt habe ich mein Passwort geändert und komme auch per su bau am LTSP (du hattest damals su kup am paedml eingegeben!) nicht mehr rein.
Die haben übrigens die Verschlüsselung von crypt auf SSHA umgestellt, macht das unseren LTSP was aus?

[Rüdiger Kupper]

Replying to bau:

Ich habe die Postgres-Datenbank heute wiederbelebt - sophomorix-check und import_workstations gehen jetzt wieder (Die notwendigen User waren nicht angelegt!).

Sehr gut! Aber heißt das, dass das Update nicht ordentlich durchgelaufen ist? (Müssen wir mit noch mehr Problemen rechnen?)

[Rüdiger Kupper]

Replying to bau:

Komisch, ich habe grade sophomorix-passwd aufgerufen und es hat geklappt:

sophomorix-passwd -u bau --pass [PASS]

Ich hab es als User kup aufgerufen. Aber normale User dürfen anscheinend ihr Passwort nicht ändern, wo kämen wir da hin?

[Rüdiger Kupper]

Replying to bau:

Jetzt habe ich mein Passwort geändert und komme auch per su bau am LTSP (du hattest damals su kup am paedml eingegeben!) nicht mehr rein.

Bei mir funktioniert alles. su wie ssh.

Die haben übrigens die Verschlüsselung von crypt auf SSHA umgestellt, macht das unseren LTSP was aus?

Anscheinend nicht. Ich nehme an, das wird im Protokoll ausgehandelt.

[Rüdiger Kupper]

Ich kann mich nach wie vor an den LTSPs authentifizieren.

[bau]

Du hast auch dein Passwort nicht mit sophomorix-password geändert.
Ich habe das gemacht und habe jetzt probleme!
Mit dem Testuser geht es bei mir auch!

[Rüdiger Kupper]

Hm, und das sophomorix-passwd hat erfolgreich in die Datenbank geschrieben? Und auch erfolgreich Dein Unix-Passwort geändert?

Müssen vielleicht noch irgendwelche Dienste neu gestartet werden, nachdem die Datenbank wieder zugänglich ist? Den slapd hast Du vermutlich schon neu gestartet...

[bau]

slapd ist neu gestartet, was anderes fällt mir auch nicht ein.
Das sophomorix-passwd hat ohne Fehler seinen Dienst beendet und sowohl in die Postgres-DB als auch in den LDAP geschrieben. ich kann mich über SAMBA und alle lokalen Dienste anmelden.

Langsam wird mir etwas mulmig zumute - nächste Woche soll das alles wieder tun!
Was machen wir?

[Rüdiger Kupper]

Wenn Du sagst, Du hast die Datenbank wiederhergestellt, hast Du mal versuchsweise Dein Initialpasswort ausprobiert?

[bau]

Ich habe nicht die DB wiederhergestellt sondern nur die Benutzer angelegt und als OWNER eingetragen. Damit gingen dann die Scripte wieder.

Für die externen Dienste (Moodle, Joomla) habe ich mir eine Lösung ausgedacht:
Die rufen ein Script auf dem paedml auf über das sie eine auth durchführen. Damit wäre das externe Problem vertagbar. Das LTSP-Anmeldeproblem nach sophomorix-passwd ist aber weiterhin problematisch!

[Rüdiger Kupper]

Ja, das muss funktionieren.

Sagt Dir der Befehl ophomorix-setup-pgldap etwas? Der scheint die ganze Sache einzurichten.
Und in dessen default-Config-File steht eine Änderung zum IP-Cop, die wir nicht übernommen haben:
diff:/keplertools/etc/trunk/sophomorix/pgldap/pgldap.conf//keplertools/etc/trunk/sophomorix/pgldap/pgldap.conf.dpkg-dist

?

[Rüdiger Kupper]

Oder könnte es doch die veränderte Verschlüsselung sein? Ist Dein neues Passwort jetzt vielleicht SSHA-verschlüsselt und die "alten" noch mit crypt?

[Rüdiger Kupper]

Ah, und machen wir überall konsequent ldaps? Das wurde doch mit der PaedML5 auch zwingend, oder?

[bau]

OK,
die Passwörter stehen mit dem Prefix {SSHA} oder {crypt} sowohl in LDAP als auch in Postgres.
Ich habe bereits seit dem Update auf 4.06 auf LDAPS umgestellt :-)

Zu den externen Diensten:
Ich habe gerade

• Moodle
• Joomla (Homepage)

auf NICHT-LDAP-Login umgestellt, von Außen sieht man nun keine Probleme mehr. Bleibt nur der interne LTSP-Kram. Und die Frage, warum das alles von Draußen nicht tut???

[Rüdiger Kupper]

Ja, ich kann mich jetzt auf der Kepler-Homepage anmelden.

Aber ich hab kein gutes Gefühl, so in den Betrieb zu gehen. Irgendwie muss es doch wohl an diesem slapd liegen. Hast Du nochmal auf der Liste gefragt?

Stimmen die Daten in der slapd.conf?
diff:/keplertools/etc/tags/paedml4/ldap/slapd.conf//keplertools/etc/trunk/ldap/slapd.conf

[bau]

Ich gehe nachhher mal in die Schule und versuche mich einzuloggen an verschiedenen Clients (LZ, Samba-Computerraum, LTSP-Client). Wenn das geht, würde ich das Passwort-Ändern verbieten und nach dem Problem suchen.

Was machen wir im Fehlerfall??
Backup zurückspielen??
Am Besten dann das komplette Backup mitsamt allem, was so drauf war am Montag!
Hoffentlich geht das dann gut :-(

[Rüdiger Kupper]

Ja, das Backup bleibt uns immer noch. Dann sollten wir ja den Server in dem Zustand zurückbekommen, wie er am Montag war. Und dann können wir in Ruhe das Update bei Gelegenheit nochmal versuchen.

Aber dieses LDAP-Problem kann doch gar nicht so kompliziert sein!

Zum Thema "müssen irgendwelche Dienste neu gestartet werden": Hast Du den Server einfach nochmal neu gebootet? Vielleicht hingen noch irgendwelche weiteren Sachen von der PostgreSQL-DB ab, die wir übersehen haben?

[Rüdiger Kupper]

Replying to bau:

Ich gehe nachhher mal in die Schule und versuche mich einzuloggen an verschiedenen Clients (LZ, Samba-Computerraum, LTSP-Client).

Bevor Du Dich an einem LTSP-Client einloggst, sag mir bitte noch Deinen Kommentar zu comment:4:ticket:434.
Ich schätze, diese Abschnitte sollen wieder hinein?

[bau]

OK, den Server könnte ich natürlich auch mal neu booten, vielleicht hilft's ja.
ich mach mal den Check mit den Clients - mal sehen.

[bau]

Bei mir zeigt der LTSP118 im auth.log:

• pam_unix(su:auth): authentication failure; logname=linadmin uid=1000 euid=0 tty=/dev/pts/0 ruser=linadmin rhost= user=bau
• pam_winbind(su:auth): getting password (0x00000388)
• pam_winbind(su:auth): pam_get_item returned a password
• pam_winbind(su:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_USER_UNKNOWN (10), NTSTATUS: NT_STATUS_NO_SUCH_USER, Error message was: No such user

NO SUCH USER - das ist interessant!

[bau]

• Login am LTSP-Client tut
• Login am Lehrerzimmerrechner (Samba) tut
• Login am Schüler PC (Samba) tut
• WebUntis - Login tut

• mit dem FreeRadius stimmt noch was nicht - Internetzugang über 10.32.1.251 hapert

[bau]

Was mit dem freeradius ist wei ich nun auch nicht, der startet einfach ohne Fehlermeldung nicht. auch der Aufruf von der Kommandozeile mit Parameter -x oder -xx (Debugging) bringt keinerlei Fehlermeldung - komisch??

Allerdings bin ich mit dem Rest recht zufrieden:

• das neue Image für die Laptops habe ich gestern mit wine und BSE versehen, und noch den User kepler angelegt, es wird gerade auf die Lappis verteilt
• Anmeldung an den Laptops auch mit meinem eigenen user bau möglich. Da die Lappis (linuxmuster-client) auch per LDAP die Anmeldung managen, muss das ja wohl tun. Kannst du mal auf einem der Lappis (stehen in 001) nachsehen, was die anders machen als unsere LTSP?

[Rüdiger Kupper]

Okay, danke für den Hinweis: die LTSP-Server haben noch LDAP gemacht, kein LDAPs.

Wieder was gelernt: Es gibt zwei ldap.conf-Dateien:

/etc/ldap.conf

wird nur für die Authentifizierung benutzt (also da, wo LDAP anstatt der normalen /etc/passwd eingeklemmt wird. Die Dienst, der das macht heisst übrigens ​nss_ldap)

/etc/[open]ldap/ldap.conf

wird für alle anderen Programme verwendet, die openldap verwenden

In beiden Dateien stand noch LDAP statt LDAPs. Das habe ich jetzt geändert.

Probier jetzt mal Dein Glück, Dich auf/von einem LTSP-Server mit ssh einzuloggen. Probier erstmal ssh aus, denn mit su gibt's jetzt wieder ein anderes Problem:

Problem: Jetzt bricht su ab mit dem Fehler

linadmin@LTServer128a:~$ su kup
Password: 
setgid: Operation not permitted

Das Passwort wird aber zuvor überprüft.
Probier jetzt nochmal

[Rüdiger Kupper]

in /var/log/auth.log steht danach:

Jan  5 15:48:58 LTServer128a su[4852]: Successful su for kup by linadmin
Jan  5 15:48:58 LTServer128a su[4852]: + /dev/pts/2 linadmin:kup
Jan  5 15:48:58 LTServer128a su[4852]: bad group ID `10000' for user `kup': Operation not permitted

10000 ist aber meine Gruppe (teachers).

[bau]

Juhu .... :-)
Ich konnte mich einloggen :-)
Was hat der su denn ???
Ich probier das nachher mal noch an einem LTSP-Client in der Schule (ich bin gerade Nachtarbeiter geworden)

Hast du eine Ahnung, warum der freeradius nicht tut?

[Rüdiger Kupper]

Replying to bau:

Juhu .... :-)
Ich konnte mich einloggen :-)

Ah! Das ist eine gute Nachricht!

Was hat der su denn ???

Scheint ein bekanntes Problem mit dem Service libnns_ldap zu sein: ​http://wiki.debian.org/LDAP/NSS

Zitat

In addition, libnss-ldap breaks setuid programs (su, sudo) when using LDAP+SSL (see ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579647).

Es existieren verschiedene Workarounds:

nscd installieren

(name service caching daemon). Der ist auf den LTSP-Servern bereits installiert, das scheint aber entgegen den Angaben in den Foren das su-mit-LDAPs-Problem leider nicht zu beheben (??).

libnns-ldapd verwenden statt libnns-ldap

libnns-ldapd ist die neuere Implementation, die mit LDAPs offenbar weniger Probleme hat. Das werde ich ausprobieren.

Ich probier das nachher mal noch an einem LTSP-Client in der Schule (ich bin gerade Nachtarbeiter geworden)

Und??

Hast du eine Ahnung, warum der freeradius nicht tut?

Nein, ich weiß nicht einmal, wozu dieser Service dient...?

[bau]

freeradius macht die Auth für den Proxy (10.32.1.251) - es gibt aber auch ein LDAP-auth-Modul, welches ich aber nicht zum Laufen gebracht habe. Leider hat sich anscheinend die freeradius.-Konfigurationsdatei geändert und jetzt will der freeradius nicht mehr richtig - ich habe schon ein Ticket beim LMZ eingestellt.

[Rüdiger Kupper]

Heißt das, dass man sich derzeit nicht am Proxy authentifizieren kann?

[bau]

(Nein, ich hatte die Authentifizierung abgeschaltet)

So, jetzt habe ich das Problem auch noch gelöst - aber ohne LDAP und freeradius-gedöns :-)
Ich habe ja auf dem paedml ein zentrales php-Script, welches ich auch in Moodle und Joomla benutze, um nach Übergabe eines Benutzernamens/Passworts entweder OK oder FALSE zurückzuliefern. Das rufe ich nun in einem Bash-Script auf dem Proxy mit WGET auf - das geht sogar schneller, als es mit Radius ging.

[Rüdiger Kupper]

Okay. Aber wäre es nicht eigentlich die sinnvollste Alternative, alles über LDAP laufen zulassen (also, jede Authentifizierung?)

[bau]

Das ist ja jetzt der Fall ;-)
Es ist nur so, dass der Zugang zum LDAP von anderen Servern aus nicht gerade einfach ist (vor allem wenn es sich um SQUID handelt und die Verbindung über ldaps:// gehen soll). So habe ich halt ein lokales Script geschrieben, welches den LDAP mit den übergebenen Daten abfragt und OK oder FALSE zurückmeldet. Das geht schnell und einfach und eben ohne Protokoll-Overhead. Vor allem aber weiß ich bei meinem eigenen Script wie es funktioniert und wo ich dran rumschrauben kann.

Ich habe grade per VNC von zu Hause aus den Zugang aus dem Firefox heraus getestet - ging prima :-)

[bau]

Mein LDAP-Abfrage-Script hat dem Squid anscheinend so nicht besonders gefallen - er hatte gestern zu viele der Prozesse gestartet und konnte diese anscheinend nicht mehr beenden (Nach /etc/init.d/squid stop waren noch zahlreiche Prozesse aktiv). Ich habe jetzt auf smb_auth gegen den Samba-Server umgestellt.

[Rüdiger Kupper]

Problem besteht weiter, momentan laufen aber alle Dienste auf anderem Weg.

[Rüdiger Kupper]

Hallo Jens,
was ist der Testfall für dieses Problem? Von innen kann ich LDAP-Abfragen machen, allerdings nur anonym:

kup@ltsp118:~$ ldapsearch -x "(uid=kup)"

funktioniert.

Ohne das "-x" funktioniert's nicht, das ging meines Wissens auch noch nie, aber vielleicht ist das ja so gewollt:

kup@ltsp118:~$ ldapsearch "(uid=kup)" cn
SASL/LOGIN authentication started
Please enter your password: 
ldap_sasl_interactive_bind_s: Invalid credentials (49)
	additional info: SASL(-13): user not found: checkpass failed

[bau]

Ehrlich gesagt: ich weiß auch nicht, was der Testfall ist. Bislang war es eben so, dass ich per Anleitung im Wiki die Einstellungen für LDAP in Moodle bzw Joomla gemacht habe und dann ging das Ding. Nach dem Update wollte der schlichtweg nicht mehr.

[Rüdiger Kupper]

Bekommst Du da eine Fehlermeldung?

[bau]

Das ist ja das Problem, ich bekomme nur die Meldung, dass die Anmeldung nicht erfolgreich war.
Ich sehe aber im Moment keine Notwendigkeit, hier Arbeitszeit zu investieren.

[Rüdiger Kupper]

Replying to bau:

Ich sehe aber im Moment keine Notwendigkeit, hier Arbeitszeit zu investieren.

Okay.