Hallo liebe Leute!

Könnt ihr folgendes bestätigen?

Wir haben zwei Rechner mit Leopard, nennen wir sie A und B.
Wir sitzen am Rechner A, öffnen ein Finder-Fenster in Spaltenansicht (wichtig?). Wir gehen zum Netzwerk (command-shift-k) und klicken auf den Rechner B, dann "verbinden als...". Wir verbinden uns also dann mit stinknormalem Filesharing (AFP) als registrierter Benutzer mit Passwort mit Rechner B.
Als nächstes trennen wir diese Verbindung wieder, indem wir in der Spaltenansicht auf "Trennen" drücken.

Jetzt das interessante: obwohl wir uns vorher korrekt vom Rechner B getrennt haben, und das Kennwort des registrierten Benutzers NICHT im Schlüsselbund gesichert haben, können wir trotzdem wieder vollen Zugriff auf den Rechner B haben!

Einfach nochmal das Netzwerk in Spaltenansicht öffnen, auf den Rechner B klicken, und ohne Kennworteingabe ist alles erreichbar!

Auch wenn man sich als Benutzer vom Rechner A abmeldet, dann wieder einloggt, ist immer noch der automount möglich!

Und jetzt die Krönung: wir ändern am Rechner B das Kennwort, und trotzdem können wir immer noch dank dem automount auf alle Sachen zugreifen, ohne ein Kennwort eingeben zu müssen!!

Erst ein Neustart des Rechners A scheint das ganze zu beheben.

(sick)

Könnt ihr mir bestätigen, dass das bei euch auch so ist??

Das ist ja heftig! =-O

gib mal im nach dem angeblichen trennen im Terminal "mount" ein und guck, ob die Platte wirklich weg ist. Wenn nicht ist sie immer noch unsichtbar da und es ist somit auch kein wunder das man einfach wieder dran kommt

@ ChrisK

Auf die Idee bin ich auch schon gekommen: tatsächlich erscheint nach dem "Trennen" KEIN AFP-Sharepoint mehr, sobald man sich aber wieder (ungewollter weise) verbunden hat und einen Sharepoint aktiviert hat, gibt es einen entsprechenden Eintrag.

Scheint tatsächlich ein Mount ohne Kennworteingabe zu sein.


Gibt es vielleicht unter 10.5 ein neues Kommunikationsprotokoll für AFP? Vielleicht irgendwelche generierten Schlüssel für automount oder so??

Unter Windows war das schon lange so.
Da wurden die Verbindungs-Informationen auch gecached.

Vielleicht gibt es ja ein Timeout, nach dem die Daten vergessen werden.

Ad Astra

Also ich konnte hier letzte Woche beim Test von 10.5 Leopard folgendes Phänomen beobachten:

- unseren Server (10.3.9 Panther) per Apfel+K angemeldet

- funktionierte normal

- später wieder abgemeldet (in den Papierkorb gezogen)

- etwas später erneut angemeldet … ABER

- Server-Platte nicht sichtbar … SONDERN

- erst nach "abschießen" (Apfel+Alt+Esc) des Finders

wheeler

Also: auf den Rechnern A und B gibt es jeweils mindestens einen Admin-Accounts, bei dem File-Sharing für den "Öffentlich"-Ordner mit den Standardwerten aktiviert ist. Das heisst: User lesen&schreiben, Gruppe nur lesen, andere nur lesen.
Beides sind die normalen Client-Versionen.
Und dass das nicht einfach irgendwie gecached ist glaube ich auch.

Stardust

Ich finde das ziemlich unsicher. Eigentlich sollte sich der Rechner nur dann Name und Passwort speichern, wenn ich ihn darum bitte!

Hast du mal versucht das Passwort auf dem Server zu ändern, einen Neustart ausgeführt und dann geguckt, ob er immer noch Zugriff hat?

Und wenn zwischenzeitlich das Netzwerk "hustet", dann wird man immer wieder nach dem Zugang gefragt.

Dann fangen andere an zu meckern.

