Persistenter Login auf den LTSP-Clients

[Rüdiger Kupper]

Ein Anwender, der sich an einem LTSP-Client anmeldet, authentifiziert sich dabei mit Nutzernamen und Passwort. Dennoch fragen Web-Anwendungen wie Web-Untis und Trac noch einmal nach Username und Passwort, bevor der Nutzer zugreifen kann. Es wäre schön, wenn Webanwendungen nachfragen könnten, ob ein authentifizierter Nutzer surft und dann den Loginprozess umgehen.

In zweiter Linie wäre ein solcher Prozess auch für alle anderen Anwendungen nützlich, auch solche, die nicht im Browser laufen, aber trotzdem Authentifizierung erfordern.

[Rüdiger Kupper]

Hallo Rüdiger,

mir ist die zündende Idee gekommen:
Der Befehl who (oder auch w?) liefert die angemeldeten User
samt dem Rechner, von dem er eingelogged ist. Ich bräuchte
also einen Daemon auf den LTSP-Servern, der von meinem
PHP-Script abgefragt werden kann. Also so:

• User logged sich z.B. auf LTSP117 (10.32.200.117) ein und startet den Browser mit dem neuen Tagebuchscript (kann ja als Startseite eingestellt sein)
• PHP-Script fragt die IP ab, liegt diese im internen Bereich (also 10.32.*.*), so fragt sie beim passenden LTSP nach, ob der User dort angemeldet ist und lässt ihn dann rein
• Wenn kein OK kommt, so zeigt das Script eine Login-Seite an

Das Ganze könnte sich sofort mit Apache/PHP umsetzen frage
mich aber, ob das nicht die Kanonen auf Spatzen sind?
Allerdings wäre auch die Umstellung des Informatikunterrichts
von Windows/XAMPP auf die LTSP/Apache möglich: Die Homes
sind ja gemountet und der Apache könnte über

​http://10.32.1.248/~username

angesprochen werden.
Wir bräuchten dann halt noch für User der Informatikkurse
Userdatenbanken unter MySQL (am Ende des Schuljahres).
Das fände ich auch mal inmteressant: Wie bei den großen
Providern ein Zugang per PHPMyAdmin und eine userbezogene
Datenbank mit dem Namen des Users.
Hast du eine Ahnung, wie so was geht?

Die public_html-Sache habe ich schonmal auf dem alten Server
gemacht, das ist nicht weiter schwer.

Grüße
Jens

[Rüdiger Kupper]

Hallo Jens,

die Idee mit "who" klingt machbar, aber irgendwie habe ich die
Vermutung, dass es für dieses Problem schon eine fertige Lösung geben
müsste. So einen einmaligen Login wollen doch andere Leute auch haben,
das muss doch schonmal jemand gelöst haben.

Zu den Userbezogenen Datenbanken: Reicht es nicht, jedem Nutzer eine
eigene mySQL-Datenbank einzurichten und ihm die Rechte daran zu
übereignen? Ich hab für das Trac auch eine eigene Datenbank
eingerichtet, weil ich nicht wollte, das Dir das Trac die
"schule"-Datenbank zumüllt und man notfalls das ganze Ding
sichern/verschieben/löschen kann, ohne dass den Schuldaten etwas
passiert. Das geht mit einzwei Kommandos.
Auf der Datenbank müsste dann auch PHPMyAdmin problemlos arbeiten.

Grüße,
Rüdiger

[Rüdiger Kupper]

Hallo Rüdiger,

Hallo Jens,

die Idee mit "who" klingt machbar, aber irgendwie habe ich die
Vermutung, dass es für dieses Problem schon eine fertige Lösung geben
müsste. So einen einmaligen Login wollen doch andere Leute auch haben,
das muss doch schonmal jemand gelöst haben.

bestimmt, aber wenn wir nicht in sehr kurzer Zeit was finden habe ich es schneller
für uns programmiert. Was meinst du: Apache/PHP?
Wäre mir am liebsten, da kenne ich mich aus - auch mit Blick auf die User-public_html's

Zu den Userbezogenen Datenbanken: Reicht es nicht, jedem Nutzer eine
eigene mySQL-Datenbank einzurichten und ihm die Rechte daran zu
übereignen? Ich hab für das Trac auch eine eigene Datenbank
eingerichtet, weil ich nicht wollte, das Dir das Trac die
"Schule"-Datenbank zumüllt und man notfalls das ganze Ding
sichern/verschieben/löschen kann, ohne dass den Schuldaten etwas
passiert. Das geht mit einzwei Kommandos.
Auf der Datenbank müsste dann auch PHPMyAdmin problemlos arbeiten.

