Bundesamt für Sicherheit in der Informationstechnik

Umsetzungshinweise zum Baustein APP.2.2 Active Directory

Schnell zum Abschnitt

1 Beschreibung

1.1 Einleitung

Das Active Directory ist der zentrale Datenspeicher für sämtliche Verwaltungsdaten einer Domäne auf Basis der Serverbetriebssysteme Windows Server seit Version Windows 2000 Server. Abstrakt gesehen, bildet das Active Directory eine hierarchisch und baumartig organisierte objektbasierte Datenbank. Es ist an den Verzeichnisdienst-Standard X.500 angelehnt, von dem es die interne Struktur und den internen Aufbau entliehen hat. Es ist jedoch kein X.500 kompatibler Verzeichnisdienst. Active Directory wird häufig als "AD" oder "ADS" (Active Directory Services) abgekürzt.

1.2 Lebenszyklus

Für den erfolgreichen Aufbau und Betrieb eines sicheren Active Directory sind eine Reihe von Maßnahmen umzusetzen, beginnend mit der Konzeption über die Installation bis zum Betrieb. Die Schritte, die dabei zu durchlaufen sind, sowie die Maßnahmen, die in den jeweiligen Schritten beachtet werden sollten, sind im Folgenden aufgeführt.

Planung und Konzeption

Als Einstieg empfiehlt es sich bei nicht bereits ausreichender Fachkenntnis, zunächst die Maßnahme APP.2.2.A4 Schulung zur Active Directory-Verwaltung zu betrachten, die einen Überblick über die Aufbau und Begrifflichkeiten eines Active Directory bietet.

Vor der eigentlichen Einrichtung des Active Directory ist im Vorfeld die Organisationsstruktur der Institution zu ermitteln, um aus dieser eine möglichst optimale Konfiguration für das Active Directory ableiten zu können. Die Maßnahme APP.2.2.A1 Planung des Active Directory erläutert die Vorgehensweise in der Planungsphase und das Domänenkonzept des Active Directory.

APP.2.2.A2 Planung der Active Directory-Administration beschäftigt sich mit der Basisstruktur zur Verwaltung einer Domäne und vermittelt die Aufgaben und Anwendungen der einzelnen administrativen Rollen. Des Weiteren wird hier der organisatorische Aufbau und die Rechteanpassung von administrativen Benutzerkonten eines Active Directory erläutert.

Die Maßnahme APP.2.2.A3 Planung der Gruppenrichtlinien unter Windows befasst sich mit den Gruppenrichtlinien für Windows Betriebssysteme, die auch mittels Active Directory verwaltet werden können.

Beschaffung

Bezüglich der Beschaffung sind keine gesonderten Anforderungen zu erfüllen, die über den Baustein APP.2.1 Allgemeiner Verzeichnisdienst hinausgehen. Es ist lediglich zu beachten, dass bestimmte Sicherheitsfunktionen nur durch neuere Versionen von AD und damit durch Einsatz neuerer Versionen von Windows Server ermöglichst werden, was Beschaffungsentscheidungen beeinflussen kann (siehe APP.2.2.A1 Planung des Active Directory).

Umsetzung

Um einen einheitlichen Sicherheitsstandard zu erhalten, ist die Maßnahme APP.2.2.A7 Umsetzung sicherer Verwaltungsmethoden für Active Directory zu beachten. Des Weiteren sind die für die Administration des Verzeichnisdienstes zuständigen Personen auf Basis APP.2.2.A4 Schulung zur Active Directory-Verwaltung mit den ihnen zugeteilten Aufgabenbereichen vertraut zu machen.

Aufgrund ihrer für die gesamte Netzumgebung zentralen Bedeutung sind die Domänencontroller einer Institution ausreichend zu härten (siehe APP.2.2.A5 Härtung des Active Directory). Dies umfasst insbesondere auch die Einrichtung des sicheren Kanals zwischen DCs, Servern und Clients (APP.2.2.A8 Konfiguration des sicheren Kanals unter Windows) und die weiteren Anforderungen aus APP.2.2.A9 Schutz der Authentisierung beim Einsatz von Active Directory.

Um den Integritätsschutz einer produktiv eingesetzten Active Directory-Umgebung durch die Sicherung der DNS -Komponenten gewährleisten zu können, ist die Maßnahme APP.2.2.A10 Sicherer Einsatz von DNS für Active Directory zu berücksichtigen.

Betrieb

Neben dem zugrundeliegenden Betriebssystem ist auch das Active Directory selbst sorgfältig zu administrieren (siehe APP.2.2.A6 Aufrechterhaltung der Betriebssicherheit von Active Directory), um sicherzustellen, dass die relevanten Systeme des Informationsverbundes auf einem aktuellen Sicherheitsstand gehalten werden.

Um rechtzeitig bei aufkommenden Problemen reagieren zu können, sollte die entsprechende Maßnahme APP.2.2.A11 Überwachung der Active Directory-Infrastruktur berücksichtigt werden. Diese befasst sich nicht nur mit den Rückmeldungen bei der Überschreitung definierter Schwellenwerte, sondern auch mit der Protokollierung durchgeführter Systemänderungen.

Aussonderung

Bezüglich der Aussonderung sind keine gesonderten Anforderungen zu beachten, die über den Baustein APP.2.1 Allgemeiner Verzeichnisdienst hinausgehen.

Notfallvorsorge

Aspekte der Notfallplanung für Active Directory werden in der Maßnahme APP.2.2.A12 Datensicherung für Domänencontroller thematisiert.

2 Maßnahmen

Im Folgenden sind spezifische Umsetzungshinweise im Bereich "Active Directory" aufgeführt.

2.1 Basis-Maßnahmen

Die folgenden Maßnahmen sollten vorrangig umgesetzt werden:

APP.2.2.M1 Planung des Active Directory [Fachverantwortliche]

Eine grundlegende Voraussetzung für den sicheren Einsatz des Active Directory ist eine angemessene Planung im Vorfeld. Die Planung für ein Active Directory kann dabei in mehreren Schritten erfolgen. Es sollte zunächst ein Grobkonzept für die Struktur der Domäne erstellt und darauf aufbauend die einzelnen Teilaspekte konkretisiert werden. Die Planung betrifft dabei nicht nur Aspekte, die klassischerweise mit dem Begriff Sicherheit verknüpft werden, sondern auch normale betriebliche Aspekte, die Anforderungen im Bereich der Sicherheit nach sich ziehen können. Hinweise zum Aufbau und zur prinzipiellen Struktur eines Active Directory bietet die Maßnahme APP.2.2.M4 Schulung zur Active Directory-Verwaltung.