Aber im Prinzip hast du Recht.
Zumindest sollte die Strategie von MacOS X offen gelegt werden.

Ad Astra

Also liebe Leute, die Lösung des Rätsels:

It´s not a bug, it´s a feature:

Screen share to another machine as a local user by picking the
machine out of the sidebar in the Finder. You'll have to enter in
your password the first time, but after that you can close out of
that screen sharing session and restart it without having to re-enter
your password. You can also see the ticket in the Kerberos.app, still
buried in /System/Library/CoreServices.

steht so auf AFP548:

Warum das dann auch für AFP gilt, wenn man aus der Column-View kommt, finde ich genau wie den ganzen Rest äußerst fragwürdig.

(sick)(sick)

oder in der osx-hilfe:

"Mithilfe von Kerberos können Sie auf sichere Weise auf mehrere Netzwerkdienste zugreifen, ohne Ihre Kennwörter stets erneut eingeben zu müssen.

Zu den Mac OS X-Programmen, die Kerberos verwenden können, zählen Safari, SSH (Secure Shell), SMB (Server Message Block), Mail, Telnet, der VPN-Client (Virtual Private Network) und der AFP-Client (Apple Filing Protocol)."

oder auf apples website zu kerberos:

das muss so sein. nachzulesen in der wikipedia unter kerberos:

"Kerberos unterstützt Single Sign On, das heißt, ein Benutzer muss sich nur noch einmal anmelden, dann kann er alle Netzwerkdienste nutzen, ohne ein weiteres Mal ein Passwort eingeben zu müssen. Kerberos übernimmt die weitere Authentifizierung."

wenn du jemanden rausschmeissen willst. musst du also erst den kerberosdienst zurücksetzen oder so.

*link nachreich*

@ wheeler: ja nu, dann musst du bzw. dein admin das halt ausstellen. aber ob das sicherer ist, jedesmal das passwort über das netzwerk wandern zu lassen?

wheeler
Zum Beispiel in meiner Situtation, wo ich täglich 200+Macs supporte, und dabei nicht zu selten auf andere Rechner / Server zugreifen muss, zum Beispiel unseren Software-Server. Nicht gerade angenehm, dass ich jetzt jedes mal entweder den Schlüsselbund, oder den "mit Server verbinden..."-Dialog besuchen muss, oder sogar neustarten muss, nur damit andere User nicht vollen Admin-Zugriff erhalten. Grauenhaft!

Btw: nicht schlimm, bin ja froh, dass ich jetzt ne Erklärung habe..
Muss jetzt nur noch nen Weg finden, dass ganze kerberizen von vorn herein zu verhindern...

pünktchen
Dafür gibt´s ja SSL, zumindest für MacOS X Server -Verbindungen. Außerdem ist unser Netzwerk ziemlich dicht nach außen.

Und ausstellen, gerne, aber wie?? Die Erwartung, das "Trennen.." auch trennen bedeutet, hat Apple da zumindest nicht erfüllt.

wheeler
Genau das hat aber nicht geklappt. Werde das aber noch mal genauer im Einzelnen prüfen müssen.

das passwort dient wie gesagt nur der ersten identifikation (meist am tag). danach werden die kerberosschlüssel verwendet.

Asmus0285: wie kommst du darauf, alle nutzer hätten admin-zugriff?

pünktchen

Das Problem ist, dass ich den vollen Zugriff auf benutzte Rechner via AFP offen stehen lasse, wenn ich nicht extra das Kerberos Ticket lösche oder den Rechner neustarte.
Wenn ich also als [User:mustermann, Passwd:test] ein registrierter Benutzer auf unserem Software-Server oder irgend einem anderen Rechner bin, reicht es nicht, nach dem Benutzen "Trennen" zu drücken.
Jeder, der danach wieder auf den Rechner klickt, hat ungefragter Weise wieder vollen Zugriff.
Und ja, der registrierte Benutzer auf dem "entfernten" Rechner hat üblicherweise Admin-Rechte.

developer.apple.com