Stimmt, das sollte gehen.

[Rüdiger Kupper]

Hallo Rüdiger,

anscheinend hast du nichts fertiges gefunden - oder?
Ich würde dann halt mal auf den LTSP den Apache
installieren und das PHP-Script testen.
Außerdem würde ich die public_html's so einrichten,
dass der Infokurs nächstes Jahr dann drauf zugreifen
kann.
Wo sollen wir die MySQL-Datenbank hosten?
Ich würde einen der LTSP dafür vorsehen.
Der wäre dann aber anders als die anderen LTSP.

Was machen wir mit dem Problem, dass man den
Symbolischen Links (z.B. __tauschen/tausch-Lehrer) auf
den LTSP nicht folgen kann. Ausweg wäre ein Link
auf den ​smb://paedml.kg-fds.de/Name oder ein
automatisches Verbinden bei der Anmeldung.

Grüße
Jens

[Rüdiger Kupper]

Wo sollen wir die MySQL-Datenbank hosten?
Ich würde einen der LTSP dafür vorsehen.
Der wäre dann aber anders als die anderen LTSP.

--> Ticket #32.

[Rüdiger Kupper]

Was machen wir mit dem Problem, dass man den
Symbolischen Links (z.B. __tauschen/tausch-Lehrer) auf
den LTSP nicht folgen kann. Ausweg wäre ein Link
auf den ​smb://paedml.kg-fds.de/Name oder ein
automatisches Verbinden bei der Anmeldung.

--> Ticket #2.

[Rüdiger Kupper]

Ich würde dann halt mal auf den LTSP den Apache
installieren und das PHP-Script testen.

Vorschlag: Ich mach vorher noch ein Backup der aktuellen LTSP-Zustände, und dann kannst Du Dich austoben :-).

[Rüdiger Kupper]

Hallo Jens,

irgendwie geistert mir die Idee herum, dass sich das Problem vielleicht einfach mit einem Browser-Cookie lösen lässt. Wäre es nicht ausreichend, wenn beim Anmelden am LTSP-Client ein Browser-Cookie erzeugt würde, der anzeigt, dass der User authentifiziert ist?
Wie "behält" sich denn Web-Untis oder Trac, ob der User authentifiziert ist? Doch sicher auch mit einem Cookie, oder? Könnte man den nicht direkt erzeugen?

[Rüdiger Kupper]

Bingo:

• Trac legt einen Cookie an für die Site paedml.kg-fds.de namens trac_auth.
• Web-Untis legt einen Cookie an für die Site paedml.kg-fds.de namens JSESSIONID.

Beide enthalten Authentifizierungsschlüssel. Wenn man die irgendwie beim Einloggen schon erzeugen könnte, müsste sich der Nutzer nicht mehr authentifizieren.

[Rüdiger Kupper]

Naja, das scheitert wohl an den Schlüsseln in den Cookies. Keine Ahnung, wie die erzeugt werden.

[Rüdiger Kupper]

Hinweis: Der Begriff, nach dem man suchen muss, ist pass-through authentication. Unter Windows ist das wohl üblich, über den Active Directory Server. Hierfür gibt es dann auch ein Apache-Modul, das macht, was wir wollen. Unter Linux müsste man statt dem AD-Server wohl Kerberos aufsetzen.

Siehe: ​http://www.edugeek.net/forums/nix/11111-apache-passthrough-ad-group-authentication.html#post112014

[Rüdiger Kupper]

So, das Backup der LTSP-Server ist durchgelaufen. Probier mal, was Du hinbekommst :-).

[bau]

Die Sache mit who oder w wird so nicht funktionieren, da der Apache auf paedml nur die IP des LTSP-Servers sieht benötigt würde aber die IP des Clients. Es bleibt also die Idee mit den Cookies umzusetzen: Beim Login wird ein Cookie gesetzt, dieser wird vom neuen Tagebuch abgefragt und der User wird dann ohne Auth reingelassen - ich schaue mal nach Cookie/PHP

[bau]

Hast du eine Ahnung, wie man im Firefox beim Login ein Cookie setzt?
Der Firefox legt die Cookies im Profilordner an allerdings in einer sqllite-Datenbank

[Rüdiger Kupper]

Replying to bau:

Die Sache mit who oder w wird so nicht funktionieren, da der Apache auf paedml nur die IP des LTSP-Servers sieht benötigt würde aber die IP des Clients.

Hm, kann man nicht irgendwo herausfinden, von welchem Client aus sich der Nutzer eingeloggt hat? Irgendwo wird das dach bestimmt protokolliert. (Auf jeden Fall steht es im syslog, aber das ist natürlich nicht der Ort, wo man solche Informationen herholen sollte...)

