Verbindung permanent trennen?

[Bernd Fröhlich]

Umgebung: mehrere Rechner mit OS X.5.8 (iMac, MacBook, mini, ...)

Problem: Wenn ich mich in der Seitenleiste des Finder-Fensters unter
Freigaben als Registrierter Benutzer an einem anderen Rechner anmelde
und diese Verbindung dann mit dem Button "Trennen" beende, würde ich
eigentlich erwarten, dass ich, wenn ich die Verbindung wieder herstellen
will, wieder das Benutzerkennwort des anderen Rechners eingeben muss.

Dem ist aber leider nicht so!

Nachdem ich auf "Trennen" geklickt habe, steht dort wieder "Verbinden
als...".
Klicke ich darauf, kommt wieder der Anmeldedialog.
Breche ich den Anmeldedialog ab, bin ich trotzdem als der User
verbunden, als der ich mich zuvor mit Kennwort angemeldet hatte!

Das Selbe passiert, wenn ich in der Seitenleiste etwas Anderes anklicke
und dann wieder auf die Freigabe des Rechners, mit dem ich zuvor
verbunden war. Sofort bin ich dann wieder angemeldet, ohne vorher erneut
nach dem Kennwort gefragt zu werden.

Das ist natürlich blöd, wenn man sich von einem fremden Rechner im Netz
mal eben auf seinem eigenen Rechner anmeldet.
Selbst wenn man die Verbindung wieder getrennt hat, kann der fremde User
sich als registrierter Benutzer mit dem eigenen Rechner verbinden ohne
nach dem Kennwort gefragt zu werden.

Entweder ist das eine immense Sicherheitslücke, oder ich habe da
irgendwas Elementares noch nicht kapiert.

Kennt jemand eine Möglichkeit (ausser Neustart), die Verbindung so
wieder zu trennen, dass man sich ohne Kennwort nicht erneut verbinden
kann?


(Google konnte mir nicht helfen. Wenn jemand die passenden Suchwörter
hat, dann immer her damit)

[Thomas Kaiser]

Post by Bernd Fröhlich
Entweder ist das eine immense Sicherheitslücke, oder ich habe da
irgendwas Elementares noch nicht kapiert.

Vielleicht die Bedeutung der Checkbox "Kennwort im Schlüsselbund
sichern", die im Anmeldedialog stets präsent ist? Mal testhalber in
"Schlüsselbundverwaltung.app"nachschauen, ob bzgl. des"Servers" was
gespeichert ist? Und ggf. vor erneuten Versuchen dort restlos löschen?

Gruss,

Thomas

[Bernd Fröhlich]

Post by Thomas Kaiser
Vielleicht die Bedeutung der Checkbox "Kennwort im Schlüsselbund
sichern", die im Anmeldedialog stets präsent ist?

Besagte Checkbox war beim Anmelden nicht abgehakt.

Post by Thomas Kaiser
Mal testhalber in
"Schlu?sselbundverwaltung.app"nachschauen, ob bzgl. des"Servers" was
gespeichert ist? Und ggf. vor erneuten Versuchen dort restlos löschen?

Die Spur ist heiss.
Die Schlüsselbundverwaltung zeigte ein Netzwerkkennwort für diesen
Rechner an, also habe ich es gelöscht.
Das ändert allerdings nichts an dem beschriebenen Verhalten.

Also Testhalber nochmal den Rechner neu gestartet.
Nun fragt er beim ersten Anmeldeversuch wieder nach dem Kennwort.
Nach trennen der Verbindung und nochmaligem Klick auf die Freigabe
meldet er sich allerdings wieder ohne Kennwort an :-/
In der Schlüsselbundverwaltung ist jetzt allerdings kein entsprechender
Eintrag mehr vorhanden.

Das war´s also leider nicht.

(Schlüsselbund Erste Hilfe habe ich auch ausprobiert, hat aber auch
nichts genützt.)

[Dirk Kring]

Post by Bernd Fröhlich

Post by Thomas Kaiser
Vielleicht die Bedeutung der Checkbox "Kennwort im Schlüsselbund
sichern", die im Anmeldedialog stets präsent ist?

Besagte Checkbox war beim Anmelden nicht abgehakt.