Im Rahmen der Active Directory Planung sind folgende Aspekte zu berücksichtigen:

  • Welche Version des AD ("Domain Functional Level) benötigt wird, um die benötigten Sicherheitsfunktionen einrichten zu können.
  • Welche Active Directory-Struktur im Sinne der Aufteilung in Domänen und welche Anordnung der Domänen in Bäume (Trees) und Wälder (Forests) soll gewählt werden?
  • Welche Benutzer und Rechner sollen in welchen Domänen zusammengefasst werden?

Für jede Domäne muss entschieden werden,

  • welche OU-Objekte existieren sollen, wie diese hierarchisch angeordnet werden und welche Objekte diese jeweils aufnehmen sollen,
  • welche Sicherheitsgruppen benötigt werden und wie diese in OUs zusammengefasst werden,
  • welches administrative Modell umgesetzt wird (zentrale/dezentrale Verwaltung),
  • ob und an wen administrative Aufgaben delegiert werden sollen,
  • welche Sicherheitseinstellungen für verschiedene Typen von Rechnern und Benutzergruppen gelten sollen,
  • welche Einstellungen bei den Gruppenrichtlinien benötigt werden und nach welchem Konzept die Gruppenrichtlinien verteilt werden (siehe Planung der Gruppenrichtlinien).
  • welche Vertrauensstellungen von Windows-Server automatisch generiert werden und welche zusätzlichen Vertrauensstellungen (z. B. zu NT-Domänen oder externen Kerberos-Realms) eingerichtet werden müssen,
  • auf welche Active Directory-Informationen über die verschiedenen Active Directory-Schnittstellen (z. B. ADSI , LDAP) von wem zugegriffen werden dürfen und
  • welche Active Directory-Objekte in den so genannten Global Catalog übernommen werden sollen, auf den in einem Forest global zugegriffen werden kann.

Generell muss die geplante Active Directory-Struktur geeignet, d. h. auch für fachkundige Dritte mit kurzer Einarbeitungszeit verständlich, dokumentiert werden. Dies trägt maßgeblich zur Stabilität, konsistenten Administration und damit zur Systemsicherheit bei. Es empfiehlt sich insbesondere festzuhalten, welche Schemaänderungen durchgeführt werden. Dabei sollten auch die Gründe für die Änderung dokumentiert sein.

Sicherheitsfunktionen von AD nach Betriebssystem bzw. Domain Functional Level

Jede neue Generation des Betriebssystems Windows Server bringt zusätzliche Sicherheitsfunktionen und -erweiterungen auch in Bezug auf AD mit. Außerdem werden in der Regel die Standardeinstellungen immer sicherer gesetzt. Einige davon sind verwendbar, sobald das neue System installiert ist, andere erst, wenn das Domänen-/Wald-Functional-Level angehoben wurde.

Es sollte immer ein möglichst hohes Domain Functional Level betrieben werden. Mindestens sollte dieses so hoch sein, dass alle Sicherheitsfunktionen angeboten werden können, die zur Gewährleistung des notwendigen Schutzbedarfs benötigt werden. Die Entscheidung für ein Domain Functional muss begründet getroffen und dokumentiert werden und sollte regelmäßig überprüft werden.

Die wichtigsten neuen Sicherheitsfunktionen bzw. Erweiterungen von solchen mit den letzten Windows-Server-Versionen bis 2012 R2 waren folgende:

Windows Server 2008 R2 Domain Functional Level:

  • Unterstützung für Kerberos AES-VerschlüsselungDadurch kann die Unterstützung von RC4 HMAC aus Kerberos entfernt werden. Außerdem unterstützen Windows 7 und Windows Server 2008 R2 kein DES bei Kerberos mehr.
  • Verwaltete Dienstkonten (Managed Service Accounts)AD verwaltet die Passwörter dieser Dienstkonten selbst
  • Authentication Mechanism Assurance
    Nutzer erhalten zusätzliche Gruppenmitgliedschaften erst nach Authentifikation via Smartcard

Windows Server 2012 Domain Functional Level:

  • Verwaltete Dienstkontengruppen (Group Managed Service Accounts)AD verwaltet die Passwörter dieser Dienstkontengruppen selbst
  • Compound Authentication und Kerberos FAST (Kerberos Armoring)

    • Kombiniert Nutzer- und Geräteauthentifizierung
    • Schützt Kerberos AS- und TGT-Anfragen.

Windows Server 2012 R2 Domain Functional Level:

  • Authentifizierungsrichtlinien und Silos
    Schützt privilegierte Konten durch Beschränkung, wo sie sich anmelden können
  • Sicherheitsgruppe Geschützte Benutzer (Protected Users)

    • Primärer DC (PDC) muss Windows 2012 R2 sein, um die Gruppe zu erhalten
    • Protected Users Host Protection (mit Windows 8.1 und 2012 R2) verhindert folgendes auf Systemen:

      • Authentifikation per NTLM, Digest Authentication oder CredSSP
      • Caching von Credentials
      • DES und RC4 bei Kerberos Pre-Authentifikation
      • Delegation von Konten

    • Protected Users Domain Enforcement verhindert folgendes bei Nutzern:

      • NTLM-Authentifikation.
      • DES und RC4 bei Kerberos Pre-Authentifikation
      • Das Delegiert-Werden
      • Eine Erneuerung von Kerberos TGTs über die anfängliche vier-Stunden-Frist hinaus (danach muss neu authentifiziert werden)

Dokumentation

Für jedes Active Directory-Objekt sollte dokumentiert sein:

  • Name und Position im Active Directory-Baum (z. B. "StandortBerlin", Vater-Objekt: OU "Filialen-Deutschland")
  • welchem Zweck das Objekt dient (z. B. Gruppe der Benutzer mit RAS-Zugang auf RAS-Server 1)
  • welche administrativen Zugriffsrechte für das Objekt und dessen Attribute vergeben werden sollen (z. B. vollständig verwaltet von "Admin1")
  • wie die Vererbung von Active Directory-Rechten konfiguriert werden soll, z. B. Blockieren der Rechtevererbung (siehe auch Planung der Active Directory-Administration, Schulung zur Active Directory-Verwaltung)
  • welche Gruppenrichtlinienobjekte auf dieses Objekt wirken (siehe Planung der Gruppenrichtlinien)

Der Planung der Active Directory-Administration und des benutzten administrativen Modells kommt eine wichtige Aufgabe zu. Empfehlungen dazu finden sich zusammengefasst in Maßnahme Planung der Active Directory-Administration.

Die sicherheitsrelevanten Kernaspekte der Active Directory-Planung sind zusammengefasst:

  • Domänen begrenzen die administrative Macht von Administratoren. Administratoren können daher nur innerhalb einer Domäne verwaltend tätig werden, sodass ihre Verwaltungsbefugnis standardmäßig nicht über die Domänengrenze reicht. Dies gilt insbesondere im Verbund mit mehreren Domänen (Baum, Wald), so dass die oft geäußerten Bedenken, dass durch das standardmäßig transitive Vertrauensmodell auch administrative Berechtigungen über Domänengrenzen hinweg möglich sind, für normale Administratorenkonten ausgeräumt werden können (siehe jedoch Organisations-Admins unten).
  • Domänenübergreifende Zugriffe setzen voraus, dass in der Ziel-Domäne explizit Zugriffsberechtigungen für den Zugreifenden aus einer anderen Domäne eingerichtet werden. Standardmäßig sind daher keine domänenübergreifenden Zugriffe möglich.
  • Dies bedeutet, dass in einem Baum oder Wald ein Administrator einer Domäne "A" nur dann administrativ auf eine beliebige andere Domäne "B" zugreifen kann, falls der Domänenadministrator von "B" dem Administrator der Domäne "A" explizit Berechtigungen dazu einräumt (siehe jedoch Organisations-Admins).
  • Die Mitglieder der Gruppe Organisations-Admins genießen einen Sonderstatus, da sie im gesamten Forest Administratorrechte auf dem Active Directory besitzen. Insbesondere werden gesetzte Zugriffsrechte auf Active Directory-Objekte bei Zugriffen von Organisations-Admins ignoriert. Die Mitgliedschaft in der Gruppe der Organisations-Admins muss daher restriktiv vergeben und strikt kontrolliert werden. Es ist zu beachten, dass ein Organisations-Admin benötigt wird, um beispielsweise eine Subdomäne anzulegen.
  • Administrative Delegation wird durch die Vergabe von Zugriffsrechten auf Active Directory-Objekte und deren Attribute erreicht. Die Verteilung der Zugriffsrechte muss gemäß dem administrativen Modell erfolgen. Durch die Mechanismen für Zugriffsrechte im Active Directory (Vererbung, Kontrolle der Vererbung, Wirkungsbereich von Zugriffseinstellungen) können sehr komplexe Berechtigungsstrukturen aufgebaut werden. Diese können sehr schnell unübersichtlich und nicht mehr administrierbar werden, so dass sich durch Fehlkonfigurationen im Active Directory Sicherheitslücken ergeben können. Eine möglichst einfache Berechtigungsstruktur ist daher vorzuziehen.
    Um Delegation sicher zu planen und einzusetzen wird empfohlen, zunächst die tatsächlichen Anforderungen in Form real benötigter minimaler Rechte zu ermitteln, zu dokumentieren (z. B. zunächst sprachlich-textuell) und diese anschließend in technische Zugriffsrechte zu übersetzen.
  • Schemaänderungen sind kritische Operationen und dürfen nur von autorisierten Administratoren nach sorgfältiger Planung durchgeführt werden.

Abschließend sei darauf hingewiesen, dass Fehler in der Active Directory-Planung und den zugrunde liegenden Konzepten nach erfolgter Installation nur mit beträchtlichem Aufwand zu berichtigen sind. Nachträgliche Veränderungen in der Active Directory-Struktur, wie z. B. die Anordnung von Domänen in Bäume und Forests, ziehen unter Umständen das komplette Neuaufsetzen von Domänen nach sich.

Active Directory Federation Services (ADFS)

Active Directory Federation Services (ADFS oder auch AD FS abgekürzt) ist eine weitere Softwarekomponente von Microsoft und Teil der ADS, mittels derer sogenannte "Federation" oder "Federated Identities" (föderierte Identitäten) abgebildet werden können. Dabei handelt es sich um Funktionen, die einen Single-Sign-On-Zugriff auf Systeme auch über Institutionsgrenzen hinweg ermöglichen. Seit Windows Server 2012 ist die Funktion als Rolle im System verfügbar und benötigt keine zusätzliche Installation mehr. Seit Windows Server 2012 ist eine Verwaltung per PowerShell möglich, seit 2012 R2 auch eine Integration mit OAuth 2.0.

In ADFS wird eine Vertrauensbeziehung zwischen zwei (oder mehr) Organisationen eingerichtet. Ein Federation-Server auf der einen Seite kann dann einen Nutzer mit Standardmitteln, z. B. am AD, identifizieren und stattet ihn daraufhin mit einem Token aus, das gewisse "Claims" (Zusicherungen) enthält. Diese kann der Nutzer vorzeigen, um Berechtigungen in der anderen Organisation zu erlangen.

ADFS gewinnt deutlich an Bedeutung, da es eine natürliche Eignung für die Integration mit Cloud-Diensten mitbringt. So kann es z. B. im Zusammenhang mit dem Microsoft-Dienst "Azure AD" genutzt werden. Eine Interaktion ist auch mit anderen WS-*- oder SAML 2.0-kompatiblen Federation-Diensten möglich.

Der Einsatz von Federation im allgemeinen und ADFS im besonderen ist zu begründen, gründlich zu planen und zu dokumentieren. Dies betrifft insbesondere die notwendigen Vertrauensbeziehungen. Diese sollten minimal gewählt und regelmäßig evaluiert werden. Die Risiken eines Missbrauchs von Rechten, die durch Authentisierung oder Autorisierung in einer anderen Organisation gewährt wurden, sind systematisch zu beschreiben, zu bewerten und geeignet zu behandeln.

Kommen Clouddienste zum Einsatz, so müssen zusätzlich die geeigneten Bausteine angewandt werden (insbesondere OPS.2.2 Cloud-Nutzung und OPS.3.2 Cloud Management).

APP.2.2.M2 Planung der Active Directory-Administration [Fachverantwortliche]

Das Active Directory besteht aus verschiedenen Objekten, die baumartig organisiert sind. Jedes Objekt besteht aus bestimmten Attributen, die die Objektinformationen speichern. Durch Objekte geschieht die Verwaltung eines Windows-Systems, die durch einen berechtigten Administrator erfolgen muss. Für alle Active Directory-Objekte können Berechtigungen vergeben werden, die den Zugriff auf die Objekte steuern. Damit kann festgelegt werden, welche Objekte von welchen Benutzern in einer bestimmten Art und Weise verändert werden können wie beispielsweise das Anlegen von Benutzern oder das Zurücksetzen von Benutzerpasswörtern.

Bei einer Standardinstallation besitzen nur Administratoren das Recht, Veränderungen an Objekten vorzunehmen und damit eine Domäne zu verwalten. Benutzer besitzen in der Regel maximal Leserecht.

Generell gilt unter Windows Server, dass an der Domänengrenze auch die administrative Macht der Administratoren der Domäne endet. Lediglich die Mitglieder der Gruppe Organisations-Admins besitzen in jeder Domäne eines Forests Vollzugriff auf alle AD-Objekte, und zwar unabhängig von den für diese Objekte eingestellten Zugriffsrechten. Standardmäßig sind dies die Mitglieder der Administratorengruppe der Forest-Root-Domain (FRD).

In großen Domänen empfiehlt sich die Delegation administrativer Aufgaben, sodass die administrative Last auf mehrere Administratoren verteilt ist oder auch, unter Umständen zusätzlich, eine Rollentrennung umgesetzt werden kann. Die Delegation administrativer Aufgaben erfolgt im Active Directory durch die Vergabe entsprechender Zugriffsrechte auf Active Directory-Objekte für die jeweiligen Adminstratorengruppen. Dabei erlaubt die Active Directory-Rechtestruktur eine feingranulare Vergabe von Rechten. Auf diese Weise kann z. B. einem Administrator erlaubt werden, Benutzerkonten anzulegen und Benutzerpasswörter zurückzusetzen, jedoch nicht Benutzerkonten zu löschen oder in andere Organizational Units (OU, Organisationseinheiten) zu verschieben. Um die Vergabe gleichförmiger Rechte innerhalb eines kompletten Teilbaums zu vereinfachen, besteht zusätzlich die Möglichkeit, Rechte eines Objektes an Objekte im Unterbaum zu vererben. Da die Übernahme von vererbten Rechten durch bestimmte Objekte im Unterbaum unter Umständen nicht gewünscht ist, lässt sich die Übernahme für Objekte auch blockieren, so dass sich hier durchaus komplexe Szenarien für die Verteilung von Berechtigungen ergeben können (siehe auch APP.2.2.A4 Schulung zur Active Directory-Verwaltung).

Aus Sicherheitssicht ergeben sich folgende Aspekte, die bei der Planung der Active Directory-Administration zu berücksichtigen sind:

  • Wird Delegation eingesetzt, so sollten nur die unbedingt notwendigen Rechte vergeben werden, die zur Ausübung der delegierten administrativen Tätigkeiten erforderlich sind.
  • Das Delegationsmodell und die daraus resultierenden Rechtezuordnungen müssen dokumentiert werden.
  • Die administrativen Tätigkeiten sollten so delegiert werden, dass sich möglichst keine Überschneidungen ergeben. Ansonsten können durch zwei Administratoren sich widersprechende Veränderungen durchgeführt werden. Dies führt dann zu Replikationskonflikten, die von Windows-Server automatisch aufgelöst werden, sodass sich eine der Änderungen auf jeden Fall durchsetzt. Es gibt jedoch für diesen Fall keine Warnungen. Es empfiehlt sich daher, das Administrationsmodell so zu entwerfen, dass möglichst überschneidungsfreie Zuständigkeiten existieren. Auf diese Weise kann die Gefahr von Replikationskonflikten verringert werden. Sind Replikationskonflikte zu erwarten oder bereits aufgetreten, so sollte in regelmäßigen Abständen oder nach wichtigen Änderungen eine manuelle Überprüfung erfolgen, ob sich immer die korrekten Werte durchgesetzt haben. Ob das Führen einer Evidenzdatenbank mit den Active-Directory-Soll-Daten unter Umständen organisatorisch sinnvoll ist, muss im Einzelfall entschieden werden.
  • Wird die Verwaltung des Active Directory delegiert, so wird dies durch die Vergabe von entsprechenden Zugriffsrechten innerhalb des Active Directory erreicht. Dabei wird in der Regel der Vererbungsmechanismus eingesetzt, um Berechtigungen auf Objekte in Teilbäumen zu verwalten. Komplexe Szenarien mit Delegation und damit Rechtevererbung sollten jedoch unbedingt vermieden werden, da sonst leicht Sicherheitslücken entstehen können. Beispielsweise kann der Fall eintreten, dass ein Benutzer zu wenig oder zu viele Rechte hat.
  • Es muss ein Konzept für die Mitgliedschaft in den verschiedenen administrativen Gruppen entworfen werden. Dabei sind vor allem die Bedingungen und Verfahren zu definieren, die festlegen, ob, wann und wie lange ein Benutzer oder eine Benutzergruppe in eine administrative Gruppe aufgenommen wird. Es muss insbesondere dafür Sorge getragen werden, die Mitgliedschaft in der Gruppe der Organisations-Admins restriktiv zu handhaben und zu kontrollieren. Falls es der organisatorische Ablauf zulässt, kann erwogen werden, alle Mitglieder in dieser Gruppe nach Aufbau der Domänenstruktur zu entfernen und nur bei Bedarf und unter Einhaltung des Vier-Augen-Prinzips entsprechende Mitglieder hinzuzufügen. Es muss jedoch berücksichtigt werden, dass ein Mitglied der Gruppe der Organisations-Admins immer dann benötigt wird, wenn eine neue Domäne im Forest angelegt werden soll.
  • Die Administratoren sind über die Active Directory-Struktur und die organisatorischen Abläufe im Rahmen ihrer administrativen Tätigkeit zu informieren und entsprechend zu schulen, um zu verhindern, dass nicht-konforme Änderungen zu Sicherheitslücken führen. Beispielsweise kann es erforderlich sein, beim Anlegen eines neuen Benutzers diesen in entsprechende Sicherheitsgruppen aufzunehmen oder sogar zusätzlich eine neue Sicherheitsgruppe mit einem speziellen Namen anzulegen. Wird dies vergessen, so erhalten Benutzer unter Umständen fehlerhafte Berechtigungen.
  • Für große Domänen sollte darüber nachgedacht werden, deren Verwaltung mit geeigneten Werkzeugen zu unterstützen. Es gibt verschiedene kommerzielle und auch frei verfügbare Werkzeuge, die die Active Directory-Verwaltung erleichtern. Es sollte überlegt werden, diese einzusetzen. Werden solche Werkzeuge verwendet, so muss sichergestellt werden, dass die Active Directory-Verwaltung ausschließlich über diese Werkzeuge erfolgt.

Rollenbasiertes Berechtigungskonzept

Es sollte ein rollenbasiertes Berechtigungskonzept implementiert werden, das eine granulare Kontrolle über die einzelnen Berechtigungen eines jeden Accounts gewährt.

Sämtliche Berechtigungen sollten rollenbasiert vergeben werden. In der Praxis bedeutet dies, dass Sicherheitsgruppen erstellt werden, an die Berechtigungen geknüpft sind. Anschließend werden Gruppen erstellt, die Rollen repräsentieren und mit den notwendigen zuvor erstellen Sicherheitsgruppen verknüpft werden. Schließlich werden Benutzerkonten der Gruppen zugewiesen, die Ihrer Rolle entsprechen. Über ein Enterprise Identity Management-Lösung kann zudem insbesondere in großen Institutionen sichergestellt werden, dass die Rechte aller Anwender definierten Vorgaben entsprechen.

Trennung der Verwaltung von Diensten und Daten eines Active Directory

Die administrativen Tätigkeiten für Windows-Server-Betriebssysteme können grundsätzlich in die zwei Rollen "Diensteverwaltung" und "Datenverwaltung" mit unterschiedlichen Verantwortungsbereichen unterteilt werden.

Unter der "Diensteverwaltung" wird die Betreuung des Active-Directory-Dienstes selbst verstanden. Diensteadministratoren verwalten die Domänencontroller, z. B. Einspielen von Updates auf Betriebssystemebene, und die Konfiguration des Active Directory, beispielsweise verzeichnisweite Einstellungen, wie Vertrauensstellungen oder Replikationsarchitektur.

Die Verwaltung der Daten im Active Directory bzw. auf den Mitgliedsrechnern der Active-Directory-Gesamtstruktur sollte von den Datenadministratoren durchgeführt werden. Dabei sollten die Datenadministratoren keine Veränderungen am Active-Directory-Dienst selbst, z. B. Änderungen an der Verzeichnisdienst-Replikation, durchführen dürfen. Mittels Zugriffskontrolllisten (Access Control Lists, ACLs) sollten die Berechtigungen soweit möglich auf einzelne Teilbereiche eingeschränkt werden.

Da Dienste-Administratoren für die Diensteverwaltung weitreichende Berechtigungen benötigen, sollten sie grundsätzlich auch administrative Tätigkeiten in Bezug auf die Datenverwaltung durchführen können. Umgekehrt sollten die Datenadministratoren jedoch nicht in der Lage sein, die Konfiguration des Active Directory zu ändern.

Um Missbrauch der administrativen Konten vorzubeugen, müssen die Benutzerkonten der oben genannten Rollen entsprechend abgesichert werden. Die hierzu erforderlichen Konfigurationen am Active Directory selbst sind in der Maßnahme APP.2.2.A7 Umsetzung sicherer Verwaltungsmethoden für Active Directory aufgeführt.

APP.2.2.M3 Planung der Gruppenrichtlinien unter Windows

Seit Windows 2000 steht zur Konfiguration ein leistungsfähiger Mechanismus der so genannten Gruppenrichtlinien zur Verfügung. Gruppenrichtlinien dienen im Active Directory dazu, einen Satz von Konfigurationseinstellungen, zu denen insbesondere auch Sicherheitseinstellungen gehören, auf eine Gruppe von Objekten anzuwenden. Durch ein so genanntes Gruppenrichtlinienobjekt (englisch Group Policy Object, GPO) wird ein vorgegebener Satz von Konfigurationsparametern zusammengefasst. Für jeden Parameter kann ein konkreter Wert angegeben werden, der unter Umständen nur aus einem beschränkten Wertebereich stammt. Generell kann der Wert auch auf "nicht definiert" gesetzt werden, sodass dann automatisch die Windows-Standardeinstellungen für diese Parameter gelten.

Die Parameter innerhalb eines Gruppenrichtlinienobjektes sind baumartig thematisch zusammengefasst. Dabei ergibt sich eine generelle Zweiteilung auf oberster Ebene in Einstellungen für Rechner sowie für Benutzer. Aus Sicherheitssicht sind insbesondere die Einstellungen interessant, die sich unterhalb der folgenden Pfade finden:

  • Rechnereinstellungen\WindowsEinstellungen\Sicherheitseinstellungen
  • Rechnereinstellungen\Administrative Einstellungen\Windows Komponenten\Windows Installer
  • Rechnereinstellungen\Administrative Vorlagen\System\Gruppenrichtlinien
  • Benutzereinstellungen\Administrative Vorlagen\Windows Komponenten\Microsoft Management Konsole
  • Benutzereinstellungen\Administrative Einstellungen\Windows Komponenten\Windows Installer

Die aktuellen Windows-Server-Systeme berechnen generell für jeden an einer Domäne angemeldeten Rechner und für jeden angemeldeten Benutzer die jeweils gültigen Einstellungen für jeden Gruppenrichtlinienparameter. Diese Berechnung ist nötig, da die Vorgaben für die Parametereinstellungen durch unterschiedliche Gruppenrichtlinienobjekte definiert sein können, die sich gegenseitig überlagern können. Folgende Gruppenrichtlinienobjekte können definiert werden:

  • Jeder Rechner besitzt ein lokal definiertes Gruppenrichtlinienobjekt. Dies erlaubt die Definition von Parametereinstellungen lokal auf dem Rechner, z. B. wenn keine Netzverbindung besteht.
  • Gruppenrichtlinienobjekte können über Windows-Server-Standorte (Sites) definiert werden. Damit können Einstellungen standortspezifisch adaptiert werden.
  • Innerhalb der Active Directory-Struktur können Gruppenrichtlinienobjekte für das Domänenobjekt definiert werden, sodass damit Parametereinstellungen für Rechner und Benutzer innerhalb der gesamten Domäne gesteuert werden können.
  • Auf jedem OU-Objekt können Gruppenrichtlinien definiert werden, deren Einstellungen dann auf alle Rechner und Benutzer unterhalb dieses OU-Objektes wirken.

Für die Berechnung der jeweils für einen konkreten Rechner oder Benutzer geltenden Parametereinstellungen wird das folgende Berechnungs- bzw. Überdeckungsschema (Lokal <- Standort <- Domäne <- Organisationseinheit, LSDO) angewandt: Zunächst werden die lokalen Einstellungen berücksichtigt (L, Lokal). Dann werden diese Einstellungen durch die Einstellungen des Gruppenrichtlinienobjektes, das auf dem zugehörigen Standort definiert ist, überdeckt (S, Standort). Danach erfolgt die Überdeckung durch die auf dem relevanten Domänenobjekt definierten Gruppenrichtlinienobjekte (D, Domäne). Schließlich werden die Gruppenrichtlinienobjekte der OU-Objekte in der Reihenfolge angewandt, wie sie auf dem Weg vom Domänenobjekt zu dem OU-Objekt, das den jeweiligen Rechner oder Benutzer enthält, definiert sind (O, Organisationseinheit).

Die Überdeckung kann durch die Optionen blockieren bzw. erzwingen beeinflusst werden. Stehen die Einstellungen blockieren und erzwingen im Konflikt, so wird die Einstellung erzwingen durchgesetzt. Zusätzlich ist es auf OU-Ebene möglich, mehrere Gruppenrichtlinienobjekte für ein OU-Objekt zu definieren. Dabei erfolgt die Überdeckung gemäß der angegebenen Reihenfolge. Es ist dabei außerdem möglich, jedes einzelne Gruppenrichtlinienobjekt für ein OU-Objekt zu aktivieren oder zu deaktivieren.

Gruppenrichtlinienobjekte können im Active Directory nur auf OU-Objekten definiert werden, nicht jedoch auf einzelnen Rechnern oder Benutzerobjekten. Das lokal definierte Gruppenrichtlinienobjekt wird nicht im Active Directory gespeichert. Soll ein Gruppenrichtlinienobjekt, das auf einem OU-Objekt definiert ist, das Rechnerobjekte zusammenfasst, nicht auf alle enthaltenen Rechnerobjekte wirken, so besteht die Möglichkeit, durch die Vergabe von Zugriffsrechten auf das Gruppenrichtlinienobjekt die Anwendung auf ein konkretes Rechnerobjekt zu unterbinden. Hierzu ist diesem Rechnerobjekt das Zugriffsrecht Anwenden auf das Gruppenrichtlinienobjekt zu entziehen.

Die bisher benutzte Darstellung der Definition von Gruppenrichtlinienobjekten auf OU-Objekten war jedoch vereinfacht: Gruppenrichtlinienobjekte werden separat im Active Directory gespeichert und bilden einen Pool von Objekten. Jedes definierte Gruppenrichtlinienobjekt kann nun einem oder auch mehreren OU-Objekten assoziiert werden. Man spricht dann von einem Link. Durch das Kennzeichnen eines Links als aktiviert oder deaktiviert wird das jeweilige Gruppenrichtlinienobjekt bei der Berechnung für das OU-Objekt herangezogen oder nicht (siehe oben). Für jedes Gruppenrichtlinienobjekt kann über den Eigenschaftsdialog festgestellt werden, mit welchen OU-Objekten ein Link besteht, d. h. auf welche Objekte sie potentiell wirken.

Aus Sicherheitssicht sind bei der Planung und im Umgang mit Gruppenrichtlinienobjekten folgende Aspekte zu berücksichtigen:

  • Das Gruppenrichtlinienkonzept muss so einfach wie möglich gehalten werden. Komplexe Strukturen aus Mehrfachüberdeckungen sind zu vermeiden. Insbesondere sollte auf die Möglichkeit der Vergabe von Zugriffsrechten auf Gruppenrichtlinienobjekte nur in Ausnahmefällen zurückgegriffen werden. Generell muss das Gruppenrichtlinienkonzept so dokumentiert sein, dass Ausnahmeregelungen einfach zu erkennen sind.
  • Das Gruppenrichtlinienkonzept und die OU-Objektstruktur beeinflussen sich gegenseitig wesentlich, da Gruppenrichtlinienobjekte im Active Directory nur auf OU-Objekte angewandt werden können und nicht auf Rechner- oder Benutzerobjekte. Beim Aufbau der OU-Gruppierungen ist daher darauf zu achten, dass nur Objekte, die mit gleichen GPO-Einstellungen versehen werden sollen, in einem OU-Objekt oder untergeordneten OU-Objekten zusammengefasst werden.
  • Durch die Rechteberechnung ist es möglich, die Verwaltung der Parametereinstellungen auf unterschiedliche "Orte" (Lokal, Standort, Domänen-Objekt, OU-Objekte) zu verteilen. Es muss daher für jeden Parameter entschieden werden, wo er definiert wird. Es ist dabei zu beachten, dass einige Parameter nur dann wirksam werden, wenn sie an bestimmten "Orten" definiert werden. So konnten z. B. die Passworteinstellungen ursprünglich nur auf Domänen-Objekten definiert werden. Mit Windows Server 2008 wurden feingranulare Passwortrichtlinien eingeführt, die es ermöglichen, verschiedene Passwortricht- und Sperrrichtlinien für unterschiedliche Nutzergruppen innerhalb einer Domäne zu definieren
  • Gruppenrichtlinienobjekte müssen vor unberechtigter Veränderung geschützt werden. Dazu müssen einerseits entsprechende Berechtigungen im Active Directory vergeben werden (siehe auch Planung der Active Directory-Administration , Schulung zur Active Directory-Verwaltung) und andererseits kann der Gebrauch von entsprechenden Verwaltungswerkzeugen, wie z. B. MMC-Gruppenrichtlinien-Snap-In oder Registrierungseditoren, für Benutzer unterbunden werden.
  • Insbesondere für die sicherheitsrelevanten Parameter innerhalb eines Gruppenrichtlinienobjektes sind die Einstellungen festzulegen. Neben den oben angegebenen Einstellungen können je nach Anwendungsszenario auch weitere Parameter sicherheitsrelevant sein. Dazu zählen z. B. Internet-Explorer-Einstellungen.

Die Einstellungen der verschiedenen Gruppenrichtlinienobjekte müssen sich dabei generell an den Sicherheitsrichtlinien des Unternehmens bzw. der Behörde orientieren und diese umsetzen.

Sicherheitseinstellungen für Gruppenrichtlinien

Im Folgenden werden Vorgaben für die Sicherheitseinstellungen aufgezeigt, die als Ausgangsbasis für die Sicherheitseinstellungen innerhalb einer Gruppenrichtlinie dienen können. Die angegebenen Werte müssen auf jeden Fall an die lokalen Bedingungen angepasst werden. Im Rahmen des Gruppenrichtlinienkonzeptes sind die einzelnen Werte zudem auf unterschiedliche Gruppenrichtlinienobjekte zu verteilen und jeweils an den Verwendungszweck anzupassen (z. B. Group Policy Objects für Server, Group Policy Objects für Arbeitsplatzrechner). Dadurch können für einzelne Einträge auch jeweils unterschiedliche Werte zustande kommen.

Kennwortrichtlinie

  • Kennwortchronik erzwingen: 6 Gespeicherte Kennwörter
  • Kennwörter müssen den Komplexitätsanforderungen entsprechen: Aktiviert
  • Kennwörtern für alle Domänenbenutzer mit umkehrbarer Verschlüsselung speichern: Deaktiviert
  • Maximales Kennwortalter: 90 Tage
  • Minimale Kennwortlänge: 6 Zeichen
  • Minimales Kennwortalter: 1 Tag

Kontosperrungsrichtlinien

  • Kontensperrungsschwelle: 3 Ungültige Anmeldeversuche
  • Kontosperrdauer: 0 (Hinweis: Konto ist gesperrt, bis Administrator Sperrung aufhebt)
  • Kontosperrungszähler zurücksetzen nach: 30 Minuten

Kerberos-Richtlinie

  • Benutzeranmeldeeinschränkungen erzwingen: Aktiviert
  • Max. Gültigkeitsdauer des Benutzertickets: 8 Stunden
  • Max. Gültigkeitsdauer des Diensttickets: 60 Minuten
  • Max. Toleranz für die Synchronisation des Computertakts: 5 Minuten
  • Max. Zeitraum, in dem ein Benutzerticket erneuert werden kann: 1 Tag

Überwachungsrichtlinie

  • Active Directory-Zugriff überwachen: Erfolgreich, Fehlgeschlagen
  • Anmeldeereignisse überwachen: Erfolgreich, Fehlgeschlagen
  • Anmeldeversuche überwachen: Erfolgreich, Fehlgeschlagen
    Kontenverwaltung überwachen: Erfolgreich, Fehlgeschlagen
  • Objektzugriffsversuche überwachen: Fehlgeschlagen
  • Prozessverfolgung überwachen: Keine Überwachung
  • Rechteverwendung überwachen: Fehlgeschlagen
  • Richtlinienänderungen überwachen: Erfolgreich, Fehlgeschlagen
  • Systemereignisse überwachen: Erfolgreich, Fehlgeschlagen

Zuweisen von Benutzerrechten

  • Als Dienst anmelden: Definiert, aber leer
  • Ändern der Systemzeit: Administratoren
  • Anheben der Zeitplanungspriorität: Administratoren
  • Anheben von Quoten: Administratoren
  • Anmelden als Stapelverarbeitungsauftrag: Definiert, aber leer
  • Anmeldung als Batchauftrag verweigern: Nicht definiert
  • Anmeldung als Dienst verweigern: Nicht definiert
  • Auf diesen Computer vom Netzwerk aus zugreifen: Jeder, Administratoren, Authentisierte Benutzer, Sicherungs-Operatoren
  • Auslassen der durchsuchenden Überprüfung: Jeder
  • Debuggen von Programmen: Nicht definiert
  • Einsetzen als Teil des Betriebssystems: Definiert, aber leer
  • Entfernen des Computers von der Dockingstation: Administratoren
  • Ermöglichen, dass Computer- und Benutzerkonten für Delegierungszwecke vertraut wird: Administratoren
  • Ersetzen eines Tokens auf Prozessebene: Definiert, aber leer
  • Erstellen einer Auslagerungsdatei: Administratoren
  • Erstellen eines Profils der Systemleistung Administratoren
  • Erstellen eines Profils für einen Einzelprozess: Administratoren
  • Erstellen eines Tokenobjekts: Definiert, aber leer
  • Erstellen von dauerhaft freigegebenen Objekten: Definiert, aber leer
  • Erzwingen des Herunterfahrens von einem Remotesystem aus: Administratoren
  • Generieren von Sicherheitsüberwachungen: Definiert, aber leer
  • Herunterfahren des Systems: Administratoren
  • Hinzufügen von Arbeitsstationen zur Domäne: Definiert, aber leer
  • Laden und Entfernen von Gerätetreibern: Administratoren
  • Lokal anmelden: Administratoren, Sicherungs-Operatoren
  • Lokale Anmeldung verweigern: Nicht definiert
  • Sichern von Dateien und Verzeichnissen: Sicherungs-Operatoren
  • Sperren von Seiten im Speicher: Definiert aber leer
  • Synchronisieren von Verzeichnisdienstdaten: Definiert, aber leer
  • Übernehmen des Besitzes von Dateien und Objekten: Administratoren
  • Verändern der Firmwareumgebungsvariablen: Administratoren
  • Verwalten von Überwachungs- und Sicherheitsprotokollen: Administratoren
  • Wiederherstellen von Dateien und Verzeichnissen: Administratoren
  • Zugriff vom Netzwerk auf diesen Computer verweigern: Nicht definiert

Sicherheitsoptionen

  • Administrator umbenennen: Nicht definiert
  • Anwender vor Ablauf des Kennworts zum Ändern des Kennworts auffordern: 7 Tage
  • Anwendern das Installieren von Druckertreibern nicht erlauben: Aktiviert
  • Anzahl zwischenzuspeichernder vorheriger Anmeldungen (für den Fall, dass der Domänencontroller nicht verfügbar ist): 0 Anmeldungen
  • Auslagerungsdatei des virtuellen Arbeitsspeichers beim Herunterfahren des Systems löschen: Aktiviert
  • Auswerfen von NTFS-Wechselmedien zulassen: Administratoren
  • Benutzer automatisch abmelden, wenn die Anmeldezeit überschritten wird (lokal): Aktiviert
  • Benutzer nach Ablauf der Anmeldezeit automatisch abmelden: Aktiviert
  • Clientkommunikation digital signieren (immer): Deaktiviert
  • Clientkommunikation digital signieren (wenn möglich): Aktiviert
  • Die Verwendung des Sicherungs- und Wiederherstellungsrechts überprüfen: Deaktiviert
  • Gastkonto umbenennen: Nicht definiert
  • Herunterfahren des Systems ohne Anmeldung zulassen: Deaktiviert
  • LAN Manager-Authentisierungsebene: Nur NTLMv2-Antworten senden\LM verweigern
  • Leerlaufzeitspanne bis zur Trennung der Sitzung: 15 Minuten
  • Letzten Benutzernamen nicht im Anmeldedialog anzeigen: Aktiviert
  • Nachricht für Benutzer, die sich anmelden wollen: Nicht definiert
  • Nachrichtentitel für Benutzer, die sich anmelden wollen: Nicht definiert
  • Serverkommunikation digital signieren (immer): Deaktiviert
  • Serverkommunikation digital signieren (wenn möglich): Aktiviert
  • Serveroperatoren das Einrichten von geplanten Tasks erlauben (Nur für Domänencontroller): Nicht definiert
  • Sicherer Kanal: Daten des sicheren Kanals digital signieren (wenn möglich): Aktiviert
  • Sicherer Kanal: Daten des sicheren Kanals digital verschlüsseln (wenn möglich): Aktiviert
  • Sicherer Kanal: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer): Aktiviert(Hinweis: Es sei denn, veraltete Systeme sind damit nicht kompatibel.)
  • Sicherer Kanal: Starker Sitzungsschlüssel erforderlich: Aktiviert(Hinweis: Es sei denn, veraltete Systeme sind damit nicht kompatibel.)
  • Standardberechtigungen globaler Systemobjekte (z. B. symbolischer Verknüpfungen) verstärken: Aktiviert
  • STRG+ALT+ENTF-Anforderung zur Anmeldung deaktivieren: Deaktiviert
    (Hinweis: D. h. STRG+ALT+ENTF ist erforderlich)
  • System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können: Deaktiviert
  • Systemwartung des Computerkontokennworts nicht gestatten: Deaktiviert
  • Unverschlüsseltes Kennwort senden, um Verbindung mit SMB-Servern von Drittanbietern herzustellen: Deaktiviert
  • Verhalten bei der Installation von nicht signierten Dateien (außer Treibern): Warnen, aber Installation zulassen
  • Verhalten bei der Installation von nicht signierten Treibern: Warnen, aber Installation zulassen
  • Verhalten beim Entfernen von Smartcards: Computer sperren
  • Weitere Einschränkungen für anonyme Verbindungen: Kein Zugriff ohne explizite anonyme Berechtigung
  • Wiederherstellungskonsole: Automatische administrative Anmeldungen zulassen: Deaktiviert
  • Wiederherstellungskonsole: Kopieren von Disketten und Zugriff auf alle Laufwerke und alle Ordner zulassen: Deaktiviert
  • Zugriff auf CD-ROM-Laufwerke auf lokal angemeldete Benutzer beschränken: Aktiviert
  • Zugriff auf Diskettenlaufwerke auf lokal angemeldete Benutzer beschränken: Aktiviert
  • Zugriff auf globale Systemobjekte prüfen: Deaktiviert