Aber sagt Dir w nicht, von wo ein User eingeloggt ist? Das was unter FROM steht?

16:15/16 [kup@paedml] ~ $ w
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
kup      pts/0    e180092119.adsl. 16:13    0.00s  0.13s  0.00s w

[Rüdiger Kupper]

Hier hatte jemand das gleiche Problem, und offenbar auch gelöst. Vielleicht hilft das weiter:
​http://www.mail-archive.com/ltsp-discuss@lists.sourceforge.net/msg23359.html

[bau]

Replying to kup:

Replying to bau:

Die Sache mit who oder w wird so nicht funktionieren, da der Apache auf paedml nur die IP des LTSP-Servers sieht benötigt würde aber die IP des Clients.

Hm, kann man nicht irgendwo herausfinden, von welchem Client aus sich der Nutzer eingeloggt hat? Irgendwo wird das dach bestimmt protokolliert. (Auf jeden Fall steht es im syslog, aber das ist natürlich nicht der Ort, wo man solche Informationen herholen sollte...)

Aber sagt Dir w nicht, von wo ein User eingeloggt ist? Das was unter FROM steht?

16:15/16 [kup@paedml] ~ $ w
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
kup      pts/0    e180092119.adsl. 16:13    0.00s  0.13s  0.00s w

Hallo Rüdiger,
das ist nicht das Problem. Das Problem ist die Kommunikation Firefox - Server, wenn ich dort die IP abfrage finde ich nur die IP des LTSP und nicht die des Clients. Da ich aber vom Nutzer absolut garnichts weiß (keinen Benutzername) wird das schwierig werden.
Allerdings finde ich die version mit den Cookies recht reizvoll. Der Firefox speichert die als sqllite-Datenbank, die kann man mit sqllite3 sehr einfach einsehen und manipulieren. Wenn ich da einen Key ablege in dem ich den Nutzername, den LTSP und die Zeit ablege und das Ganze dann MD5_Hashe so habe ich einen Key, der z.B. 90 Minuten lang gültig bleibt. Beim nächsten Login wird der wieder überschrieben.

[Rüdiger Kupper]

Replying to bau:

Das Problem ist die Kommunikation Firefox - Server, wenn ich dort die IP abfrage finde ich nur die IP des LTSP und nicht die des Clients. Da ich aber vom Nutzer absolut garnichts weiß (keinen Benutzername) wird das schwierig werden.

Ah, jetzt, ja. Verstehe, wo das Problem liegt... :-)

Allerdings finde ich die version mit den Cookies recht reizvoll. Der Firefox speichert die als sqllite-Datenbank, die kann man mit sqllite3 sehr einfach einsehen und manipulieren. Wenn ich da einen Key ablege in dem ich den Nutzername, den LTSP und die Zeit ablege und das Ganze dann MD5_Hashe so habe ich einen Key, der z.B. 90 Minuten lang gültig bleibt. Beim nächsten Login wird der wieder überschrieben.

Cool, hast Du das schon ausprobiert? Woher weisst, Du, was in dem Cookie drinstehen muss? Ich hatte mal ein wenig herumgesurft und dann wieder aufgegeben, weil niemand zu wissen schien, wie man

1. einen Firefox-Cookei von Hand erstellt und
2. was dann in dem Cookie drinstehen muss

Sieht aus, als wüsstest Du beides :-).

Aber es gibt vielleicht noch eine halbmanuelle Methode, man könnte den Browser bitten, den Cookie anzulegen. Das Protokoll dafür ist hier beschrieben: ​http://en.wikipedia.org/wiki/HTTP_cookie#Setting_a_cookie
Könnte das Dein Skript nicht erledigen, statt den Cookie direkt anzulegen?

Die Methode hätte den Vorteil, dass sie weniger Annahmen über die Interna von Firefox macht. (Was, wenn die sich überlegen, mit der nächsten Version ihre Cookies anders zu speichern?) Und sie würde sogar mit anderen Browsern funktionieren. Oder hab ich jetzt wieder was übersehen?

[bau]

Thema wir folgt gefixed:
========================

• Der Kepler-Login setzt den Cookie im Browser selbst bei erfolgreichem Login wenn der User das so gewählt hat (Einstellungen)
• Im Cookie wird der Username und ein jedesmal veränderter Sicherheitscode gespeichert
• Das Cookie ist 1 Jahr gültig
• Bei jedem Login wird der Benutzer darauf hingewiesen, dass das Cookie auf diesem Rechner gesetzt wurde, per LINK kann er das Cookie löschen (Sicherheit)