... is exactly what Kerberos accomplishes in its implementation of Single Sign On in network environments. At the beginning of the workday, a user enters his/her password into the system once; this action decrypts a ticket from a server running as a Kerberos Key Distribution Center (KDC). The ticket holds a set of encrypted keys, which are used throughout the day to authenticate user access without exchanging sensitive password information. It expires after a given amount of time (typically one day), so even if a would-be intruder sniffs it out and decrypts the information, the user-access information remains safe in the long term.

Asmus0285:

"jeder" ist dann aber jeder, der denselben account benutzt. dann ist doch wohl das gemeinsame nutzen des accounts die sicherheitslücke und nicht kerberos.

aber vielleicht hilft dir ja kdestroy weiter:

ha - es geht auch mit gui! etwas versteckt: /System/Library/CoreServices/Kerberos.app

dein problem & die lösung fand ich hier:

Wie gesagt, Kerberos an sich ist ja ganz nett - aber die Tatsache, dass es für den "normalen" User keinerlei Hinweis gibt, dass man sich später wiederverbinden kann, und es keinen "jetzt bitte trennen, aber auch richtig!"-Knopf gibt, finde ich bedenklich.

Jetzt kann ich, sobald z.B. ein User eines entfernten Rechners "mal eben" Daten von seinem Computer auf meinen kopiert hat sogar Screen Sharing anschalten, und ihn beobachten.
Das Ticket gilt scheinbar also übergreifend für AFP und VNC (vielleicht auch SSH??), wobei das nun eben auch nicht immer klappt (s. "mit server verbinden..") und das finde ich eben nicht gut.
Beim sichern im Schlüsselbund gibt es wenigstens ein kleines Häckchen zu setzen.

schaut soch mal in die Schlüsselbundverwaltung, dagibt es den Keberos-Ticket-Viewer, da kann man das beobachten oder auch löschen.

ja nu, steht doch in der hilfe, hab ich oben schon gepostet:

"Zu den Mac OS X-Programmen, die Kerberos verwenden können, zählen Safari, SSH (Secure Shell), SMB (Server Message Block), Mail, Telnet, der VPN-Client (Virtual Private Network) und der AFP-Client (Apple Filing Protocol)"

und man kann auch einstellen wie lange ein Ticket gültig sein soll usw.

@ ralfi: ist aber recht gut versteckt!

pünktchen
Das gemeinsame Nutzen lässt sich aber kaum vermeiden, wenn
a) z.B. ich als IT-Supportler bei irgendwem mal eben schnell was installieren muss
b) User A User B mal eben die tolle .ppt oder was auch immer zeigen will, und sie vorher nicht in seinen öffentlichen Ordner gelegt hat. Das gab vor 10.5 nicht unbemerkt vollen Zugriff.

Die Tatsache, dass ich "mal eben" in /System/Library/CoreServices/Kerberos.app gehen, oder kdestroy eingeben oder neustarten muss, ist für den OttoNormalo nirgendswo ersichtlich, und das ist nicht gut.

Oder wusstet ihr, schon vor diesem Thread, dass ihr jedem User, von dessen Rechner aus ihr ne Datei von eurem eigenen kopiert habt, 10 h freien Zugang zu eurem Rechner beschert?

das war vorher bei kerberos auch so. wenn ich recht verstehe, ist der unterschied lediglich, dass jetzt auch jeder client ein kerberosserver ist, kerberos also auch in einem serverlosen netzwerk funktioniert.

und nein, das wusste ich nicht. aber das man sich von einem fremden account nicht irgendwo als admin einloggt, wenn man auf die sicherheit seiner daten wert legt, sollte doch eigentlich naheliegend sein.

pünktchen
Ja, deswegen nutze ich ja auch meistens SSL/SCP bzw. auf der Arbeit unsere zusätzlichen Admin-Accounts, und weiß jetzt ja auch wie mit Kerberos umzugehen ist.

Zu Zeiten von 10.4. hätte es jedenfalls meiner Meinung nach mehr Aufwand bedeutet, ohne das Wissen des (normal-) Users Passwortunabhängige Zugriffe zu ermöglichen, ohne ihn darüber zu informieren. Und das halte ich für eine Sicherheitslücke.

