Sicherheitskonfiguration im AD

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.