Ereignisprotokoll

  • Anwendungsprotokoll aufbewahren für: Nicht definiert
  • Aufbewahrungsmethode des Anwendungsprotokolls: Ereignisse bei Bedarf überschreiben
  • Aufbewahrungsmethode des Sicherheitsprotokolls: Ereignisse bei Bedarf überschreiben
    (Hinweis: Im Hochsicherheitsbereich ist folgende Einstellung zu wählen: Ereignisse nicht überschreiben (Protokoll manuell aufräumen).)
  • Aufbewahrungsmethode des Systemprotokolls: Ereignisse bei Bedarf überschreiben
  • Gastkontozugriff auf Anwendungsprotokoll einschränken: Aktiviert
  • Gastkontozugriff auf Sicherheitsprotokoll einschränken: Aktiviert
  • Gastkontozugriff auf Systemprotokoll einschränken: Aktiviert
  • Maximale Größe des Anwendungsprotokolls: 30080 Kilobytes
  • Maximale Größe des Sicherheitsprotokolls: 100992 Kilobytes
  • Maximale Größe des Systemprotokolls: 30080 Kilobytes
  • Sicherheitsprotokoll aufbewahren für: Nicht definiert
  • System bei Erreichen der max. Sicherheitsprotokollgröße herunterfahren: Deaktiviert
    (Hinweis: Für Hochsicherheitssysteme aktivieren)
  • Systemprotokoll aufbewahren für: Nicht definiert

Security Compliance Manager (SCM)

Gruppenrichtlinien gehören zu den wichtigsten Werkzeugen in Windows-Umgebungen, um eine angemessene Absicherung der Systeme erzielen zu können. Das manuelle Setzen von hunderten von Einstellungen auf sichere, dem Verwendungszweck in der Institution angemessene Werte kann jedoch einen sehr hohen Aufwand darstellen.

Ein Werkzeug, das die Verwaltung von Gruppenrichtlinienobjekten unter Windows Client- und Serversysteme erleichtert, ist der Security Compliance Manager (SCM) von Microsoft. Dieser soll dabei unterstützen, von Microsoft und Drittanbietern empfohlene Sicherheitsrichtlinien institutionsweit durchzusetzen. Er gehört zur Gruppe der von Microsoft frei zum Download angebotenen "Solution Accelerators", die Aufgaben rund um die Planung und das Deployment von Systemumgebungen und Anwendungen unterstützen.

Der SCM stellt bereits nach der Installation eine Vielzahl von aktuellen Baselines für Windows-Betriebssysteme und -Anwendungen bereit, die entsprechend den Sicherheits- und Compliance-Anforderungen einer Institution angepasst und erweitert werden können. Bei einer Baseline handelt es sich um eine Sammlung relevanter Sicherheits- und Konfigurationseinstellungen (engl. Configuration Items), die letztendlich zur Gesamtsicherheit des jeweiligen Systems beitragen sollen.

Die Auswahl an Baselines beschränkt sich nicht auf einzelne Produkte und Versionen, sondern ist zudem nach Anwendungsrollen und Sicherheitsanforderungen unterteilt. So gibt es eigene Vorlagen für File- und Web-Server, Hyper-V, Domänen-Controller oder die Remote Desktop Services sowie die verschiedenen Versionen des Windows-Client-Betriebssystems und von Anwendungssoftware wie Internet Explorer, Microsoft Office, SQL Server oder Exchange Server.

In Version 4 des SCM werden neben Windows 8/8.1 und Windows Server 2012 (R2) mittlerweile auch Windows 10 und Windows Server 2016 unterstützt.

Die wichtigsten Funktionen des Security Compliance Managers sind im Folgenden dargestellt:

  • Absicherung von Microsoft-Produkten (Windows Server, Windows Client, Office, Exchange Server, SQL Server, Internet Explorer)
  • Zentrale Speicherung und Verwaltung von Baselines
  • Möglichkeit der Nutzung von Baselines auf Stand-Alone- und Domänensystemen
  • Vergleich und Zusammenführung (Merge) von Baselines
  • Verschiedene Import- und Exportmöglichkeit
  • Ausführliche integrierte Hilfe und Beschreibung der einzelnen Einstellmöglichkeiten

Beispielsweise werden für Windows Server 2012 R2 folgende Baselines mitgeliefert:

  • Domain Controller Security Compliance (Version 1.0: 620 Einstellungen)
  • Domain Security Compliance (Version 1.0: 9 Einstellungen)
  • Member Server Security Compliance (Version 1.0: 421 Einstellungen)

Für Windows Server 2016 sieht dies folgendermaßen aus:

  • Domain Controller Security Compliance (Version 1.0: 1013 Einstellungen)
  • Domain Security Compliance (Version 1.0: 9 Einstellungen)
  • Member Server Security Compliance (Version 1.0: 1011 Einstellungen)

Die Einstellungen dürfen nicht einfach übernommen werden, sondern müssen jeweils überprüft werden auf Kompatibilität mit den Sicherheitsanforderungen und speziellen Gegebenheiten der Institution. Dies gilt auch für Einstellungen, die auf "undefiniert" gesetzt sind. Vor einem Ausrollen auf produktive Systems sollten die Einstellungen getestet werden.

Feingranulare Passwortrichtlinien

Mit Windows Server 2008 wurden feingranulare Passwortrichtlinien eingeführt, die es ermöglichen, verschiedene Passwortricht- und Sperrrichtlinien für unterschiedliche Nutzergruppen innerhalb einer Domäne zu definieren.

In einer feingranularen Passwortrichtlinie können mit Ausnahme der domänenglobalen Kerberos-Einstellungen alle Passworteinstellungen inkl. der Sperrparameter gesetzt werden. Alle diese Parameter müssen beim Einsatz einer feingranularen Passwortrichtlinie definiert werden. Standardmäßig können nur Mitglieder der Gruppe Domänenadministratoren feingranulare Passwortrichtlinien einrichten. Jedoch lässt sich dieses Recht auch an andere Nutzer delegieren.

Feingranulare Passwortrichtlinien sollten eingesetzt werden, um innerhalb einer Institution überall angemessene Kennwortstärken durchzusetzen.

Shadow Groups

Feingranulare Passwortrichtlinien und einige weitere Parameter können nicht direkt auf OUs angewandt werden. Um eine feingranulare Passwortrichtlinie auf alle Nutzer einer bestimmten OU anzuwenden, können sogenannte Shadow Groups verwendet werden. Eine Shadow Group ist eine globale Sicherheitsgruppe, die logisch einer OU zugewiesen wird. Die Nutzer werden der Shadow Group zugewiesen, und die Passwortrichtlinie auf die Shadow Group angewandt. Zu beachten ist, dass beim Bewegen eines Nutzers in eine andere OU die Mitgliedschaft in den Shadow Groups anzupassen ist.

Keine Verwaltung von Passwörtern per GPO

Grundsätzlich lassen sich lokale Konten per GPO verwalten. Dies gilt etwa für das Anlegen lokaler (auch administrativer) Accounts, das Setzen von Passwörter, die Erstellung von Diensten mit Dienstkonten etc. Das Problem dabei ist, dass die Credentials in diesem Fall in XML-Dateien auf dem SYSVOL-Share auf allen Domänencontrollern der Domäne gespeichert sind und relativ einfach ausgelesen bzw. reversed werden können.

GPOs sollten nicht für das Setzen von Passwörtern verwendet werden. Liegen bereits Passwörter in GPOs vor, so sollten die Richtlinien entfernt und die entsprechenden Dateien gelöscht werden. Gleiches gilt für Skripte (z. B. VBS oder PowerShell), die Passwörter enthalten. Microsoft bietet ein PowerShell-Skript an, das SYSVOL nach Passwörtern in GPO XML-Dateien durchsucht.

APP.2.2.M4 Schulung zur Active Directory-Verwaltung

Das Active Directory ist die zentrale Datenbank der Serverbetriebssysteme ab Windows Server 2000, in der Benutzerdaten, Gruppenzugehörigkeiten und andere Verwaltungsdaten abgelegt werden. Clients können im Active Directory seit der Version Windows 2000 verwaltet werden.

Für die Administration eines Windows-Netzes werden detaillierte Kenntnisse des Active Directory und seiner grundlegenden Konzepte benötigt. Ansonsten kann es leicht zu Fehlkonfigurationen kommen, die erhebliche sicherheitstechnische Auswirkungen haben können. Eine Schulung der Administratoren auf diesem Gebiet und insbesondere zu Active Directory Sicherheitsthemen ist daher unerlässlich.

Schulungsinhalte

Je nach Größe und Komplexität des Netzes wird ein Active Directory nicht von einem einzelnen Administrator, sondern von einer ganzen Reihe von Administratoren mit speziellen Aufgaben und Tätigkeitsbereichen durchgeführt. Insoweit besteht auch nicht für alle Administratoren eines Active Directories der gleiche Schulungsbedarf. Zur Gewährleistung eines sicheren Betriebes muss jedoch jeder Administrator über ein hinreichendes Grundwissen verfügen, um seine eigenen Tätigkeiten in einen Gesamtkontext einordnen zu können.

Schulungsinhalte sollten in jedem Fall die folgenden Stichpunkte umfassen und diese erläutern. Wie tief ein Administrator sich mit den einzelnen Punkten beschäftigen muss, hängt von seinem späteren Tätigkeitsfeld ab.

Grundlagen

  • Überblick über die Sicherheitsmechanismen von Windows Server
  • Neuerungen in Sicherheitsmechanismen von aktuellen Windows-Client-Betriebssystemen (mit Berücksichtigung der von neuen Betriebssystemversionen oder aktuellen Service Packs hervorgerufenen Änderungen)
  • Sicherheitsverwaltung (MMC, Security Editor, GPMC)
  • Active Directory und DNS
  • Vertrauensbeziehungen zwischen Domänen
  • Notwendiger physikalischer Schutz aller Domänencontroller als Träger der Kerberos Daten

Active Directory

  • Allgemeines: Planung, Einrichtung, Administration
  • Schema-Verwaltung
  • Replikation
  • Backup
  • Rechtevergabe
  • Authentisierung
  • Gruppenrichtlinien

PKI (Public Key Infrastruktur)

  • Funktionsweise einer PKI
  • Zertifikate und Zertifikatstypen
  • Planung einer PKI
  • Einrichten einer PKI
  • Verwalten einer PKI
  • Benutzerinteraktion mit der PKI

IPsec

  • Funktionsweise von IPsec
  • Konfiguration von IPsec
  • Prüfung der erfolgreichen Einrichtung sicherer Verbindungen, Tools

DFS (Distributed File Service)

  • Funktionsweise des DFS
  • Administration des DFS
  • Planung der DFS-Struktur
  • Schutz der über DFS zugreifbaren Daten

Die einzelnen Active Directory Themen sollten dabei wie folgt detaillierter dargestellt werden:

Schema-Verwaltung

Im Normalfall ist eine installationsspezifische Veränderung des Active Directory-Schemas durch einen Administrator nicht notwendig. Die Schulung kann sich insofern auf die Problematik und Auswirkungen von Schema-Veränderungen beschränken.

Sollen individuelle Anpassungen des Schemas vorgenommen werden, sind weitergehende Schulungen zu Interna des Active Directory notwendig.

Replikation des Active Directory

  • Verwendete Mechanismen zur Replikation des Active Directory (RPC und SMTP)
  • Voreingestellte Parameter zur Replikation von Active Directory Inhalten
  • Problematik der dezentralen Administration des AD im Zusammenhang mit Replikationskonflikten

Backup

  • Problematik des Erstellens eines "Backups des Active Directory"
  • Wiedereinspielen von Backups eines Domänencontrollers
  • Zu ergreifenden Maßnahmen bei Ausfall von Domänencontrollern, die FSMO-Rollen innehaben

Rechtevergabe im Active Directory

  • Vergabe von Zugriffsrechten auf AD-Objekte auf Attributsebene
  • Vererbung von Zugriffsrechten und Blockade der Vererbung
  • Mögliche Zugriffsrechte
  • Delegation von administrativen Aufgaben auf der Ebene einzelner OUs

Authentisierung

  • Kerberos
  • PKI
  • Smartcards

Gruppenrichtlinien

  • Lokale Gruppenrichtlinien und im Active Directory gespeicherte Gruppenrichtlinien
  • Konfigurationsmöglichkeiten mit Hilfe von Gruppenrichtlinien
  • Wann werden Gruppenrichtlinien angewandt? Wie lässt sich dies konfigurieren?
  • Gruppenrichtlinienobjekte (GPOs) als Objekte im Active Directory
  • Gruppenrichtlinienobjekte können an Standorte / Domänen / OUs gebunden werden
  • Reihenfolge, in der Gruppenrichtlinien abgearbeitet werden
  • Möglichkeiten, die Anwendung von Gruppenrichtlinien zu kontrollieren

    • Vergabe von Zugriffsrechten auf Gruppenrichtlinien
    • No Override Eigenschaft der Bindung eines Gruppenrichtlinienobjektes an ein AD-Objekt
    • Block Policy Inheritance Eigenschaft von AD-Objekten

  • Möglichkeiten zur selektiven Anwendung der Gruppenrichtlinien:

    • Sicherheitsfilter
    • WMI Filters und deren Ungeeignetheit (Performance-Gründe)

  • Security Compliance Manager (SCM)

    • Bedienung
    • Enthaltene Baselines
    • Anpassung von Baselines
    • Anwendung lokal und per AD / SCCM

Einführung in Active Directory

Die folgenden Informationen stellen das Minimum dessen dar, was jedem Administrator als Einführung in AD und dessen Sicherheit bekannt und vertraut sein sollte. Dies kann weder eine gründliche Schulung noch die notwendige Arbeitserfahrung ersetzen, die auf anderem Wege zu erreichen und nachzuweisen ist.

In einer Domäne werden Rechner und Benutzer zusammengefasst und können durch den Domänenadministrator verwaltet werden. Eine Domänengrenze bildet grundsätzlich eine administrative Grenze, wenn auch keine Sicherheitsgrenze (siehe unten sowie Maßnahme APP.2.2.A5 Härtung des Active Directory) und begrenzt auch den Wirkungsbereich von Berechtigungen. Zusätzlich zu diesem Konzept bieten Windows Server an, Domänen baumartig miteinander in Beziehung zu setzen, sodass Eltern-Kind-Beziehungen zwischen Domänen bestehen können. Eine Kind-Domäne wird dabei auch als Sub-Domäne bezeichnet, da sich der Name der Kind-Domäne aus dem Namen der übergeordneten Domäne ableitet, indem diesem Namen der Name der Domäne durch einen Punkt getrennt angehängt wird.

Beispiel:

Name der Eltern-Domäne: unternehmen.de Name der Sub-/Kind-Domäne: verwaltung.unternehmen.de

Der so aufgespannte Namensraum ist mit dem zugehörigen DNS Namensraum identisch und kann auch nicht verschieden von diesem gebildet werden. Domänen, die einen gemeinsamen Namensstamm besitzen, bilden einen Baum (englisch Tree).

Domänen, die in mehreren Bäumen angesiedelt sind, also unterschiedliche Namensräume aufspannen, können dennoch gemeinsam verwaltet werden.

Derart zusammengeschlossene Domänenbäume bilden einen Wald (englisch Forest). Insbesondere bildet eine einzige alleinstehende Domäne auch einen Baum und gleichzeitig auch einen Wald.

In einem Wald gibt es immer eine ausgezeichnete Domäne, die eine gewisse Sonderstellung besitzt. Es ist die als erstes erzeugte Domäne, die auch als Forest-Root-Domäne (FRD, Wurzel-Domäne des Waldes) bezeichnet wird. Die Sonderstellung besteht darin, dass Administratoren der Forest-Root-Domäne im gesamten Forest weitreichende Berechtigungen besitzen. Für die Mitglieder der Gruppe Organisations-Admins stellen die Domänengrenzen keine administrativen Grenzen dar, da sie in allen Domänen Zugriffsrechte besitzen. Beim Aufbau eines Windows Domänenverbundes ist zu bedenken, dass die zuerst erzeugte Domäne immer die Forest-Root-Domäne ist. Insbesondere kann die "Rolle" der Forest-Root-Domäne nachträglich nicht auf eine andere Domäne "übertragen" werden, sodass die Domänenstruktur vollständig in der gewünschten Form neu erzeugt werden muss.

Das Active Directory besteht aus verschiedenen Objekten, den Active Directory Objekten (ADOs). Jedes Objekt besitzt einen ausgezeichneten Typ wie z. B. Benutzerobjekt oder Rechnerobjekt und ist gemäß dieses Typs aus verschiedenen Attributen zusammengesetzt. Die verschiedenen Objektattribute können verschiedene Werte aufnehmen wie z. B. Telefonnummer oder IP-Adresse. Das Active Directory kennt verschiedene vordefinierte Objekttypen:

  • Domänen-Objekt: Dieses Objekt ist die Wurzel aller Active Directory-Objekte einer Domäne und enthält Informationen über die Domäne wie z. B. den Namen. Unterhalb eines Domänen-Objektes können andere Objekte angeordnet sein.
  • Gruppierungs-Objekte: Diese Objekte dienen dazu, andere Objekte zu gruppieren. Standardmäßig steht das Objekt Organisations-Einheit (Organizational Unit, OU) zur Verfügung. Unterhalb eines OU-Objektes können weitere OU-Objekte enthalten sein sowie Rechner-, Benutzer- und Benutzer-Gruppen-Objekte.
  • Rechner-Objekt: Durch dieses Objekt werden Windows Client-Rechner repräsentiert. Unterhalb eines Rechner-Objektes können keine weiteren Objekte mehr angeordnet sein. Das Active Directory ist nur auf die Verwaltung von Windows Rechnern ausgelegt, sodass Rechner-Objekte ausschließlich Windows Rechner repräsentieren können, die mit dem Active Directory zusammenarbeiten. Dies sind standardmäßig Rechner mit den Betriebssystemen ab Windows NT.
  • Benutzer-Objekt: Durch dieses Objekt werden Domänenbenutzer repräsentiert. Unterhalb eines Benutzer-Objektes können keine weiteren Objekte mehr angeordnet sein.
  • Benutzer-Gruppen-Objekte: Durch diese so genannten Sicherheitgruppen werden Windows-Gruppen repräsentiert. Es gibt verschiedene Gruppentypen, die sich im Geltungsbereich (domänen-, forestweit) und in den möglichen Gruppenmitgliedern (Domänen-, Forest-Objekte) unterscheiden. Es wird unterschieden zwischen lokalen, domänenlokalen, globalen und universalen Gruppen. Sicherheitsgruppen werden dazu benutzt, Berechtigungen zu vergeben. In Windows Server ist für größere Institutionen mit einer hohen Anzahl von Gruppen zu rechnen (durchaus mehrere zehntausend), sodass u. U. über eine werkzeuggestützte Verwaltung nachgedacht werden muss. Diese kann sowohl über selbst geschriebene Skripte als auch über Produkte von Drittherstellern erfolgen. Ob und welche Werkzeuge hier sinnvoll sind, muss jedoch im Einzelfall entschieden werden.