Gegen den Cache spricht aber, daß auch nach Ändern des Paßwortes der zugriff noch geht.
Der müßte dann ja eigentlich abgelehnt werden oder täusche ich mich da?

Asmus0285:
Als was für ein Benutzer war der Benutzer von Rechner A denn auf Rechner B angelegt?
Admin, normaler Nutzer oder "sharing only"?
Will das heute abend mal nachstellen mit iMac und MacBook.
Waren beides Clientversionen von Leo oder war einer der beiden Rechner mit Leo Server ausgestattet?

Asmus0285:
Alles klar. Sollte also kein Problem sein, das nachzustellen. Wenn ich heute Abend von der Arbeit zurück bin werde ich das mal testen. Denke aber auch nicht, daß das gecached ist.
Hast Du mal geschaut, ob Du irgendwo irgendwelche *.plist-Dateien oder sowas findest? Das wäre zwar ziemlich nachlässig aber... Naja.
Könnte auch sein, daß es nach dem Schema läuft:

RachnerA an RechnerB: Hallo, Hier ist User Bla mit Paßwort blabla und will zugreifen.

RechnerB an Rechner A: User und Paßwort sind o.k., dann mal los.

Dann Rechner A an B: So, Tschüß, wir sind fertig und dann mal wieder wech.

RechnerB: Alles klar, macht's gut.

Wenn dann aber die Verbindung wiederhergestellt wird:

RechnerA an RechnerB: Wir sind's wieder, Rechner A mit User Bla
RechnerB: Ach so, na dann, legt mal los....


Will sagen, daß es dann evtl. keine Rolle spielt, weil auf RechnerB nur hinterlegt ist, daß der User schonmal verbunden war. Und es deswegen irrelevant ist, ob das Paßwort geändert wurde oder nicht...

Aha.
Das klingt mal interessant.
Das heißt, daß der zweite Rechner dann tatsächlich sagt "Ihr schon wieder? Na los, kommt rein, macht's Euch bequem."
Ob ich das so gut finde weiß ich noch nicht so recht. Es gibt garantiert Situationen in denen man so ein Verhalten NICHT haben möchte...

Btw.: Ich hatte gestern kenie Gelegenheit mehr, das zu testen... Besprechung mit meinem Chef bis 23.45h und dann war ich noch verabredet, das war mir dann doch wichtiger...
Sorry, Asmus0285

Das muß nicht so sein.
Daß Kerberos das unterstützt heißt, daß Kerberos das unterstützt... Nicht erfordert...

tjo.
DAS ist wieder eine andere Sache.

Allerdings sollte die Sache erledigt sein, solbald ich das Paßwort auf der Zielmaschine ändere. Und nicht erst nach einem Neustart der "Quelle" der Anfrage.
Denn indem ich das Paßwort ändere sage ich ja knallhart, daß ich eine erneute Anmeldung aller Berechtigten erzwingen möchte.

Ja, das Problem kenne ich.

Ich habe schon einen Bugreport an Apple geschickt.

Es wäre sinnvoll, wenn ihr das auch tuen würdet, je mehr Benutzer sich melden, desto eher sollte der Fehler behoben werden.

Mein OS: 10.5.5

ach, ich sehe gerade, dieses Phänomen wird durch Kerberos verursacht.

Nächste Frage:

Wie kann man Kerberos deaktivieren?

Gar nicht. Aber Du kannst dem Link von Pünktchen folgen und Dein Kerberos-Ticket "zerstören". Wenn Du das Konzept von Kerberos verstehen würdest, wärst Du jetzt nicht so aufgebracht.

... und es ist definitiv kein Bug, sondern ein gewolltes und dokumentiertes Feature, das bereits seit 10.4 im System vorhanden ist.

Ja, dumm nur, daß das Trennen in 10.4 besser funktioniert hat als in 10.5

Blöd...

wenn ich aber dem Computer den Befehl erteile, er solle die Verbindung kappen, dann erwarte ich, daß ich das er das tut!

