Kennwort-Optionen für Benutzer

Sicherheit ist eines der zentralen IT-Themen. Daher verwundert es auch nicht, dass es im Active Directory eine beachtliche Menge von Optionen gibt, mit denen die Authentifizierung von Benutzern gesteuert werden kann. Einige davon sind wohlbekannt, andere dagegen kaum. Wenn man in Active Directory-Benutzer und -Computer ein Benutzerkonto öffnet und dort auf das Register Konto zugreift, findet man neben den verschiedenen Anmeldenamen, einem Ablaufdatum und Steuerungsoptionen für die Anmeldezeiten auch noch die Kontooptionen. In dieser Liste ist eine beachtliche Zahl von Optionen untergebracht, die auf die Authentifizierung von Benutzern und damit auf die Sicherheit von Active-Directory-Umgebungen massiven Einfluss haben.

Die Grundeinstellungen

Einige der Einstellungen in dieser Liste sind vertraut oder doch leicht verständlich. Das beginnt bei Benutzer muss Kennwort bei der nächsten Anmeldung ändern. Diese Option sollte immer gesetzt werden, wenn neue Benutzerkonten mit einem Standard-Kennwort angelegt werden oder wenn ein Kennwort von einem Administrator zurückgesetzt wurde.

Dagegen ist Benutzer kann das Kennwort nicht ändern vor allem für spezielle Benutzerkonten wie Gast von Bedeutung. Gast ist ein Konto, das wie auch einzelne andere Konten von mehreren Benutzern verwendet werden kann. In solchen Fällen darf das Kennwort nicht durch einen der Nutzer veränderbar sein, sondern soll nur von Administratoren angepasst werden können. In einzelnen Fällen kann es auch bei Dienstkonten Sinn machen, diese Option zu setzen, wenn mehrere verteilte Komponenten über das Kennwort zugreifen und bei diesen das Kennwort jeweils fest vorgegeben ist.

Wichtiger für Dienstkonten ist aber meist die Option Kennwort läuft nie ab. Damit wird die über die Kontorichtlinien in den Gruppenrichtlinien eventuell festgelegte maximale Lebensdauer für ein Kennwort - beispielsweise 30 Tage - ausser Kraft gesetzt. Ansonsten könnten die Dienste nach diesem Zeitraum nicht mehr starten, weil das Kennwort ungültig wäre. Falls man diese Option bei Dienstkonten verwendet und diese nicht unter Lokales Systemkonto oder Netzwerkdienst ausführt, sollte entsprechend mit starken Kennwörtern gearbeitet und diese dennoch in regelmässigen Abständen anpasst werden. Trotz des so entstehenden Administrationsaufwandes ist es sinnvoller, diesen Weg zu wählen: Wird statt dessen mit den beiden Standard-Systemkonten gearbeitet, kann man doch nur für ein spezielles Dienstkonto auch gezielt Zugriffsberechtigungen festlegen. Ein Vorteil ist auch, dass ein solcherart angelegtes Konto noch nicht zwingend betroffen ist, wenn beispielsweise ein erfolgreicher Angriff auf das lokale Systemkonto erfolgt ist.

Zu den Grundeinstellungen zählt schliesslich noch Konto ist deaktiviert. Damit lässt sich (logischerweise) ein Konto deaktivieren. Es bleibt aber in den ACLs und Benutzergruppen vorhanden und kann bei Bedarf jederzeit wieder aktiviert werden. Wenn man dagegen ein Konto löscht, müssen unter Umständen ein neues Konto erstellt und die gesamten Sicherheitszuweisungen wieder neu vorgenommen werden, während bei der Deaktivierung nur keine Anmeldung mehr erfolgen kann. Das ist beispielsweise bei langen Abwesenheiten von Mitarbeitern sinnvoll.

Die umkehrbare Verschlüsselung

Zu den weniger bekannten Einstellungen gehört hingegen Kennwort mit umkehrbarer Verschlüsselung speichern. Standardmässig werden Kennwörter als Hash gespeichert. Ein Hash ist eine Ableitung über eine Einweg-Funktion. Diese Funktionen zeichnen sich dadurch aus, dass sie ein eindeutiges Ergebnis bei der Anwendung auf eine Zeichenkette erzeugen, aber keine Funktion bekannt ist, mit der aus dem Hash wieder der ursprüngliche Wert hergestellt werden könnte. Damit kann ein Angreifer, der an die gespeicherten Kennwörter gelangt, die Kennwörter nur über eine sogenannte "Dictionary-based attack" herausfinden, indem er für alle möglichen Kennwörter den Hash ermittelt und diesen mit den gespeicherten Hashs vergleicht.

Das Problem bei Hashs ist, dass sie nur mit Authentifizierungsverfahren funktionieren, die ebenfalls einen Hash erzeugen können, der dann mit dem gespeicherten Hash verglichen wird. Es gibt aber einige Authentifizierungsverfahren wie die CHAP-Authentifizierung (Challenge Handshake Authentication Protocol) des Remote Access Services (RAS) oder die Digestauthentifizierung bei den IIS, die wiederherstellbare Kennwörter benötigen. Auch der Zugriff von Apple-Clients wird in diesem Zusammenhang von Microsoft genannt. Darüber hinaus kann diese Option aber auch für Anwendungen der Kennwortsynchronisation Sinn machen.

