Das Active Directory führt die Authentifizierung von Benutzern durch und erstellt das für die Autorisierung von Zugriffen erforderliche Access Token. Dieses wird wiederum vom Betriebssystem beispielsweise beim Zugriff auf das NTFS-Dateisystem verarbeitet.
Gleichzeitig ist das Active Directory aber selbst auch ein Dienst, bei dem Zugriffe autorisiert werden müssen. Auch dazu wird das Access Token verwendet.
In diesem Artikel wird auf verschiedene Aspekte der Sicherheitskonfiguration des Active Directory in Bezug auf Authentifizierung und Autorisierung, eingegangen.
Die Grundlage: Authentifizierung
Das Active Directory ist der wichtigste Speicher für sicherheitsrelevante Informationen in Windows-Netzwerken. Dort werden die Benutzer und Computerobjekte angelegt, für die eine Authentifizierung erfolgen muss. Die Objekte sind eindeutig durch die SID gekennzeichnet, wie übrigens auch Gruppen. Letztere werden allerdings nur bei der Autorisierung benötigt.
Wichtig ist, dass das Active Directory dabei zunächst „nur“ ein Speicher ist. Ein Teil der Informationen wurde bereits früher von den Domänencontrollern von Windows NT 4.0 gespeichert. Ebenso können auch heute noch auf allen Systemen außer den Domänencontrollern lokale Benutzerkonten definiert werden.
Die Authentifizierung erfolgt daher auch nicht durch das Active Directory, sondern gegen das Active Directory. Das wird schon daran deutlich, dass Kerberos als eigenständiger Dienst in der Liste der Dienste aufgeführt ist. Es gibt ebenso wie für NTLM eine Kerberos-Authentifizierungsmethode, die von der LSA (Local Security Authority) aufgerufen werden kann. Diese Methode nutzt wiederum den Kerberos-Dienst und das Active Directory, um die Authentifizierung durchzuführen.
Das Active Directory nimmt aber dennoch eine zentrale Position ein, da es eben als Repository für die Authentifizierungsinformationen dient. Der gezielte Schutz des Verzeichnisdienstes ist deshalb sehr wichtig. Das gilt umso mehr, als man darauf über Werkzeuge wie ldp.exe und andere LDAP-Schnittstellen sehr einfach zugreifen kann. Wenn die Berechtigungen innerhalb des Active Directory nicht gezielt eingeschränkt werden, entstehen signifikante Sicherheitsrisiken.
Die Sicherung des Active Directory
Die Sicherung des Active Directory muss auf mehreren Ebenen erfolgen. Das beginnt bei der physischen Sicherheit, die bei Domänencontrollern besonders wichtig ist. Zwar sind die sensiblen Informationen dort verschlüsselt oder als Hash abgelegt – dennoch sind die Datenbanken auf Domänencontrollern besonders sicherheitskritisch.
Die weiteren Ebenen sind die generellen Regeln für den Zugriff auf die Domänencontroller – also die Sicherheitskonfiguration für das Active Directory – und die Sicherheitseinstellungen für das Betriebssystem. Der Schwerpunkt in diesem Artikel liegt auf den Sicherheitseinstellungen für das Active Directory.
Zugriffsberechtigungen im Active Directory
Im Active Directory können Zugriffsberechtigungen mit unterschiedlichen Werkzeugen gesetzt werden. Dabei ist zu beachten, dass sowohl die Anwendung Active Directory-Benutzer und - Computer als auch Active Directory-Standorte und -Dienste jeweils nur einen Ausschnitt des Active Directory zeigen. Das gilt auch, wenn die Option Erweiterte Funktionen im Menü Ansicht bei Active Directory-Benutzer und -Computer ausgewählt wurde.
In Bezug auf das Sicherheitsmanagement ist dies eine wichtige Einschränkung. Mit den Funktionen dieser Anwendungen kann keine vollständige Sicherheitskonfiguration für das Active Directory durchgeführt werden.
Mit ADSI Edit steht ein Tool zur Verfügung, das Zugriff auf alle Bereiche des Active Directory erlaubt und das für die Vergabe von Sicherheitseinstellungen geeignet ist. ADSI Edit ist Teil der Windows Support Tools, zu finden im Ordner support\tools auf der Windows Server-CD geliefert. Mit ADSI Edit kann der Benutzer auf alle Bereiche des Active Directory zugreifen und dort die Zugriffsberechtigungen setzen. Da die Zugriffsberechtigungen wie alle anderen Informationen repliziert werden, muss diese Anpassung für jede Domäne nur einmal erfolgen. Interessant ist, dass trotz der insgesamt deutlich umfassenderen Informationen bei ADSI Edit die Schnittstelle für die Vergabe von Zugriffsberechtigungen identisch zu den anderen Anwendungen ist.
Man kann sich allerdings mit ADSI Edit auch darauf beschränken, die Sicherheitseinstellungen für die Partitionen Configuration und Schema anzupassen, da die Objekte in der Domäne zumindest bei Auswahl von Ansicht/Erweiterte Funktionen in Active Directory-Benutzer und - Computer vollständig angezeigt werden.
Über den Befehl Eigenschaften im Kontextmenü eines Objekts gelangt man zum Dialog Properties. Der Befehl findet sich bei allen Objekten unterhalb der Partitionen. Im Register Sicherheit wird zunächst die normale Ansicht der ACLs angezeigt, in der auf relativ hoher, abstrakter Ebene Zugriffsberechtigungen vergeben werden können.
Einige der Einstellungen sind allerdings bereits recht detailliert. Wenn beispielsweise die Eigenschaften auf der obersten Ebene unterhalb von Domain gewählt werden, finden sich neben Standardberechtigungen wie Vollzugriff oder Lesen auch speziellere Einstellungen wie Active Directory-Replikation überwachen, PDC ändern oder SID-Verlauf migrieren. Auf den darunter liegenden Ebenen gibt es keine solchen speziellen Einstellungen, dafür aber direkt unterhalb von Configuration und unterhalb von Schema.
Die dort zu findenden zusätzlichen Parameter sind sehr wichtig, um grundlegende Administrationsaufgaben im Active Directory zu delegieren. Es bietet sich an, diese genauer zu analysieren und zu entscheiden, welche der Einstellungen gegebenenfalls speziell angepasst werden müssen.
Falls die Berechtigungen auf dieser hohen Ebene nicht ausreichen, kann über die Schaltfläche Erweitert zum Dialogfeld Erweiterte Sicherheitseinstellungen gewechselt werden. Dort finden sich alle einzelnen ACEs (Access Control Entries) die auch darüber informieren, ob und von wo eine Berechtigung geerbt wurde. Interessant ist, dass sich dort auf der obersten Ebene eine Reihe einzelner Einträge für verschiedene wichtige Aufgaben wie die Synchronisation von Repliken innerhalb des Active Directory gibt (Bild 4) befinden.
Wichtig ist, dass die Berechtigungen für spezielle Benutzer wie Domänencontroller nicht modifiziert werden dürfen, um ein korrektes Verhalten des Systems sicherzustellen.
Diese Einträge können wiederum über Bearbeiten angepasst werden, ebenso wie sich mit Hinzufügen zusätzliche Berechtigungen erstellen lassen. Bei dieser Modifikation der Berechtigungen sollten einige Funktionen besonders beachtet werden:
-
Die Liste der Berechtigungen im Register Objekt ist grundsätzlich sehr lang. Hier finden sich meist spezielle Berechtigungen, insbesondere auf der obersten Ebene.
-
Im Listenfeld Übernehmen für kann ausgewählt werden, für welchen Bereich und welche Objektklassen die Berechtigungen gelten sollen. Das ist vor allem wichtig, um Berechtigungen nur für ausgewählte Objektklassen zu vergeben, beispielsweise nur die Klasse user oder nur spezielle Objektklassen, die von einer Anwendung im Active Directory angelegt werden.
-
Im Register Eigenschaften können Berechtigungen noch differenzierter konfiguriert werden. Hier findet sich eine Liste aller Eigenschaften, für die Berechtigungen gesetzt werden können. Es ist in der Regel nicht empfehlenswert, diese direkt zu modifizieren, da das sehr schnell sehr unübersichtlich wird. Bei speziellen Anforderungen für die Delegation von administrativen Berechtigungen können Eingriffe auf dieser Ebene aber erforderlich werden.
Es ist in jedem Fall nötig, die hier konfigurierten Sicherheitseinstellungen genau zu dokumentieren, um später nachvollziehen zu können, wer was machen darf. Dabei sollten die Standardberechtigungen für Administratoren normalerweise nicht angepasst werden. Vielmehr sollte mit zusätzlichen Operatorengruppen gearbeitet werden, denen die für ihre Aufgaben erforderlichen eingeschränkten Berechtigungen zugeordnet werden.
Die Delegation administrativer Berechtigungen
Für die standardmäßig (also ohne Ansicht/Erweiterte Funktionen in Active Directory-Benutzer und -Computer sowie Active Directory-Standorte und -Dienste) angezeigten Ordner kann die Zuweisung von Berechtigungen auch auf einfachere Weise über den Assistenten für die Delegation von Berechtigungen – von Microsoft als Assistent für die Zuweisung von Objektberechtigungen bezeichnet – erfolgen. Damit gibt es keine so differenzierten Steuerungsmöglichkeiten wie zuvor beschrieben. Für die Zuweisung zusätzlicher Berechtigungen an neu definierte Operatorengruppen sind die Möglichkeiten aber in der Regel ausreichend, wenn man von speziellen Berechtigungen beispielsweise beim Replikationsmanagement oder Schema-Management absieht.
Der Assistent arbeitet in zwei verschiedenen Modi. Im ersten Fall können die gleichen Berechtigungen wie bei der direkten Bearbeitung einzelner ACEs, nur eben über den Assistenten, gesetzt werden. Diese Option steht bei allen Ordnern zur Verfügung, bei denen der Assistent über den Befehl Objektverwaltung zuweisen im Kontextmenü aufgerufen werden kann. Der zweite Fall sind vordefinierte, spezielle Berechtigungen. Diese finden sich im Verwaltungsprogramm Active Directory-Benutzer und -Computer bei den Knoten
-
Domäne (oberste Ebene)
-
Computers
-
Domain Controllers
-
ForeignSecurityPrincipals
-
Program Data
-
System
-
Users
sowie bei Active Directory-Standorte und -Dienste bei den jeweiligen Standorten. Bei letzteren kann nur die Berechtigung zur Zuordnung von Gruppenrichtlinienobjekten konfiguriert werden.
Bei dem Assistenten kann im zweiten Fall nach der Auswahl der Gruppe – oder Benutzer, was aber nicht empfehlenswert ist – entweder ein vorkonfigurierter Task ausgewählt (Bild 6) oder mit Benutzerdefinierte Tasks zum Zuweisen erstellen direkt zum Berechtigungsmanagement gewechselt werden. Im ersten Fall ist die Konfiguration damit abgeschlossen. Im zweiten Fall kann ausgewählt werden, ob die Delegation für alle Objektklassen oder nur für ausgewählte Objektklassen erfolgen soll. Anschließend können die einzelnen Berechtigungen bis auf Eigenschaftsebene hinunter konfiguriert werden.
Damit können Aufgaben delegiert werden, die standardmäßig nicht vorgesehen sind. Ob man dazu allerdings über den Assistenten oder direkt über die vorgestellten Dialogfelder für das Berechtigungsmanagement arbeitet, ist Geschmacksache.
Standardgruppen für die Administration
Die Zuordnung der Berechtigungen ist ein wesentlicher Teil der Sicherung des Active Directory. Zwangsläufig stellt sich die Frage, zu welchen Gruppen diese Zuordnung erfolgen soll. Eine Zuweisung an einzelne Benutzer ist praktisch nie sinnvoll, da das die Administration sehr unübersichtlich macht.
In den Containern Builtin sowie Users des Active Directory finden sich die vordefinierten Gruppen. Die wichtigsten Administratoren-gruppen sind bei Users definiert. Hier finden sich
-
Domänen-Admins (Administratoren für die aktuelle Domäne)
-
Organisations-Admins (Administratoren mit spezifischen Berechtigungen für den gesamten Forest)
-
Schema-Admins (Administratoren mit der Forest-weiten Berechtigung zur Anpassung des Schemas).
Die beiden zuletzt genannten Gruppen gibt es allerdings nur in der Forest Root-Domäne. Außerdem werden je nach installierten Diensten weitere Gruppen wie DnsAdmins angelegt, die für die Administration dieser Dienste erforderlich sind.
Im Container Builtin finden sich dagegen Gruppen, die primär aus Gründen der Abwärtskompatibilität weiter benutzt werden. So stammen Gruppen wie die Konten-Operatoren oder Sicherungs-Operatoren noch aus Windows NT- oder sogar LAN Manager-Zeiten. Diese Gruppen können dennoch für die Zuweisung von operativen Berechtigungen weiterhin eingesetzt werden.
Alternativ und ergänzend dazu kann auch ein spezielles Rollenkonzept entwickelt werden. Das ist in der Regel auch empfehlenswert, um verschiedene Aufgaben gezielt verschiedenen Rollen zuzuweisen. Bedauerlich ist, dass – zumindest ohne erheblichen Programmieraufwand – keine zusätzlichen Tasks definiert werden können, sondern jeweils eine direkte Zuweisung von Zugriffsberechtigungen zu den einzelnen Rollen erfolgen muss.
Da Benutzer aber mehreren Gruppen zugeordnet werden können und es mit den globalen und lokalen (sowie optional den universalen) Gruppen auch Hierarchien gibt, können die lokalen Gruppen für die Repräsentation von einzelnen Aufgaben (Tasks) und die globalen Gruppen für die eigentlichen Rollen eingesetzt werden. Auf diese Weise entstehen zwar relativ viele lokale Gruppen. Die Administration wird aber dennoch sehr viel einfacher und übersichtlicher. Konkret würden also beispielsweise lokale Gruppen für das Zurücksetzen von Kennwörtern oder das Management der Zuordnung von Gruppenrichtlinien in verschiedenen Containern erstellt. Durch die Zuordnung von Benutzern zu globalen Gruppen und von globalen Gruppen zu lokalen Gruppen lassen sich die effizienten Berechtigungen anschließend einfach verwalten.
Vertrauensstellungen und deren spezifische Risiken
Vor einigen Jahren gab es größere Diskussionen, weil sich herausgestellt hatte, dass nicht die Domäne, sondern nur der Forest eine wirksame Sicherheitsgrenze darstellt. Innerhalb eines Forests ist es möglich, dass sich durch Modifikation des Attributs SIDhistory Administratoren Zugriffsberechtigungen in anderen Domänen verschaffen. Das Attribut kann beispielsweise über ADSI Edit einfach angepasst werden (Bild 7). Dieses Risiko lässt sich nicht vollständig ausschließen, da einige der Konzepte für das Funktionieren anderer Bereiche der Sicherheit und der Replikation des Active Directories erforderlich sind.
Eine Beschreibung der Problematik findet sich unter anderem im Artikel 289243 der Knowledge Base von Microsoft.
Für ein Active Directory-Sicherheitskonzept ist das in mehrfacher Hinsicht von Bedeutung:
-
Es muss auch unter diesem Aspekt überlegt werden, ob mit mehreren Forests gearbeitet werden muss und wo die Grenzen zwischen diesen Forests definiert werden. Die Nutzung mehrerer Forests ist durch die Unterstützung von Vertrauensstellungen zwischen verschiedenen Forests beim Windows Server 2003 deutlich einfacher geworden.
-
Innerhalb von Forests muss man sich bewusst sein, dass ein potenzielles Risiko dafür besteht, dass sich ein Benutzer mit administrativen Berechtigungen solche Rechte auch unberechtigt in einer anderen Domänen verschafft. Man muss hier abschätzen, wie hoch das Risiko ist. Durch die restriktive Vergabe von administrativen und operativen Berechtigungen lassen sich die realen, operationalen Risiken in diesem Bereich verringern – ausschließen lassen sich Probleme aber grundsätzlich nicht.
-
Bei der Definition von expliziten Vertrauensstellungen auf der Ebene von Domänen muss gegebenenfalls mit der SID-Filterung gearbeitet werden. Wenn beispielsweise der Domäne beratung vertraut wird, können die SIDs anderer Domänen aus der SIDhistory ausgefiltert werden. Wichtig ist insbesondere, dass man SIDs ausfiltert, die administrative Berechtigungen in der eigenen Domäne über die SIDhistory geben würden. Da die SIDs wichtiger administrativer Konten nach einem standardisierten Konzept aufgebaut werden, ist es für einen Angreifer relativ einfach, aus der SID einer Domäne und der RID (Relative Identitifier) eines solchen Accounts einen SID zu erstellen und in die SIDhistory aufzunehmen.
Die SID-Filterung wird ab dem Service Pack 4 von Windows 2000 generell genutzt. Bei älteren Systemen oder schon länger bestehenden Vertrauensstellungen muss sie dagegen explizit aktiviert werden. Weitere Informationen dazu finden sich unter www.go.microsoft.com/fwlink/?LinkId=18545 oder http://go.microsoft.com/fwlink/?LinkId=35413.
Es ist grundsätzlich möglich, die SID-Filterung mit netdom.exe zu deaktivieren, wenn man den Administratoren eines anderen, vertrauten Forests vertrauen kann. Das macht aber nur Sinn, wenn man es in der SIDhistory überhaupt Informationen gibt, die von der Filterung betroffen sind.
In den meisten Umgebungen dürfte das Risiko, dass durch die SIDhistory entstehen kann, als gering einzustufen sein. Es ist aber ein Aspekt, der bei der Planung berücksichtigt werden muss.
Die Konfiguration der Authentifizierung
Neben den Sicherheitseinstellungen, die im Active Directory vorgenommen werden, spielt auch die Authentifizierung für die Sicherheit eine wichtige Rolle. Dabei ist zu beachten, dass sich die Authentifizierungsmechanismen nur beschränkt steuern lassen.
In den Gruppenrichtlinien kann zwar die LAN Manager-Authentifizierungsebene für die Authentifizierung im Netzwerk konfiguriert werden (Bild 8). Das schränkt aber nur ein, in welcher Form eine NTLM-Authentifizierung durchgeführt werden kann. Es gibt aber keine Einstellung, mit der beispielsweise zwingend die Verwendung von Kerberos durchgesetzt werden könnte. Das liegt auch daran, dass es bestimmte Funktionen im System gibt, die noch auf NTLM angewiesen sind.
Hinzu kommt, dass es neben der NTLM- und Kerberos-Authentifizierung auch die LDAPSchnittstelle gibt. Diese wird beispielsweise von ldp.exe, aber auch allen anderen LDAP-Clients genutzt. Über diese Schnittstelle können auch nicht verschlüsselte Zugriffe erfolgen. Die potenziellen Sicherheitsprobleme lassen sich allenfalls darüber beschränken, dass man an definierten Stellen wie Firewalls die Verwendung von Port 636 und damit LDAP over SSL erzwingt.
Außerdem gibt es auch noch die Authentifizierung über die IIS oder andere Webserver, wobei die IIS durch ihre enge Integration mit dem Active Directory an erster Stelle zu nennen sind. Auch hier gibt es mehrere Mechanismen mit einem deutlich unterschiedlichen Grad an erreichbarer Sicherheit.
Die Konsequenz daraus, dass sich zumindest durch Konfigurationseinstellungen beim Active Directory selbst keine Verwendung von definierten, starken Authentifizierungsmechanismen erzwingen lässt, muss sein, dass man operative respektive administrative Benutzerkonten sauber von normalen Benutzerkonten trennt und durch Regelungen und Überwachungseinstellungen sicherstellt, dass die Operatoren- und Administratorenkonten ausschließlich für die entsprechenden verwaltenden Aufgabenstellungen, nicht aber für die tägliche Arbeit verwendet werden. Gleichzeitig muss man über die Sicherheitseinstellungen im Active Directory dafür sorgen, dass normale Anwender nur die minimal erforderlichen Zugriffsberechtigungen haben.
In den Gruppenrichtlinien sollten übrigens nicht nur Sicherheitseinstellungen wie die Festlegung der LAN Manager-Authentifizierungsebene vorgenommen werden. Zusätzlich ist es auch zwingend nötig, dass man die Gruppenrichtlinien und hier spezifisch die Default Domain Controllers Policy nutzt, um weitere Sicherheitseinstellungen für die Domänencontroller vorzunehmen. Dazu zählt unter anderem die Einschränkung der Dienste, die auf diesen Systemen ausgeführt werden dürfen.
Überwachung
Neben der konsequenten Festlegung von Sicherheitseinstellungen ist für eine hohe Sicherheit im Active Directory auch erforderlich, dass man die Zugriffe darauf überwacht. Dafür müssen die entsprechenden Überwachungseinstellungen gesetzt werden. Der erste Schritt dabei ist die Aktivierung von Verzeichnisdienstzugriff überwachen im Bereich Computerkonfiguration/Windows Einstellungen/Sicherheitseinstellungen/Lokale Richtlinien/Überwachungsrichtlinie der Gruppenrichtlinie, über die Domänencontroller konfiguriert werden – also in der Regel der Default Domain Controllers Policy (Bild 9). Zusätzlich muss bei den Zugriffsberechtigungen im Active Directory konfiguriert werden, bei welchen Objekten welche Zugriffe durch welche Benutzer überwacht werden sollen.
Die Festlegungen dazu finden sich bei den erweiterten Sicherheitseinstellungen im Register Überwachung. Dort können in ähnlicher Form wie ACEs auch Einträge für die Überwachung festgelegt werden. Es gibt einige Standardeinträge, die konfiguriert sind und die als Ausgangsbasis dienen können (Bild 10).
Die Standardeinträge reichen für eine wirksame und vollständige Überwachung nicht aus. So wird das Anlegen neuer Objekte dadurch nicht wirksam erfasst, was aber wichtig ist.
Der Security Configuration Wizard
Im Zusammenhang mit der Sicherheit des Active Directory und von Windows-Servern generell ist auch der Sicherheitskonfigurations-Assistent (Security Configuration Wizard) erwähnenswert, der ab dem Service Pack 1 für den Windows Server 2003 verfügbar ist. Mit diesem Assistenten können auf Basis vordefinierter Serverrollen Einschränkungen für die Sicherheit definiert werden.
Der Assistent muss über den Bereich Software der Systemsteuerung explizit installiert werden. Er arbeitet über XML-Dateien, in denen die Konfigurationsinformationen abgespeichert werden. Der Vorteil des Assistenten liegt in seiner einfachen Nutzbarkeit, auch im Vergleich mit den Gruppenrichtlinien. Letztere sind aber vor allem in größeren Netzwerken die bessere Alternative zur Sicherung des Active Directory, da sie noch mehr Konfigurationsoptionen beinhalten und deutlich besser nachvollziehbar sind.
Schon die Vielzahl unterschiedlicher Konfigurationsansätze macht aber deutlich, wie planungsaufwändig und komplex die Sicherung des Active Directory ist. Eine solche Planung und Konfiguration ist aber unerlässlich, um an dieser zentralen Stelle des Netzwerks keine unkalkulierbaren Sicherheitsrisiken entstehen zu lassen.