Adminrechte

Eigene Seite zu AdminSDHolder

Wie halten Sie es bei sich im eigenen Netzwerk?  Sind sie auch "Domänen Administrator", damit Sie wirklich jederzeit ein Problem beheben können? Oder kennen viele Leute das Kennwort für den Benutzer "Administrator"? Haben Sie sich schon mal Gedanken gemacht, ob Sie damit nicht genau das Problem sind ? Was bedeutet es denn genau, als Administrator täglich zu arbeiten ?

Generell kann ich aber nur davon abraten, als privilegiertes Konto auch tägliche Routineaufgaben, z.B. Dokumentationen, Internetrecherche etc. durchzuführen.

Welche Alternativen gibt es denn, wenn ich kein Administrator mehr sein möchte, um meine Arbeit trotzdem auszuführen und kein Risiko für mein Netzwerk zu sein ? Es fängt erst mal damit an, dass Sie selbst keine besonderen Rechte mehr haben. Um es mit Orwell zu sagen: "Alle sind gleich" und dazu zählt auch die IT-Betriebsmannschaft. Um dann doch mit erweiterten Berechtigungen arbeiten zu können, gibt es mehrere Wege, z.B.:

Sie sehen also, dass der Spruch "Nur als Domänen Administrator kann ich vernünftig Arbeiten" heute so nicht mehr stehen bleiben kann.

Prinzipien eines Administrationskonzepts

Wenn Sie nun meinen, dass all das bisher gesagte ganz logisch und schlüssig klingt, dann möchte ich noch ein paar weitere Stichpunkte für eine klare Konzeption für administrative Aufgaben nennen. Folgende Liste könnte der Anfang eine Firmenrichtlinie zur Sicherung der Administration sein:

Wobei all diese Punkte nur der Anfang eines Adminkonzepts sind.

Wie geht es nun weiter ?

Von diesen Beispielen bis zur Umsetzung ist es noch ein weiter Weg. So sind Frage zu beantworten wir:

Das sind nur einige der Fragen, die sie klären müssten. Überlegen Sie sich, ob Sie vielleicht externe Hilfe bei der genauen Definition für ihr Umfeld hinzuziehen. Das verhindert eher eine Art "Betriebsblindheit" und auch bei der Umsetzung der Konzeption in NTFS und Active Directory ACLs kann einiges daneben gehen. Oftmals fehlt auch einfach die Zeit zu ermitteln, wie eine bestimmte Aufgabe delegiert werden kann. Wussten Sie z.B. schon, dass ein Administrator der ein Benutzerobjekt verwalten darf, auch komplett die Exchange Eigenschaften anlegen kann ?. Die MMC-SnapIns für Active Directory Benutzer und Computer laufen aber auf eine Fehlermeldung, wenn Sie nicht zumindest "READ"-Rechte in der Organisation und der entsprechenden administrativen Gruppe haben. Die MMC versucht nämlich eine Liste der Postfachspeicher zu erhalten, damit Sie als Administrator eine Auswahl haben. Für das Mailbox aktivieren eines Anwenders selbst ist dieses Recht aber nicht erforderlich, wenn Sie wissen wie ...

Vorsicht bei Vergaben von Rechten

Zum Schluss noch eine Warnung, ehe Sie nun an die Umsetzung der Berechtigungen denken. Wenn Sie nun alle administrativen Benutzer und Gruppen angelegt haben dann müssen Sie diesen Benutzern und Gruppen entsprechende Rechte geben. Hierbei sollten Sie sehr vorsichtig vorgehen. Es ist sehr einfach, einer Gruppe zusätzliche Berechtigungen zu geben. Es ist aber sehr schwer, einer Gruppe bestimmten Berechtigungen wieder zu nehmen. Gerade wenn Sie daran denken, bestimmte Berechtigungen zu "verbieten", dann ist die Gefahr groß, dass das Verbot nicht nur die gewünschten Benutzer betrifft, sondern entsprechende Seiteneffekte hat.

Es ist schon passiert, dass die ACL eines Objekts die Einträge enthalten hat:

Domänen Administratoren: Vollzugriff
Domain-Benutzer: Lesen
Jeder: alle Verboten

Der Denkansatz, dass erst mal niemand etwas kann, es sei denn das Konto ist Benutzer oder Administrator mag gut klingen, aber das "DENY"-Recht gewinnt auch gegenüber den beiden anderen Berechtigungen (mit einer Ausnahme), so dass faktisch nichts und niemand mehr etwas tun kann.

Im Bezug mit Exchange ist daher darauf zu achten, das beim Verbieten von Zugriffsrechten nicht aus Systemdienste wie der MTA, die Routing Engine, der Store oder auch der Exchange RUS weiterhin ausreichende Berechtigungen besitzen. Solche Dienste müssen weiterhin alle Mailadressen finden können, um Mails zustellen oder neue Benutzer mit entsprechenden Mailadressen versehen zu können.

Ein Recht, welches Sie nicht vergeben haben, müssen Sie weiter unten in der Struktur nicht wieder über den Umweg des "DENY" entziehen. Sie können schon bei der Vergabe des Rechtes kontrollieren, ob es überhaupt vererbt wird.

Genauso schädlich ist es, die Vererbung abzuschalten, da damit der Status Quo der Berechtigungen der Unterstruktur festgezurrt wird. Wird durch eine neue Installation weiter oben ein Recht ergänzt, so wirkt sich dieses nicht mehr in diese Zweige aus, was zu sehr schwer zu diagnostizierenden Ergebnissen führt.

Gruppenrichtlinien, administrative Gruppen und Benutzer mit  Administrationsrechten

Wenn nun niemand mehr "Domänen Administrator" ist und auch das eigene "normale" Benutzerkonto nicht mehr zur Administration zugelassen wird, dann müssen eigene Konten für die Administration und Dienste und entsprechende Gruppen zur Vergabe von Berechtigungen geschaffen werden.

Benutzer und Gruppen

Das könnten dann wie folgt aussehen:

Achten Sie darauf,  Sie in einer Umgebung mit mehreren Domänen auf jeden Fall universelle Gruppen verwenden, da sonst einige Berechtigungen z.B.: im Bereich der Konfigurationspartition (Exchange) nicht von allen DCs aufgelöst werden können.

Die Vergabe von Berechtigungen sollte natürlich nicht direkt an die ADM-Benutzer erfolgen, sondern über Gruppen. Und idealer weise trennt man dabei die Zugehörigkeit zu Abteilungen oder administrativen Gruppen von den Berechtigungsgruppen. Das könnte wie folgt aussehen

 So "dokumentieren" ihre Gruppen sogar die verschiedenen Berechtigungen und Sie müssen nicht lange rätseln, welche Gruppe auf welchen Objekten in den ACLs enthalten ist.

Für die Benutzer sollten natürlich strenge Regeln gelten:

Es gibt noch jede Menge weitere Dinge, die sinnvoll eingesetzt werden können.

Vergabe von Rechten

Administrator über Computer

Die wesentliche Veränderung beim  Verzicht auf die Rechte als Domänen Administrator ist, dass Sie auf einen Schlag auch kein Administrator mehr über Server sind. Dies ist natürlich nicht sinnvoll, da Sie mit ihrem ADM-Benutzer natürlich Server administrieren müssen. Dieses Recht müssen Sie wieder erhalten, indem Sie in die lokale Administratorengruppe der jeweiligen Systeme aufgenommen werden. Die Pflege dieser lokalen Gruppen steht daher auf der Tagesordnung. Natürlich sollten Sie nicht einzelne Benutzer in eine lokale Administratorengruppe aufnehmen sondern immer nur entsprechende Sicherheitsgruppen, die entsprechend dem Namenskonzept anzulegen sind. Ob sie nun Gruppen pro Server oder für bestimmte Server und Workstationkategorien oder nach Standorte anlegen, überlass ich ihnen. Die Aufnahme dieser Gruppe in die lokalen Gruppen ist dann wieder einfach:

Die Steuerung, welche Richtlinie dabei auf welchen Server greift können Sie über OU's oder über entsprechende Computergruppen steuern. Ihre Domänencontroller bilden dahingehend eine Ausnahme, da es dort keine lokalen Gruppen gibt und demnach ein Administrator damit auch immer Domänen Administrator ist. Daher empfiehlt es sich aber einer bestimmten Firmengröße, die Funktion der Domänen Controller auf eigenen Systemen auszuführen. Umgekehrt ist eine Netzwerk mit wenig Servern meist auch so klein, dass eine Unterscheidung nach administrativen Rollen sowieso nicht statt findet.

Das Konzept kann natürlich noch so weit erweitert werden, dass auch normale Anwender sich nicht mehr überall, sondern nur noch auf den Computern der eigenen Abteilung anmelden dürften etc. Auch hier können Sie z.B.: über Abteilungsgruppen und Computergruppen das Recht der lokalen Anmeldung steuern. So wird ausgeschlossen, dass sich ein Azubi abends auf einem anderen PC mit seinen Daten anmeldet und zumindest Zugriff auf ungesicherte lokale Daten erhält.

Administrative Rollen

Das ganze führt letztlich zu eine Matrix, welche Sie in ihrer Firma erstellen sollten

Gruppe Beschreibung ADM-User1 ADM-User2 ADM-User3 ADM-User4
SAG-PCAdmins Verwaltet die normalen Standard-PCs X X    
SAG-Userhelpdesk Verwalten Benutzer und Gruppen X X X  
SAG-PasswordReset Dürfen zusätzlich auch Kennworte zurücksetzen     X X
SAG-MBFull Haben das Recht in Postfächer "rein zu schauen"       X
SAG-Logauswertung Dürfen die IIS-Logs und entsprechende Auswerteprogramme einsehen       X
           

Das ist natürlich nur eine "Kurzfassung", denn die Ermittlung der Rollen und Gruppen mit den Berechtigungen ist immer eine firmenspezifische Aufgabe. Hier eine Abbildung einer solchen produktiven Matrix.

Links sind ein paar Gruppen samt Beschreibung und der delegierten Berechtigungen zu sehen. Oben dann farblich nach Abteilung abgetrennt die administrativen Konten und ihre Gruppenzugehörigkeit.

Wenn Sie solch eine Konstruktion umgesetzt haben, dann ist es natürlich einfach möglich, per VBScript eine aktuelle Tabelle anhand der Gruppennamen, Beschreibungen und Mitgliedern erstellen zu lassen und Änderungen oder gar Verletzungen (z.B.: "normale Konten in ADM-Gruppen) zu melden.

Admin bei Bedarf

Wenn Sie nun soweit sein,  dass Sie mit ihrem "normalen" Konto kein Administrator mehr sind, aber auf ihrem PC doch mal das ein oder andere Programm als Administrator starten müssen,  dann gibt es mehrere Optionen.

C:\WINDOWS\system32\runas.exe /user:nawwsfc1\administrator %windir%\system32\admin.cmd

Das Batchfile enthält nicht viel mehr als folgende Zeilen:

Die Hintergrundfarbe wird damit auf "dunkelrot" gesetzt und eine  zweite CMD-Box geöffnet. Das Script selbst wird dann beendet. Beachten Sie, dass nun jedes aus dieser Box heraus gestartet Programm ebenfalls die Rechte hat.

admincmd.ico
admincmd2.ico
Zwei Icons zur grafischen Unterscheidung einer administrativen Konsole

Über diese Wege ist es sehr sehr einfach, lokal ohne Administrator zu arbeiten und bei Bedarf sehr schnell nur den gewünschten Programmen die erforderlichen Berechtigungen zu geben, ohne dass ihr Word, Excel, Outlook oder auch der Internet Explorer umfangreiche Rechte haben.

Zusätzlicher Schutz

Selbst wenn jemand DomainAdmin ist, so wünscht man sich doch einen besseren Schutz. Das ist sogar möglich durch explizit gesteuerte Berechtigungen oder Filterprogramme auf dem Domain Controllern, die alle Änderungen noch mal validieren und optional anhalten:

Weitere Links

Keywords: Adminkonzept Administrator Rechte