• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

Admin konto auf client über Server erstellen

fastjack

Golden Delicious
Registriert
10.04.17
Beiträge
8
Moin moin,

ich möchte gern über den Server lokale Konten auf den Clients erstellen. Gibt es da eine Möglichkeit dies über den Server zu regeln.
Kurze Erklärung, ich benötige für einen Dienst ein Lokales Administrator Konto, um Turnschuh Administration zu vermeiden würde ich gern ein Benutzerkonto über den Server an die Clients verteilen.

Gruß

Sven
 

Marcel Bresink

Hadelner Sommerprinz
Registriert
28.05.04
Beiträge
8.560
über den Server lokale Konten auf den Clients erstellen. Gibt es da eine Möglichkeit dies über den Server zu regeln.

Nicht wirklich, denn das würde den Sinn des Servers ad absurdum führen. Der Server ist normalerweise dazu gedacht, genau das Gegenteil zu erreichen, nämlich netzweite Konten zu verwenden und die Zahl der lokalen Konten so gering wie nur möglich zu halten.

ich benötige für einen Dienst ein Lokales Administrator Konto

Ist das wirklich nötig? Normalerweise versucht man auch das zu vermeiden, da das ein Sicherheitsrisiko ist. Ein Dienst sollte so wenig Rechte wie nur möglich haben, idealerweise laufen Dienste mit dem Systembenutzerkonto "nobody".
 

fastjack

Golden Delicious
Registriert
10.04.17
Beiträge
8
Hm mittlerweile habe ich einen Weg gefunden, aber gern erkläre ich den Sinn dahinter und den Lösungsweg.
Es gibt Möglichkeiten um Benutzer über einen Server an die Clients zu verteilen das Zauberwort heist in diesem Fall Developstudio und ist ein tool von ehemaligen OSX Entwicklern. Und die aussage das das einen Server absurdum führt kann ich so leider nicht nachvollziehen. Um Dienste auf einem Client laufen zu lassen benötigt man ein Dienstkonto über welchen dieser dann auf dem Client ausgeführt wird. Ob dieser Benutzer nun unbedingt Lokale Administratoren Berechtigung haben muss sei dahingestellt. Da ich aber über diesen Dienst Programme und ähnliches installieren will werde ich mit dem benutzer nobody nicht wirklich weiter kommen aber auch da gibt einem Developstudio möglichkeiten an die Hand.

Trotzdem danke für die Mühe :)
 

Marcel Bresink

Hadelner Sommerprinz
Registriert
28.05.04
Beiträge
8.560
Es gibt Möglichkeiten um Benutzer über einen Server an die Clients zu verteilen

So ist es, und das ist genau das Gegenteil davon, lokale Konten anlegen zu müssen.

Um Dienste auf einem Client laufen zu lassen benötigt man ein Dienstkonto über welchen dieser dann auf dem Client ausgeführt wird.

Dann erklär mal, warum Du auf jedem Client ein neues (und damit anderes) Konto anlegen musst. Wir sind alle ganz gespannt.
 

fastjack

Golden Delicious
Registriert
10.04.17
Beiträge
8
weil sofern man in einer Firmenumgebung arbeitet und mit Clients jenseits von 3500 arbeitet man Dienstkonten anlegt um für die verschiedenen Systeme verschiedene Konten benutzt, das hat was mit Sicherheit und Verwaltung zutun :)-
 

Marcel Bresink

Hadelner Sommerprinz
Registriert
28.05.04
Beiträge
8.560
Genau deshalb ist das, was Du beschreibst, großer Blödsinn.

Wenn Du das so umsetzt, legst Du 3.500 verschiedene Benutzerkonten an, was eine verwaltungstechnische Katastrophe wäre. Normal wäre es, 1 Benutzerkonto auf dem Server anzulegen, das dann von allen Clients genutzt wird. Das funktioniert dann auch mit 50.000 Clients einwandfrei.
 

fastjack

Golden Delicious
Registriert
10.04.17
Beiträge
8
Ich habe das Dumpfe Gefühl das wir aneinander vorbeireden. Ich will nicht 3500 verschiedene Benutzerkonten anlegen sondern für diesen einen Server nur eins. Aber es ging darum das man mit verschiedenen Server auch ein paar Benutzerkonten hat zumindest in Konzernweiten Umgebungen.