Hallo,

im Moment habe ich ein Netzwerk mit 5 Clients an einem Macmini mit 'nicht-Server' OS X und aktiviertem Filesharing als Server. Die 5 Clients melden sich alle mit dem gleichen 'user' am Mini an, um das Filesharing zu nutzen. Das funktionierte jahrelang problemlos.

Angenommen ich würde auf dem Mini OS X Server einrichten, sehe ich für mich zwei Optionen (die anderen Möglichkeiten erwähne ich hier nicht):

A) Ich richte einen lokalen User auf dem Mini ein und alle loggen sich wie früher als dieser lokale User ein.
B) Ich richte einen Netzwerk Account ein, den alle Clients verwenden.

A) wird vermutlich genauso gut funktionieren wie bisher.
Meine Frage ist: funktioniert B ebenfalls?

Danke für Hinweise
Fadenschein

OS X 10.10.5 Yosemite Server

P.S.
Wer sich durch meine OS X Server Fragen gestört fühlt, möge sie bitte ignorieren.

Natürlich funktionert B. Es ist auch die bessere Lösung, da damit nicht jedes Nutzerkonto Rechte auf dem Server selbst hat (sondern nur Zugriff auf Freigaben) und schon gar keine Administratorenrechte. Sollte sich doch einmal Schadsoftware auf einem Client breitmachen, hat die dann wenigstens weit weniger Chancen, auch den Server zu schädigen.

@dreyfus: Die Frage ging doch nach netzwerkweiten Accounts, nicht nach Sharing- oder Administratoren-Accounts.

Zur Frage: Natürlich funktioniert auch B und hätte den Vorteil, dass die Dateieigentümer auf den lokalen Platten der Clients mit den Eigentümern auf dem Server synchron sind. Gut sind allerdings beide Lösungen nicht, denn die Accounts werden zweckentfremdet. Das ist Computernutzung wie in den 1950er Jahren.

Normalerweise sollte jede einzelne Person einen eigenen netzwerkweiten Account haben. Dann sind die Nutzer auch nicht mehr an bestimmte Computer gebunden. Je nach dem, welche Daten zu welchem Zweck gespeichert werden, kann das auch aus Gründen der Sorgfaltspflicht gesetzlich vorgeschrieben sein.

Warum gestört? Das passt besser in dieses Forum als Fragen zu Telefonen und Uhren, die hier eigentlich nichts zu suchen haben.

Meine Kaffeemaschine entkalkt noch... ich wohl auch. Kaufe trotzdem ein B

A ist vom technischen gesehen eine Lösung, die man nicht macht (ein User im ganzen Netz kann alles zugreifen und löschen). Trotzdem hat es jahrelang funktioniert und es war nie ein Administrator notwendig der groß Rechte verteilt oder ändert und Gruppenzugehörigkeiten verwaltet. >Weniger Sicherheit - Mehr Comfort.

B teilt teilt jedem User ein Netzwerk User Konto zu. Ermöglicht weiter Nutzung von Seeverdiensten die Unterscheidung zwischen meinen persönlichen Daten auf der Serverseite und unseren (Gruppe) Daten auf der Serverseite. Das erfordert etwas Administrativen Aufwand die Gruppe anzulegen und die User. und auch die User über den Unterschied zu unterrichten. > Größere Sicherheit - weniger Comfort.

Bei der Umstellung auf B kommt es vor, dass User neue Ordner anlegen, die für die Gruppe gedacht sind, aber sie nur persönlich Zugriff haben.

@stargator: Da geht etwas durcheinander. Was Du als "A" beschreibst, ist die Lösung "B". Was Du als "B" beschreibst, ist eine dritte Lösung, die ich vorgeschlagen habe.

@dreyfus
Danke, das Argument 'nur Zugriff auf Freigaben und keine Rechte auf dem Server selbst' leuchtet mir sehr ein. In die Richtung hatte ich auch gefragt. Wobei ich bei A - wie Marcel Bresink schreibt - natürlich auch einen reinen Sharing User am Server einrichten könnte. Daran hatte ich gar nicht gedacht.

@Marcel BresinkStimmt - ich bin nur vorsichtig, weil es das ein oder andere Mal schon als unschicklich angesehen wurde, wenn sich ein Server Laie an Server heranwagt.