Der generelle Active Directory-Aufbau lässt sich wie folgt darstellen:

  • Das Domänen-Objekt ist die Wurzel des Active Directory-Baumes einer Domäne.
  • Unter dem Domänen-Objekt werden OU-Objekte erzeugt, um Rechner-, Benutzer- und Benutzer-Gruppen-Objekte strukturiert zusammenzufassen. Da OU-Objekte geschachtelt werden können, ergibt sich eine institutionsspezifische Baumstruktur.

Nach einer Standardinstallation existiert eine einfache und flache Active Directory-Struktur, die von einem Windows Server angelegt wird und dann entsprechend der Active Directory-Planung verändert werden muss. Da das Active Directory primär der Verwaltung eines Windowssystems dient, sollte beim Aufbau der Active Directory-Struktur darauf geachtet werden, dass die Struktur vornehmlich auf administrative Gegebenheiten abgestimmt wird. Wenn stattdessen die organisatorische Struktur einer Institution bis ins Kleinste nachgebildet wird, kann dies zu Problemen in der Administration, mindestens jedoch zu hohem administrativen Aufwand führen.

Die möglichen Anordnungen von Active Directory-Objekten, d. h. die Festlegung, welches Objekt welche anderen Objekte enthalten darf, welche Attribute existieren und aus welchen Attributen Objekte zusammengesetzt werden, wird durch das so genannte Active Directory-Schema definiert. Das von Microsoft vorgegebene Active Directory-Schema kann auch verändert werden. Dies stellt jedoch einen gravierenden Eingriff in das Active Directory dar, der nur nach sorgfältiger Planung durchgeführt werden darf. Eine Schemaänderung wirkt sich in allen gemeinsam verwalteten Domänen, d. h. im Wald, aus. Da die Schemaänderung eine kritische Operation ist, kann diese nur an genau einem Rechner, dem sogenannten Schema-Master durch Mitglieder der Gruppe Schema-Admins durchgeführt werden. Schemaänderungen können zudem unter Umständen nicht mehr rückgängig gemacht werden. Die Mitgliedschaft in dieser Gruppe ist daher unbedingt restriktiv zu vergeben und streng zu kontrollieren.

Die Mitglieder der Gruppe "Organisations-Admins", zu der in der Voreinstellung der Administrator der Forest Root Domäne gehört, haben besondere Befugnisse in allen Domänen des Netzes. Sie können z. B. neue Domänen in den Forest aufnehmen und haben Administratorrechte auf allen Domänencontrollern des Active Directory.

Innerhalb einer einzelnen Domäne erfolgt die Administration durch Mitglieder der jeweiligen domänenspezifischen Gruppe "Domänen-Admins". Diese Gruppe verfügt innerhalb einer Domäne über unbeschränkte administrative Berechtigungen. Es ist jedoch möglich, einzelne administrative Aufgaben auch für andere Benutzerkonten zu ermöglichen und so administrative Aufgaben zu delegieren (siehe auch APP.2.2.A2 Planung der Active Directory-Administration).

Eine Delegation administrativer Aufgaben innerhalb einer Domäne kann auch so erfolgen, dass lediglich die Administration eines Teils der Benutzerkonten und Computer einer Domäne delegiert wird. Dies ist innerhalb der Grenzen der OUs möglich, die zur Gruppierung von Benutzer- bzw. Computerkonten innerhalb der Domäne dienen.

Eine Vielzahl von Windows-Client-Konfigurationsparametern ist in den Gruppenrichtlinien zusammengefasst. Neben den lokalen Gruppenrichtlinien auf jedem einzelnen Windows Client-Rechner gibt es auch Gruppenrichtlinien, die im Active Directory gespeichert sind. Dies gestattet es, Rechner oder Benutzerkonten zentral zu konfigurieren. Wirkungsbereich einer solchen, im AD gespeicherten Gruppenrichtlinie können unter anderem ganze Domänen oder OUs sein. Hier dienen OUs zur Gruppierung gleichartig konfigurierter Rechner oder Benutzerkonten. Da sich OUs schachteln lassen und mit einer einzelnen OU mehrere Gruppenrichtlinien verbunden sein können, wirken auf einen einzelnen Rechner unter Umständen viele verschiedene Gruppenrichtlinien ein (siehe auch APP.2.2.A3 Planung der Gruppenrichtlinien unter Windows und die entsprechenden Client-Bausteine).

Zur Speicherung der Daten wird eine relationale, transaktionsorientierte Datenbank verwendet. Diese Datenbank wird auf speziellen Servern, den "Domänencontrollern", verteilt. Der Domänencontroller nutzt dabei das Active Directory, um eine zentrale Authentisierung und Autorisierung von Benutzern und Computern in einer Domäne zur Verfügung zu stellen. Folgende Protokolle werden dazu verwendet:

  • LDAP (Lightweight Directory Access Protocol) zur Abfrage von Objekten und Attributen des Active Directory
  • Kerberos zur Authentisierung von Benutzern und Computern
  • CIFS (Common Internet File System) zum Transfer von Dateien im Rechnernetz
  • DNS (Domain Name System) zur Namensauflösung der Computersysteme im Netz

Mit einigen Ausnahmen enthält jeder Domänencontroller dabei nur die Daten seiner eigenen Domäne. Diese Ausnahmen sind:

  • Jeder Domänencontroller enthält die Schema- und Konfigurationsdaten des gesamten Forests.
  • Mindestens ein Domänencontroller jeder Domäne enthält zusätzlich noch den "Global Catalog".

Das Active Directory wird auf Domänencontrollern gehalten und innerhalb einer Domäne zwischen diesen durch Replikation synchronisiert. Das Active Directory einer Domäne enthält nur domänenbezogene Informationen. Um in einem Forest schnell auf Informationen aus dem gesamten Forest zugreifen zu können, wird der so genannte Global Catalog (GC) aufgebaut. Er besteht aus Teilinformationen von Active Directory-Objekten und wird im gesamten Forest repliziert, sodass über den Global Catalog in einer Domäne auch direkt auf Informationen aus anderen Domänen zugegriffen werden kann.

Neben der beschriebenen baumartigen und hierarchischen Struktur baut Windows Server automatisch eine zusätzliche und orthogonale Struktur auf. Räumlich nahe Rechner (dies bestimmt Windows Server über Netzlaufzeiten) werden zu so genannten Standorten (englisch Sites) zusammengefasst. Über Sites wird unter anderem auch die Replikationsstruktur von Domänen Controllern gesteuert. Je Site muss mindestens ein Rechner existieren, der eine Kopie des Global Catalogs hält. Der Global Catalog muss im Rahmen des Anmeldeprozesses eines Benutzers angefragt werden, sodass bei der Anmeldung immer ein Global Catalog-Server zugreifbar sein muss. Die von Windows Server automatisch aufgebaute Standortstruktur sollte an die institutionsinternen Gegebenheiten wie z. B. Standorte in verschiedenen Städten oder Ländern individuell angepasst werden. Da dies Einfluss auf die Active Directory-Replikationsbeziehungen hat, ist dazu ein Konzept zu erstellen.

Die Daten des Active Directory werden mittels Multi-Master-Replikation zwischen den Domänencontrollern einer Institution repliziert. Auf jedem Domänencontroller existiert somit ein Replikat des Active Directory, das geändert und als Grundlage für zukünftige Replizierungen dienen kann. Bei der Verwendung mehrerer Domänencontroller in einer Institution werden so redundante Kopien des Active Directory erzeugt und die Wahrscheinlichkeit eines Totalausfalls minimiert.

Der Abgleich der Daten zwischen den einzelnen Domänencontrollern kann über zwei verschiedene Replikationsmechanismen erfolgen (RPC oder asynchrones SMTP). Welcher Mechanismus verwendet wird, lässt sich ebenso konfigurieren wie die Zeitabstände, in denen die Replikation erfolgt.

Durch das Konzept der verteilten Datenbanken kann eine gewisse Ausfallsicherheit des Active Directory erreicht werden, indem eine genügende Anzahl geeignet verteilter DCs betrieben wird. Problematisch sind dabei jedoch die Inhaber der FSMO-Rollen.

FSMO bzw. Operations Master

Operations Master bzw. FSMO (Flexible/Floating Single Master Operations), wie es offiziell bis 2005 hieß (der Name ist trotzdem weiterhin in Gebrauch), ist ein Feature von AD. Der FSMO ist eine bestimmte Menge von Aufgaben eines Domaincontrollers, die nicht wie normale DC-Aufgaben verteilt auf mehreren DCs bearbeitet werden können, die über Kopien der AD-Datenbank verfügen und sich über Multi-Master-Replikation synchronisieren. FSMO-Aufgaben hingegen lassen sich nur in einer einzigen Datenbank ausführen, die Master-Datenbank genannt wird.

Es gibt verschiedene FSMO-Rollen, darunter auf Domänenebene

  • PDC (Primärer Domänencontroller)-Emulator: unter anderem für die Zeitsynchronisation verantwortlich
  • RID-(Relative ID-)Master: zur konsistenten ID-Vergabe
  • Infrastruktur-Master: für die Konsistenz domänenübergreifender Links

