Adminkonzept

Beachten Sie dazu auch die Seiten AdminSDHolder, Exchange Adminkonzept und Office 365 Admin Konzept

Hinweis: Die Einführung von RBAC verändert die Art, wie Berechtigungen delegiert werden aber machen ein ordentliches Konzept natürlich nicht überflüssig.

Best Practices für Delegating Active Directory Administration white paper.
http://www.microsoft.com/downloads/details.aspx?familyid=631747a3-79e1-48fa-9730-dae7c0a1d6d3&displaylang=en
The Administrator Accounts Security Planning Guide
http://www.microsoft.com/technet/security/topics/serversecurity/administratoraccounts/default.mspx

So sollte es nicht sein!

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 können 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?

  • Ich kann immer arbeiten
    Natürlich können Sie als Administrator ohne erneute Abmeldung sofort alle administrativen Tätigkeiten ausführen. Das spart Zeit, weil Sie sich nicht erst umständlich ummelden müssen. Das Gleiche gilt natürlich auch für Schadprogramme, die sie unbeabsichtigt installieren oder starten.
  • Bei mir geht alles, aber ...
    wenn Sie ein Anwender anruft, dass bei ihm etwas nicht mehr geht ist es nicht gerade einfach für Sie, das sofort nachzuvollziehen. Als Domänen Administrator dürfen Sie meist ziemlich viel und Sie bemerken eigentlich gar nicht, dass Sie bei der Einrichtung etwas übersehen haben, was aber "normale Anwender" leider sofort bemerken.
  • "Drag and Drop" oder die Tücken des Explorer
    Oftmals sind Sie es sogar selbst, der aus versehen, quasi als Flüchtigkeitsfehler, eine Datei oder komplette Verzeichnisstruktur per "Drag and Drop" mal eben verschoben hat. Mir ist das schon passiert und ihnen auch. Solange es nur die eigenen Dateien betrifft, ist das kein Problem aber als Administrator können Sie auch "aus Versehen" ...  Reden wir nicht drüber
  • Wer hat Angst vor ..
    ... Viren, Trojaner, Keylogger? Es muss nicht immer erst das Schlimmste eintreten, um ihre Berechtigungen zu missbrauchen. Aber unrealistisch ist es nicht, dass ein ActiveX, ein JavaScript oder die schnell mal zum Test herunter geladene Software XY einen Fehler oder sogar einen Schadanteil hat. Wer heute als Administrator im Internet surft ist wahrlich von allen guten Geistern verlassen.

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.:

  • RunAs
    Der einfachste Weg ist natürlich, die administrativen Programme einfach per RunAs mit einem anderen Benutzerkonto zu starten. Natürlich müssen Sie das Kennwort dann auch entsprechend eingeben. Denkbar ist z.B.: eine DOS-Box mit einer anderen Hintergrundfarbe mit einem administrativen Account zu starten und von dort aus dann die erforderlichen Programme zu starten. (MMC etc.). Allerdings kann dann immer noch ein Programm oder Fehler derart zuschlagen, der eben Tastatureingaben etc. durchführt (Wenn es das richtige Fenster findet)
  • Terminaldienste
    Das Problem der Administration vom Arbeitsplatz ist aber auch, dass Sie immer die Hilfsprogramme auf ihrem PC haben müssen, d.h. z.B.: den Exchange System Manager, die ADC-SnapIns, die IIS-SnapIns, Active Directory Benutzer und Computer und viele mehr. Und diese ganzen Komponenten müssen Sie genau wie ihren Server auch auf dem gleichen Service Pack Level halten. Da kommen einem die Termin Dienste von Windows 2000/2003 gerade rechte. Ich habe keinen Exchange System Manager mehr auf meinem PC. Nebenbei erlauben Terminaldienste es einem Administrator auch von jedem Arbeitsplatz im unternehmen oder sogar der Welt eine Verbindung per MSTSC.EXE aufzubauen und zu administrieren, ohne die aktuelle Benutzersitzung abmelden zu müssen. Ein Beenden der Verbindung hinterlässt keine Spuren und keine Verbindungen des Administrators, die vom Anwender missbraucht werden könnten.
  • Zweiter PC, Administrationsserver oder Virtual PC
    Wenn Sie ihren eigenen PC nicht verändern möchten, so dass er wirklich dem "Standard Arbeitsplatz" ihres unternehmens entspricht, dann können Sie sich z.B.: einen zweiten PC mit einem Bildschirmumschalter unter den Tisch stellen. Andere Firmen stellen einen eigenen Windows Terminal  Server in das LAN, der für die Administration genutzt wird. Oft laufen darauf dann auch gleich Programme wie MOM2005. Eine dritte Option ist die Installation eines Administratorensystems als virtuelle Maschine auf ihrem Desktop,  z.B.: mit Virtuelle Systeme.
  • Programme mit Rechte/Provisioning
    Zuletzt gibt es auch die Möglichkeit, über entsprechende Provisioning Systeme bestimmte Tätigkeiten vereinfacht zugänglich zu machen. So kann eine Webanwendung über einen Browser viele Routinetätigkeiten nicht nur dem Administrator sondern sogar entsprechenden Personenkreisen zugänglich gemacht werden. Siehe auch Provisioning

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:

  • Ein Benutzerkonto hat niemals Adminrechte
    Es mag wenige Ausnahmen geben aber ich würde davon nicht abweichen wollen und Benutzer als "Benutzer" sehen. Wer heute nur einen kleinen Teil administrieren will, kann in einigen Monaten schon mehr Verantwortung haben. Daher ein eigenes AdminKonto. Wer das nicht will, kann die Administration vielleicht über ein Provisioning-Werkzeug für den Benutzer bereitstellen.
  • Personalisierte Administratorenkonten
    Jeder Benutzer mit administrativen Aufgaben bekommt einen zusätzlichen administrativen Account. Dieser erhält administrative Berechtigungen zur Verwaltung über Gruppen. Der Account darf nur für administrative Zwecke genutzt werden. Diese Konto hat z.B.: kein Anmeldeskript, kein Profil und nur eingeschränkt Zugriff auf das Internet. Das bedeutet natürlich auch, dass diese Zugänger möglichst überall genutzt werden. Der Zugang zu Switches und Router kann z.B: per RADIUS oder LDAP gegen das AD verifiziert werden, so dass lokale Konten mit unabhängigen Kennworten entfallen. Im Idealfall müssen Sie bei einem ausscheidenden Administrator nur das Admin-Konto deaktivieren, damit er ihnen kein Osterei hinterlassen kann.
  • Kennwort-Safe
    Viele Dienste und Geräte haben trotz Integration ins AD immer noch lokale Benutzer. Die Kennworte müssen irgendwo "sicher" gespeichert sein. Programme ie KeeSafe funktionieren für Einzelpersonen aber nicht in Firmen, Wer so eine Kennwortdatei samt Masterkennwort hat, kann sie einfach kopieren und mitnehmen. Firmenkennworte müssen auf einem System liefen, welches auf Anfrage immer nur genau das gewünschte Kennwort an die berechtigten Personen ausliefert und den Zugriff auch protokolliert.
  • Normale Anwender sind nie Domain Admins
    Es ist viel zu gefährlich und diverse Programme haben sogar "DENY"-Rechte für Administratoren, die dann die Regelfunktion stören.
  • Personalifizierte Domain Administrator Accounts
    Für die eigentliche Administration als Domänen Administrator werden eigene Konten genutzt,  d.h. es gibt gesonderte administrative Konten, die auch fest einem Benutzer zugeordnet sind und Mitglied in der Gruppe "Domänen Administratoren" sind.
  • UAC für lokale Administratoren
    Auf Servern und Workstations sollte unbedingt UAC (User Account Control) aktiv sein, damit ein Admin bewusst ein "Als Admin starten" ausführen muss. Allerdings sollten Sie hier nicht jedes mal das Kennwort abfragen, da das eher dazu verführt, das AdminKennwort zu oft einzugeben und dann ein Dialog einer Malware nicht weiter auffällt.
  • Administratoren haben kein Postfach
    Zum einen brauchen sie keins, da der Anwender ja auch ein "Normales Konto" hat und sicher nicht mehrere Postfächer beobachten will. Zudem kostet es Lizenzen und es verleitet vielleicht dazu eine Anlage aus Versehen auszuführen.
  • Schutz des "Administrator"
    Das Konto des „Administrators“ wird umbenannt. Das Kennwort wird versiegelt abgelegt. Dies ist daher immer ein Notfallkennwort, wenn die normalen Domänen Administratoren nicht greifbar sind. Maximal Zwei Personen haben Zugriff auf den Administrator.
  • Gruppe Domänen Administratoren
    Die Mitgliedschaften in der Gruppe Domänen Administratoren können nur von Domänen Administratoren geändert werden. Die Mitgliedschaften sind festgelegt (Umbenannter Administrator und besondere administrative Konten). Die Gruppe der "Domänen Administratoren" enthält nur sehr wenige administrative Konten. für die meisten Tätigkeiten ist es nicht notwendig, "Domänen Administrator" zu sein.
  • Sicherung der Domain Controller
    Eine Anmeldung auf Infrastrukturservern soll nur den "Domänen Administratoren" möglich sein. Sofern andere Dienste (z.B. DNS, Gruppenrichtlinien ) zu administrieren sind, sind entsprechende Server zu nutzen. Allgemeine Funktionen wie die Ansicht des Eventlog, Einstellungen von SNMP, Backup etc. können remote oder per Gruppenrichtlinie erfolgen. Dienste wie DHCP, DNS werden über die eingebauten Gruppen delegiert.
  • Admins dürfen sich nur auf „vertrauenswürdigen“ Umgebungen anmelden
    Das kann der eigene Computer sein (per RunAs) aber nie ein unbekannter Desktop im Feld oder sonst wo. Dies kann per Richtlinien (LogOn Locally) etc. erzwungen werden Optional wäre eine Multi Faktor Anmeldung als Absicherung zu überlegen.
  • Administrationsserver
    Ideal ist ein eigener Server, der für die Administration bereit gestellt wird. So kann man von überall sich per RDP auf ein System anmelden, welches "nahe" an den anderen Server steht und alle aktuellen Tools enthält. Er kann zugleich "Job-Server" sein und erlaubt auch die Wiederaufnahme einer unterbrochenen Verbindung.
  • Sichere Übertragungswege
    Wenn ein Admin irgendwo sein Kennwort eingibt, dann muss er natürlich sicher sein, dass es nicht "mitgelesen" wird. Das bedeutet, dass die Anmeldung auf Switches, Routern und anderen Geräten per Browser über HTTPS erfolgen muss. Dazu sollten bitte gültige Zertiifkate (Gerne von der eigenen PKI) genutzt werden und keine "SelfSigned", die auch ein Man in the Middle-Angreifer erstellen kann. Anstatt einem TELNET sollte SSH verwendet werden und SNMP-Zugriffe sollten nur mit ReadOnly-Communities möglich sein. RW-Zugriffe sollten über ein Verwaltungs-VLAN erfolgen.
  • Vergabe administrativer Rechte über Gruppen
    Alle Berechtigungen auf Organisationseinheiten oder Servern werden über entsprechende Sicherheitsgruppen delegiert. Es gibt keine Delegierung auf einzelne Benutzer. Es versteht sich von selbst, dass z.B. in der Beschreibung der Gruppe dokumentiert wird, wo diese berechtigt wurde.
  • „Funktionsbenutzer“
    Es kann „Funktionsbenutzer“ geben, z.B. für die Installation von PCs oder für Schemaoperationen. Gerade für die Installation von PCs ist es häufig erforderlich, dass ein vordefiniertes Konto für Dienstleister angelegt wird und von mehreren Mitarbeitern dieser Firma genutzt wird. Dies ist eine erlaubte Ausnahme, wenn diese Konto dann nur die Funktion ausführen kann.
  • Überwachung von Anmeldungen
    Alle Anmeldungen werden im Sicherheitseventlog protokolliert. Mit entsprechenden Programmen ist es dann möglich, z.B. fehlgeschlagene Anmeldeversuche auf die administrativen Konten und damit Eindringversuche zu erkennen.
  • Zentrale Gruppenrichtlinien
    GPOs werden von besonders unterwiesenen Benutzern erstellt. Die OU-Administratoren können die vorgegebenen Richtlinien an ihre OU’s verbinden, aber keine eigenen GPOs erstellen oder bestehende GPOs verändern. Dies sichert, dass die Qualität der GPOs hoch bleibt, bei Fehlern und Probleme die Ansprechpartner bekannt sind und eine Vereinheitlichung der Umgebung möglich ist.
  • Jeder Dienst oder Prozess erhält sein eigenes Dienstkonto.
    Kein Dienst sollte als "Administrator" laufen. Es muss jederzeit möglich sein, ein Kennwort eines Dienstes oder Administrators zu ändern oder zu sperren, ohne andere Funktionen im Netzwerk behindert werden. Zudem sollte sehr genau geprüft werden, ob ein Dienstkonto tatsächlich Domänen Administrator sein muss, oder ob sich damit der Hersteller oder Installateur nur das Leben sehr einfach macht. Durch die Verwendung eigenständiger Konten pro Service ist es auch möglich, später bei Zugriffen auf Dateien oder andere Ressourcen und Meldungen im Sicherheits-Eventlog entsprechende Zuordnungen machen zu können. Zudem könnte jede Konto für die Anmeldung auf bestimmte Systeme eingeschränkt werden.
  • Berechtigungen auf ADM-Gruppen
    Werden Benutzer und Systeme in Organisationseinheiten zusammengefasst, so wird nie ein Benutzer auf die OU berechtigt, sondern immer eine Gruppe, in die die administrativen Kontern aufgenommen werden. Auch sollte man auf eine Verschachtelung von ADM-Gruppen verzichten.
  • Kooperative Funktion
    Auch wenn Windows und das Active Directory mit den Zugriffsrechten eine 1005tige Kontrolle und Berechtigung erlauben, so ist es sehr oft nicht sinnvoll, bis auf einzelne Felder oder Objekte herunter mit unterschiedlichen ACLs zu arbeiten. Aus praktischen Aspekten können Berechtigungen zu Gunsten der Vereinfachung gesetzt werden. So kann ein Administrator vielleicht mehr Funktionen ausführen aber dies nicht tut, weil es organisatorisch nicht erlaubt ist.
  • Vorsicht mit primären Gruppen
    Das Konto, welches z.B.: beim Exchange Setup OUs anlegt, ist zugleich auch "Besitzer". Aber auch die primäre Gruppe des Benutzers wird zum "Owner". Ist die primäre Gruppe dieses Installationskontos nun die Gruppe der "Domänen Benutzer", dann führt dies dazu, dass zukünftig alle Domänen Benutzer zu viel Berechtigungen hat. Daher sollten administrative Benutzer niemals eine solche Gruppe als "primäre Gruppen" haben.