Ist das so? Bei B wollte ich auch nur einen einzigen Netzwerk Account anlegen, den alle Clients benutzen. Werden dann als Dateieigentümer die lokalen 'user' des jeweiligen Client Rechners für die Daten auf dem Server verwendet?
Ja, das stimmt. Und obwohl mir das Spaß machen würde, habe ich davon Abstand genommen. Denn wenn ich es richtig weiß, muss ich das 'home' Verzeichnis für jeden Client dann auf dem Server ablegen. Das erhöht den Datenverkehr und ich müsste größere Vorkehrungen treffen, damit der Schaden bei einem Ausfall des Servers nicht erheblich ist. Es handelt sich in meinem Fall nur um 5 Clients, die so gut wie nie Rechner tauschen. Außerdem haben alle Clients die gleichen Zugriffsrechte bei den Dokumenten, so dass dort auch keine Unterscheidung notwendig ist.

@stargatorEigentlich wollte ich allen Usern ein gemeinsames Netzwerk User Konto zuweisen. Da sie alle die exakt gleichen Zugriffsrechte auf Dokumente haben, würde ich das aus Anwendersicht unproblematisch sehen.
Meine Frage zielte darauf, ob der Server 'empfindlich' ist oder durcheinander kommt, wenn 5 Clients über den gleichen Netzwerk Account auf ihn zugreifen.

Alternativ könnte ich natürlich auch 5 Netzwerk Accounts für meine 5 Clients erstellen. Aber hier würde ich nur einen Vorteil sehen, falls 1 Netzwerk Account für 5 Clients aus irgendeinem Grund Probleme machen würde.

Danke allen schon mal für die bisherigen und mögliche weitere Einwürfe...

@Marcel Bresink Stimmt.

A ist vom technischen gesehen eine Lösung, die man nicht macht (ein User im ganzen Netz kann alles zugreifen und löschen). Trotzdem hat es jahrelang funktioniert und es war nie ein Administrator notwendig der groß Rechte verteilt oder ändert und Gruppenzugehörigkeiten verwaltet. >Weniger Sicherheit - Mehr Comfort.

B trennt zwar den Server Administrator vom Netzwerk user. Ist also einen Schritt weiter. Wobei Netzwerk User bei manchen Hobbyadministratoren der lokale user mit dem Namen "Netzwerk" ist. Ist in diesem Fall wenn es nur um Filesharing geht aber egal.
Sollte wie bisher funktionieren.

C teilt teilt jedem User ein Netzwerk User Konto zu. Ermöglicht weiter Nutzung von Seeverdiensten die Unterscheidung zwischen meinen persönlichen Daten auf der Serverseite und unseren (Gruppe) Daten auf der Serverseite. Das erfordert etwas Administrativen Aufwand die Gruppe anzulegen und die User. und auch die User über den Unterschied zu unterrichten. > Größere Sicherheit - weniger Comfort.

Bei der Umstellung auf C kommt es vor, dass User neue Ordner anlegen, die für die Gruppe gedacht sind, aber sie nur persönlich Zugriff haben. Das ist für manche Workgroups oder Familien oft schon zu kompliziert, auch wenn es die technisch beste Lösung ist.

Warum sollte man dann noch lokale Accounts der Client-Rechner verwenden? Dann ergibt die ganze Frage keinen Sinn, denn dann ist ja zwischen A und B überhaupt kein Unterschied mehr. In Fall A kennt 1 Rechner diesen Account, in Fall B 6 Rechner, was aber niemanden interessiert, wenn sowieso nur 1 Rechner diesen Account verwendet.

Nein, das stimmt nicht. Man kann zwischen 3 möglichen Konfigurationen wählen:
1) Die Privatordner werden auf dem Client angelegt.
2) Die Privatordner werden auf dem Server angelegt.
3) Die Privatordner werden auf Client und Server angelegt und automatisch synchronisiert, so dass sich ein mobiler Client-Rechner jederzeit aus dem Netz entfernen und wiederkehren kann.

Die Accounts haben eigentlich nur Auswirkungen auf Rechte. Es gibt keinen Grund, weshalb da etwas durcheinander gehen könnte.