und auf Waldebene

  • Schema-Master: um Schemaänderungen zu replizieren (etwa beim Upgrade von DCs oder dem Deployment von Exchange Server oder Skype for Business (vormals Lync) Server
  • Domain-Naming-Master: zur Verteilung von Änderungen an Namensräumen

Aufgrund der hohen Wichtigkeit von DCs, die FSMO-Rollen innehaben, sind diese besonders zu schützen.

APP.2.2.M5 Härtung des Active Directory

Da die Absicherung der Infrastrukturkomponenten, welche die Funktionen des AD abbilden, wesentlich für die Sicherheit der gesamten Institution sind, ist eine gründliche Härtung sämtlicher Komponenten notwendig.

Built-In-Accounts als Notfallkonten

Built-In-Accounts sollten mit komplexen Passwörtern (mindestens 20 Zeichen) versehen werden und ausschließlich als Notfallkonten dienen. Dafür werden die Passwörter an sicherer Stelle hinterlegt und ein Prozess definiert, von wem sie im Notfall wie genutzt werden sollen.

Protected Users-Gruppe

Für privilegierte Accounts empfiehlt sich die Verwendung der Protected Users-Gruppe (siehe Baustein APP.2.2 Windows Server 2012). Konten dieser Gruppe ist die Authentisierung nur via Kerberos gestattet. Effektiv verhindert dies Pass-The-Hash-Attacken. Diese Maßnahme setzt ein Domain Function Level 2012 voraus. Alle Anwendungen müssen mit Kerberos kompatibel sein.

(Group) Managed Service Accounts

Nach Möglichkeit sollten (Group) Managed Service Accounts verwendet werden, wenn Anwendungen auf Servern besondere Berichtigungen benötigen (siehe Baustein APP.2.2 Windows Server 2012).

Ist das nicht möglich, so sollten, um das Brute-Force-Brechen des Passworts eines Dienstkontos zu verhindern, alle Dienstkonten mit mindestens 20 Stellen Passwortlänge abgesichert sein. Ab Domain Functional Level Windows Server 2008 kann und sollte dies per Passwort-Richtlinie erzwungen werden.

Konfiguration von Windows Server als Domänencontroller

Domänencontroller stellen in einem Netz auf Basis der Windows Server-Betriebssysteme die zur Verwaltung einer Windows Server-Domäne nötigen Dienste zur Verfügung, unter denen ADS die wichtigste Rolle einnimmt. In der Regel wird von einem Domänencontroller auch der Namensdienst DNS (Domain Name Service) angeboten, ohne den das Active Directory nicht betrieben werden kann. Im DNS werden von Windows Referenzen auf wichtige Windows Server-Ressourcen gehalten, deren Integrität für das korrekte Funktionieren einer Windows Server-Domäne essentiell sind. Da ein Domänencontroller als Anmeldeserver fungiert, führt er den dazu notwendigen Kerberos-Dienst aus. Die Kerberos-Komponenten auf dem Domänencontroller bewahren zudem die im Rahmen des Authentisierungsprotokolls genutzten geheimen Schlüssel auf.

Da jedem Domänencontroller daher eine wichtige Rolle zukommt und durch ihn schützenswerte Daten gespeichert werden, sind für die Konfiguration folgende Punkte zu beachten. Daneben gelten auch für einen Domänencontroller die im entsprechenden passenden Baustein für das Betriebssystem (z. B. SYS.1.2.2 Windows Server 2012) beschriebenen Aspekte.

  • Die Sicherheit eines Domänencontrollers leitet sich hauptsächlich aus zwei wesentlichen Bereichen ab: der Sicherheit der Betriebssystemkonfiguration und der Sicherheit des Active Directory, das auf eigene Sicherheitsmechanismen zurückgreift (siehe auch APP.2.2.A4 Schulung zur Active Directory-Verwaltung). Die Sicherheitseinstellungen des Betriebssystems erfolgen im Wesentlichen durch Gruppenrichtlinien. Die Sicherheitseinstellungen des Active Directory erfordern entsprechende Planung und Umsetzung (siehe APP.2.2.A1 Planung des Active Directory, APP.2.2.A3 Planung der Gruppenrichtlinien unter Windows).
  • An einem Domänencontroller dürfen sich nur berechtigte Administratoren lokal anmelden. Ein Benutzerbetrieb auf einem Domänencontroller darf nicht erlaubt werden. Nach einer Standardinstallation ist es normalen Benutzern daher nicht gestattet, sich lokal an einem Domänencontroller anzumelden.
  • Ein Domänencontroller sollte neben den zwingend notwendigen Standard-Domänencontrollerdiensten wie z. B. Active Directory, Kerberos und DNS keine weiteren Infrastrukturdienste (z. B. DFS, DHCP) anbieten. Insbesondere vom Betrieb eines DHCP-Servers auf einem Domänencontroller muss aus Sicherheitsgründen abgeraten werden. Beide Dienste laufen unter den gleichen Berechtigungen ab. Dadurch können vereinfacht dargestellt die Zugriffsrechte auf DNS-Daten nicht mehr durchgesetzt werden, wenn der DHCP-Dienst Veränderungen an DNS-Daten durchführt.
  • Ein Domänencontroller sollte keine (Applikations-)Serverdienste anbieten, da bei Fehlern in den Serverprogrammen eine Kompromittierung des Domänencontrollers und damit der gesamten Windows Server-Domäne möglich ist.
  • Die Konfiguration des Kanals, der zur Kommunikation von Verwaltungsdaten zwischen Rechnern einer Windows-Server Domäne genutzt wird, sollte so sicher wie möglich sein (siehe dazu APP.2.2.A8 Konfiguration des sicheren Kanals unter Windows).
  • Kann ein Domänencontroller in den so genannten Active Directory-Restore-Modus gebootet werden, so ist es möglich, Veränderungen am AD durchzuführen, indem z. B. alte Zustände (teilweise oder vollständig) von Backup-Medien geladen werden. Diese Veränderungen lassen sich so einspielen, dass sie nach dem regulären Booten durch die Active Directory-Replikation an alle anderen Domänencontrollern einer Domäne propagiert werden. Es ist daher sicherzustellen, dass der Active-Directory-Restore-Modus durch ein geeignetes Passwort geschützt ist und Arbeiten in diesem Modus nur unter Einhaltung des Vier-Augen-Prinzips erfolgen. Der Active Directory-Restore-Modus ist kommandozeilenbasiert, und Tippfehler können gravierende Folgen haben, z. B. Löschen oder Überschreiben des falschen Active Directory-Zweiges. Daher bietet das Vier-Augen-Prinzip hier neben der Tätigkeitskontrolle auch eine Sicherheit durch die Kontrolle aller Eingaben durch zwei Personen.
  • Die Domänencontroller der Forest-Root-Domäne (FRD) sind aufgrund der Sonderstellung der FRD besonders schutzbedürftig.

Sicherer Betrieb von Domänencontrollern

Um Konfigurationsfehler zu vermeiden und einen einheitlichen Sicherheitsstand zu erhalten, sollte ausgehend von einer Referenzinstallation eine abbildbasierte Einrichtung der Domänencontroller vorgenommen werden. Ferner sollten auch die Sicherheitseinstellungen in der Basiseinrichtung der Domänencontroller einheitlich vorgenommen werden. Dies sollte durch die Implementierung eines vorhersagbaren und leicht zu wiederholenden Bereitstellungsvorgangs erreicht werden. Dies beinhaltet:

  • Regelmäßiges Einspielen aktueller Hotfixes und Service Packs
    In regelmäßigen Abständen sollten aktuelle Hotfixes und Service Packs eingespielt werden. Die Auswirkungen sollten jedoch vorher an einem Abbild des Referenz-Domänencontrollers ausführlich getestet werden.
  • Vergabe von ausreichend starken Passwörtern
    Für die Benutzerkonten im Active Directory sind ausreichend starke Passwörter zu vergeben. Hinweise auf ausreichend starke Passwörter finden sich in der institutionsweiten Regelung des Passwortgebrauchs . Neben der Erstellung komplexer Passwörter ist sicherzustellen, dass die Weitergabe der Passwörter an die betroffenen Personen über vertrauensvolle Wege erfolgt. Auch sollten die Benutzerkonten insbesondere bei der Ersteinrichtung mit individuellen Passwörtern ausgestattet werden.
  • Sicherstellen der Integrität der Installation
    Werden die Domänencontroller an einem anderen Zielstandort bereitgestellt, sollten für deren Transport Signaturen verwendet werden, um auf diese Weise die Integrität der Installationen sicherzustellen

Berechtigung ausführbarer Dateien

Um nach der Heraufstufung der Domänencontroller die Stammordner der Datenträger vor Speicherplatzangriffen zu schützen, sollten die Berechtigungen für die Gruppe "Jeder" auf "Lesen und Ausführen" eingrenzt werden. Der "Vollzugriff" ist lediglich für die Administratoren zu erteilen.

Systemstart von anderen Betriebssystemen verhindern

Ein Systemstart von anderen Betriebssystemen auf den Domänencontrollern kann die Zugangsrestriktionen von NTFS aushebeln und einen Zugriff auf kritische Daten ermöglichen. Neben der bereits erwähnten räumlichen Absicherung der Server sind daher ebenfalls organisatorische Vorkehrungen zu treffen.

Der Remote-Netzstart und somit auch die Möglichkeit zur Remote-Netzinstallation z. B. durch Remote Installation Services (RIS) oder Bootstrap Protocol (BOOTP) sollte deaktiviert und die Verwendung eines BIOS-Kennwortes beim Systemstart vorgesehen werden.

Neustart-Schutz mit Festplattenverschlüsselung (BitLocker)

Noch sicherer ist eine Festplattenverschlüsselung, welche die Eingabe eines Passworts oder Nutzung eines Datenträgers beim Systemstart des DC erfordert. Die Maßnahme ist im entsprechenden Windows Server-Baustein beschrieben (z. B. SYS.1.2.2 Windows Server 2012).

Sichere Richtlinieneinstellungen für Domänen und Domänencontroller

Ein Windows Server mit Active Directory enthält Standard-Sicherheitsrichtlinieneinstellungen für die Domäne und für die Domänencontroller. Es werden jedoch Änderungen der Standard-Richtlinieneinstellungen zur Erhöhung der Sicherheit von Domäne und Domänencontrollern durch die folgenden Punkte empfohlen:

  • Sichere Kennwortrichtlinien-Einstellungen
    Der Zugriff auf Domänencontroller muss mit starken Mechanismen abgesichert sein. Näheres zu den dafür notwendigen Einstellungen der Kennwortrichtlinien findet sich in den Microsoft-Server-spezifischen Bausteinen.
  • Konto-Sperrungsrichtlinien
    Die Protokollierung der Anmeldeversuche (siehe hierzu auch APP.2.2.M11 Überwachung der Active Directory Infrastruktur ) sollte so eingerichtet werden, dass Angriffe erkannt werden können. Beispielsweise könnte eine große Zahl nicht erfolgreicher Kennworteingaben während eines Anmeldeversuchs auf einen Brute-Force-Angriff hindeuten. Die eigentliche Kontosperrung ist über die Optionen Kontosperrdauer, Kontosperrungsschwelle und die Zurücksetzung des Kontosperrungszählers entsprechend der Beschreibung in Maßnahme APP.2.2.M3 Planung der Gruppenrichtlinien unter Windows zu definieren.
  • Kerberos-Richtlinien-Einstellungen
    Der durch Kerberos zur Verfügung stehende Authentisierungsdienst teilt dem jeweiligen Client die erforderlichen Autorisierungsdaten für Ressourcenzugriffe zu. Hierbei wird der Zugriff auf Netzressourcen anhand von Sitzungstickets gewährt. Dazu stellt der Domänencontroller im Vorfeld ein sogenanntes Ticket-Granting-Ticket (TGT) an den Client aus. Erfolgt ein Zugriffsversuch seitens der Clients auf eine Ressource, so übermittelt der Client das TGT zur Prüfung an den Domänencontroller. Der Domänencontroller wiederum generiert dem Client nach erfolgreicher Prüfung ein Sitzungsticket, mit dem ein zeitlich begrenzter Zugriff auf die Ressource ermöglicht wird.
    Durch eine Anpassung der Kerberos-Richtlinieneinstellung können für Domänen-Benutzerkonten Aspekte der Kerberos-Tickets wie die Gültigkeitsdauer angepasst werden (siehe Maßnahme APP.2.2.A3 Planung der Gruppenrichtlinien unter Windows).

In Bezug auf sichere Richtlinieneinstellungen für Domänencontroller werden des Weiteren nachfolgende Maßnahmen empfohlen:

  • Benutzerrechte sollten restriktiv vergeben werden, sodass die Benutzer in der Domäne oder auf dem Domänencontroller lediglich die von ihnen verantworteten betrieblichen oder administrativen Aufgaben erledigen können. Die Zugriffsmöglichkeiten von Benutzern sollte dabei so eingeschränkt werden, dass sie die Sicherheit der Domänencontroller nicht gefährden (siehe auch Maßnahme APP.2.2.A1 Planung des Active Directory).
  • Durch die Einrichtung von Richtlinieneinstellungen für die Domänencontroller-Überwachung wird der Nachweis der Verantwortung für sensible Verzeichnisoperationen, z. B. Verwaltungs- oder Konfigurationsänderungen, ermöglicht. Es sollte eine Überwachung von Anmeldeversuchen, Kontoverwaltung, Active Directory-Zugriff, Objektzugriffsversuchen, Richtlinienänderungen, Rechteverwendung, Prozessverfolgung und Systemereignisse eingerichtet werden (siehe Maßnahme APP.2.2.A11 Überwachung der Active Directory Infrastruktur).
  • Wichtige Active Directory-Objekte wie z. B. die Verzeichnispartitionen sind mit geeigneten Richtlinieneinstellungen zu überwachen. Dazu muss die Überwachung der Verzeichnispartitionen (logische Bereiche der Active Directory-Datenbank) aktiviert werden. Die hiervon betroffenen Verzeichnispartitionen lauten "Schema", "Konfiguration" und "Domäne" (dito).

Die obigen Empfehlungen zur Einrichtung von Richtlinieneinstellungen führen dazu, dass die voreingestellte maximale Größe des Sicherheitsprotokolls angehoben werden muss, damit eine größere Anzahl überwachter Ereignisse aufgenommen werden kann. Die Protokolle müssen zeitnah ausgewertet werden. Außerdem muss es ein klar definiertes Vorgehen für die regelmäßige und rechtzeitige Archivierung sowie eine Sicherung der Sicherheits- und Systemereignisprotokolle geben, damit keine Ereignisse verloren gehen oder überschrieben werden.

Ist darüber hinaus die Zusammenarbeit zwischen Domänen in verschiedenen Gesamtstrukturen zu unterstützen, z. B. zur gemeinsamen Nutzung von Anwendungen oder zur begrenzten Zusammenarbeit zwischen verschiedenen Gesamtstrukturen in einer Institution, sollten externe Vertrauensstellungen eingerichtet werden. Durch externe Vertrauensstellungen entsteht jedoch ein potenzielles Sicherheitsrisiko, da Sicherheitsgrenzen überschritten werden. Daher sollten die Domänencontroller in der vertrauenden Domäne Autorisierungsdaten der Benutzer filtern und Sicherheitskennungen (Security IDs, SIDs) entfernen, die sich nicht auf die Domäne des Benutzerkontos beziehen. Eine ausführliche Beschreibung hinsichtlich der Erschleichung umfassender Berechtigungen durch gefälschte SIDs und die Gegenmaßnahmen durch SID-Filterung ist in den Microsoft-Knowledge-Base-Artikeln 289243 und 289246 aufgeführt.

Die Richtlinieneinstellungen der Sicherheitsoptionen für Domänencontroller beeinflussen die sicherheitsrelevanten Konfigurationseinstellungen der Windows Server Betriebssysteme und sollten daher gewissenhaft eingestellt werden. Dies gilt nicht nur für die Active Directory-relevante Konfiguration, sondern auch für andere Komponenten des Windows Server-Betriebssysteme (z. B. Sicherheitskonfigurationseinstellungen für Netz, Dateisystem und Benutzeranmeldung).

Viren-Schutz für Domänencontroller

Für einen ausreichenden Schutz gegen Computer-Viren und andere Schadprogramme muss in einer Institution ein umfassendes Viren-Schutzkonzept umgesetzt werden. Die entsprechende Vorgehensweise wird im Baustein OPS.1.1.5 Schutz vor Schadprogrammen beschrieben. In dem Viren-Schutzkonzept sollten grundsätzlich auch die Domänencontroller einer Institution berücksichtigt werden.

Damit die Nutzung eines Viren-Schutzprogramms auf einem Domänencontroller keine negativen Auswirkungen auf den laufenden Betrieb hat, sind jedoch für Domänencontroller einige Besonderheiten zu beachten.

Die Hinweise in dieser Maßnahme sind als allgemeine Hinweise zu verstehen. Unter Umständen müssen zusätzlich die speziellen Anweisungen des Herstellers des jeweils eingesetzten Viren-Schutzprogramms berücksichtigt werden.

Bei der Auswahl der Viren-Schutz-Software muss darauf geachtet werden, dass der Einsatz auf einem Domänencontroller explizit unterstützt wird. Entscheidend ist dabei, dass die Viren-Schutz-Software die vom Betriebssystem-Hersteller vorgesehenen Programmierschnittstellen (Application Programming Interface, API ) verwendet.

Bei der Verwendung falscher Programmierschnittstellen werden unter Umständen die Metadaten der untersuchten Dateien durch den Zugriff der Viren-Schutz-Software verändert. In diesem Fall ist es möglich, dass der File Replication Service (FRS) des Betriebssystems eine Replizierung der vermeintlich geänderten Datei innerhalb der Institution veranlasst. Solche unnötigen Replizierungen können zu einer verminderten Systemleistung führen und sollten daher vermieden werden. Weitere Details bezüglich kompatibler Viren-Schutzprogramme sind im Microsoft-Knowledge-Base-Artikel mit der Artikel-ID 815263 zu finden.

Die korrekte Funktionsweise der Viren-Schutz-Software sollte vor dem endgültigen Einsatz in einer Produktivumgebung in einer Testumgebung ausgiebig auf korrekte Funktionalität getestet werden. Die Testumgebung sollte dabei den Gegebenheiten der Produktivumgebung möglichst nachempfunden werden, um Auswirkungen auf die Gesamtleistung des Domänencontrollers festzustellen.

Um die Einführung von Schadsoftware zu vermeiden, sollte auf Domänencontrollern ausschließlich die Active Directory-Funktionalität des Betriebssystems verwendet und möglichst keine weiteren Dienste angeboten werden. Insbesondere darf ein Domänencontroller nicht als herkömmlicher Arbeitsplatz genutzt werden. So sollten lokal auf einem Domänencontroller angemeldete Benutzer nicht in der Lage sein, im Internet zu surfen, E-Mails zu empfangen oder auf externe Datenträger wie z. B. USB-Speicher oder optische Medien zuzugreifen.

Ebenso sollte der Domänencontroller nicht als Dateifreigabe-Server genutzt werden. Werden auf dem Domänencontroller Dateien per Dateifreigaben im Netz verfügbar gemacht, so werden diese Dateien vom Viren-Schutzprogramm bei jedem Zugriff auf Schadsoftware untersucht, was zu Performance-Einbußen auf dem Domänencontroller führen kann. Dateifreigaben auf dem Domänencontroller sollten daher deaktiviert werden.

Grundsätzlich sollte das Viren-Schutzprogramm alle Dateizugriffe transparent im Hintergrund überwachen. Allerdings existieren in Windows Server-Betriebssystemen einige Dateien, z. B. Verzeichnisdienst-Datenbank, Protokolldateien, Datenbank des Dateireplikationsdienstes, die bei einem Zugriff durch ein Viren-Schutzprogramm die Funktionen des Domänencontrollers beeinträchtigen können. Um unnötige Dateisperrungen durch das Viren-Schutzprogramm zu verhindern und den einwandfreien Betrieb des Domänencontrollers sicherzustellen, sollten daher die folgenden Punkte beachtet werden.

Zugriff auf die Active Directory-Datenbank und Protokolldateien durch die Extensible Storage Engine (ESE)

Die Verzeichnisdienst-Datenbank und Protokolldateien werden vom Active Directory mittels ESE für den exklusiven Dateizugriff geöffnet. Daher kann die ESE nur auf die Dateien zugreifen, die nicht durch die Viren-Schutz-Software blockiert werden. Gleichzeitig kann die Viren-Schutz-Software nur auf die Dateien zugreifen, die nicht durch die ESE blockiert werden.

Sowohl die Datenbankdateien als auch die Protokolldateien verwenden Active Directory-interne Prüfsummen, die durch den Dateizugriff eines Viren-Schutzprogramms ungültig werden und zu inkonsistenten Datenbanken führen können. Eine inkonsistente Datenbank kann zu einem Ausfall des Active Directory führen.

Daher sind folgende Dateien aus der regelmäßigen Virenüberprüfung auszuschließen:

  • Active Directory-Hauptdatenbank
  • Active Directory-Transaktionsprotokolldateien
  • Active Directory-Arbeitsordner

Zugriff auf die Datenbank und Protokolldateien des Dateireplikationsdienstes (FRS) durch ESE

Wie bereits beschrieben können durch den unsachgemäßen Einsatz von Viren-Schutzprogrammen bei Datenbank- oder Protokolldateizugriffen konkurrierende Zugriffe des Replikationsdienstes auftreten. Ebenso kann eine Änderung der internen Prüfsummen dieser Dateien zu einem Ausfall des Active Directory führen. Daher sollten folgende Dateien aus der regelmäßigen Virenüberprüfung ausgeschlossen werden:

  • Dateien im Arbeitsordner des Dateireplikationsdienstes
  • Datenbankprotokolldateien des Dateireplikationsdienstes
  • Staging-Ordner (Cache für neue und geänderte Dateien, die repliziert werden sollen) und Stammreplikat (Kopie des Distributed-File-System-Stamms und dessen untergeordnete Verknüpfungen) des Dateireplikationsdienstes
  • Vorinstallationsordner des Dateireplikationsdienstes

Wird der Dateireplikationsdienst verwendet, um Windows-Freigaben zu replizieren, deren Verknüpfungsziel auf Windows Server-Betriebssystemen liegt, so sind diese Dateien der SYSVOL-Ordner ebenfalls auszuschließen.

Dateireplikation durch den Dateireplikationsdienst (File Replication Service, FRS)

Der Dateireplikationsdienst wird von den Windows Server-Betriebssystemen für die Replizierung von Anmeldeskripten und Systemrichtlinien des SYSVOL-Ordners zwischen Domänencontrollern verwendet. Werden die Metadaten (Sicherheitsinformationen oder Zeitstempel) einer Datei durch ein Viren-Schutzprogramm verändert, so wird die entsprechende Datei durch FRS zwischen den Domänencontrollern erneut repliziert. Dieses Verhalten führt zu einer erhöhten Replizierung der SYSVOL-Dateien und damit zu

  • einem erhöhten Bandbreitenverbrauch im Netz,
  • einem erhöhten Ressourcenverbrauch auf den Domänencontrollern und
  • einer hohen Anzahl von Dateien im Staging-Ordner.

Um eine übermäßige Replikation zu verhindern, sollten folgende Punkte beachtet werden:

  • Es ist ein Viren-Schutzprogramm auszuwählen, das die Metadaten der SYSVOL-Dateien nicht ändert.
  • Sollte eine entsprechende Auswahl nicht möglich sein, so ist das SYSVOL-Verzeichnis inklusive aller Unterverzeichnisse aus der automatischen Überprüfung durch das Viren-Schutzprogramm zu entfernen. Dabei erhöht sich allerdings das Risiko für einen Virenbefall, da anders als bei den oben genannten Dateien in diesem Falle ausführbare Dateien, z. B. Anmeldeskripte, von der Viren-Schutz-Software nicht mehr erfasst werden. Daher sollten für den Fall, dass die SYSVOL-Verzeichnisse nicht durch das Viren-Schutzprogramm abgesichert werden können, ausschließlich signierte Anmeldeskripte auf den Domänencontrollern und Arbeitsstationen der Administratoren verwendet werden.

Update-Funktion des Microsoft Betriebssystems

Im Rahmen der Update-Funktion des Windows-Server-Betriebssystems ("Microsoft Update", "Windows Update" oder "Automatisches Update") kann das exklusive Zugriffsrecht für Dateien eines Viren-Schutzprogramms zu Problemen führen.

Um diese Probleme zu vermeiden, sollten folgende Dateien aus der regelmäßigen Virenüberprüfung ausgeschlossen werden:

  • Datenbankdateien mit Bezug auf die Update-Funktionalität wie z. B. im Ordner %windir%\SoftwareDistribution\Datastore die Datei "Datastore.edb"
  • die im Ordner %windir%\SoftwareDistribution\Datastore\Logs abgelegten Transaktionsprotokolldateien

Weitere Details zu den auszuschließenden Dateien finden sich online im Dokument "Empfehlungen zum Virenscan auf Unternehmenscomputern, auf denen unterstützte Windows-Versionen ausgeführt werden".

RDP

Beim Schließen einer RDP-Sitzung sollte der Benutzer automatisch abgemeldet werden. Dies kann per GPO realisiert werden.

Individuell geprüft werden muss die Verwendung des Restricted Admin Mode. Bei Aktivierung können keine Zugangsdaten bei der Anmeldung via RDP übertragen werden. Dadurch sind auf dem Host-System keine Hashes vorhanden. Allerdings erlaubt diese Einstellung die Durchführung von Pass-the-Hash-Angriffen auf den RDP-Dienst.

APP.2.2.M6 Aufrechterhaltung der Betriebssicherheit von Active Directory

Die in der Produktivumgebung eingesetzten Domänencontroller sind durch die Administratoren auf dem vorangegangen Sicherheitsniveau zu halten und bei erhöhten Anforderungen entsprechend anzupassen. Für Änderungen an den Systemen, die sich unter anderem durch die regelmäßigen Wartungsarbeiten ergeben, sind im Vorfeld schriftlich niedergelegte Richtlinien zu entwickeln.

Beschränkung der Vertrauensbeziehungen

Die Vertrauensbeziehungen zwischen Domänen und vor allem von und zu anderen Wäldern bzw. zwischen verschiedenen Wäldern (z. B. Tiers) der Institution sollten regelmäßig evaluiert werden daraufhin, ob sie weiterhin benötigt und gerechtfertigt sind, ob sie den korrekten Typ haben (d. h. vor allek, ob eine zweiseitige Vertrauensbeziehung wirklich notwendig ist) und ob die Sicherheitskontrollen zu ihrer Gewährleistung ausreichend sind.

Die Frage "Was geschieht, wenn diese Vertrauensbeziehung gelöscht wird?" sollte für jede Vertrauensbeziehung gestellt werden. Wenn die Antwort unbekannt oder nicht klar ist., ist dies ein Hinweis darauf, dass die Vertrauensbeziehung unter Beachtung üblicher Testprozeduren und Fallbackplanung deaktiviert und bei Ausbleiben von Problemen gelöscht werden sollte.

Sicherheit der Dienste-Administratorkonten

Die Verantwortung zur Steuerung der Konfiguration und Funktionsweise des Verzeichnisdienstes ist nur zuverlässigen, vertrauenswürdigen Personen zu übertragen. Dieser Personenkreis muss mit den gültigen Sicherheitsrichtlinien der Institution vertraut sein und Bereitschaft demonstrieren, diese konsequent durchzusetzen.

Die Zugriffsrechte der Dienste-Administratoren sollten auf das für ihre Arbeiten notwendige Minimum reduziert und ausschließlich für Aufgaben genutzt werden, die erhöhte Rechte voraussetzen. Um die berechtigte Notwendigkeit für Personen mit Dienste-Administratorrechten sicherzustellen, ist diese in regelmäßigen Abständen zu überprüfen und bei Bedarf entsprechend anzupassen. Auch ist die Mitgliederanzahl der Administratorenkonten auf einem notwendigen Minimum zu halten. Die Benutzung ausreichend starker Passwörter für die Konten der Administratorengruppen ist zwingend erforderlich. Es sollte überlegt werden, Verfahren zur starken Authentisierung zu verwenden wie z. B. die zusätzliche Nutzung von Chipkarten zur Anmeldung am Betriebssystem.

Beschränkung der Gruppe Domänenadministratoren (DA)

Idealerweise sollte die Gruppe DA (Domänenadministratoren) sogar leer sein, um sicherzustellen, dass jede Gruppe nur genau die Rechte erhält, die sie für ihre Arbeit benötigt.

Die Administratoren des AD selbst etwa benötigen lediglich Mitgliedschaft in der Gruppe der Administratoren der entsprechenden Domäne, um volle Verwaltungsrechte auf dem AD sowie auf den DC zu erhalten. Nur wer tatsächlich mit der Verwaltung der ADS beauftragt ist, sollte DA sein.

Zusätzlich sollte für den Notfall ein Domänenadministratorkonto (z. B. der Default-DA mit einem starken Passwort) eingerichtet und sicher sowie gleichzeitig gut erreichbar hinterlegt werden für den Fall, dass keiner der DAs verfügbar ist.

Entfernung inaktiver Konten aus dem AD

Nicht mehr verwendete Konten sollten im AD deaktiviert oder gelöscht werden, damit sie nicht von Angreifern missbraucht werden können. Ist der Account deaktiviert, so fällt eine versuchte Verwendung auf und sollte geloggt und ausgewertet werden, denn ein legitimer Gebrauch sollte nun nicht mehr vorkommen.

Am sichersten funktioniert dies, wenn Konten bei Ende ihrer Verwendung in einem Prozess automatisch aus dem AD ausgetragen werden. Dies kann technisch oder organisatorisch sichergestellt werden.

Gewährleistung der Aktualität von Basisinformationen

Unter dem Begriff "Basisinformationen" werden die wichtigsten Konfigurationsparameter des Active Directory zusammengefasst. Die Basisinformationen sollten mindestens folgende Punkte beinhalten:

  • Überwachungsrichtlinien
  • Gruppenrichtlinienobjekte und deren Zuweisung
  • bestehende Vertrauensstellungen
  • Organisationseinheit der Domänencontroller und Dienst-Admins
  • Inhaber der Betriebsmasterfunktionen
  • Replikationstopologie
  • Datenbankeigenschaften
  • verwendete Service Packs und Hotfixes für Domänencontroller und Administratorarbeitsstationen und deren aktueller Systemstatus
  • aktuell vorhandene Sicherungsmedien
  • Überprüfung der Sicherungsmedien
  • Überprüfung der aktuell benötigten Dienste-Administratorenberechtigungen

Mit Hilfe dokumentierter Basisinformationen ist eine Nachverfolgung und Überprüfung der am Active Directory durchgeführten Änderungen möglich. Die Basisinformationen sollten für alle Domänencontroller in einer Basisdatenbank zusammengefasst werden. Diese Basisdatenbank bietet zusätzlich einen Überblick der aktuell eingesetzten Komponenten. Die Zuständigkeiten für die Pflege der Basisinformationen muss geklärt werden.

APP.2.2.M7 Umsetzung sicherer Verwaltungsmethoden für Active Directory [Fachverantwortliche]

Trennung von Standard- und privilegierten Identitäten

Administratorkonten sollten nicht für die gewöhnliche tägliche Arbeit verwendet werden. Gleiches sollte gelten für Administrationssysteme, wenn hier die Möglichkeit für dedizierte Systeme besteht. Insbesondere sollte mit Administratorkonten und Administrationssystemen nicht auf das Internet zugegriffen werden.

Jeder Anwender sollte daher über ein Standard-Benutzerkonto für den allgemeinen Gebrauch verfügen. Administrative Tätigkeiten sollten mit einem gesonderten Konto erfolgen. Das Administrationskonto darf nicht für allgemeine Tätigkeiten verwendet werden.

Benannte Accounts

Jeder Account, der verwendet wird, sollte sich eindeutig einem Mitarbeiter zuordnen lassen. Das erhöht nicht nur die Verantwortlichkeit der Mitarbeiter, sondern erleichtert auch die Rückverfolgung im Fall eines Angriffs.

Beschränkung der Anmeldemöglichkeiten von Administratoren

Die Anzahl der Systeme, an denen sich Administratoren der ADS anmelden, sollte möglichst weit eingeschränkt werden. Wenn AD-Administratoren sich lediglich an den Systemen anmelden, die sie tatsächlich zu verwalten haben sowie indirekt an bestimmten wenigen Administrations-Workstations, können die Orte, an denen wertvolle Credentials abgegriffen werden, stark einschränkt werden. Server-Administratorkonten dürfen daher nicht auf Workstations verwendet werden, Domain-Administratorkonten nicht auf Workstations oder Servern. Es sollte möglichst technisch ausgeschlossen sein, dass ein privilegierter Account zur Anmeldung an einem System einer anderen Schicht genutzt wird.

Ab einem Domain Functional Level 2012 lässt sich mittels GPOs sicherstellen, dass eine interaktive Anmeldung von einer Schicht auf eine andere nicht möglich ist. Somit darf sich ein Domänen-Administrator nicht an einem System der Produktions-IT oder der Büro-IT anmelden. Ein Server-Administrator darf sich nicht an einem Domänencontroller oder einem Gerät in der Büro-IT anmelden.

Dienste- und Datenadministration

Zur Administration einer Domäne werden Verantwortlichkeiten und Aufgabenfelder in weitere Untergruppen verteilt. Da die Benutzerkonten in den Verwaltungsgruppen "Dienste-Administratoren" (verantwortlich für die Ausführung der Aufgaben, die zur Bereitstellung des Verzeichnisdienstes erforderlich sind) und "Datenadministratoren" (verantwortlich für das Verwalten der Inhalte, die in Active Directory gespeichert oder durch Active Directory geschützt werden) besonders weitreichende Zugriffsrechte haben, sind für deren Schutz entsprechende Vorkehrungen zu treffen:

Dienste-Administratorkonten

In jeder Domäne der Gesamtstruktur wird das Standardkonto "Administrator" bei der Installation angelegt. Als Standardkonto ist dieses Benutzerkonto im besonderen Maße Angriffen ausgesetzt. Da das Administrator-Konto nicht deaktiviert oder gelöscht werden kann, sollte es als Schutzmaßnahme umbenannt werden. Bei der Umbenennung ist darauf zu achten, dass auch die Beschreibung des Administrator-Kontos abgeändert wird. Nachdem das Konto umbenannt wurde, sollte anschließend ein unprivilegiertes Konto mit Namen "Administrator" eingerichtet werden, das im täglichen Betrieb nicht verwendet werden darf. Bei der Auswertung der Protokoll-Dateien kann so erkannt werden, ob es erfolgreiche oder nicht erfolgreiche Anmeldungen an dieses unprivilegierte Benutzerkonto gab. Dies würde auf einen Angriffsversuch hindeuten.

Die Anzahl der Dienste- und Datenadministratoren ist auf ein Minimum zu beschränken. Routinemäßige Administrations- und Verwaltungsaufgaben, z. B. Verwaltung der Domänen-Benutzer, die nicht die Konfiguration des Active Directory selbst betreffen, sollten nicht von Dienste-Administratoren durchgeführt werden, sondern an Datenadministratoren delegiert werden.

Die Administratorkonten sollten möglichst sparsam eingesetzt werden. Unnötige Anmeldung an der Domäne mit administrativen Rechten sollten vermieden werden. Daher sollten die Administratoren einer Institution für alltägliche, nichtadministrative Aufgaben, z. B. Informationsbeschaffung im Internet, unprivilegierte Benutzerkonten verwenden.

Die Verwaltung von Dienste-Administratorkonten darf ausschließlich von Mitgliedern der Dienste-Administratorgruppe durchgeführt werden. Insbesondere Benutzer mit weniger Privilegien, z. B. Datenadministratoren, dürfen keine Änderungen an Dienste-Administratorkonten vornehmen, da sich die weniger privilegierten Nutzer ansonsten erweiterte Rechte einräumen könnten.

Daher sollte zur Verwaltung der Dienste-Administratorkonten eine eigene Organisationseinheit, z. B. Dienst-Admins, in der Benutzerverwaltung des Active Directory angelegt werden. Die Berechtigungen für diese Unterstruktur müssen dabei wie folgt gewählt werden:

  • Vererbung der Berechtigungen von übergeordneten Objekten deaktivieren
  • Zugriffsberechtigungen auf die einzurichtende Organisationseinheit (inklusive untergeordnete Objekte)

    • Administratoren: Vollzugriff
    • Organisations-Admins: Vollzugriff
    • Domänen-Admins: Vollzugriff

Die Dienste-Administratorgruppen (Domänen-Admins, Organisations-Admins und Schema-Admins) werden anschließend in die neue Unterstruktur verschoben. Darüber hinaus sind die administrativen Benutzerkonten der Domänenadmins in die Organisationseinheit "Benutzer und Gruppen" und die Konten der Arbeitsstationen in die Organisationsstruktur "Administrator-Arbeitsstationen" der neuen Unterstruktur zu verschieben. Dabei ist zu beachten, dass Domänencontroller-Konten nicht verschoben werden dürfen.

Zusätzlich sollten sowohl die Protokollierung von Änderungen, Löschungen und Einrichtung von Dienste-Administratorkonten und Arbeitsstationen sowie Änderungen an den Richtlinien überwacht werden.

Da einige der vordefinierten Dienste-Administratorkonten nicht in die neu erstellte Unterstruktur verschoben werden können, müssen diese Konten gesondert geschützt werden.

Lokale Administrationskonten

Lokale Administrationskonten sollten über sichere, einzigartige Passwörter verfügen. Mit LAPS (Local Administrator Password Solution) stellt Microsoft ein kostenloses Tool bereit, mit dem solche einfach per AD automatisch generiert und verwaltete werden können, siehe Baustein SYS.1.2.2 Windows Server 2012.

AdminSDHolder

Im Active Directory werden die geschützten Dienste-Administratorkonten regelmäßig überprüft. Dabei werden die Sicherheitseinstellungen der geschützten Konten mit den Sicherheitsbeschreibungen des AdminSDHolder-Objekts (frei übersetzt "Bewahrer des Security Descriptors für Admin-Konten", im Systemcontainer "CN=AdminSDHolder, CN=System, DC=Domänen-name") überschrieben. Der entsprechende Prozess, mit dessen Hilfe das Überschreiben angestoßen wird, startet nach fest vorgegebenen Intervallen (standardmäßig jede Stunde).

Dieser Mechanismus galt auf Windows Server 2000-Systemen für die Benutzergruppen "Administratoren", "Domänen-Admins", "Organisations-Admins" und "Schema-Admins". In der Betriebssystemversion Windows Server 2003 wurde der Mechanismus auf die Gruppen "Serveroperatoren", "Kontenoperatoren", "Sicherungsoperatoren", "Druckoperatoren" und "Zertifikat-Herausgeber" erweitert.

Folgende Berechtigungen sollten für das AdminSDHolder-Objekt zugelassen werden:

  • Jeder

    • Kennwort ändern

  • Administratoren

    • Inhalt auflisten
    • Alle Eigenschaften lesen
    • Alle Eigenschaften schreiben
    • Löschen
    • Berechtigungen lesen
    • Berechtigungen ändern
    • Besitzer ändern
    • Alle bestätigten Schreibvorgänge
    • Alle erweiterten Rechte
    • Alle untergeordneten Objekte erstellen
    • Alle untergeordneten Objekte löschen

  • Authentifizierte Benutzer

    • Inhalt auflisten
    • Alle Eigenschaften lesen
    • Berechtigungen lesen

  • Domänen-Admins

    • Inhalt auflisten
    • Alle Eigenschaften lesen
    • Alle Eigenschaften schreiben
    • Berechtigungen lesen
    • Berechtigungen ändern
    • Besitzer ändern
    • Alle bestätigten Schreibvorgänge
    • Alle erweiterten Rechte
    • Alle untergeordneten Objekte erstellen
    • Alle untergeordneten Objekte löschen

  • Organisations-Admins

    • Inhalt auflisten
    • Alle Eigenschaften lesen
    • Alle Eigenschaften schreiben
    • Berechtigungen lesen
    • Berechtigungen ändern
    • Besitzer ändern
    • Alle bestätigten Schreibvorgänge
    • Alle erweiterten Rechte
    • Alle untergeordneten Objekte erstellen
    • Alle untergeordneten Objekte löschen

  • SYSTEM

    • Vollzugriff

Personen

Die Personen der Dienste-Administratorengruppen müssen sowohl vertrauenswürdig sein als auch über ausreichend sichere Kenntnisse hinsichtlich der Active Directory-Administration verfügen. Damit eine geradlinige Umsetzung der Sicherheitsrichtlinien der Institution gewährleistet werden kann, müssen die Dienste-Administratoren mit den entsprechenden Richtlinien vertraut sein.

Die Mitgliederliste der Dienste-Administratorgruppen darf ausschließlich aus Benutzern der eigenen Active Directory-Gesamtstruktur bestehen. Wird Dienste-Administratoren aus entfernten Domänen vertraut, so vertraut die Institution automatisch auch den Sicherheitsmaßnahmen der entfernten Institution. Da diese Sicherheitsmaßnahmen in der Regel nicht beeinflusst werden können, ist für institutionsfremde Benutzer ein Benutzerkonto in der eigenen Gesamtstruktur einzurichten. Hierdurch können die Zugriffe auf die eigene Domäne besser reglementiert werden und es wird verhindert, dass Benutzer auf die Domäne zugreifen, deren Rechte aufgrund der automatischen Vertrauensregelung nicht bekannt sind.

Aufgrund der weitreichenden Berechtigungen sind Dienste-Administratorkonten bevorzugte Angriffsziele. Daher wird bei erhöhten Sicherheitsanforderungen empfohlen, die Zugehörigkeitsinformationen aller Dienste-Administratorgruppen für nicht privilegierte Benutzer zu unterbinden.

Dabei ist jedoch zu beachten, dass einige Serverapplikationen den lesenden Zugriff auf die Mitgliederliste der Dienste-Administratoren für einen störungsfreien Betrieb brauchen. Daher ist im ersten Schritt zu ermitteln, ob derartige Serveranwendungen in der Institution verwendet werden.

Die Benutzerkonten, unter denen die identifizierten Serverprozesse gestartet werden, sind in einer eigenen Gruppe, z. B. Serveranwendungen, zusammenzufassen. Anschließend werden folgende Berechtigungen in der ACL des AdminSDHolder Objekts für diese Gruppe vergeben:

  • Inhalt auflisten
  • Alle Eigenschaften lesen
  • Berechtigungen lesen

Der Zugriff kann somit auf die authentisierten Benutzer eingegrenzt werden, die über einen lesenden Zugriff auf die Mitgliederliste verfügen müssen.

Da das Verbergen der Gruppenzugehörigkeit für Dienste-Administratorgruppen Auswirkungen auf den Betrieb haben kann, wird dringend empfohlen, die oben beschriebenen Änderungen am AdminSDHolder-Objekt im Vorfeld auf mögliche Auswirkungen zu überprüfen.

Die Mitglieder der Active Directory-Gruppe "Sicherungsoperatoren" sind als Dienstadministratoren anzusehen, da sie Systemdateien des Domänencontrollers wiederherstellen können. Die Anzahl der Mitglieder dieser Benutzergruppen sollte möglichst klein gehalten werden. Daher sind Administratoren, die für die Sicherung und Wiederherstellung von Anwendungsservern innerhalb des Active Directory verantwortlich sind, nicht in die Active Directory-Gruppe "Sicherungsoperatoren" einzutragen. Vielmehr sind die entsprechenden Benutzerkonten in den lokalen Gruppen "Sicherungsoperatoren" der Anwendungsserver einzutragen.

Die Active Directory-Gruppe "Kontenoperatoren" sollte nicht für die Datenverwaltung (z. B. Kontenverwaltung) verwendet werden, da Mitglieder die Möglichkeit haben, die eigenen Rechte auszuweiten. Aus Sicherheitsgründen sollten sich daher in der Gruppe "Kontenoperatoren" keine Mitglieder befinden.

Ähnliches gilt für die Active Directory-Gruppe "Schema-Admins". Da Änderungen am Schema des Active Directory normalerweise sehr selten sind, sollten vertrauenswürdige Administratoren nur solange zur Gruppe "Schema-Admins" hinzugefügt werden, wie die Berechtigungen auch tatsächlich benötigt werden. Sobald die Änderungen am Schema erfolgt sind, sollten die Mitglieder wieder aus der Gruppe entfernt werden.

Die Benutzerkonten der Gruppen "Organisations-Admins" und "Domänen-Admins" in der Stammdomäne der Active-Directory-Gesamtstruktur einer Institution sind aufgrund der weitreichenden Berechtigungen besonders zu schützen. Daher sollten jedem dieser Konten zwei Administratoren zugewiesen und das Passwort in zwei Hälften geteilt werden. Jedem der beiden Administratoren darf jeweils nur eine Hälfte des Passworts bekannt sein, damit innerhalb des Benutzerkontos nur unter Beachtung des Vier-Augen-Prinzips gearbeitet werden kann. So kann die unbemerkte Nutzung von Dienste-Administratorkonten der Stammdomäne in der Gesamtstruktur des Active Directory vermieden werden.

Alternative Methoden zur Durchsetzung des Vier-Augen-Prinzips wie z. B. die Verwendung von Chipkarten, wobei PIN und Chipkarte voneinander getrennt werden, sind ebenfalls denkbar.

Neben der Absicherung der Dienste- und Datenadministratorkonten sind außerdem die Arbeitsplätze der Administratoren wie folgt abzusichern:

  • Die Benutzerkonten der Administratoren sollten so eingerichtet werden, dass die Konten nur von bestimmten Arbeitsplätzen aus verwendet werden können. Kompromittierte Administratorkonten können so nur noch von bestimmten Arbeitsstationen aus verwendet werden.
  • Nach 5 Minuten Inaktivität durch den Benutzer ist die automatische Sperrung zu aktivieren. Dabei ist darauf zu achten, dass zur Aufhebung der Konsolensperrung keine zwischengespeicherten Daten verwendet werden dürfen, sondern zwingend eine erneute Authentisierung am Domänencontroller erfolgen muss. Dazu muss der Wert des Registrierungsschlüssels ForceUnlockLogon im Verzeichnis HKLM\Software\Microsoft\ Windows NT\CurrentVersion\Winlogon\ auf den Wert "1" gesetzt werden.
  • Auf den Arbeitsstationen der Administratoren sollten Viren-Schutzprogramme eingesetzt werden.
  • Anwendungen sollten nicht im Kontext der Administratoren ausgeführt werden. Beim Hinzufügen einer neuen Arbeitstation zur Domäne ist daher darauf zu achten, dass die Domänen-Admins nicht automatisch zu der lokalen Gruppe der Administratoren der Arbeitsstation hinzugefügt werden.
  • Prozesse sollten nicht mit den Berechtigungen der Domänen-Admins ausgeführt werden. Stattdessen sollte der Sicherheitskontext der lokalen Administratorgruppe der jeweiligen Arbeitsstation verwendet werden.
  • Der Datenverkehr zwischen den Arbeitsstationen der Administratoren und den Domänencontrollern ist entsprechend abzusichern. Hierzu sollten die LDAP-Paketsignaturen aktiviert werden. Dafür ist der Registrierungsschlüssel LDAPClientIntegrity in dem Windows-Registry-Pfad HKLM\System\CurrentControlSet\Services\LDAP\ auf den Wert "2" zu setzen.

Für die Remoteadministration von Domänencontrollern sollten ausschließlich Protokolle verwendet werden, die eine Verschlüsselung des Datenverkehrs ermöglichen.

Datenadministratorkonten

Grundsätzlich hängen die Strukturen und Berechtigungen der Datenadministratorenkonten stark von der Struktur der jeweiligen Institution ab. Für die im Folgenden aufgeführten Aspekte ist daher zu verifizieren, ob sie sich mit den Anforderungen der Institution verbinden lassen.

Die Delegierung der Datenverwaltung erfolgt über Gruppen, denen die entsprechenden Benutzerrechte zugewiesen werden. Auf die Mitglieder dieser Gruppen werden die Gruppenrichtlinieneinstellungen angewendet. Nach diesen Schritten genügt es, für die Delegierung Benutzerkonten zu den erstellten Gruppen hinzuzufügen. Das gewährleistet größtmögliche Sicherheit und ermöglicht es den Administratoren, ihre übertragenen Aufgaben weiterhin zu erfüllen.

Der Zugriff auf die Gruppenrichtlinien ist auf vertrauenswürdige Personen einzuschränken. Benutzer, deren Konten die Erstellung und Änderung von Gruppenrichtlinieneinstellungen zulassen, können anderen Benutzerkonten über diese Richtlinien höhere Berechtigungen einräumen und müssen folglich vertrauenswürdig sein.

Datenadministratoren werden als Ersteller eines Objektes gleichzeitig auch dessen Besitzer. Im Zugriffssteuerungsmodell von Windows Server verfügt der Besitzer eines Objektes über Vollzugriff auf dieses Objekt. Dazu gehört auch die Möglichkeit, die ACL des Objektes zu ändern. Der Besitzer eines Objektes verfügt außerdem über Vollzugriff auf alle untergeordneten Objekte. Er hat des Weiteren die Möglichkeit, die ACL-Vererbung von übergeordneten Objekten zu sperren und den Zugriff von Dienste-Administratoren auf dieses Objekt zu blockieren.

Es ist sicherzustellen, dass die Gruppen "Administratoren" bzw. "Domänenadministratoren" in den einzelnen Domänen Besitzer des Domänenstammobjektes für die jeweilige Domänenpartition sind. Die Besitzer dieser Partitionsstammobjekte können über vererbliche Access Control Entries (ACEs) die Sicherheitseinstellungen aller anderen Objekte in dieser Partition ändern.

Es ist sicherzustellen, dass bei der Planung von Kontenverwaltungsaufgaben die Gruppenzugehörigkeit in einem delegierten Bereich von einem einzigen Datenadministrator geändert wird oder aber die Aufgabe unter Abstimmung weniger Datenadministratoren erfolgt. Falls im Rahmen der Replikation ein Konflikt zwischen zwei gleichzeitigen Änderungen der Gruppenzugehörigkeit durch verschiedene Domänencontroller festgestellt wird, hat die aktuellste Änderung an einem Konto Vorrang. Bis zur Serverrepliktation ist die auf dem jeweiligen Server eingerichtete Änderung gültig.

Der Einsatz von domänenlokalen Gruppen für die Steuerung der Leseberechtigung für Objektattribute, die in den globalen Katalog repliziert werden, sollte vermieden werden, da hierbei fälschlicherweise der Objektzugriff verweigert oder gewährt werden könnte. Um dennoch Zugriffe auf die Daten des globalen Katalogs zu steuern, sollten stattdessen globale oder universelle Gruppen verwendet werden.

Papierkorb

Bis Windows Server 2008 mussten versehentlich gelöscht AD-Objekte oder solche, die absichtlich gelöscht, aber trotzdem später wieder benötigt wurden, aufwändig und fehleranfällig aus Backups wiederhergestellt werden. In Windows Server 2008 R2 wurde ein Papierkorb (Trash Bin) eingeführt, der jedoch nur von der Kommandozeile aus bedient werden konnte. Erst seit Windows Server 2012 existiert ein einfach zu verwendender Papierkorb, der sowohl von der Kommandozeile per PowerShell als auch per GUI bedient werden kann.

Der Papierkorb ist standardmäßig deaktiviert. Er sollte aktiviert werden, um den Verlust von AD-Objekten zu verhindern. Einmal aktiviert, lässt sich der Papierkorb nicht mehr ausschalten. Da er Domain Functional Level Windows Server 2008 R2 verlangt, müssen alle Domänencontroller im Wald mindestens dieses Level besitzen. Mit einmal aktiviertem Papierkorb lässt sich das Functional Level daher auch nicht mehr auf ein älteres zurückrollen, sodass bei erstmaliger Aktivierung eine gründliche Planung notwendig ist. Wie alle Änderungen am AD sollte auch diese zunächst in einer Testumgebung getestet werden.

Die Aktivierung wird als Organisations-Admin oder Schema-Admin im ADAC (AD Administration Center) in der Forest Root Domain (FRD) durchgeführt. Danach sollte die Anzeige des ADAC neu geladen werden, um die Aktivierung zu prüfen. Diese muss sich nun noch durch den Wald replizieren, bis gelöschte Objekte wiederhergestellt werden können.

Enterprise Identity Management

Über eine separat zu beschaffende Enterprise Identity Management-Lösung kann insbesondere in großen Institutionen sichergestellt werden, dass die Rechte aller Anwender definierten Vorgaben entsprechen.

2.2 Standard-Maßnahmen

Gemeinsam mit den Basis-Maßnahmen entsprechen die folgenden Maßnahmen dem Stand der Technik im Bereich Active Directory.

APP.2.2.M8 Konfiguration des sicheren Kanals unter Windows

Zwischen Rechnern einer Windows-Domäne müssen administrative Daten ausgetauscht werden. So tauschen beispielsweise Domänencontroller einer Domäne Verwaltungsdaten aus. Generell werden dabei sensitive Daten transportiert, die abgesichert übertragen werden müssen. Schon unter Windows NT stand dafür der so genannte Sichere Kanal (englisch Secure Channel) zur Verfügung. Auch unter Windows ab Version 2000 wird dieser Mechanismus genutzt und muss entsprechend den Sicherheitsanforderungen und den lokalen Gegebenheiten konfiguriert werden. Hierbei werden als Sicherheitsmechanismen die Authentisierung der beiden Kommunikationspartner, Verschlüsselung zur Wahrung der Vertraulichkeit und Signaturen zur Absicherung der Integrität eingesetzt.

Die Konfiguration des sicheren Kanals erfolgt über Gruppenrichtlinien. Bei deren Konfiguration ist Folgendes zu berücksichtigen:

  • Die gegenseitige Authentisierung ist immer gewährleistet, Verschlüsselung und Signatur können jedoch unabhängig voneinander gefordert werden. Unterstützt der Kommunikationspartner die geforderte Absicherung nicht, wird diese nicht eingesetzt. Die Kommunikation erfolgt dann ungesichert.
  • Verschlüsselung oder Signatur können als notwendige Voraussetzung für die Kommunikationsaufnahme spezifiziert werden. Unterstützt der Kommunikationspartner die Absicherung nicht, wird keine Kommunikation aufgebaut. Dies kann zum Beispiel zur Folge haben, dass sich Clients nicht an einer Domäne anmelden können. Diese Option sollte nur aktiviert werden, wenn alle IT-Systeme einer Domäne und alle IT-Systeme aller vertrauten Domänen das Verschlüsseln und Signieren unterstützen. Dies ist ab Windows Server 2000 der Fall und sollte daher heutzutage als gegeben vorausgesetzt werden können.

Bei Windows Server (sowie Clients seit Windows XP) lauten die Einstellungen:

  • Domänenmitglied: Daten des sicheren Kanals digital signieren (wenn möglich)
  • Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln (wenn möglich)
  • Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer)
  • Domänenmitglied: Starker Sitzungsschlüssel erforderlich (Verschlüsselung mit 128 Bit, immer wenn Windows 2000 oder höher)
  • Domänenmitglied: Änderungen von Computerkennwörtern deaktivieren
  • Domänenmitglied: Maximalalter von Computerkennwörtern (Standard: 30 Tage, sollte im Normalfall nicht auf größere Werte geändert werden)