Wobei all diese Punkte nur der Anfang eines Administrationskonzepts sind.

Prinzip "Responsible Person"

Administrative Rollen aber auch Datentöpfe sind natürlich begehrtes Ziel für Angriffe oder Missbrauch. Wenn es mir gelänge, mein Konto in eine interessante Gruppe zu addieren, dann könnte ich diese erweiterten Berechtigungen nutzen, um auf fremde Daten zuzugreifen. Das darf nicht passieren aber oft ist es ja keine Sicherheitslücke, die ich ausnutze, sondern eine organisatorische unzulänglichkeit, z.B.: dass ich einen Zugriff beantrage und dieser durch eine Fehlerhafte Prüfung gewährt wird. Verhindern lässt sich so etwas besser, wenn die “Verantwortlichkeit” festgelegt ist. Dies gilt für jede Art von Objekte, wie Dateifreigaben, Drucker aber auch Active Directory Benutzer, Computer und OUs. Hier kann sogar ein “Manager” eingetragen werden.

Interessant wird die nun in dreierlei weise

  • Delegierung von Rechten
    Es ist sehr einfach möglich, dass ein "Manager" zugleich das Recht hat, die Mitgliedschaften zu pflegen. im Active Directory ist dies sehr einfach zu delegieren.

    Je nach Umgebung kann der Manager die Mitglieder dann z.B.: per Outlook pflegen
  • Verifikation
    Verwaltet ein Helpdesk die Mitglieder einer Gruppe, dann kann es über den "Manager" ebenfalls direkt die Person ermitteln, welche gefragt werden muss.
  • Meldung
    Zudem könnte ein automatischer Prozess bei Änderungen an einem Objekt dem Manager eine Mail senden. So könnte dieser zum einen ein positive Feedback einer angeforderten Änderung erhalten (Erfolg) oder nicht autorisierte Änderungen zeitnah erkennen.

Das sind aber nur die technischen Aspekte. Auch die rechtlichen und organisatorischen Fragen, die sich damit verbinden lassen, bedürfen einer Klärung. So könnte ein Bericht Konten ausfindig machen, die schon länger nicht mehr genutzt werden und den Manager darüber informieren. Auch könnten Objekte mit verwaistem Manager neu zugeordnet oder ohne Zuordnung nach einer Karenzzeit deaktiviert werden.

Wie geht es nun weiter?

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

  • Namensgebung der Gruppen
    Diese administrativen Gruppen benötigen eine Namensgebung. Sie sollten sich z.B.: überlegen, dass Sicherheitsgruppen für administrative Belange vielleicht nicht als Verteiler in Exchange oder Sicherheitsgruppe für Dateifreigaben und Berechtigungen benutzt werden. Oder vielleicht grade doch, weil Sie damit dem "Single Administration" nahe kommen ?. Entsprechend sollte der Name vielleicht schon einen Hinweise zur Nutzung der Gruppe geben. Detailfragen, die geklärt sein müssen.
  • OU-Konzeption der Zielobjekte
    Die Benutzer (Anwender) und dazu gehörigen Gruppen (Für Dateifreigaben, Exchange Verteiler etc.) müssen in entsprechenden OUs aufgeteilt werden. Erst dann können die entsprechenden ACLs überhaupt gesetzt werden. Allerdings ist dabei auch Rücksicht auf das Gruppenrichtlinienkonzept und Domänenkonzept zu nehmen.
  • Wo liegen die Admin Gruppen selbst ?
    Wäre doch schade, wenn ein Administrator über Gruppen sich selbst in die Gruppe der "Domänen Administratoren" aufnehmen könnte und sich damit mehr Rechte verschaffen kann.
  • Wie führen die Administratoren ihre Arbeit letztlich aus ?
    Sollten die Administratoren mit ihren Berechtigungen direkt mit der MMC die Änderungen durchführen oder nutzen Sie ein System für das Provisioning hierfür, welches die Plausibilität und Konformität der Eingaben mit den Firmenrichtlinien überprüft und alle Veränderungen protokolliert ?

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

Sie sollten Sich natürlich ein "Namenskonzept" für Gruppen überlegen. Hier ein Vorschlag.

  1. Erster Buchstabe ist die Verwendung
    A=Administrativ, S=Security, E=Exchange
  2. zweiter Buchstabe der Scope
    U=Universal, G=Global, L = Local
  3. Typkennzeichnung
    G= Gruppe

Das könnten dann wie folgt aussehen:

  • EDG = Exchange Distribution Group
  • ESG = Exchange Security Group
  • AUG = Administrative universal Group
  • AGG = Administrative Global Group
  • SUG = Security universal Group
  • SGG = Security Global Group

Denkbar ist natürlich auch eine andere Namenkonvention. Hier noch ein Beispiel

  • DM-xxxxx
    Ein Prefix kennzeichnet administrative Konten. Jeder Administator erhält neben seinem normalen Account ein zweites Konto zur Administration. Dieses Konto kann z.B. über "Ausführen als" oder bei der Anmeldung über Terminaldienste genutzt werden.
  • SVC-xxxxx
    Auch Dienste im Netzwerk dürfen nicht als "Administrator" gestartet werden. Daher erhält auch jeder Dienst ein eigenes Konto
  • AUG-XXX oder SAG-xxxxx
    Für die Vergabe von Rechten sind entsprechende Gruppen zu schaffen. Diese Gruppen werden nicht genutzt, um z.B. Berechtigungen auf Dateien oder Freigaben einzurichten (also Nutzdaten) sondern explizit nur zur Vergabe von Berechtigungen auf Objekte Im Active Directory.

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:

  • ADM-Benutzer haben komplexe Kennworte
    Aufgrund der höheren Berechtigungen sollten diese Konten entsprechend gesichert werden.
  • Die Anmeldung von ADM-Benutzern sollte überwacht werden
    Jede Anmeldung als ADM-Benutzer bedeutet eine Nutzung administrativer Berechtigungen. Dies kann protokolliert werden. Anmeldungen zu "ungewöhnlichen" Zeiten oder fremden Arbeitsstationen können einen Alarm auslösen. Andererseits könnte das System dem normalen Benutzer z.B. eine Mail senden.
  • Fehlerhafte Anmeldung als ADM-User sind immer ein Alarmkriterium
    Viele Personen werden irgendwann erkennen
  • ADM-Benutzer sollten ihr Kennwort regelmäßig ändern.
    Besonders wenn Anmeldungen nicht überwacht werden, ist diese
  • ADM-Benutzer nicht löschen
    Da bei Installationen oft der installierende Benutzer als "Owner" eingetragen wird und teilweise sogar unter Systemsteuerung/Software hinterlegt sind, sollte ein Admin nach Ausscheiden nicht gelöscht, sondern nur deaktiviert werden. So bleibt auch nachvollziehbar, was er gemacht hat.
  • Andere Anwender als ADM/SVC müssen Sie nicht auf Servern anmelden
    Entsprechende Anmeldungen oder Versuche könnten überwacht und gemeldet werden
  • ADM-Benutzer benötigen kein Postfach
    Damit belegen Sie keine Mailadresse aber empfangen vor allem auch keine schädlichen Anlagen.
  • ADM-Benutzer haben beschränkten Internetzugriff
    So wird sichergestellt, dass nur niedrig privilegierte Konten Dateien aus dem Internet herunter laden. Wenn ADM-Benutzer auf das Internet zugreifen sollen, dann können z.B.: die integrierte Authentifizierung, ActiveX und Skripte deaktiviert oder zumindest mit einem Hinweis versehen werden.
  • AUG-Gruppen enthalten NUR ADM-Benutzer
    Über Skripte und Auswertungen können Sie z.B. dokumentieren, welche Benutzer in welchen Gruppen sind. Ich nutze dazu mein Script ADMGROUP.VBS, welches im Forrest alle Gruppen mit dem Prefix "ADM-" sucht und die Beschreibung, den Type und die Mitglieder in einer XML-Datei ausgibt, die dann in Excel oder mit einem Stylesheet formatiert werden kann. (Das Script ist nicht öffentlich)

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

Vergabe von Rechten

  • Aufgabe der Domänen Administratoren
    Sie legen Sicherheitsgruppen (SAG-Gruppen) an
    Sie legen administrative Benutzer (ADM-User) an
    Sie fügen administrative Benutzer in Sicherheitsgruppen hinzu
    Sie delegieren Berechtigungen auf OUs etc. an die Sicherheitsgruppe
    Sie führen die wenigen Aktionen aus, für die Domain Admin Rechte erforderlich sind (z.B. Trusts einrichten etc.)
  • SAG-Gruppen können berechtigt sein auf
    OU's um Benutzer und Computerkonten zu verwalten
    Rechte in der Exchange Organisation erhalten
    In der lokalen Administratorengruppe von Servern sein. (z.B.: per GPOs)
    etc.

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 Workstation-Kategorien oder nach Standorte anlegen, überlass ich ihnen. Die Aufnahme dieser Gruppe in die lokalen Gruppen ist dann wieder einfach:

  • Manuelle Pflege
    Sie können natürlich von Hand die universellen Sicherheitsgruppen in die Gruppe der Administratoren auf jedem einzelnen PC hinzu fügen
  • GPO "Restricted Groups" - Member
    Über eine Gruppenrichtlinie können Sie sehr elegant steuern, welche Mitglieder eine Gruppe enthält.
    Die Sicherheit dieser Richtlinie sorgt aber auch dafür, dass alle anderen Konten aus der Gruppe entfernt werden. Dies betrifft als auch Dienstkonten oder andere Benutzer, die durch eine Installationsroutine hinzugefügt werden. Gerade bei einer Installation sollten Sie daher schnell prüfen oder den Hersteller fragen, welche Gruppenzugehörigkeiten und Berechtigungen eine Installationsroutine vergibt
  • GPO "Restricted Groups" - Member of
    Daher kann der etwas abgeschwächte Weg sinnvoll sein, bei der nicht die Mitglieder der lokalen Admingruppe sondern die Mitgliedschaften einer universellen Sicherheitsgruppe vorgeschrieben werden. Diese wirkt dann auditiv, d.h. entfernt nicht bestehende Einträge. Allerdings ist die Sicherheit dann auch etwas geringer, bzw. Sie müssen eine eigene Überwachung einführen, um Verletzungen der Berechtigungen zu erkennen.

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

Rolle
Gruppe		 Beschreibung ADM-User1 ADM-User2 ADM-User3 ADM-User4

SAG-PCAdministratoren

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.

  • Ausführen Als
    Sie können in den Eigenschaften des Programms im  Startmenü (Also des Icons oder Eintrags) auf der Karteikarte "Verknüpfung - Erweitert" eine andere Anmeldung hinterlegen

    Beim jedem Start des Programms werden Sie dann nach den Anmeldeinformationen gefragt. Wenn Sie nur bei Bedarf ein Programm mit einem anderen Benutzer starten wollen, dann drücken Sie einfach mit gedrückter umschalttaste (SHIFT) auf das Icon mit der rechten Maustaste und wählen im Kontextmenü einfach "Ausführen als" aus
  • RUNAS als Icon hinterlegen
    Eine andere Option ist direkt der Aufruf des Programms mittels "RUNAS". Dies kann problemlos über einen Link erfolgen. Beim Start öffnet sich eine DOS-Box, in der Sie nur noch das Kennwort eingeben müssen. Die Verknüpfung könnte wie folgt aussehen:

    Natürlich können Sie über ein ICON diese "besondere" Kommandozeile kennzeichnen. Aufgerufen wird dabei ein BATCH mit der Kommandozeile

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 Domainadministrator 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:

  • Windows 2008 Berechtigungen
    Mit Windows 2003 ist ein erster Schutz gegen versehentliches Löschen nur eine Checkbox entfernt:
    Windows 2008 Löschschutz
    Unter der Haube wird einfach ein "DENY" für JEDER gesetzt
  • Quest Intrust
    www.quest.com/intrust
  • Unify's role-based delegated administration
    www.ensim.com
  • Und sicher noch einige andere Produkte

Weitere Links