Machen kann man vieles, funktionieren tut manches,aber empfehlenswert ist es eben auch nicht nur einen Account zu erstellen der von mehreren (gleichzeitig) genutzt wird. Macht man nicht, ist nicht "Stand der Technik" wie Marcel es schon schrieb. Und ja, bei der Lösung C von stargator kann es passieren was er im letzten Absatz schreibt. Das passiert die mit "einAccount für Alle" nicht.
Wenn du also nur Filesharing machen willst dann lass die Finger vom Server und richte im normalen System einen Netzwerkaccount für alle ein. Es gilt dann zwar Satz 1 aber du brauchst dich nicht drum zu kümmern. Ob es dabei zu Problemen kommt wird dir keiner genau sagen können (wollen) da es eben "unsupported" ist.

Solltest du jedoch andere Dienste von "Server" nutzen wollen (zB. Wiki) dann bedenke das du eigentlich doch für jeden User einen eigenen Account brauchst damit man sieht wer etwas geschrieben hat. Da kann man dann zwar auch wieder nur einen Netzwerkaccount fürs Filesharing nutzen und bei den anderen Diensten jeweils den jeweils eigenen. Macht man aber nicht

@Marcel Bresink
Danke für die Erläuterungen
Ich glaube, das Missverständnis beruht darauf, dass ich mich unklar ausdrücke und tatsächlich die Unterschiede nicht genau differenzieren kann. Was ich meinte ist:
A: Ich lege einen lokalen User auf dem Server an, nennen wir ihn 'markus'. Von den Client Rechnern aus verwendet man bspw. afp://markus@192.178.0.4, um auf Dateien zugreifen zu können.
B: Ich lege einen Netzwerkaccount 'markus' an und binde alle Clients über diesen Account an den Server.
Sehr schön. Dann wähle ich wohl 1). Dann müsste ich den Client Rechner ja auch bei einem Totalausfall des Servers starten können. Das geht zwar bei 3 auch, aber hier fürchte ich den Platzbedarf für die home Verzeichnisse der Clients und den zusätzlichen Datenverkehr.
Gut zu hören, aber wenn ich die Variante 1 von weiter oben wähle, habe ich ja eh' 5 Netzwerkaccounts und meine ursprüngliche Frage ist gegenstandslos geworden.

Nein, die Fragestellung war völlig klar und ich habe sie auch so verstanden. Wie gesagt ist aber zwischen A und B überhaupt kein Unterschied, wenn sich die Benutzer auf den Clients mit lokalen Accounts anmelden.

Nein, das wiederum geht nicht, denn ohne den Server kann ja die Identität des netzweiten Accounts gar nicht überprüft werden. Platt gesagt: Der User ist weg, wenn der Server nicht läuft. Ein Anmelden ist dann nicht möglich.

Oh. Ich dachte, ich könnte bei einem Ausfall des Servers den lokalen Rechner dann als einzelnen lokalen Rechner ohne jedes Netzwerk weiterverwenden, weil die für die Anmeldung notwendigen Daten im lokalen home Verzeichnis auf der lokalen Festplatte liegen.
Ginge das denn bei Variante 3)? Oder führen Netzwerkaccounts in jedem Fall dazu, dass ich mich auf keinem lokalen Rechner mehr lokal anmelden kann, wenn der Server ausfällt?

Ja, das ginge. Diese Variante, die bei Apple "Mobiler Account" oder "Portable Home Directory" heißt, ist aber für Ungeübte nicht unbedingt zu empfehlen. Apple unterstützt das seit Mac OS X 10.7 nur noch halbherzig und die ständigen Synchronisationsvorgänge können schnell für Ärger sorgen.

Wenn es sicher und auch ausfallsicher gehen soll, und nicht mehr als die gemeinsame Nutzung von Daten geplant ist, dann wäre die Beibehaltung von Lösung A am einfachsten.

Alles klar, dann bleibe ich lieber bei A.
Danke für den Hinweis.

Und schade, dass Apple das Portable Home Direktory nicht beherzt unterstützt.
Von meinen vielen Windows Kollegen kenne ich es genauso: sie haben ein Firmenlaptop und können es sowohl in der Firma am Netzwerk als auch unterwegs ohne Serververbindung gleichermaßen benutzen.