Diese Parameter finden sich unter Computerkonfiguration | Windows-Einstellungen | Sicherheitseinstellungen | Lokale Richtlinien | Sicherheitsoptionen. Alle Optionen sollten entsprechend aktiviert werden.

APP.2.2.M9 Schutz der Authentisierung beim Einsatz von Active Directory

Das Active Directory fungiert innerhalb des Netzes als zentrale Komponente. Um eine vertrauenswürdige Kommunikation zwischen den betroffenen Teilnehmern innerhalb des Netzes gewährleisten zu können, ist die Sicherheit und Zuverlässigkeit hinsichtlich der Authentisierung und Autorisierung beim Zugriff auf Netzressourcen erforderlich. Um einen möglichst hohen Schutz der Active Directory-Authentisierung zu erhalten, sollte die LAN-Manager-Authentisierung deaktiviert und der Server-Message-Block-Datenverkehr (SMB-Datenverkehr) zwischen Domänencontrollern sowie zwischen Domänencontroller und Computern der Domäne signiert werden. Ferner sollte der prä-Windows-2000-kompatible Zugriff deaktiviert, sowie die anonymen Zugriffe auf die Domänencontroller eingeschränkt werden.

Authentisierung

Ein hohes Maß an Sicherheit kann nur erreicht werden, wenn alle Domänencontroller, Mitgliedsserver und Arbeitsstationen mindestens das Authentisierungsprotokoll NTLMv2 (NT LAN Manager Version 2) unterstützen. NTLMv2 steht standardmäßig ab Windows NT 4.0 SP4 zur Verfügung. Ältere Authentisierungsprotokolle aus früheren Windows-Versionen bieten eine geringere Sicherheit. So werden beispielsweise bei dem LAN-Manager-Authentisierungsprotokoll (LM) die Kontokennwörter in einem unsicheren LM-Hashformat gespeichert. Die Kennwörter für das Windows-NT-Authentisierungsprotokoll NT LAN Manager (NTLM) und NT LAN Manager Version 2 (NTLMv2) werden im NTLM-Hashformat abgelegt. Der NTLM-Hash ist kryptografisch stärker als das LM-Hashformat.

