Univention Bugzilla – Bug 19173
Base64-codierte Speicherung des Passworts bei der XenApp-Anmeldung ermöglichen
Last modified: 2010-11-10 19:44:04 CET
Das im univention-thin-client-session-xenapp enthaltene Session-Script Citrix-XenApp wertet die Passwortinformationen im Klartext aus der Datei /tmp/passwd zur Single-Sign-On-Lösung aus. Das Passwort wird jedoch base64-encoded gespeichert, so dass die Anmeldung am Windows nicht funktioniert. Hier fehlt eine base64-decode: --- Citrix-XenApp.orig 2010-07-30 12:02:53.000000000 +0200 +++ Citrix-XenApp 2010-07-30 12:08:56.000000000 +0200 @@ -45,7 +45,7 @@ /usr/bin/metacity & if test -e /tmp/passwd; then - user_password=`cat /tmp/passwd` + user_password=`cat /tmp/passwd | base64-decode` rm /tmp/passwd fi
(In reply to comment #0) > Das im univention-thin-client-session-xenapp enthaltene Session-Script > Citrix-XenApp wertet die Passwortinformationen im Klartext aus der Datei > /tmp/passwd zur Single-Sign-On-Lösung aus. Das Passwort wird jedoch > base64-encoded gespeichert, so dass die Anmeldung am Windows nicht > funktioniert. > > Hier fehlt eine base64-decode: > > --- Citrix-XenApp.orig 2010-07-30 12:02:53.000000000 +0200 > +++ Citrix-XenApp 2010-07-30 12:08:56.000000000 +0200 > @@ -45,7 +45,7 @@ > /usr/bin/metacity & > > if test -e /tmp/passwd; then > - user_password=`cat /tmp/passwd` > + user_password=`cat /tmp/passwd | base64-decode` > rm /tmp/passwd > fi Die base64-Codierung wurde bisher nur in einer Kundenumgebung verwendet, in der die pam-Konfiguration das entsprechende Script zur Speicherung der Passwortinformationen verwendet. --- gdm.orig 2010-07-30 12:03:15.000000000 +0200 +++ gdm 2010-07-30 13:13:27.000000000 +0200 @@ -35,7 +35,7 @@ ''' @!@ -session required pam_runasroot.so export_pass program=/usr/bin/save_pass.sh demouser=demo silent +session required pam_runasroot.so export_pass program=/usr/bin/save_pass-base64.sh demouser=demo silent #auth required pam_runasroot.so demouser=demo demouserscript=/usr/share/univention-client-login/cleanup-demo.sh silent #auth required pam_runasroot.so save_pass silent Für eine allgemeine Produktintegration wäre eine UCR-basierte Konfiguration denkbar, um die Codierung/Decodierung an- oder abzuschalten. Pakete: univention-thin-client-session-xenapp, univention-thin-client-x-base
Eine Teil der Kunden-Anpassungen wurde bereits in TCS 3.0 integriert (es gibt ein weiteres Skript save-pass-base64). Man könnte die Zwischenspeicherung in Base64 auch allgemein zum Standard machen, das müsste gar nicht per UCR konfigurierbar sein.
(In reply to comment #2) Man könnte die Zwischenspeicherung in > Base64 auch allgemein zum Standard machen, das müsste gar nicht per UCR > konfigurierbar sein. Das wurde nun für UCS TCS 3.1 umgesetzt - die Passwortspeicherung erfolgt nun immer base64-kodiert. fixed
Die Speicherung des Passworts in /usr/bin/save-pass erfolgt nun standardmässig base64-codiert. Eine Anmeldung mit dem Citrix XenApp-Skript wurde erfolgreich getestet. Das Windows-TS-Skript decodiert ebenfalls base64 bevor der Zugriff erfolgt.
Ich wollte auf einer frischen Installation das Windows Terminalserver-Skript testen (dort war im Gegensatz zu der anderen VM noch nicht das XenApp-Paket installiert) und die Anmeldung am Windows TS schlägt mit der Fehlermeldung /etc/gdm/Sessions/Windows-Terminal-Server: line 44: base64-decode: command not found Da fehlt noch eine Abhängigkeit.
Das war ein Fehler in der VM, mime-codecs wurde durch eine kaputte Repository-Einstellung zurückgehalten.
(In reply to comment #6) > Das war ein Fehler in der VM, mime-codecs wurde durch eine kaputte > Repository-Einstellung zurückgehalten. Das darvf eigentlich nicht passieren. Das Tool muss dann per univention-thin-client-download-debs vom Paket mitgebracht werden. Ansonsten wird das auf amd64-Systemen scheitern.
(In reply to comment #7) > (In reply to comment #6) > > Das war ein Fehler in der VM, mime-codecs wurde durch eine kaputte > > Repository-Einstellung zurückgehalten. > > Das darvf eigentlich nicht passieren. Das Tool muss dann per > univention-thin-client-download-debs vom Paket mitgebracht werden. Ansonsten > wird das auf amd64-Systemen scheitern. Das war aber ein generischer Fehler in der Verwaltung der apt-Quellen: Ich hatte eine 2.4 von DVD mit den Standard-Thin-Client-Komponenten installiert und dann uts für 2.3 und 2.4 über /etc/apt/sources.list eingebunden. Es fehlten aber in /etc/apt/sources.list.d/15_ucs_online-version.list die generierten Einträge für das Standard 2.3/2.4. mime-codecs kommt nicht aus dem uts-Scope, sondern aus dem normalen Repository, deshalb wurde es zurückgehalten.
Das muss für amd64 noch angepasst werden.
Änderungen angepasst - die base-64* Tools waren auf einem amd64 System nun vorhanden. Changelog wurde nachgetragen.
Ich habe eine TCS 3.1-VM unter amd64 aufgesetzt; eine Windows-TS-Anmeldung hat damit funktioniert und base64-decode und base64-encode sind auf dem Thin Client aufrufbar.
UCS TCS 3.1 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS TCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".