Wenn ich einen OS X Server in meinem Netzwerk habe, und die Clients nicht per Open Directory einbinde, habe ich doch auch keinen mobilen Account, oder? Das wäre zumindest neu.
Daher: Beliebige User auf dem Server anlegen, eine Gruppe auf dem Server anlegen, alle User in die Gruppe stecken und Ordnerberechtigungen immer nur für die Gruppe erteilen. Die User werden dann nur für Filesharing benutzt.
Die Clients arbeiten weiterhin autark, auch bei einem Serverausfall, wobei dann logischerweise der Zugriff auf die Netzwerkordner nicht mehr möglich ist.
Das ist doch die einfachste Methode.
Ich muss gestehen, dass ich 10.7 als letztes "Server"system gesehen habe und nicht weiß, wie es aktuell aussieht.

@caMpi
Das hört sich für mich so an, als wäre es eine Abwandlung meiner Variante A?
Anstatt einen einzigen lokalen Account auf dem Server anzulegen, den alle Clients verwenden, um sich am Server anzumelden, lege ich für jeden Client einen eigenen lokalen Account auf dem Server an. Dann schmeiße ich alle Accounts in eine Gruppe, um die Rechte komfortabel für alle vergeben zu können. Richtig verstanden?

@Marcel Bresink
Hab' gerade einen Test gemacht und einen Netzwerk Account auf meinem Server angelegt.
Mein Probe Client Rechner hat leider nur 10.7. Wenn ich mich da über Anmeldeoptionen an den Netzwerkaccount 'binden' möchte, bietet er mir nur eine anonyme Möglichkeit an.
Ist es korrekt, dass ich unter 10.7. auf dem Client die Systemeinstellungen/ Freigaben/ Gerätenamen/ Bearbeiten verwende, um mich mit dem Netzwerkaccount und Passwort anmelden zu können?

Im Prinzip ist deine Aussage richtig, nur stört mich bei dir "lokaler Account auf dem Server".
Wie gesagt weiß ich nicht wie der OS X Server momentan aussieht. Es kann also sein, dass das so stimmt. Früher gab es jedenfalls einen Unterschied zwischen lokalen und Netzwerkusern.