Unsichere Legacy-Authentisierung per LM und NTLMv1 sollte dringend per GPO verboten werden. Falls wegen des Einsatzes von Legacy-Systemen noch nicht möglich, so muss die Umstellung auf NTLMv2 oder (da auch in NTLMv2 Schwachstellen in Bezug auf Replay-Angriffe bestehen) noch besser reines Kerberos mindestens geplant und ein Termin festgelegt werden.

Windows Server ab 2008 R2 kann unsichere Authentisierung im Netz per NTLM oder schlechter identifizieren und melden und so helfen, die Umstellung zu planen.

SMB-Signatur

Das SMB-Protokoll bildet die Grundlage für die Microsoft Datei- und Druckfreigabe sowie für viele andere Netzoperationen wie z. B. die Remoteverwaltung von Windows. Um beispielsweise Man-in-the-Middle-Angriffe zu verhindern, bei denen SMB-Pakete während der Übertragung geändert werden, unterstützt das SMB-Protokoll die digitale Signatur von SMB-Paketen.

Dafür sollten folgende vier Einstellungen unter Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options aktiviert werden:

  • Microsoft Network Client: Digitally Sign Communications (Always)
  • Microsoft Network Server: Digitally Sign Communications (Always)
  • Microsoft Network Client: Digitally Sign Communications (If Server Agrees)
  • Microsoft Network Server: Digitally Sign Communications (If Client Agrees)

APP.2.2.M10 Sicherer Einsatz von DNS für Active Directory

Eine Active Directory-Installation besteht üblicherweise aus mehreren Servern mit unterschiedlichen Verzeichnispartitionen. Damit der Zugriff sowohl für die Clients als auch der Zugriff zwischen den Servern z. B. bei der Replikation erleichtert wird, verwendet Active Directory DNS (Domain Name System) für die Suche nach Active Directory-Servern. Somit muss der DNS-Dienst als eine Grundlage des Active Directory angesehen werden.

Um die Integrität und Verfügbarkeit des Active Directory sicherzustellen, ist dafür Sorge zu tragen, dass DNS-Clientabfragen nicht durch unautorisierte Systeme im Netz fehlgeleitet werden können. In Windows-Umgebungen sollte der Schutz der DNS-Daten durch in Active Directory integrierte DNS-Zonen auf den Domänencontrollern erhöht werden. Dabei werden die zonenspezifischen DNS-Daten in dem Container "MicrosoftDNS" des Active Directory gespeichert.

Die Konfigurationsdaten für in Active Directory integrierte DNS-Zonen werden in der Windows-Registry abgelegt. Der Zugriff auf die Konfigurationsdaten sollte auf administrative Konten beschränkt werden.

Im Folgenden wird ausschließlich auf in Active Directory integrierte DNS-Zonen und damit auf die Windows Server-spezifischen Eigenschaften zur Unterstützung des sicheren Betriebs von Active Directory eingegangen. Darüber hinausgehende, allgemeine Maßnahmen zur Absicherung von DNS werden hier nicht beschrieben.

Zum Schutz der DNS-Infrastruktur sollten die DNS-Server geschützt werden sowie auf den DNS-Servern gespeicherte DNS-Daten ausreichend abgesichert werden und die Integrität der DNS-Antworten auf die Client-Anfragen bei der Übertragung gesichert werden. Wie dies umgesetzt werden kann, wird im Folgenden erläutert.

Um die Integrität der auf dem Domänencontroller zwischengespeicherten DNS-Daten zu gewährleisten, muss die Option "Zwischenspeicher vor Beschädigungen sichern" für den DNS-Server-Prozess aktiviert werden. Damit soll sichergestellt werden, dass ausschließlich autorisierte DNS-Einträge im Zwischenspeicher eingefügt werden können.

Der Zugriff auf den DNS-Dienst der Domänencontroller sollte so weit wie möglich eingeschränkt werden. Dies kann z. B. dadurch erreicht werden, dass an den Sicherheitsgateways zwischen zwei Netzsegmenten der DNS-Dienst (UDP-Port 53) eingeschränkt wird. Der DNS-Dienst muss dabei für folgende Komponenten verfügbar sein:

  • zwischen den DNS-Clients und dem entsprechenden DNS-Server,
  • zwischen DNS-Servern, die Zonentransfers durchführen,
  • zwischen DNS-Servern, die Client-Anfragen an die entsprechenden Zonen delegieren, und den für die jeweilige Zone verantwortlichen DNS-Servern,
  • zwischen DNS-Servern, die Client-Anfragen weiterleiten und den DNS-Servern der übergeordneten Hierarchieebene.

Des Weiteren sollten die Netzaktivitäten in Bezug auf DNS-Anfragen überwacht werden, da ein ungewöhnlich hohes Aufkommen an DNS-Anfragen auf einen Denial-of-Service-Angriff (DoS-Angriff) gegen einen DNS-Server und damit unter Umständen auch gegen einen Domänencontroller hindeuten kann. In diesem Falle sollte der Angreifer möglichst schnell identifiziert und entsprechende Gegenmaßnahmen eingeleitet werden (siehe auch Maßnahme Erstellung eines Notfallplans im Baustein APP.2.1 Allgemeiner Verzeichnisdienstes).

Mittels IPsec (Internet Protocol Security) kann die Vertraulichkeit, Authentizität und Integrität des IP-Datenverkehrs im Netz sichergestellt werden. Bei einem IPsec-Verbindungsaufbau authentisieren sich Client und Server gegenseitig, so dass die Authentizität der Daten vom DNS-Client überprüft werden kann.

Die Integrität der DNS-Daten bei der Übertragung kann durch IPsec bei der Verwendung von Authentication Header (AH) bzw. durch Encapsulating Security Payload (ESP) sichergestellt werden.

Im Gegensatz zum Authentication Header des IPsec wird bei der Verwendung von ESP der Datenverkehr zusätzlich verschlüsselt. Durch ESP ist ebenfalls die Vertraulichkeit der DNS-Daten sichergestellt. ESP sollte daher bevorzugt werden.

Durch die Verwendung von IPsec erhöht sich das Datenaufkommen. Daher sollte vor dem Einsatz von IPsec sichergestellt werden, dass ausreichend Ressourcen vorhanden sind, damit bei aktivierter Verschlüsselung bzw. Signierung ein ausreichender Datendurchsatz im Netz möglich ist.

Ausreichende Absicherung der gespeicherten DNS-Daten

Für den Schutz der DNS-Daten auf dem Server sollten folgende Punkte berücksichtigt werden:

  • Bei Windows Server-Betriebssystemen wird ein DNS-Server mitgeliefert. Wird dieser verwendet, muss er so konfiguriert werden, dass nur Registrierungsanforderungen von autorisierten Clients der Active Directory-Gesamtstruktur verarbeitet werden. Falls er nicht verwendet wird, ist er zu deaktivieren.
  • Wird ein DNS-Server eines anderen Herstellers verwendet, so ist darauf zu achten, dass dieser die sichere dynamische Aktualisierung der DNS-Daten unterstützt und entsprechend konfiguriert wurde.
  • Der Zugriff von Benutzern auf die DNS-Daten im entsprechenden Active Directory-Container "MicrosoftDNS" sollte über ACLs so eingerichtet werden, dass nur Administratoren, Domänen-Administratoren, Organisations-Administratoren und DNS-Administratoren Vollzugriff auf die Domänendaten besitzen.
  • Die Administration der DNS-Server und damit auch der DNS-Daten ist ebenso kritisch wie die Konfiguration des Active Directory. Daher ist bei der Vergabe der Administratorberechtigungen in gleicher Art und Weise vorzugehen wie bei der Vergabe der Berechtigungen für die Dienste-Administratorkonten (siehe APP.2.2.M2 Planung der Active Directory-Administration)
  • Die Informationen sekundärer DNS-Zonen werden auf einem Domänencontroller nicht im Active Directory, sondern in einer textbasierten Zonendatei gespeichert. Wenn möglich sollte auf eine verteilte DNS-Struktur zurückgegriffen werden, bei der jeder DNS-Server nur eine Zone verwaltet und entsprechende Client-Anfragen von den anderen Servern an den verantwortlichen DNS-Server weitergeleitet werden. Können sekundäre DNS-Zonen auf diese Weise nicht vermieden werden, z. B. aufgrund des erhöhten Datenvolumens, so muss die Zonen-Datei mittels NTFS-Berechtigungen vor unbefugten Zugriffen geschützt werden. Lediglich die allgemeinen Administratoren, Domänen-Administratoren, Organisations-Administratoren und DNS-Administratoren sollten Vollzugriff auf die sekundären Domänen-Daten erhalten.

Weiterführende Informationen zur Konfiguration von DNS-Servern finden sich online im Dokument "Securing the DNS Server Service" im Microsoft TechNet.

APP.2.2.M11 Überwachung der Active Directory-Infrastruktur

Der Sicherheitsstatus der Active Directory Infrastruktur wird über die Protokollierung der systemeigenen Ereignisse überwacht und bewertet. Die Protokolltiefe ist den jeweiligen Anforderungen anzupassen und sollte regelmäßig neu bewertet werden.

Die Protokolldaten sollten regelmäßig ausgewertet werden. Zur Kontrolle sollten sie des Weiteren zusätzlich mit einem Referenzwert verglichen werden, der sich beispielsweise aus früheren Daten ermitteln lässt.

Active Directory

Die Auswertung der bei der Überwachung erzeugten Protokolldaten kann in Abhängigkeit von deren Umfang manuell oder mit der Hilfe spezieller Überwachungssoftware erfolgen. In großen Active Directory-Strukturen kann normalerweise eine rein manuelle Auswertung der Überwachungsdaten nicht mehr realisiert werden.

Die Ergebnisse der Sicherheitsüberwachung sollten in regelmäßig erstellten Berichten zusammengefasst und ausgewertet werden, damit grundlegende Sicherheitsprobleme frühzeitig erkannt und behoben werden können.

Bei der Protokollierung können auch Sicherheitswarnungen auftreten, auf die sofort reagiert werden muss, so wie es im Notfallplan (siehe auch Baustein Notfallmanagement) der Institution vorgesehen ist.

Es können grundsätzlich zwei Methoden angewandt werden, um Änderungen an sicherheitsrelevanten Konfigurationsparametern des Domänencontrollers bzw. des Active Directory zu erkennen. Zum einen ist dies die Ereignisbenachrichtigung, zum anderen sind das Trendanalysen.

Für die Ereignisbenachrichtigung werden so genannte Schwellen- oder Grenzwerte für Änderungen von Konfigurationsparametern im Active Directory oder am Domänencontroller selbst definiert. Wird ein Konfigurationsparameter abgeändert und somit ein zuvor definierter Grenzwert überschritten, so wird dieses Ereignis vom Betriebssystem protokolliert.

Im Rahmen der Trendanalyse werden festgelegte Parameter über einen längeren Zeitraum in regelmäßigen Abständen erfasst. Werden bei der Auswertung dieser Daten extreme Änderungen bemerkt, so könnte das auf sicherheitsrelevante Vorfälle hindeuten. Wird beispielsweise der freie Festplattenspeicherplatz in regelmäßigen Abständen (z. B. alle 5 Minuten) erfasst und ein dramatischer Anstieg des Verbrauches von Festplattenspeicher bemerkt, so kann das auf einen Denial-of-Service-Angriff (DoS) gegen den Domänencontroller hinweisen.

Änderungen des Domänencontroller-Status

Änderungen an den Domänencontrollern können die Sicherheit des Active Directory beeinflussen. Daher sollten mindestens die Bereiche Verfügbarkeit und Systemressourcen der Domänencontroller überwacht werden:

Die Verfügbarkeit von Domänencontrollern kann auf verschiedene Weise überwacht werden. Denkbar ist beispielsweise der Einsatz spezieller Überwachungssoftware. Alternativ können jedoch auch regelmäßige LDAP-Anfragen an die Domänencontroller geschickt werden. Dabei kann mit dieser Methode nicht nur bestimmt werden, ob der entsprechende Domänencontroller aktiv ist (der Test-Client erhält eine Antwort), sondern zusätzlich können aus der Antwortzeit auch Rückschlüsse auf die Systemauslastung des Domänencontrollers gezogen werden.

Es ist außerdem sicherzustellen, dass Neustarts der Domänencontroller erkannt werden, da ein nicht autorisierter Neustart von Domänencontrollern auf einen Angriff hindeuten kann. Dementsprechend sind die Systemereignisprotokolle aller Domänencontroller in einer Institution auf unautorisierte Systemneustarts zu untersuchen.

Zusätzlich zur direkten Verfügbarkeit von Domänencontrollern sollten auch die Systemressourcen der Domänencontroller überwacht werden. Eine Änderung der Systemressourcen muss nicht zwangsläufig auf einen Angriff hindeuten. Vielmehr kann die Ursache auch technischer Natur sein, z. B. Fehlkonfiguration oder Verwendung veralteter Hardware bei wachsenden Active Directory-Strukturen.

Folgende Systemressourcen sollten auf allen Domänencontrollern in einer Institution überwacht werden:

  • Prozentuale Prozessorauslastung (oberer Grenzwert: 80%)
  • Freier Speicherplatz auf dem Datenträger mit der Active Directory-Datenbank in Prozent (unterer Grenzwert: 25%)
  • Verfügbarer Arbeitsspeicher in Prozent (unterer Grenzwert: 10%)
  • Bindungsdauer für LDAP-Verbindungen (Auffällig wäre eine ungewöhnlich starke Zunahme der Bindungsdauer.)
  • Anzahl erfolgreicher LDAP-Verbindungen pro Sekunde (Auffällig wäre eine ungewöhnlich starke Zunahme der LDAP-Verbindungen. Der jeweilige Grenzwert hängt hierbei von dem Datenaufkommen von LDAP Verbindungen innerhalb der Institution ab.)

Änderungen im Active Directory

Werden Änderungen auf Domänenebene durchgeführt, so wirken sich diese meist auf alle Domänencontroller, Mitgliedsserver, Benutzer und Arbeitsstationen aus. Folgende Änderungen sind in diesem Zusammenhang denkbar:

  • Ändern der domänenweiten Betriebsmasterfunktion
    Änderungen an den domänenweiten Betriebsmasterfunktionen wirken sich auf die gesamte Domäne aus. Zu den domänenweiten Betriebsmasterfunktionen gehört unter anderem der Emulationsmaster des Primären Domänen Controllers (PDC). Dies kann sich im Falle einer Fehlkonfiguration negativ auf das Gesamtkonstrukt der Domäne auswirken und zu weitreichenden Beeinträchtigungen innerhalb des Netzes führen. Eine im Vorfeld sorgfältig durchgeführte Planung hinsichtlich angedachter Änderungen an den Betriebsmasterfunktionen ist daher unabdingbar.
  • Ändern der Vertrauensstellungen
    Zwischen unterschiedlichen Domänen einer Institution können Vertrauensbeziehungen eingerichtet werden. Änderungen an Vertrauensbeziehungen müssen unbedingt überwacht werden, damit insbesondere das Hinzufügen von Vertrauensbeziehungen und damit unter Umständen erweiterte Rechte der Domänen-Benutzer schnellstmöglich erkannt werden.
  • Ändern des AdminSDHolder
    Das AdminSDHolder-Objekt wird vom primären Domänencontroller (PDC) verwendet, um die Benutzer der Dienste-Administratorgruppen und die Dienste-Administratorengruppe selbst vor nicht autorisierten Veränderungen der Berechtigungen zu schützen. Dazu sollte vom PDC stündlich überprüft werden, ob die benutzerbestimmbaren Zugriffskontrolllisten (D ACLs, Discretionary Access Control Lists) der zuvor genannten Benutzerkonten mit der DACL des AdminSDHolder-Objekt übereinstimmen. Weichen die DACLs voneinander ab, so müssen die DACLs der Benutzerkonten an die Einstellung des AdminSDHolder-Objekts angepasst werden.
  • Änderungen an Gruppenrichtlinienobjekte und deren Zuweisung
    Änderungen an den Gruppenrichtlinien wie z. B. Passwortrichtlinien für Domänenbenutzer wirken sich auf die Domäne und damit auch auf alle Domänencontroller der betroffenen Domäne aus und sind daher zu überwachen Darüber hinaus sind auch die Zuweisungen von Gruppenrichtlinienobjekten zu Domänen Containern sowie von Gruppenrichtlinienobjekten zur Organisationseinheit "Domänencontroller" zu überwachen.
  • Ändern der Mitgliedschaft vordefinierter Dienste-Administratorgruppen
    Das unautorisierte Hinzufügen oder Entfernen von Benutzern in vordefinierten Dienste-Administratorgruppen wie z. B. Administratoren oder Sicherungs-Operatoren kann auf einen Angriff hindeuten. Daher sind Änderungen an Mitgliedschaften von Diensteadministratorgruppen zu überwachen.
  • Überwachung der Mitgliedschaft in der privilegierten Gruppen
    Die Gruppen mit administrativen Rechten in Bezug auf das AD müssen regelmäßig betrachtet werden, insbesondere wenn neue Mitglieder hinzugefügt werden. Noch effektiver ist ein System (technisch oder organisatorisch implementiert), das eine formale Bestätigung einholt, bevor ein Konto einer privilegierten Gruppe hinzugefügt wird. Dieses System kann auch Nutzer aus Gruppen ausschließen, wenn ihre Genehmigung der Mitgliedschaft abläuft
  • Ändern der Überwachungsrichtlinien für eine Domäne
    Eine unautorisierte Änderung an den Überwachungsrichtlinien kann die Überwachung stören oder sogar komplett deaktivieren. Damit eine Deaktivierung der Überwachung erkannt werden kann, müssen die Überwachungsrichtlinien selbst auch überwacht werden.

Werden Änderungen durchgeführt, die sich auf die gesamte Active-Directory-Struktur, z. B. alle definierten Domänen, der Institution auswirken, so spricht man von Änderungen an der Gesamtstruktur. Änderungen an der Gesamtstruktur umfassen folgende Ereignisse:

  • Änderungen an der Einstufung von Domänencontrollern
    Wird ein Domänencontroller herauf- oder herabgestuft, so wird von Änderungen an der Domänencontroller-Einstufung gesprochen.
  • Änderungen am Active Directory-Schema
    Wird die Struktur der Verzeichnisdienstdatenbank verändert, z. B. bei Änderungen von Objektklassen oder Attributen innerhalb des Active Directory, so wird das Active Directory-Schema geändert.
  • Änderungen der LDAP-Richtlinien
    Mit Hilfe von LDAP-Richtlinien können LDAP-Anfragen und damit ebenfalls der Zugriff auf die Active Directory-Daten per LDAP eingeschränkt werden.
  • Änderungen an der Replikationstopologie zwischen Domänencontrollern
    Unter Änderungen der Replikationstopologie wird das Erstellen, Löschen und Ändern von Active Directory-Standorten, Standortverknüpfungen und Subnetzen verstanden.
  • Ändern des dSHeuristic-Attributs
    Das dSHeuristic-Attribut steuert das Verhalten des Active Directory, hierüber kann z. B. die Auflistung von Objekten aktiviert oder deaktiviert werden.
  • Änderungen der gesamtstrukturweiten Betriebsmasterfunktionen
    Die gesamtstrukturweiten Betriebsmasterfunktionen werden historisch auch als Flexible oder Floating Single Master Operations (FSMO ) bezeichnet. Zu den FSMO zählen die Schemamaster- und die Domänen-Master-Funktion.

Alle zuvor genannten Änderungsereignisse, sowohl auf Ebene einzelner Domänen als auch in Bezug auf die Gesamtstruktur, sollten auf allen Domänencontrollern einer Institution überwacht und ausgewertet werden. Wird bei der Auswertung der Sicherheitsüberwachungsprotokolle eines Domänencontroller eine nicht autorisierte Änderung festgestellt, so sind entsprechende Notfallmaßnahmen einzuleiten, die im Vorfeld geplant sein müssen.

Bei einigen Ereignissen ist aus den Protokolldateien nicht ersichtlich, welche Objekte oder Attribute geändert wurden. Daher ist das Schema des Active Directory zu dokumentieren, damit Änderungen später gegebenenfalls durch manuellen Abgleich identifiziert und behoben werden können.