Die Kennwörter werden dabei nicht unverschlüsselt, sondern eben mit reversibler Verschlüsselung über einen symmetrischen Schlüssel abgelegt. Dieser Schlüssel muss ebenfalls im System gespeichert werden, so dass die Kennwörter bei einem erfolgreichen Angriff gegen den Server nicht mehr sicher sind. Es kann aber eben Anwendungssituationen geben, in denen man ein solches Verfahren einsetzen muss.

Die umkehrbare Verschlüsselung lässt sich einerseits über die Gruppenrichtlinien für den Anwendungsbereich der Richtlinie mit der Einstellung Kennwörter
mit umkehrbarer Verschlüsselung speichern bei Computerkonfiguration - Windows-Einstellungen - Sicherheitseinstellungen - Kontorichtlinien - Kennwortrichtlinien und andererseits individuell für einzelne Konten bei den Eigenschaften des Kontos anpassen.

In diesem Zusammenhang ist auch die Option DES-Verschlüsselungstypen für dieses Konto verwenden von Interesse. Damit wird festgelegt, dass unterschiedliche DES-Verschlüsselungsebenen für die Kontoinformationen eingesetzt werden können - und nur diese. Falls Smartcards eingesetzt werden, lässt sich auch die Option Benutzer muss sich mit einer Smartcard anmelden setzen. Das erzwingt die Anmeldung über die Smartcard; die Kombination von Benutzername und Kennwort ist in einem solchen Fall nicht mehr zulässig.

Kerberos und Delegation

Die übrigen drei Optionen stehen schliesslich im Zusammenhang mit Kerberos und der Delegation. Mit Konto wird für Delegierungszwecke vertraut definiert man, dass ein Konto für die Delegation von Zugriffen verwendet werden darf. Das ist im Zusammenhang mit Dienstkonten von Bedeutung: Ein Benutzer kann sich an einem Dienst anmelden. Ein Dienst wie beispielsweise eine Serveranwendung kann darauf im Kontext des Benutzers auf einen anderen Dienst, beispielsweise einen Datenbankserver zugreifen. Der Benutzer delegiert also eine Aufgabe an einen Dienst, der wiederum unter seiner Identität handelt. Das ist etwa sinnvoll, damit der Dienst nur auf genau diejenigen Daten in der Datenbank zugreifen darf, für die der aktuelle Benutzer ebenfalls Zugriffsrechte hat. Um zu verhindern, dass eine solche Delegation unkontrolliert erfolgt, müssen aber die Konten, an die delegiert wird, explizit dafür aktiviert werden, indem diese Option gesetzt wird.
Mit Konto kann nicht delegiert werden wird im umgekehrten Fall für ein Benutzerkonto festgelegt, dass dort die Delegation nicht möglich ist. Ein Beispiel dafür ist das Konto Gast, bei dem eine solche Delegation meist keinen Sinn macht - Zugriffe eines Dienstes im Kontext von Gast sollten eher die Ausnahme sein. Die Delegation funktioniert nur bei Kerberos.

Schliesslich gibt es noch die Option Keine Kerberos-Präauthentifizierung erforderlich. Wenn diese gesetzt ist, wird die Anforderung eines TGT (Ticket Granting Ticket) nicht verschlüsselt. Das kann aus Gründen der Interoperabilität mit anderen Kerberos-Implementierungen erforderlich sein, ist aber nicht so sicher wie die Standardeinstellung ab Windows 2000, bei der auch dieser erste Schritt der Authentifizierung bereits verschlüsselt erfolgt. Die Liste macht deutlich, dass es mittlerweile eine ganze Reihe von Einstellungen für die Authentifizierung gibt, die - richtig genutzt - zur Sicherheit einer Windows-Umgebung beitragen.

Kerberos, NTLM, Smartcards

Im Zusammenhang mit der Authentifizierung gibt es Optionen für Smartcards und Kerberos bei den Kontooptionen. Neben diesen Festlegungen sind aber auch die Sicherheitsoptionen in den Gruppenrichtlinien interessant. Dort lässt sich das Niveau der NTLM-Authentifizierung konfigurieren. Diese Einstellung wird auf Systemebene gesetzt und findet sich daher nicht bei den Kennwortoptionen. Hier sollten Sie in Umgebungen, in denen nur Systeme ab Windows NT 4.0 SP 4 und höher eingesetzt werden, die NTLMv2-Authentifizierung erzwingen. Diese Einstellung ergänzt die anderen Festlegungen bei den Kontooptionen. Da die Festlegung aber nicht auf Kontoebene erfolgt, sondern nur pro Server, muss sie in einem anderen Bereich gesetzt werden. Nicht steuern lässt sich, ob NTLMv2 überhaupt genutzt wird. Das hängt ausschließlich von den kommunizierenden Systemen, den Anwendungen und den Kommunikationswegen ab. In einer Umgebung, in der nur Windows 2000, Windows XP und der Windows Server 2003 genutzt werden, wird Kerberos
genutzt, falls das möglich ist. NTLMv2 - auch schon sicher - ist dann nur noch die Ausnahme für die Abwärtskompatibilität.