Ich mag es einfach nicht, wenn Dinge passieren, die ich nicht will. Wenn ich ihm das sage, dann will ich das es so ausgeführt wird und will nicht, daß der Computer sich verselbständigt!

Und das man das nicht deaktivieren kann, ist auch dumm. Unter jedem anderen System kann man Kerberos deaktivieren, aktivieren wie man will. Nur unter OS X nicht?

Soso, wie deaktiviert man denn unter Windows Kerberos?

Selten so einen Schmarrn gelesen wie in dem Thread

Das geht meines Wissens nach in der "Lokalen Sicherheitsrichtlinie" unter Systemsteuerung > Verwaltung.

Genauere Informationen liefere ich nach; dazu müßte ich erst mal mein Windows XP Buch wieder hervorzaubern, da ich mittlerweile nicht mehr so viel über Windows weiß, da ich damit kaum noch arbeite. Ich starte das ja noch nur zum Zocken. Also bis dann...

Apropos:

Die Dame an der Apple Hotline fand das Verhalten von Mac OS X wie im Eingangsbeitrag auch als merkwürdig.

Mal sehen, was die sagen wenn ich die damit mal konfrontiere...

Die Dame an der Hotline hat das Wort KERBEROS noch nie gehört. Kerberos ist die normale Authentifizierung seit Mac OS X 10.5, auch davor schon i.V.m 10.4 Server. Vom Server bekommt der Client ein Ticket, wenn er einmal das korrekte Passwort eingibt. Das Ticket ist dann eine bestimmte Zeit gültig. Bei jeder neuen Verbindung "zeigt" Dein Client das Ticket dem Server - wenn es OK ist, darf er rein.

Angenommen, es würde mit der herkömlichen Client Authentifizierung laufen. Wie würdest Du dann einen Client XYZ aussperren? Richtig, Du nimmst XYZ von der Liste der authorisierten Benuter.

Wo ist denn da das Problem? Gleich hohe Sicherheit wie voher, nur deutlich unkomplizierter.

Ich versteh nur Bahnhof.

Das schlimme ist, daß ein Nichtadmin einmal vollen Zugriff auf das Heimverzeichnis eines Admins zugreifen konnte.

Kann nur vorkommen, wenn 1) du dich als Admin eingeloggt hattest - dann gilt der Login ja noch eine bestimmte Zeit oder 2) die Zugriffsrechte völlig durcheinander sind oder 3) das Homeverzeichnis ausdrücklich freigegeben wurde.

Und wenn Du nur Bahnhof verstehst, hier ein Link:
http://developer.apple.com/opensource/kerberosintro.html

Sorry:

Übrigens kann man in der oben erwähnten Kerberos.app Das verhalten des Kerberos Systems und die Gültigkeitsdauer der Tickets einstellen. (siehe Bild)
Damit sollte jeder zufrieden sein. Also erst Informieren statt gleich zu motzen und Vermutungen anzustellen!

Kerberos stört einfach. Ich kann mich nicht richtig als weiteren Benutzer anmelden ohne daß ich wieder als Benutzer A angemeldet werde. Das nervt.

Nein, das ist Blödsinn. Du hast die Sache immer noch nicht verstanden.

Der Benutzer A wird nur dann (und auch nur bei Bedarf) angemeldet, wenn er sein Kennwort in einer laufenden Sitzung des Benutzers B eingegeben hatte, um eine "anmeldepflichtige" Funktion auszulösen. Und dies bestätigt ja wohl, dass Benutzer A dem Benutzer B voll vertraut, denn B könnte ja während der Anmeldezeit von A beliebige Dinge im Hintergrund laufen lassen. B schaltet für A explizit den Zugriff frei.

Dass A irgendwann die anmeldepflichtige Funktion nicht mehr nutzt (z.B. indem er eine Netzverbindung trennt), spielt keine Rolle, denn das System "weiß", dass während der Anmeldung von B ein gültiges Kennwort für A eingegeben wurde, der Zugriff auf die Ressourcen von A für B also ausdrücklich erlaubt wurde.