Kann die vollständige Behebung unautorisierter Änderungen im Active Directory nicht sichergestellt werden, so ist die Wiederherstellung der Gesamtstruktur in Erwägung zu ziehen.

In der Gruppe "Dienst-Admins" ist die Erstellung, Löschung und Änderung von Benutzerkonten in der Dienste-Administratorgruppe zu überwachen. Darüber hinaus sollte ein Hinzufügen oder Löschen von Administratorarbeitsstationen in der Organisationseinheit "Dienst-Admins" überwacht werden.

Wenn der Speicherplatz auf dem Domänencontroller für die Active Directory-Datenbank erschöpft ist, können keine neuen Objekte im Active Directory mehr angelegt werden. Daher sollte der Speicherplatz, der von Active Directory-Objekten verwendet wird, kontinuierlich überwacht werden.

Mit einer derartigen Überwachung kann nicht nur der zur Neige gehende Speicherplatz für die Active Directory-Datenbank verfolgt werden, sondern es können auch Objektüberflutungsangriffe erkannt werden, bei denen der Speicherplatzbedarf in vergleichsweise kurzer Zeit dramatisch ansteigt.

Für ein schnelles Eingreifen bei einem Objektüberflutungsangriff kann auf den Domänencontrollern eine Reservedatei beliebiger Größe angelegt werden. Im Fall eines Speicherplatzangriffs kann die Reservedatei auf den betroffenen Domänencontrollern gelöscht werden, um kurzfristig freien Speicherplatz zu schaffen und so den normalen Betrieb zu sichern.

Im Nachgang müssen die unerwünschten Objekte des Angriffs im Active Directory ermittelt und entfernt werden.

Änderungen an kritischen Dateien

Sowohl auf den Domänencontrollern selbst als auch an den Administrationsarbeitsplätzen sollte eine Überwachung eingerichtet werden, mit der eine Veränderung an kritischen Dateien erkannt werden kann. Dabei sollten mindestens die Dateien überwacht werden, die zur Konfiguration des Betriebssystems und der installierten Anwendungen verwendet werden. Darüber hinaus sollten wichtige ausführbare Dateien, z. B. Administrationswerkzeuge auf den Administratorarbeitsplätzen, ebenfalls auf Änderungen überwacht werden.

Für die Überwachung der Systemkonfiguration muss zunächst eine geeignete Software ausgewählt werden. Anschließend sollte eine vertrauenswürdige Basiskonfiguration der zu überwachenden Betriebssysteme erstellt werden.

Mit Hilfe der Überwachungssoftware wird auf Basis dieser Konfiguration ein Referenzabbild erstellt, das als Grundlage für zukünftige Überprüfungen verwendet wird. In regelmäßigen Abständen ist zu überprüfen, ob sich die aktuelle Konfiguration der Domänencontroller oder Administratoren-Arbeitsplätze im Vergleich zur Referenzkonfiguration geändert hat. Werden Änderungen festgestellt, so ist der ursprüngliche Systemzustand schnellstmöglich wieder herzustellen.

APP.2.2.M12 Datensicherung für Domänen-Controller

Da Domänencontroller üblicherweise zentrale Authentisierungs- und Autorisierungsaufgaben für den Zugriff auf wichtige Ressourcen im Netz ermöglichen, führt ein Ausfall unmittelbar zu schwerwiegenden Beeinträchtigungen im Netz. Daher muss für die Datensicherung der Domänencontroller als zentrale IT-Komponenten eine geeignete Vorgehensweise festgelegt werden. Diese sollte entweder im Datensicherungskonzept der Institution oder in einer eigenständigen Datensicherungsrichtlinie dokumentiert sein. Die grundsätzliche Vorgehensweise wird im Baustein OPS.1.1.6 Datensicherung beschrieben. Darüber hinaus sind zusätzlich Domänencontroller-spezifische Besonderheiten bei der Entwicklung der Datensicherungsrichtlinie für Active Directory zu berücksichtigen. Dieses Regelwerk sollte folgende Aspekte berücksichtigen:

  • Auf Domänencontrollern müssen regelmäßig und nachvollziehbar Datensicherungen durchgeführt werden.
  • Es sollten für Datensicherungen keine institutionsweiten, allgemeinen Benutzerkonten verwendet werden.
  • Datensicherungssysteme sollten nur an Standorten aufgestellt werden, bei denen die Sicherheit der Hardware und Medien gewährleistet ist.
  • Es muss regelmäßig getestet werden, ob sich die Domänencontroller unter Verwendung der Sicherungsmedien wiederherstellen lassen.
  • Ausgesonderte Datensicherungsmedien müssen vernichtet werden.

Gegenüber herkömmlichen Server-Sicherungen sollten bei Domänencontrollern die im Folgenden genannten Punkte zusätzlich betrachtet werden:

Die Wiederherstellung eines ausgefallenen Domänencontrollers wird selten unter alleiniger Zuhilfenahme von Datensicherungsmedien durchgeführt. Bewährt hat sich hierbei die Hochstufung eines Mitgliedsservers zum Domänencontroller und anschließende Replizierung der Active Directory-Daten von einem anderen Domänencontroller. Diese Methode kann allerdings nur dann verwendet werden, wenn durch den Einsatz mehrerer Domänencontroller nach dem Ausfall eines oder mehrerer Systeme noch mindestens ein gültiges Replikat des Active Directory existiert.

Existierte lediglich ein Domänencontroller oder ist nach dem Ausfall der Domänencontroller kein Active Directory-Replikat mehr verfügbar, so muss die Wiederherstellung über die Datensicherungsmedien erfolgen. Dabei ist zu beachten, dass unter Umständen Probleme wie fehlerhafte Sicherungsmedien, unvollständige Wiederherstellungsverfahren oder fehlende Verfahrenskenntnisse bei den Verantwortlichen auftreten können. Um diesen Problemen entgegenzuwirken ist sicherzustellen, dass die Administratoren mit den Wiederherstellungsverfahren für die Gesamtstruktur vertraut sind.

Auswahl kompatibler Sicherungssoftware

Werden die Metadaten der zu sichernden Dateien vom Datensicherungsprogramm nicht korrekt behandelt, so kann dies ebenso wie bei der Verwendung ungeeigneter Virenschutzprogramme zu einer erhöhten Dateireplizierung durch den File Replication Service (FRS) führen.

Ähnlich wie beim Einsatz von Virenschutz-Programmen (siehe APP.2.2.A5 Härtung des Active Directory) ist daher bei der Auswahl der Datensicherungssoftware zwingend darauf zu achten, dass die einzusetzende Software für die Datensicherung von Domänencontrollern vom Hersteller freigegeben wurde.

Besondere Sicherheitsanforderungen

Das Dienstkonto, mit dem Domänencontroller gesichert werden, muss über Dienste-Administratorrechte und damit über hohe Rechte verfügen. Um dem Missbrauch dieser Rechte vorzubeugen, sollte der Benutzerkreis, der Zugang zu diesen Konten hat, möglichst gering gehalten werden.

Daher empfiehlt es sich, für den Sicherungsagenten auf den Domänencontrollern andere Dienstkonten zu verwenden als auf den übrigen Servern der Institution. Unterschiedliche Benutzerkonten auf Domänencontrollern und anderen Servern schützen darüber hinaus den Domänencontroller zusätzlich, für den Fall, dass ein herkömmlicher Server der Institution kompromittiert wurde.

Des Weiteren sollten die Mitglieder der Gruppe "Sicherungs-Operatoren" auf Benutzer beschränkt werden, die zur Datensicherung der Systemdateien erforderlich sind. Benutzer, die für die Datensicherung von Anwendungsdaten zuständig sind, sollten nicht Mitglied der Gruppe "Sicherungs-Operatoren" des Domänencontrollers sein. Vielmehr sollten diese Benutzer als Mitglieder in der lokalen Gruppe "Sicherungs-Operatoren" des jeweiligen Anwendungsservers eingetragen werden.

Die Domänen-Gruppe "Sicherungs-Operatoren" ist standardmäßig nicht besonders geschützt. Um einen entsprechenden Schutz umzusetzen, ist der Zugriff auf das entsprechende AdminSDHolder-Objekt (Containerobjekt zur Speicherung von Berechtigungen) möglichst eng zu reglementieren (siehe APP.2.2.M7 Umsetzung sicherer Verwaltungsmethoden für Active Directory).

Es müssen in regelmäßigen Abständen Datensicherungen der Domänencontroller durchgeführt werden. Bei der Festlegung eines geeigneten Sicherungsintervalls ist zu berücksichtigen, dass zur Löschung markierte Active Directory-Objekte nicht direkt aus dem Active Directory entfernt, sondern zunächst in einen speziellen Container des Active Directory ("Gelöschte Objekte") verschoben werden. Solche zur Löschung markierten Objekte werden als veraltete oder auch als "Tombstone"-Objekte bezeichnet.

Nach einer einstellbaren Zeitdauer (Standard: 60 Tage) werden die veralteten Objekte dann endgültig gelöscht. Dieses Verfahren hat den Vorteil, dass versehentlich gelöschte Objekte innerhalb der Frist wieder aktiviert werden können. Bei der Löschung wird das Konto bzw. Objekt daher zunächst effektiv deaktiviert, so dass es nicht mehr genutzt werden kann. Stellt sich allerdings heraus, dass es voreilig gelöscht wurde, kann es schnell wiederhergestellt werden.

Um Probleme bei der Replizierung zu vermeiden, sollte darauf geachtet werden, dass die Datensicherungen so wenig wie möglich veraltete Objekte mit überschrittener Lebensdauer beinhalten. Um dies sicherzustellen, sollten die Sicherungsmedien nach circa 75% der Lebensdauer von veralteten Objekten im Rahmen der regelmäßigen Sicherung überschrieben werden. Es sollte also möglichst häufig gesichert werden, allerdings ist dabei zu empfehlen, die Backup-Medien nach 45 Tagen (bei einer Objektlebensdauer von 60 Tagen) wieder mit neuen Backups zu überschreiben, damit eine Wiederherstellung veralteter Objekte ausgeschlossen wird.

Da die Datensicherungsmedien der Domänencontroller alle Informationen der Active Directory-Datenbank beinhalten, sollten für jene die gleichen physikalischen Sicherheitsvorkehrungen getroffen werden wie sie auch für die Domänencontroller gelten. Insbesondere für die Sicherung in Niederlassungen muss überprüft werden, ob eine ausreichende Sicherheit der Sicherungshardware und -medien gewährleistet werden kann. Hierfür gibt es folgende Möglichkeiten:

  • Es erfolgt keine Datensicherung der Domänencontroller in den Niederlassungen.
  • Die Datensicherung in den Niederlassungen erfolgt mit Hilfe von Remote-Sicherungssystemen (Offline-Medien) in sichere Rechenzentren.
  • Die Datensicherung in den Niederlassungen erfolgt mit Hilfe von lokalen Sicherungen auf Datenträgern.

Diese Optionen sind hinsichtlich des administrativen Aufwands, der Verzögerung durch die Wiederherstellung und der Sicherheitsgewährleistung zu prüfen. Der Zustand und die Tauglichkeit der Datensicherungsmedien muss in regelmäßigen Abständen geprüft werden, indem Datenwiederherstellungen durchgeführt werden.

Die vor Ort verwendeten Sicherungsmedien müssen an einer sicheren und überwachten Stelle aufbewahrt werden, um Änderungen oder Diebstähle von Daten zu verhindern. Das Medium selbst ist nur während der Sicherung und Wiederherstellung im entsprechenden Laufwerk einzusetzen. Auch sollten Verfahren erstellt werden, die Unterschriften autorisierter Administratoren vorsehen, wenn Archivsicherungsmedien zurückgeholt werden.

Auswahl der zu sichernden Domänencontroller

Sind Domänencontroller an mehreren Standorten verteilt (z. B. in Zweigniederlassungen), so sollten Datensicherungslösungen angestrebt werden, die eine angemessene Absicherung des Backup-Verfahrens und der hierfür benutzten Medien zulassen. Es ist darauf zu achten, dass standortübergreifend für alle Domänencontroller das Datensicherungskonzept angemessen umgesetzt wird. Existieren an einem Standort z. B. keine sichere Lagerungsmöglichkeiten für die Sicherungsmedien, so sollten die Sicherungsmedien an einen geeigneten Standort ausgelagert werden.

Für Niederlassungen sind Remote-Lösungen denkbar, bei denen die zu sichernden Daten an einem zentralen Standort über das Netz eingesammelt werden. Folgende Punkte sind im Rahmen einer Remote-Datensicherungslösung zu beachten:

  • Die Integrität und Vertraulichkeit der Daten sind bei der Übertragung über das Netz durch geeignete Maßnahmen zu schützen, z. B. durch Verschlüsseln der zu sichernden Daten vor oder während der Übertragung.
  • Es muss ausreichend Bandbreite zur Verfügung stehen, sodass weder der Betrieb noch die Datensicherung während eines Remote-Backups gestört wird.
  • Wird die Datensicherung zunächst lokal in den Standorten durchgeführt und dann von einer zentralen Stelle aus die Backup-Medien eingesammelt, so ist der Zugriff entsprechend abzusichern, z. B. ist der Zugriff auf Dateifreigaben mit den lokal zwischengespeicherten Datensicherungen auf Domänenadministratoren zu beschränken.

Inkrementelle Sicherungen

Zur platzsparenden Datensicherung wird bei Systemdateien häufig auf inkrementelle Datensicherungsverfahren zurückgegriffen. Bei diesen Verfahren werden ausschließlich die Dateien gesichert, die sich seit der letzten Datensicherung geändert haben. Im Falle einer Wiederherstellung bringt dieses Verfahren jedoch auch einen erhöhten Zeitbedarf mit sich. Inkrementelle Datensicherung sollte für Domänencontroller nicht angewendet werden, auch der Hersteller rät davon ab.

Wiederherstellungsmethoden

Wenn trotzdem inkrementelle Datensicherungen angefertigt werden, werden hierbei nur die seit der letzten Komplettsicherung neu erstellten Daten gesichert. Ältere Aktualitätsstände werden nicht berücksichtigt. In Einzelfällen kann allerdings die Anforderung bestehen, ältere Aktualitätsstände wiederherzustellen und entsprechend zu replizieren, z. B. im Zuge einer Roll-Back-Aktion. Die hiervon betroffenen Daten können mit Hilfe des Kommandozeilen-Werkzeugs ntdsutil für eine Replizierung priorisiert werden. Bei der Priorisierung wird festgelegt, welche Daten aus der Sicherung wiederhergestellt bzw. welche Daten beibehalten werden sollen. Aus diesem Grund ist das Priorisieren der Daten sorgfältig durchzuführen, da es hierbei sonst zu Inkonsistenzen in der Gesamtstruktur kommen kann, z. B. dass gesperrte oder ungültige Benutzerkonten wieder verfügbar sind.

Die Datensicherung und Wiederherstellung von Domänencontrollern mittels einer Image-Erstellung wird aufgrund der auftretenden Inkonsistenz beim USN-Rollback (Update Sequence Number Rollback) nicht empfohlen.

Ausreichende Verfügbarkeit von Sicherungen

Damit die Datensicherungen im Notfall auch verfügbar sind, muss am Ende jedes Sicherungsvorganges überprüft werden, ob er fehlerfrei durchgeführt werden konnte.

In allen Domänen sollte regelmäßig eine Überprüfung der Datensicherungen durchgeführt werden, um drei Aspekte sicherzustellen:

  • Es muss sichergestellt sein, dass in der betreffenden Woche ausreichend Domänencontroller erfolgreich gesichert wurden.
  • Es ist sicherzustellen, dass die erstellten Sicherungsmedien deutlich mit der eindeutigen Bezeichnung des Domänencontrollers und dem Datum der Datensicherung beschriftet und anschließend sicher aufbewahrt werden. Dabei sollte die Beschriftung der Sicherungsmedien die Funktion des Domänencontrollers einschließen, um eine spätere Identifizierung zu erleichtern.
  • Im Fall einer erfolglosen Datensicherung ist der Fehler schnellstmöglich zu beheben.

Dabei ist in regelmäßigen Abständen zu testen, ob sich die Datensicherungen auch wieder einspielen lassen. Erfolgreich geprüfte Backup-Medien sollten entsprechend gekennzeichnet werden. Diese Tests sind in einer gesonderten Testumgebung, die von der Produktionsumgebung getrennt ist, durchzuführen.

2.3 Maßnahmen für erhöhten Schutzbedarf

Im Folgenden sind Maßnahmenvorschläge aufgeführt, die über das dem Stand der Technik entsprechende Schutzniveau hinausgehen und bei erhöhtem Schutzbedarf in Betracht gezogen werden sollten. Die jeweils in Klammern angegebenen Buchstaben zeigen an, welche Grundwerte durch die Maßnahme vorrangig geschützt werden (C = Vertraulichkeit, I = Integrität, A = Verfügbarkeit).

APP.2.2.M13 Zwei-Faktor-Authentifizierung(CIA)

Privilegierte Konten im Bereich des AD sollten mittels Zwei-Faktor-Authentifizierung geschützt werden. Für diesen Zweck können Smartcards verwendet werden. Smartcards alleine bieten jedoch keinen Schutz vor Kompromittierung, da Smartcard-Logon-Sessions einen NTLM-Hash haben, der bei ungeeigneter Konfiguration von Angreifern ausgelesen werden und im Rahmen von Pass-the-Hash-Angriffen missbraucht werden können. Die Maßnahme ist daher mit der sicheren Konfiguration und Härtung des AD im Zusammenhang zu sehen.

APP.2.2.M14 Dedizierte privilegierte Administrationssysteme(CIA)

Es ist möglich, die Administration der Active Directory Services lediglich von besonders für diese Aufgabe bereitgestellten (also dedizierten) und besonders für diesen Zweck gehärteten Systemen aus durchzuführen und den administrativen Zugriff von allen anderen Systemen zu unterbinden. Derartige Systeme werden häufig als PAWs (Privileged Access Workstations) oder auch, so etwa bei Microsoft intern, als SAWs (Secure Admin Workstations) bezeichnet.

Empfohlene Maßnahmen zur Absicherung der PAWs umfassen die folgenden Punkte (für Details siehe die jeweiligen Clientbausteine):

  • UEFI/TPM/Secure Boot/Measured Boot
  • BitLocker
  • Standard User Configuration
  • AppLocker
  • USB Media Restrictions
  • Device Guard (Windows 10)
  • Credential Guard (Windows 10)
  • EMET (abgekündigt)
  • Outbound Traffic restrictions (kein Internet)
  • Inbound Traffic restrictions (Default Deny)
  • Automatische Updates
  • Endpoint Protection
  • Known Good Media Build Process
  • Rapid Build Process
  • Logon Restrictions
  • Microsoft Security Baselines (SCM)
  • Analyse von unsigniertem Code
  • OU und GPO ACL Lockdowns
  • Lateral Traversal Mitigation(s)
  • Nur autorisierte Verwaltungswerkzeuge

APP.2.2.M15 Trennung von Administrations- und Produktionsumgebung(CIA)

Zur Partitionierung der Benutzerdaten kann die Administrationsumgebung in einen separaten Forest ausgelagert werden. Zwischen dem Administrations- und dem Produktionsforest wird ein einseitiger Trust etabliert, so dass die Produktionsumgebung dem Administrationsforest vertraut. Diese Möglichkeit bietet einige Vorteile. So können Konten in der Administrationsumgebung als Standard-Benutzer provisioniert werden, die in der eigenen Umgebung keine besonderen Rechte haben, aber in der Produktionsumgebung hochprivilegiert sind. Weiter können so durch die selektive Authentisierung der Vertrauensstellung weitere Einschränkungen getroffen werden, welche Konten zur Anmeldung an welchen Systemen verwendet werden können.

Bei Microsoft wird das Konzept unter dem Namen "Enhanced Security Administrative Environment" (ESAE) geführt. Dies beschreibt einen Satz von Referenzimplementierungen, die auf der Grundidee der Bildung von "Tiers" (Schichten) für Workstations, Server und AD beruhen. Verschiedene Varianten nutzen unterschiedlich viele Wälder und Zusatztechnologien wie Microsoft Identity Manager (MIM) oder Privileged Access Management (PAM) für feingranulare Kontrolle von Rechten und Protokollierung privilegierter Handlungen.

Jede Institution muss sich ihr eigenes Tiering-Konzept gemäß den eigenen erhöhten Sicherheitsanforderungen erstellen und validieren.

Abstufung von Schutzschichten

Domaincontroller > Server > Workstations

Alle Systeme sollten nach drei Kategorien eingeteilt werden:

  • Kritische Systeme (Domaincontroller, CA…), die Kontrolle über andere Systeme haben
  • Server (Produktions-IT)
  • Workstations (Office-IT)

Kein System einer unteren Schicht darf Kontrolle über ein System der darüber liegenden Schicht(en) haben.

Aufwand und Komplexität

Zu beachten ist, dass Einrichtung und Betrieb mehrerer Wälder eine hohe Komplexität und möglicherweise erhebliche Kosten mit sich bringt, da viele Systeme und Dienste mehrfach vorgehalten werden müssen. Dies betrifft nicht nur die AD-Infrastruktur selbst, sondern bei konsequenter Umsetzung der Idee auch weitere Infrastrukturkomponenten wie WSUS, Antivirus, Backup sowie Clients/Workstations.

3 Weiterführende Informationen

3.1 Wissenswertes

Hier werden ergänzende Informationen aufgeführt, die im Rahmen der Maßnahmen keinen Platz finden, aber dennoch beachtenswert sind. Derzeit liegen für diesen Baustein keine entsprechenden Informationen vor. Sachdienliche Hinweise nimmt die IT-Grundschutz-Hotline gerne unter grundschutz@bsi.bund.de entgegen.

3.2 Literatur

Weiterführende Informationen zu Gefährdungen und Sicherheitsmaßnahmen im Bereich "Active Directory" finden sich unter anderem in folgenden Veröffentlichungen:

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK