5
Empfehlungen für den Einsatz von Zweigstellen-Admins
Hallo,
wir haben in unserer Firma mehrere Standorte. In allen Standorten steht mind. 1 Server. Die Administration ist zentralisiert. Jetzt habe ich mir überlegt, bestimmten MitarbeiterInnen in den Standorten das Recht zu geben, einige Aktionen direkt an dem lokalen Server durchzuführen, um die zentrale IT zu entlasten. In der Fachliteratur habe ich dazu mal den Begriff "Zweigstellen-Administrator (ZS-Admin)" gefunden.
Da keiner von diesen MitarbeiterInnen wirklich Ahnung von der Serverbetreuung hat und auch wegen möglichen Sicherheitsrisiken möchte ich den Zugriff natürlich weitestgehend einschränken.
Ich habe mir dafür ein Schema überlegt, dass ich hier gern mal zur Diskussion stellen möchte:
- die entsprechenden User-Accounts kommen in eine domänenlokale Gruppe ZAdmin (je Site eine eigene Gruppe)
- in einer GPO wird der Gruppe die lokale Anmeldung gewährt, der Loopbackverarbeitungsmodus ist aktiviert
- die GPO gilt nur für die entsprechenden Server und die Gruppe ZAdmin (Sicherheitsfilterung)
- in den Benutzereinstellungen der GPO habe ich dann verschiedene Einstellungen konfiguriert; es bleiben nur die Aktionen erlaubt, welche die ZS-Admins auch ausführen sollen
Jetzt habe ich aber ein Problem, bei dem ich nicht weiter komme: ich kann keine Zugriffsberechtigungen für den TaskPlaner in der GPO setzen (die User sollen Tasks starten und beenden können). Normalerweise haben ja nur Sicherungsoperatoren und Administratoren Zugriff auf den TaskPlaner.
Ein weiteres Problem: auf einigen Servern laufen Anwendungen, für die ein Administrator angemeldet sein muss (srvany & co. funktionieren nicht). Diese Server sind natürlich gesperrt. Und die Sperrung kann nur der Administrator oder der angemeldete Benutzer (=Administrator) aufheben. Wenn es jetzt Probleme mit dem Server gibt, dann soll der ZS-Admin sich lokal anmelden können. Das geht aber nicht, solange dieser nicht Mitglied der lokalen Administratorgruppe des Servers ist...
Ich möchte den ZS-Admins keine Administratorenrechte auf den Servern geben, weil sie so auch im Filesystem in Verzeichnisse reinkommen, für die sie sonst gesperrt wären. Zudem hängen da noch weitere Rechte dran, die nur Fachleute haben sollten.
Wie würdet ihr das angehen? Ich freu mich auf eure Antworten.
Bis denne sagt der creyzee
wir haben in unserer Firma mehrere Standorte. In allen Standorten steht mind. 1 Server. Die Administration ist zentralisiert. Jetzt habe ich mir überlegt, bestimmten MitarbeiterInnen in den Standorten das Recht zu geben, einige Aktionen direkt an dem lokalen Server durchzuführen, um die zentrale IT zu entlasten. In der Fachliteratur habe ich dazu mal den Begriff "Zweigstellen-Administrator (ZS-Admin)" gefunden.
Da keiner von diesen MitarbeiterInnen wirklich Ahnung von der Serverbetreuung hat und auch wegen möglichen Sicherheitsrisiken möchte ich den Zugriff natürlich weitestgehend einschränken.
Ich habe mir dafür ein Schema überlegt, dass ich hier gern mal zur Diskussion stellen möchte:
- die entsprechenden User-Accounts kommen in eine domänenlokale Gruppe ZAdmin (je Site eine eigene Gruppe)
- in einer GPO wird der Gruppe die lokale Anmeldung gewährt, der Loopbackverarbeitungsmodus ist aktiviert
- die GPO gilt nur für die entsprechenden Server und die Gruppe ZAdmin (Sicherheitsfilterung)
- in den Benutzereinstellungen der GPO habe ich dann verschiedene Einstellungen konfiguriert; es bleiben nur die Aktionen erlaubt, welche die ZS-Admins auch ausführen sollen
Jetzt habe ich aber ein Problem, bei dem ich nicht weiter komme: ich kann keine Zugriffsberechtigungen für den TaskPlaner in der GPO setzen (die User sollen Tasks starten und beenden können). Normalerweise haben ja nur Sicherungsoperatoren und Administratoren Zugriff auf den TaskPlaner.
Ein weiteres Problem: auf einigen Servern laufen Anwendungen, für die ein Administrator angemeldet sein muss (srvany & co. funktionieren nicht). Diese Server sind natürlich gesperrt. Und die Sperrung kann nur der Administrator oder der angemeldete Benutzer (=Administrator) aufheben. Wenn es jetzt Probleme mit dem Server gibt, dann soll der ZS-Admin sich lokal anmelden können. Das geht aber nicht, solange dieser nicht Mitglied der lokalen Administratorgruppe des Servers ist...
Ich möchte den ZS-Admins keine Administratorenrechte auf den Servern geben, weil sie so auch im Filesystem in Verzeichnisse reinkommen, für die sie sonst gesperrt wären. Zudem hängen da noch weitere Rechte dran, die nur Fachleute haben sollten.
Wie würdet ihr das angehen? Ich freu mich auf eure Antworten.
Bis denne sagt der creyzee
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 146330
Url: https://administrator.de/forum/empfehlungen-fuer-den-einsatz-von-zweigstellen-admins-146330.html
Ausgedruckt am: 22.12.2024 um 11:12 Uhr
5 Kommentare
Neuester Kommentar
Hallo creyzee.
Das scheint ein Teufelskreis zu sein, aus welchem du selbst nur den Ausweg finden kannst, bspw. indem die MitarbeiterInnen ausreichend geschult werden oder weitere fähigere Mitarbeiter eingestellt werden.
Dann sollten auch Admins auf den Servern in den Außenstellen machbar sein.
Da keiner von diesen MitarbeiterInnen wirklich Ahnung von der Serverbetreuung hat und auch wegen möglichen Sicherheitsrisiken möchte ich den Zugriff natürlich weitestgehend einschränken.
Ein weiteres Problem: auf einigen Servern laufen Anwendungen, für die ein Administrator angemeldet sein muss (srvany & co. funktionieren nicht). Diese Server sind natürlich gesperrt. Und die Sperrung kann nur der Administrator oder der angemeldete Benutzer (=Administrator) aufheben. Wenn es
jetzt Probleme mit dem Server gibt, dann soll der ZS-Admin sich lokal anmelden können. Das geht aber nicht, solange dieser nicht Mitglied der lokalen Administratorgruppe des Servers ist...
jetzt Probleme mit dem Server gibt, dann soll der ZS-Admin sich lokal anmelden können. Das geht aber nicht, solange dieser nicht Mitglied der lokalen Administratorgruppe des Servers ist...
Ich möchte den ZS-Admins keine Administratorenrechte auf den Servern geben, weil sie so auch im Filesystem in Verzeichnisse reinkommen, für die sie sonst gesperrt wären. Zudem hängen da noch weitere Rechte dran, die nur Fachleute haben sollten.
Das scheint ein Teufelskreis zu sein, aus welchem du selbst nur den Ausweg finden kannst, bspw. indem die MitarbeiterInnen ausreichend geschult werden oder weitere fähigere Mitarbeiter eingestellt werden.
Dann sollten auch Admins auf den Servern in den Außenstellen machbar sein.
Hallo goscho,
da hast du schon Recht, aber meine Lösung soll ja keine Vollwartung der Site-Server werden. Mir geht es darum, dass kleine Routineaufgaben von Nicht-Fachleuten ausgeführt werden können. Ich kann diesen MitarbeiterInnen durchaus diese Tätigkeiten beibringen, aber:
- ich möchte den Tätigkeitsbereich exakt abgrenzen, um mögliche Fehler auszuschließen
- den Zugriff auf vertrauliche Daten vermeiden, den ein Serveradministrator ja durchaus hat
Und gerade dem zweiten Punkt ist mit der besten Schulung der Welt nicht beizukommen... Klar, man muss seinen Admins vertrauen. Aber bring mal der GL bei, dass jetzt einige Leute Zugriff auf sensible Daten haben könnten und wir im Gegenzug die zentrale IT entlasten...
Mein Ansatz sieht vor, dass für die üblichen Aufgaben und Serverproblemchen fertige Scripte auf dem Server liegen, welche der ZS-Admin ausführen (aber nicht ändern) kann. Einige dieser Scripte sind auch in Tasks fertig eingebunden, die bei Bedarf manuell ausgeführt werden sollen. Aber speziell an die Tasks komme ich ja als ZS-Admin ohne lokale Adminrechte nicht ran...
Hast du da vielleicht noch ne Idee?
der creyzee
da hast du schon Recht, aber meine Lösung soll ja keine Vollwartung der Site-Server werden. Mir geht es darum, dass kleine Routineaufgaben von Nicht-Fachleuten ausgeführt werden können. Ich kann diesen MitarbeiterInnen durchaus diese Tätigkeiten beibringen, aber:
- ich möchte den Tätigkeitsbereich exakt abgrenzen, um mögliche Fehler auszuschließen
- den Zugriff auf vertrauliche Daten vermeiden, den ein Serveradministrator ja durchaus hat
Und gerade dem zweiten Punkt ist mit der besten Schulung der Welt nicht beizukommen... Klar, man muss seinen Admins vertrauen. Aber bring mal der GL bei, dass jetzt einige Leute Zugriff auf sensible Daten haben könnten und wir im Gegenzug die zentrale IT entlasten...
Mein Ansatz sieht vor, dass für die üblichen Aufgaben und Serverproblemchen fertige Scripte auf dem Server liegen, welche der ZS-Admin ausführen (aber nicht ändern) kann. Einige dieser Scripte sind auch in Tasks fertig eingebunden, die bei Bedarf manuell ausgeführt werden sollen. Aber speziell an die Tasks komme ich ja als ZS-Admin ohne lokale Adminrechte nicht ran...
Hast du da vielleicht noch ne Idee?
der creyzee
Nein, hier habe ich keine weitere Idee.
Wenn das admins sein müssen, hast du nur die Möglichkeit, diese admins zu sensibilisieren und zu schulen, regelmäßige Dasi helfen auch.
Wenn das admins sein müssen, hast du nur die Möglichkeit, diese admins zu sensibilisieren und zu schulen, regelmäßige Dasi helfen auch.
Hallo,
also für mein Taskplanerproblem habe ich eine Lösung gefunden:
1) mit cacls den ZS-Admins Vollzugriff auf den Ordner C:\Windows\Tasks geben
2) mit der GPO AdministrativeVorlagen\Windows-Komponenten\Taskplaner
- das Erstellen von Tasks verhindern
- das Löschen von Tasks nicht zulassen
Das Ergebnis: der ZS-Admin kann Tasks starten und beenden (und diese werden dann ja im hinterlegten Kontext ausgeführt), aber Löschen oder Erstellen funktioniert nicht. Es bleibt nur die Änderung von bestehenden Aufgaben.
Leider reichen beim cacls keine Leserechte aus, um Tasks starten bzw beenden zu können. Aber so reicht mir das schon.
Nun bleibt nur noch das Problem mit der Computersperre. Diese kann ja nur von Administratoren oder dem angemeldeten User aufgehoben werden. Mir fällt momentan nur ein, das Ganze organisatorisch zu lösen:
1) auf Servern, die eine dauerhafte Anmeldung erfordern, müssen sich die Admins der zentralen IT mit RDP anmelden und die Sitzung offen lassen
2) dann kann sich ein ZS-Admin lokal direkt am Server anmelden.
Welche Einstellungen würdet ihr denn für mein Vorhaben konfigurieren, um den ZS-Admins nur die nötigsten Rechte zu geben? Mein aktueller Stand: die ZS-Admins
- haben lokale Benutzerrechte (das ist ja schon mal recht minimal)
- können den Server neustarten, aber nicht herunterfahren
- können von mir vorgesehene Dienste über Scripte neustarten/starten
- Tasks starten/beenden
- können im FileSystem nur die Verzeichnisse/Dateien sehen, für die sie im NTFS vorgesehen sind
- können DruckJobs verwalten
Die Systemsteuerung, Eingabeaufforderung, und einige andere Konfigurationsmenüs sind natürlich nicht freigegeben.
Hat noch wer eine Idee?
Viele Grüße vom creyzee
also für mein Taskplanerproblem habe ich eine Lösung gefunden:
1) mit cacls den ZS-Admins Vollzugriff auf den Ordner C:\Windows\Tasks geben
2) mit der GPO AdministrativeVorlagen\Windows-Komponenten\Taskplaner
- das Erstellen von Tasks verhindern
- das Löschen von Tasks nicht zulassen
Das Ergebnis: der ZS-Admin kann Tasks starten und beenden (und diese werden dann ja im hinterlegten Kontext ausgeführt), aber Löschen oder Erstellen funktioniert nicht. Es bleibt nur die Änderung von bestehenden Aufgaben.
Leider reichen beim cacls keine Leserechte aus, um Tasks starten bzw beenden zu können. Aber so reicht mir das schon.
Nun bleibt nur noch das Problem mit der Computersperre. Diese kann ja nur von Administratoren oder dem angemeldeten User aufgehoben werden. Mir fällt momentan nur ein, das Ganze organisatorisch zu lösen:
1) auf Servern, die eine dauerhafte Anmeldung erfordern, müssen sich die Admins der zentralen IT mit RDP anmelden und die Sitzung offen lassen
2) dann kann sich ein ZS-Admin lokal direkt am Server anmelden.
Welche Einstellungen würdet ihr denn für mein Vorhaben konfigurieren, um den ZS-Admins nur die nötigsten Rechte zu geben? Mein aktueller Stand: die ZS-Admins
- haben lokale Benutzerrechte (das ist ja schon mal recht minimal)
- können den Server neustarten, aber nicht herunterfahren
- können von mir vorgesehene Dienste über Scripte neustarten/starten
- Tasks starten/beenden
- können im FileSystem nur die Verzeichnisse/Dateien sehen, für die sie im NTFS vorgesehen sind
- können DruckJobs verwalten
Die Systemsteuerung, Eingabeaufforderung, und einige andere Konfigurationsmenüs sind natürlich nicht freigegeben.
Hat noch wer eine Idee?
Viele Grüße vom creyzee
Moin,
genauspo - wie du das Tasks Problem gelöst hast - wirst du auch dein "Programm braucht Adminrechteproblem" lösen.
- glaub mir - ich hab nicht nur fette A Promi Software hier laufen - auch manche Konzerninterne Krücke - die bei unseren Schwestern schon immer unter Adminrechten liefen. - Jetzt auch nicht mehr.
Hier läuft das stinknormal unter daurechten - man muß nur das rechtekonzept entweder auf File oder Reg Ebene anpassen.
Von daher - ich hab auch keinen Server - der eine dauerhafte Anmeldung braucht.
Ok ein paar Kisten machen was wildes - das sind aber z.B irgendwelche Officemakros die auf einer VM laufen, die in einer anderen Domain stehen - die nur einen einseitigen Trust hat.
Ich denke - für jeden geschmack ist da immer was dabei und da die Geschmäcker unterschiedlich sind - auch die Rezepte mit denen man kocht.
Gruß
genauspo - wie du das Tasks Problem gelöst hast - wirst du auch dein "Programm braucht Adminrechteproblem" lösen.
- glaub mir - ich hab nicht nur fette A Promi Software hier laufen - auch manche Konzerninterne Krücke - die bei unseren Schwestern schon immer unter Adminrechten liefen. - Jetzt auch nicht mehr.
Hier läuft das stinknormal unter daurechten - man muß nur das rechtekonzept entweder auf File oder Reg Ebene anpassen.
Von daher - ich hab auch keinen Server - der eine dauerhafte Anmeldung braucht.
Ok ein paar Kisten machen was wildes - das sind aber z.B irgendwelche Officemakros die auf einer VM laufen, die in einer anderen Domain stehen - die nur einen einseitigen Trust hat.
Ich denke - für jeden geschmack ist da immer was dabei und da die Geschmäcker unterschiedlich sind - auch die Rezepte mit denen man kocht.
Gruß