Post by Thomas Kaiser
Mal testhalber in
"Schlu?sselbundverwaltung.app"nachschauen, ob bzgl. des"Servers" was
gespeichert ist? Und ggf. vor erneuten Versuchen dort restlos löschen?

Die Spur ist heiss.
Die Schlüsselbundverwaltung zeigte ein Netzwerkkennwort für diesen
Rechner an, also habe ich es gelöscht.
Das ändert allerdings nichts an dem beschriebenen Verhalten.
Also Testhalber nochmal den Rechner neu gestartet.
Nun fragt er beim ersten Anmeldeversuch wieder nach dem Kennwort.
Nach trennen der Verbindung und nochmaligem Klick auf die Freigabe
meldet er sich allerdings wieder ohne Kennwort an :-/
In der Schlüsselbundverwaltung ist jetzt allerdings kein entsprechender
Eintrag mehr vorhanden.
Das war´s also leider nicht.
(Schlüsselbund Erste Hilfe habe ich auch ausprobiert, hat aber auch
nichts genützt.)

Ist der Nutzer auf dem Zielrechner ein lokaler oder einer aus einem
Verzeichnisdienst? Du müßtest dann z.B. über den Kerberos Ticket Viewer
gehen, falls es ein Verzeichnisdienst mit Kerberos Authentifizierung
ist. Ein Kerberos-Ticket gilt häufig bis zu 10 Stunden.

[Bernd Fröhlich]

Post by Dirk Kring
Ist der Nutzer auf dem Zielrechner ein lokaler oder einer aus einem
Verzeichnisdienst?

Kein Verzeichnisdienst.
Ein simples Heimnetzwerk mit 3 Rechnern.
Das Verhalten ist überall dasselbe, egal von welchem auf welchen Rechner
ich mich anmelde.
Nachdem einmal eine Anmeldung mit Kennwort erfolgt ist, wird nach dem
Trennen die nächste Verbindung ohne Kennwortabfrage aufgebaut.

Da das auf jedem Rechner hier auftritt habe ich erstmal angenommen, dass
es das Standardverhalten von OS X.5.8 ist.
Kann das wirklich niemand nachvollziehen?

...

Ah, neue Erkenntnis:
Ich habe auf allen Rechnern einen User namens "bernd". Mit diesem User
tritt besagtes Verhalten aus.
Wenn ich mich auf dem Rechner, von dem aus ich mich anmelde, einen
anderen Useraccount benutze, dann wird nach dem Trennen auch wieder neu
nach dem Kennwort gefragt.
Der Username scheint da also irgendeine Rolle zu spielen.

[Marc Stibane]

Post by Bernd Fröhlich
Ich habe auf allen Rechnern einen User namens "bernd". Mit diesem User
tritt besagtes Verhalten aus.

Evtl. auch auf allen Rechnern dasselbe Passwort?

[Thomas Kaiser]

Post by Marc Stibane

Post by Bernd Fröhlich
Ich habe auf allen Rechnern einen User namens "bernd". Mit diesem
User tritt besagtes Verhalten aus.

Evtl. auch auf allen Rechnern dasselbe Passwort?

Man könnte ja auch evtl. nachschauen, was da hinter den Kulissen
abläuft. Bei mir steht in /etc/syslogd.conf eine Zeile:

*.debug /var/log/debug.log

(halte ich inzwischen für sinniger als den Ansatz, aus "kern.debug"
"*.debug" zu machen und alles nach /var/log/system.log kippen zu lassen
wie noch in <http://kaiser-edv.de/news/MacOS/afp-sessions-debuggen.html>
vorgeschlagen).

Und in eben jenem debug.log verewigt sich NetAuthAgent.app bei mir
ziemlich massiv. Vielleicht finden sich ja dort Hinweise, was konkret
bzgl. Authentifizierung (falsch) läuft?

Gruss,

Thomas

[Bernd Fröhlich]

Post by Thomas Kaiser
Man könnte ja auch evtl. nachschauen, was da hinter den Kulissen
*.debug /var/log/debug.log

Auha, jetzt gehts über meinen Horizont, aber ich bin ja
experimentierfreudig.

/etc/syslogd.conf gibt es bei mir nich, aber dafür
/etc/syslog.conf

wenn ich die mit BBEdit öffne und um obige Zeile ergänzen will, sagt
BBEdit mir erstmal, dass die Datei root gehört und will seine
commandline tools installieren.

Ehe ich mir da jetzt was zerschiesse:
ist /etc/syslog.conf die richtige Datei und kann ich die gefahrlos
ändern?
Muss ide Zeile an einer bestimmten Stelle rein, oder ist es egal?

Momentan sieht die Datei so aus:

*.err;kern.*;auth.notice;authpriv,remoteauth,install.none;mail.crit
/dev/console
*.notice;authpriv,remoteauth,ftp,install.none;kern.debug;mail.crit
/var/log/system.log

# Send messages normally sent to the console also to the serial port.
# To stop messages from being sent out the serial port, comment out this
line.
#*.err;kern.*;auth.notice;authpriv,remoteauth.none;mail.crit
/dev/tty.serial

# The authpriv log file should be restricted access; these
# messages shouldn't go to terminals or publically-readable
# files.
auth.info;authpriv.*;remoteauth.crit
/var/log/secure.log

lpr.info /var/log/lpr.log
mail.*
/var/log/mail.log
ftp.* /var/log/ftp.log
install.*
/var/log/install.log
install.* @127.0.0.1:32376
local0.*
/var/log/appfirewall.log
local1.*
/var/log/ipfw.log

*.emerg *

[Daniel K®ebs]

Post by Bernd Fröhlich
/etc/syslogd.conf gibt es bei mir nich, aber dafür
/etc/syslog.conf

Ist schon ok. Ein sehr beliebter Schreibfehler, weil es ja die
Konfigurationsdatei des syslogd ist :-)
Daniel

[Thomas Kaiser]

Post by Bernd Fröhlich
ist /etc/syslog.conf die richtige Datei und kann ich die gefahrlos
ändern?

Ja, das ist die richtige Datei. Und vermutlich nichts ist gefahrlos,
wenn man es ohne Ahnung betreibt.

Post by Bernd Fröhlich
Muss ide Zeile an einer bestimmten Stelle rein, oder ist es egal?

Das wäre egal.
Garantiert _so_ wird die syslog.conf nicht aussehen (weil falsch
umbrochen), denn dann wäre sie schon defekt und Du hättest ein Problem.

Die Zeilenumbrüche sind eine "Gefahrenquelle", Encodings (v.a. UTF8-BOM,
das Du evtl. aus Versehen einschleifst) eine andere. Laß es lieber sein,
wenn das Ändern einer kleinen Konfig-Datei eine solche Hürde darstellt.

Mit BBEdit handelt man sich zwar nicht aus Versehen eine völlig andere
Repräsentation der Datei ein (bspw. auf einmal RTF) und kann per
Authentifizierungs-Nachfrage auch Dateien wieder sichern, die eigentlich
nur root ändern darf... aber irgendwie ist das der falsche Ansatz vgl.
mit

sudo cp -p /etc/syslog.conf /etc/syslog.conf.bak
sudo nano -w /etc/syslog.conf

(vollwertige Sicherungskopie der Datei für alle Fälle anfertigen, sehr
gefahrlose "text only"-Editierung starten). Ein bisserl Trittsicherheit
sollte vorhanden sein, wenn man die muffige und bisweilen steile Treppe
in den BSD-Keller hinabsteigt...

Gruss,

Thomas

[Bernd Fröhlich]

Post by Thomas Kaiser
Ein bisserl Trittsicherheit
sollte vorhanden sein, wenn man die muffige und bisweilen steile Treppe
in den BSD-Keller hinabsteigt...

OK, dann breche ich an der Stelle lieber ab, eh ich noch die
Kellertreppe runterstürze. Soo dringend ist mir das Problem jetzt nicht.
Ich dachte, das wäre evtl. allgemein bekannt und es gäbe eine einfache
Lösung.

Auf jeden Fall Danke für Deine Hinweise.

[Thomas Kaiser]

Post by Bernd Fröhlich

Ein bisserl Trittsicherheit sollte vorhanden sein, wenn man die
muffige und bisweilen steile Treppe in den BSD-Keller hinabsteigt...

OK, dann breche ich an der Stelle lieber ab, eh ich noch die
Kellertreppe runterstürze. Soo dringend ist mir das Problem jetzt nicht.
Ich dachte, das wäre evtl. allgemein bekannt und es gäbe eine einfache
Lösung.

Also "allgemein bekannt" war das IMO nicht. Ich kann's aber inzwischen
nachvollziehen (eben gegen meinen Mac Mini mit 10.6.3 und nicht nur
3rd-Party-AFP-Server getestet).

Solange der AFP-URI gleichbleibt (also in meinem Fall bspw. zweimal
nacheinander Zugriff auf "afp://Keksdose"), werden bei einem relativ
kurzfristig erfolgenden erneutem Mount-Versuch keine Logon Credentials
abgefragt. Ändere ich den AFP-URI (bspw. auf "afp://192.168.83.30", was
ebenfalls auf den Mini zeigt), wird wieder nachgefragt.

In debug.log fliegt auch 'ne Menge an aber ich hab grad weder Zeit noch
Lust, den Kram näher anzuschauen (dito Sniffer anzuwerfen, etc.)

Wenn sich Zeit/Lust einstellen (dazu muß sich aber die Frühlingssonne
wieder vom Acker machen ;-) guck ich mal, ob's ggf. was mit AFP
Reconnects zu tun hat. Obwohl das könnteste auch selber: Schau mal nach,
auf was "afp_reconnect_max_time" auf Deinem "Client" steht und laß mal
mindestens diese Zeitspanne (wird in Sekunden angegeben) zwischen zwei
Zugriffsversuchen verstreichen.

Nachschauen (völlig gefahrlos) in Terminal.app per

defaults read /Library/Preferences/com.apple.AppleShareClient

Gruss,

Thomas

[Bernd Fröhlich]

Post by Thomas Kaiser
Also "allgemein bekannt" war das IMO nicht. Ich kann's aber inzwischen
nachvollziehen (eben gegen meinen Mac Mini mit 10.6.3 und nicht nur
3rd-Party-AFP-Server getestet).

Ah, super. Dann gibt es das Problem also wirklich. Danke fürs
Ausprobieren.

Post by Thomas Kaiser
Wenn sich Zeit/Lust einstellen (dazu muß sich aber die Frühlingssonne
wieder vom Acker machen ;-) guck ich mal, ob's ggf. was mit AFP
Reconnects zu tun hat. Obwohl das könnteste auch selber: Schau mal nach,
auf was "afp_reconnect_max_time" auf Deinem "Client" steht und laß mal
mindestens diese Zeitspanne (wird in Sekunden angegeben) zwischen zwei
Zugriffsversuchen verstreichen.
Nachschauen (völlig gefahrlos) in Terminal.app per
defaults read /Library/Preferences/com.apple.AppleShareClient

Das liefert "afp_reconnect_max_time" = 600;

Sind das jetzt Minuten, Sekunden, Stunden, ...?

Die Vermutung hatte ich inzwischen aber auch schon, dass es da
irgendeinen Timeout gibt, innerhalb dessen kein Kennwort abgefragt wird.
Selbst nach über einer Stunde wird die Verbindung allerdings wieder ohne
Abfrage hergestellt.
Allerdings nur zu dem Useraccount an meinem MacBook, der den gleichen
Namen hat wie mein Account auf meinem iMac (bzw. andersrum).

Wenn ich mich von meinem iMac am mini meiner Tochter anmelde, wo es
keinen User mit meinem Namen gibt, tritt das Problem nicht auf. Wenn ich
mich von ihrem mini bei meinem iMac anmelde allerdings schon.
(Das war überhaupt der Grund der Anfrage. Wenn ich ihr an ihrem Rechner
was von meinem Rüberkopiere, soll sie sich danach natürlich nicht
einfach so mit meinem Rechner verbinden können :-)

Sehr misteriös, das Ganze.

[Ralph Böhme]

Post by Bernd Fröhlich

Post by Thomas Kaiser
Also "allgemein bekannt" war das IMO nicht. Ich kann's aber inzwischen
nachvollziehen (eben gegen meinen Mac Mini mit 10.6.3 und nicht nur
3rd-Party-AFP-Server getestet).

Ah, super. Dann gibt es das Problem also wirklich. Danke fürs
Ausprobieren.

Post by Thomas Kaiser
Wenn sich Zeit/Lust einstellen (dazu muß sich aber die Frühlingssonne
wieder vom Acker machen ;-) guck ich mal, ob's ggf. was mit AFP
Reconnects zu tun hat. Obwohl das könnteste auch selber: Schau mal nach,
auf was "afp_reconnect_max_time" auf Deinem "Client" steht und laß mal
mindestens diese Zeitspanne (wird in Sekunden angegeben) zwischen zwei
Zugriffsversuchen verstreichen.
Nachschauen (völlig gefahrlos) in Terminal.app per
defaults read /Library/Preferences/com.apple.AppleShareClient

Das liefert "afp_reconnect_max_time" = 600;
Sind das jetzt Minuten, Sekunden, Stunden, ...?
Die Vermutung hatte ich inzwischen aber auch schon, dass es da
irgendeinen Timeout gibt, innerhalb dessen kein Kennwort abgefragt wird.
Selbst nach über einer Stunde wird die Verbindung allerdings wieder ohne
Abfrage hergestellt.
Allerdings nur zu dem Useraccount an meinem MacBook, der den gleichen
Namen hat wie mein Account auf meinem iMac (bzw. andersrum).
Wenn ich mich von meinem iMac am mini meiner Tochter anmelde, wo es
keinen User mit meinem Namen gibt, tritt das Problem nicht auf. Wenn ich
mich von ihrem mini bei meinem iMac anmelde allerdings schon.
(Das war überhaupt der Grund der Anfrage. Wenn ich ihr an ihrem Rechner
was von meinem Rüberkopiere, soll sie sich danach natürlich nicht
einfach so mit meinem Rechner verbinden können :-)
Sehr misteriös, das Ganze.

Ahh, ebent machts klick. Obwohl afair Daniel schon den Hinweis gab:
Kerberos. Seit 10.5 in OS X (Client) in der Variante Local KDC:
<http://www.afp548.com/article.php?story=20080709091503862&mode=print>

Dann sollte zum Zeitpunkt wo die Auth. ohne PW geht `klist` wohl
ein Ticket anzeigen.

Gruß Ralph

[Dirk Freibeuter]

Post by Ralph Böhme
<http://www.afp548.com/article.php?story=20080709091503862&mode=print>

Scheint mir auch so. Kai Surendorf sagt mir in seinem Buch zu 10.5, dass
mit "Verbinden als" (= nicht als Gast) ein Kerberos-Ticket erstellt
wird. Die Gültigkeit ist 10 Stunden.

Grüße, Dirk

[Thomas Kaiser]

[Ralph Böhme wrote:]

Post by Ralph Böhme
<http://www.afp548.com/article.php?story=20080709091503862&mode=print>

Scheint mir auch so. Kai Surendorf sagt mir in seinem Buch zu 10.5,
dass mit "Verbinden als" (= nicht als Gast) ein Kerberos-Ticket
erstellt wird. Die Gültigkeit ist 10 Stunden.

Tatsache: klist(1) listet zwei Tickets (krbtgt und afpserver) mit je 10
Std. Gültigkeit. Ein forsches "kdestroy -a" löscht sie, und man darf
wieder erneut Logon Credentials eingeben...

Gruss,

Thomas

[Dirk Kring]

Post by Thomas Kaiser

[Ralph Böhme wrote:]

Post by Ralph Böhme
<http://www.afp548.com/article.php?story=20080709091503862&mode=print>

Scheint mir auch so. Kai Surendorf sagt mir in seinem Buch zu 10.5,
dass mit "Verbinden als" (= nicht als Gast) ein Kerberos-Ticket
erstellt wird. Die Gültigkeit ist 10 Stunden.

Tatsache: klist(1) listet zwei Tickets (krbtgt und afpserver) mit je 10
Std. Gültigkeit. Ein forsches "kdestroy -a" löscht sie, und man darf
wieder erneut Logon Credentials eingeben...
Gruss,
Thomas

Sollte das nicht auch über die Schlüsselbundverwaltung ->
Kerberos-Ticket-Viewer gehen?

[Thomas Kaiser]

Post by Dirk Kring

Post by Thomas Kaiser

[Ralph Böhme wrote:]

Post by Ralph Böhme
Ahh, ebent machts klick. Obwohl afair Daniel schon den Hinweis
gab: Kerberos. Seit 10.5 in OS X (Client) in der Variante Local
<http://www.afp548.com/article.php?story=20080709091503862&mode=print>

Scheint mir auch so. Kai Surendorf sagt mir in seinem Buch zu 10.5,
dass mit "Verbinden als" (= nicht als Gast) ein Kerberos-Ticket
erstellt wird. Die Gültigkeit ist 10 Stunden.

Tatsache: klist(1) listet zwei Tickets (krbtgt und afpserver) mit je 10
Std. Gültigkeit. Ein forsches "kdestroy -a" löscht sie, und man darf
wieder erneut Logon Credentials eingeben...

Sollte das nicht auch über die Schlüsselbundverwaltung ->
Kerberos-Ticket-Viewer gehen?

Yep, tut's auch. Wobei Keychain.app in dem Fall nur

/System/Library/CoreServices/Kerberos.app

aufruft und dort der Rest (erneuern, löschen, ändern) geschieht. Könnte
man also auch direkt starten, wenn man es nur braucht, um Tickets zu
löschen und nicht in Terminal.app rumwuseln will. Ah, grad gesehen, daß
das Dingens auch noch hinreichend AppleScriptable ist, d.h. ein Script

tell app "Kerberos" to destroy tickets

funktioniert auch für den Zweck.

Gruss,

Thomas

[Bernd Fröhlich]

Post by Dirk Kring
Sollte das nicht auch über die Schlüsselbundverwaltung ->
Kerberos-Ticket-Viewer gehen?

Jau, das ist es in der Tat. Also doch "Standardverhalten".

Ich werte das trotzdem als massive Sicherheitslücke.
Normalerweise erwarte ich nicht, dass eine getrennte Verbindung einfach
so wiederhergestellt werden kann.
Scheint hier ja auch sonst keinem so auf anhieb klar gewesen zu sein.

Wie auch immer, nun weiss ich zumindest was los ist und kann das Ticket
löschen.

Besten Dank an alle, die zur Aufklärung beigetragen haben.

[Ralph Böhme]

Post by Bernd Fröhlich

Post by Dirk Kring
Sollte das nicht auch über die Schlüsselbundverwaltung ->
Kerberos-Ticket-Viewer gehen?

Jau, das ist es in der Tat. Also doch "Standardverhalten".
Ich werte das trotzdem als massive Sicherheitslücke.

Headline @ mitre.org:
dcsmln entdeckt massive Sicherheitslücke in Kerberos.
*kicher*

Post by Bernd Fröhlich
Normalerweise erwarte ich nicht, dass eine getrennte Verbindung einfach
so wiederhergestellt werden kann.
Scheint hier ja auch sonst keinem so auf anhieb klar gewesen zu sein.

Man wird ja nochmal aufm Schlauch stehen dürfen. ;)

Gruß Ralph

[Dirk Kring]

Post by Bernd Fröhlich

Post by Dirk Kring
Sollte das nicht auch über die Schlüsselbundverwaltung ->
Kerberos-Ticket-Viewer gehen?

Jau, das ist es in der Tat. Also doch "Standardverhalten".
Ich werte das trotzdem als massive Sicherheitslücke.
Normalerweise erwarte ich nicht, dass eine getrennte Verbindung einfach
so wiederhergestellt werden kann.
Scheint hier ja auch sonst keinem so auf anhieb klar gewesen zu sein.
Wie auch immer, nun weiss ich zumindest was los ist und kann das Ticket
löschen.

Ich könnte wetten, das das so eingerichtet wurde auf Forderung vieler
bequemer Nutzer. Schutz vor unberechtigten Zugriff macht man halt durch
Anwesenheit bzw. Sperrung durch Abmeldung bzw. Bildschirmschoner mit
Paßwort.

[Thomas Kaiser]

Post by Bernd Fröhlich

Post by Dirk Kring
Sollte das nicht auch über die Schlüsselbundverwaltung ->
Kerberos-Ticket-Viewer gehen?

Jau, das ist es in der Tat. Also doch "Standardverhalten".

Nur gegenüber einem "kerberisierten" (was'n Wort) AFP-Server und erst ab
10.5 und in der Spielart Kerberos "Local beros Key Distribution Center"
(LKDC). Also vulgo zwischen zwei Macs mit (Snow) Leopard ;-)

Lies Dir

<http://www.afp548.com/article.php?story=20080709091503862>

einfach nochmal genau durch.

Nutzer, die in kerberisierte Verzeichnisdienste eingebunden sind
(OpenDirectory, Active Directory) kennen die "Problematik" schon länger.
Mit lokaler Anmeldung am (Client-)Rechner steht auch alles netzwerkweit
zur Verfügung, was dieser am Verzeichnis angemeldete Benutzer dort im
Zugriff hat. Abmelden nach Beendigung der Arbeit ist daher Pflicht.

Ab 10.5 muß man das nun auch ohne existente Verzeichnisdienste im
Hinterkopf behalten (betrifft ja nicht nur den AFP-Server sondern andere
Dienste wie SMB und VNC/ScreenSharing genauso -- man vergleiche mit
"sudo klist -kt")

Post by Bernd Fröhlich
Ich werte das trotzdem als massive Sicherheitslücke.
Normalerweise erwarte ich nicht, dass eine getrennte Verbindung
einfach so wiederhergestellt werden kann.

Naja, das Verfahren nennt sich "Single Sign On" und so drastisch ist das
alles nicht, schließlich kann auf dem Weg nicht das Paßwort an sich
(bzw. die konkreten Logon Credentials) ermittelt werden (man kerberos --
in dem Fall mal tatsächlich sinnig ;-)

Man muß halt im Hinterkopf haben, daß in heutigen Zeiten (wo sich das
sicherlich schon 30 Jahre alte Kerberos dann doch tatsächlich so langsam
aber sicher auch in der Praxis durchsetzt) auf Fremdrechnern nicht nur
das Löschen von Browser-Cache, -History, etc. nötig sein kann sondern
sowas auch für Fileserver-Verbindungen und Fernwartung gilt. Im
Zweifelsfall immer noch ein Neustart hinterher...

In _welchen Szenarien_ siehst Du denn konkret Mißbrauchsgefahr bzw. das
Sicherheitsrisiko?

Post by Bernd Fröhlich
Scheint hier ja auch sonst keinem so auf anhieb klar gewesen zu sein.

Liegt wohl auch daran, daß die AFP-Kasper hier mit ziemlich hoher
Wahrscheinlichkeit immer einen 3rd-Party-AFP-Server im Zugriff haben
aber eben nicht immer einen zweiten Mac (ich hab jahrelang den Testsepp
für Netatalk-Entwickler gespielt, die noch nicht mal einen einzigen Mac
hatten -- bis ich irgendwann entnervt Kunden um Spenden angehauen habe)

Post by Bernd Fröhlich
Wie auch immer, nun weiss ich zumindest was los ist und kann das
Ticket löschen.

Wobei für Dich ein AppleScript-Applet (siehe Vorposting) wohl das
schnellste wäre. Kannst Dich aber natürlich auch mit sso_util(8) auf
Deinem "Server" spielen, um dem AppleFileServer Kerberos abzugewöhnen.

Gruss,

Thomas

[Bernd Fröhlich]

Post by Thomas Kaiser
In _welchen Szenarien_ siehst Du denn konkret Mißbrauchsgefahr bzw. das
Sicherheitsrisiko?

Z.B.: Ich melde mich kurz vom Rechner meiner Tochter bei meinem Rechner
an, um ihr etwas rüberzukopieren.
Danach hat sie vollen Zugriff auf meinen User, selbst nachdem ich die
Verbindung getrennt habe.

Selbes Szenario in der Firma: Ich melde mich mal kurz auf meinem MacBook
an, um einem anderen User was rüberzukopieren. Weiter wie oben.

Wenn man nicht weiss, dass der Zugriff dann ohne Kennworteingabe möglich
ist, kann das haarig werden.

Jetzt weiss ich ja dank Euch glücklicherweise wie ich das verhindern
kann.