Wenn du auf deinem Mac mit einem Netzwerkuser des Servers arbeiten willst, steht hier (https://support.apple.com/kb/PH18884?viewlocale=de_DE&locale=de_DE) wie es gemacht wird.
Für deinen Fall brauchst du das aber gar nicht.

@caMpi
Danke.
Anders als vorgehabt, habe ich nun doch mal spaßesweise einen Netzwerk-User Account auf dem Server eingerichtet. Dabei habe ich in der Server App für diesen Benutzer die Option 'Ohne Benutzerordner - nur Dienste' angewählt.

Dann habe ich versucht, mich von meinem Client Rechner aus mit meinem Netzwerk zu verbinden.
Wie in Deiner Anleitung hab' ich dazu in den Systemeinstellungen unter Benutzer & Gruppen/ Anmeldeoptionen etc. eine Verbindung zu meinem Netzwerkaccount-Server hergestellt.

Das Seltsame ist: auf die Weise kann ich nur eine anonyme Verbindung herstellen. Ich kann nirgends den Namen und das Kennwort des auf dem Server angelegten Netzwerkaccounts eingeben.

Was mache ich falsch?

Fadenschein

Das ist wieder für etwas anderes gedacht, nämlich wenn für den Bindevorgang an sich eine weitere Authentifizierung erforderlich sein sollte. Das kann zum Beispiel für den Zugriff auf LDAP-Server von fremden Anbietern nötig sein, oder um Fälschungen von Clients und Servern im Netz abzuwehren. In einer normalen Open Directory-Installation brauchst Du das nicht und kannst das Dialogfenster mit der Bindungs-Anmeldung übergehen. Der Computer bindet sich anonym an den Verzeichnisdienst. Das hat nicht direkt etwas mit der Anmeldung von Benutzern zu tun.

Nachdem der Client-Computer gebunden ist, kann dieser Computer nun zusätzlich zu seinen lokalen Benutzern auch Netzwerk-Benutzer identifizieren und deren Authentifizierung an Server abgeben.

Verstehe. Das heisst, ich identifiziere mich erst, wenn ich mich für bestimmte Dienste anmelden will.
Beispielsweise wenn ich das Filesharing des Servers benutzen möchte.

Wobei dann wohl ein völliges Missverständnis bei mir vorliegt:
Wenn ich mich von meinem Client aus anonym an den Netzwerkserver binde und mich nur für bestimmte Dienste fallweise autorisieren muss, dann ist es ja doch nicht so, dass mein Client Rechner bei einem Ausfall des Servers ebenfalls unbenutzbar wird (so hatte ich Dich verstanden) Im Gegenteil - dann gibt es ja gar keine Verbindung zwischen dem lokalen User auf dem Client und dem Netzwerkaccount, den er auf dem Server verwendet. Beide existieren unabhängig voneinander und werden gleichzeitig benutzt. Der lokale Account zur Anmeldung auf meinem Client Rechner und der Server Account für den Genuß irgendwelcher bereitgestellter Dienste.

Ja, aber mit einem Netzwerk-Account kannst Du Dich auch für Dienste auf dem Client anmelden oder Dich auf dem Client einloggen, also eine Bildschirmsitzung und Programme als dieser Benutzer starten.

Die gibt es nie. Das hatte ich ja oben schon gesagt: Wenn Du Dich sowieso mit einem lokalen Account auf dem Client anmeldest, wird ja der Netzwerk-Account überhaupt nicht genutzt.

Ein lokaler Account ist nur lokal auf einem Rechner bekannt. Wenn zwei Accounts auf verschiedenen Rechnern "zufällig" gleich heißen, bleiben sie trotzdem verschieden.

Ein Netzwerk-Account ist auf allen Rechnern im Netzwerk bekannt. Wenn zwei Accounts gleich heißen, dann sind sie auch identisch.

Hmm. Dann hab' ich irgendwas falsch gemacht.

Denn es gelingt mir nicht, mich über meinen Netzwerkaccount bei meinem Client einzuloggen und eine Bildschirmsitzung zu starten und Programme als dieser Benutzer zu starten.

Folgendes habe ich gemacht:
Ich hab' einen 'Lokalen Netzwerkbenutzer' auf dem Server angelegt mit dem Namen 'seppl'.
Als Option habe ich 'Benutzerordner - Ohne - Nur Dienste' gewählt, da ich keinen Benutzerordner auf dem Server ablegen wollte. Ich dachte, damit erzeuge ich einen User nach Deiner Option 1).

Auf meinem Client ist es mir gelungen, ein Binding herzustellen. Allerdings nur anonym. Es ist mir nicht gelungen 'authenticated binding' zu aktivieren. Vielleicht brauche ich das auch gar nicht.

Es gelingt mir, vom Client das Filesharing zu benutzen, das ich vom Server aus bereit stelle. Dabei verlangt der Client Rechner auch login und passwort von 'seppl', was tadellos funktioniert.

Was aber nicht gelingt, ist eben mich über meinen Netzwerkaccount bei meinem Client einzuloggen und eine Bildschirmsitzung zu starten und Programme als dieser Benutzer zu starten.

Das kann in diesem Fall nicht gehen, da Du das für diesen Benutzer ausdrücklich gesperrt hast, durch Auswahl von "Benutzerordner - Ohne - Nur Dienste". Richtig wäre gewesen "Benutzerordner: Nur lokal".

@Marcel Bresink
Ahh, danke - wenn ich das umstelle kann ich mich einloggen. Der Home Folder liegt dann auf meinem Server.
Aber wie erzeuge ich einen Network User mit einem Home Folder auf dem Client Rechner?
Also die Variante 1) der Varientenliste...

Das kann nicht sein, es sei denn, Du meldest Dich am Server an.

Du hast recht. Aber das seltsame ist: es wird sowohl ein Home Folder auf dem Server, als auch auf dem Client angelegt. Er benutzt aber wohl den Home Folder auf dem Client.

Wobei - was mir nicht ganz klar ist:
In der Server.app kann ich für diesen Lokalen Netzwerkaccount die 'Festplattenverwendung beschränken auf xxx MB'

Beschränke ich damit die Größe des Home Folders auf dem Client oder auf dem Server.
Eigentlich doch auf dem Server, dachte ich. Aber wenn der 'eigentliche' Home Folder auf dem Client liegt, hätte diese Option ja gar keinen Sinn.