Post by Thomas Kaiser
Kannst Dich aber natürlich auch mit sso_util(8) auf
Deinem "Server" spielen, um dem AppleFileServer Kerberos abzugewöhnen.

Umm, da war doch was mit Kellertreppe und so. Da spiel ich lieber nicht
dran rum :-)

[Thomas Kaiser]

Post by Bernd Fröhlich

Post by Thomas Kaiser
In _welchen Szenarien_ siehst Du denn konkret Mißbrauchsgefahr bzw.
das Sicherheitsrisiko?

Z.B.: Ich melde mich kurz vom Rechner meiner Tochter bei meinem
Rechner an, um ihr etwas rüberzukopieren.
Danach hat sie vollen Zugriff auf meinen User, selbst nachdem ich die
Verbindung getrennt habe.

Naja, "voller Zugriff auf Deinen User"... das ist ziemlich flapsig
formuliert und in jedem Fall am Ziel vorbei. Alles, was sie in dem Fall
machen kann (wenn sie es denn überhaupt weiß bzw. auf die Idee kommt),
ist eine erneute AFP-Verbindung herzustellen und Zugriff auf die Shares
zu bekommen, die mit Deinen vorher eingegebenen Logon Credentials
erreichbar waren (soger NetAuthAgent.app das Kerberos Ticket dafür für
valide hält).

Klar, bedeutet voller Fileserver-Zugriff auf Dein HomeDir (außer "Dein
User" steckt auch noch in der admin-Gruppe, dann Zugriff auf alle Shares
respektive Volumes). Aber mehr auch erstmal nicht. Um hier 'nen
Vollzugriff (im Sinne "steuern") zu erlangen, muß sie dann doch noch
bisserl mehr drauf haben ("privileges escalation")

Post by Bernd Fröhlich
Selbes Szenario in der Firma: Ich melde mich mal kurz auf meinem
MacBook an, um einem anderen User was rüberzukopieren. Weiter wie
oben.

Auch da erstmal so nur Dateiserver-Zugriff. Und man sollte IMO sehr,
sehr vorsichtig sein, was man auf fremden Rechnern macht. Ich kenne
konkret zwei IT-Abteilungen in eher großen Firmengruppen, die für
Externe Notebooks vorhalten (eigene bzw. externe Rechner dürfen nicht
ans LAN), auf denen allerhand Zeugs installiert ist, unter anderem
Keylogger. Damit gibst Du wirklich Logon Credentials aus der Hand, da
auf dem Weg Username/Paßwort aufgezeichnet werden und nicht nur ein
Kerberos-Ticket eine Zeit lang Gültigkeit hat...

Post by Bernd Fröhlich

Post by Thomas Kaiser
Kannst Dich aber natürlich auch mit sso_util(8) auf Deinem "Server"
spielen, um dem AppleFileServer Kerberos abzugewöhnen.

Umm, da war doch was mit Kellertreppe und so. Da spiel ich lieber
nicht dran rum :-)

Ich les mich da auch noch grad bisserl ein. Aber das scheint damit
möglich zu sein, zumindest, was Tante Google, nach "sso_util lkdc"
gefragt, so meint.

Gruss,

Thomas

[Daniel Krebs]

Post by Bernd Fröhlich
Z.B.: Ich melde mich kurz vom Rechner meiner Tochter bei meinem Rechner
an, um ihr etwas rüberzukopieren.
Danach hat sie vollen Zugriff auf meinen User, selbst nachdem ich die
Verbindung getrennt habe.

Aber das ist doch Deine Tochter. Hast Du etwa Geheimnisse vor ihr?
(-;
Daniel

[Daniel Krebs]

Post by Ralph Böhme
<http://www.afp548.com/article.php?story=20080709091503862&mode=print>

Nee, ich war's nicht.
Aber endlich mal wie der ein interessanter thread...
Daniel

[Bernd Fröhlich]

Post by Marc Stibane

Post by Bernd Fröhlich
Ich habe auf allen Rechnern einen User namens "bernd". Mit diesem User
tritt besagtes Verhalten aus.

Evtl. auch auf allen Rechnern dasselbe Passwort?

Ja.
Aber das hatte ich testweise auch schonmal geändert.
Er hat sich trotzdem beim zweiten mal wieder einfach so angemeldet.