Hinweise zur Einführung bzw. Aktivierung von Kennwortrichtlinien

Hi zusammen. In einigen Domänenumgebungen unserer Kunden sind Kennwortrichtlinien, also beispielsweise die zentrale Vorgabe von Kennwortlänge, Komplexität, minimalem und maximalem Kennwortalter und Kontosperrungsschwellen, bei der Installation / Inbetriebnahme der Domäne deaktiviert worden oder für andere Zwecke, etwa längere Migrationsphasen" o.ä., außer Betrieb genommen.

Möchte man nun nach einiger Zeit (vielleicht sogar nach einigen Jahren) Kennwortrichtlinien wieder in Betrieb nehmen, sind einige Fallstricke zu beachten. So zieht zum Beispiel die Aktivierung des maximalen Kennwortalters z.B. auf 100 Tage den Effekt nach sich, daß die Kennwörter von den Benutzern unter Umständen direkt ablaufen, da sie mehr als diese 100 Tage nicht mehr geändert wurden. Die Aufforderung zur Kennwortänderung passiert bei interaktiven Anmeldungen automatisch, jedoch melden sich einige Benutzer gar nicht interaktiv am System an, sondern nutzen hauptsächlich “extern” Dienste wie Outlook Web-Access, Outlook mittels RPC über HTTP/S, Push-E-Mail, VPN Einwahl usw.

Genau für diese Benutzer kommt es dann unmittelbar nach der Aktivierung der Policies zu Problemen, da Ihr Kennwort abgelaufen ist und sie es nicht von extern setzen können. Zusätzlich sind auch Service Accounts immer wieder ein “heißes Thema” in diesem Kontext.

Im Kern ist es sinnvoll, die Wiedereinführung oder die Ersteinführung von Kennwortrichtlinien in verschiedene Phasen einzuteilen. Diese Phasen könnten wie folgt aussehen:

• Phase 1: Dokumentation des derzeitigen Status, d.h. es erfolgt eine Überprüfung, wie alt die Benutzer-Kennwörter in der Umgebung sind. Das Ergebnis wirkt sich auf das weitere Vorgehen aus.
• Phase 2: Die betroffenen Benutzer und Administratoren müssen über die geplanten Änderungen informiert werden, am besten auf verschiedenen Wegen (E-Mails, Betriebsbekanntmachungen etc.). Dies ist einer der kritischsten und wichtigsten Punkte des Vorhabens – denn rein technisch lassen sich die mit der Re-Aktivierung von Kennwortrichtlinien verbundenen Fallstricke nicht lösen. Eine erfolgreiche Einführung der Kennwortrichtlinien kann nur in sehr enger Zusammenarbeit mit den Beschäftigten erfolgen. Den Mitarbeitern muss nicht nur erklärt werden, dass die Richtlinien eingeführt werden, sondern auch WARUM. Wir schlagen vor, die Aktion Kennwörter mit anderen Aktionen zur Computersicherheit zu ergänzen, zum Beispiel Wechseldatenträger, Arbeiten an öffentlichen Plätzen, Umgang mit mobilen Geräten, usw.
• Phase 3: Identifizieren von Dienstkonten, so daß diese – je nach interner Planung – vor den Kennwortänderungen geschützt sind. So kann beispielsweise das Flag „password never expires“ auf diesen Konten gesetzt werden, so dass Dienstkonten nicht von den Kennwort-Änderungsrichtlinien / Änderungsintervallen betroffen sind. Hier können ggf. auch weitere Konten mit einbezogen werden.
• Phase 4: Implementierung von „schwachen“ Kennwortrichtlinien. Hier wird etwa für das maximale Kennwortalter der unter Windows Server 2003 unterstützte Maximalwert von „999“ Tagen eingesetzt; es werden noch keine Account Lockouts konfiguriert etc. In dieser Phase sollten die Benutzer an regelmäßige Kennwortänderungen gewöhnt werden. Sie sollten Emails erhalten, wenn ihe Kennwort vom Alter her den späteren Zielwert überschreitet. Die Benachrichtigungen sollten dauerhaft beibehalten werden, kommen dann aber einige Wochen vor dem Ablauf des Kennworts.
• Phase 5: Nach erneutem Monitoring des Status der Kennwortänderungen können dann Schritt für Schritt stärkere Werte eingesetzt werden. Hierbei sollte in kleinen Schritten vorgegangen werden, nicht die Zielpolicies gleich im ersten Wechsel eingesetzt werden.

Generell muß gesagt werden, daß das Vorhaben (gerade während der Einführung der Kennwortrichtlinien) als kritisch in Bezug auf die Funktionsfähigkeit der Umgebung angesehen werden muß. D.h. die Planung hat einen hohen Stellenwert auf eine erfolgreiche (Wieder-)Einführung der Kennwortrichtlinien, um Ausfälle in der Produktionsumgebung zu vermeiden.

Es gibt unter Windows Server 2008 (Domain Functional Level 2008) eine neue Möglichkeit, mehrere Kennwortrichtlinien pro Domäne zu konfigurieren. Dies sind die sogenannten “Fine-Grained Password Policies” bzw. “Password Setting Objects”. Da eine stufenweise / gruppenweise Einführung der Kennwortrichtlinien das wahrscheinlich sinnvollste Vorgehen ist, sollte daher geprüft werden, ob mögliche Probleme bei der Einführung der Kennwortrichtlinien unter Windows Server 2003 ein Upgrade der Domänencontroller Umgebung auf Windows Server 2008 (R2) rechtfertigen. Dies kann betriebswirtschaftlich interessant sein. Die PSOs erlauben eine einfachere Verwaltung der Benutzergruppen, die mit den Richtlinien versehen werden.

Beispiele zur möglichen Umsetzung könnten in groben Zügen also wie folgt aussehen:

Es folgen nun einige Hinweise zu den oben genannten möglichen Phasen. Es sollte beachtet werden, daß die Punkte nur einen groben Leitfaden darstellen. Je nach Umgebung können einige Punkte dazu kommen, die hier nicht begesprochen werden.

In Bezug auf die möglichen Einstellungen für Kennwortrichtlinien findet man beispielsweise im “Windows Server 2003 Security Guide” bzw. “Windows Server 2003 Sicherheitshandbuch” die Erklärungen der einzelnen Einstellungen inklusive einiger Hinweise zu den Implikationen der Einstellungen.

Phase 1:
Unter Windows Server 2003 kann nur eine Kennwortrichtlinie pro Domäne eingesetzt werden. Diese gilt dann für alle Benutzerkonten und wird auf den Domänencontrollern angewendet.

Wurden etwa seit mehreren Jahren in einer Domänenumgebung die Kennwortrichtlinien außer Kraft gesetzt, stellt das maximale Kennwortalter ein Problem dar, da der unter Windows Server 2003 unterstützte Maximalwert „999“ Tage beträgt, siehe dazu: Configuring Password Policies „Maximum Password Age“https://technet.microsoft.com/en-us/library/dd277399.aspx

Da der Zeitraum der letzten Kennwortänderung höher als „999“ Tage sein kann, sollte in der Domänenumgebung zuallererst eine Überprüfung der Benutzerkonten in Bezug auf diesen letzten Änderungszeitpunkt erfolgen. Der Zeitraum der letzten Kennwortänderung läßt sich (neben eigenen Scripts) herausfinden, indem man die DS*-Tools auf einem DC nutzt. So kann etwa ein

C:\> dsquery user -stalepwd 999

ausgeben, welche Benutzerkonten vor mehr als 999 Tagen Ihr Kennwort das letzte Mal geändert haben. Siehe dazu auch https://technet.microsoft.com/en-us/library/cc725702(WS.10).aspx zu „dsquery user“.

So kann man verschiedene Benutzergruppen zur Umstellung bilden, wenn man das maximale Kennwortalter ausgelesen und dokumentiert hat.

Zeigt sich, daß fast alle Benutzer vor mehr als „999“ Tagen das Kennwort zuletzt geändert haben, kann keine Gruppeneinteilung erfolgen. Andernfalls hat man jedoch ein gutes Instrument, um die Kennwortrichtlinien stufenweise einzuführen, sieh auch Phase 4.

Die Alternative dazu ist, das maximale Kennwortalter auf den Wert “0” zu stellen, denn dann erfolgt eine Einstufung nach dem Prinzip “Kennwort läuft nie ab”. Damit ist die harte Grenze von “999” Tagen kein Problem mehr.

Phase 2:
Da sich die Umstellung nicht ausschließlich technisch lösen läßt, ist das Involvieren der Benutzer der betroffenen Domäne im Gesamtvorgehen wichtig, wenn nicht sogar der wichtigste Punkt. Ohne die Mitarbeit der Benutzer kann eine erfolgreiche Umstellung nicht erfolgen. Hier sollte die notwendige Sichtbarkeit auch von Seiten des Managements forciert werden, um von vornherein Probleme zu vermeiden.

Wir gehen an dieser Stelle einmal davon aus, daß bezüglich der Kennwortrichtlinien selbst, als auch zu Themen wie „Kennwortweitergabe“, „Kennwort notieren“ etc. interne Richtlinien / Betriebsvereinbarungen existieren. Andernfalls sollte dies geprüft und nachgeholt werden.

Die Benutzer sollten mehrfach und auf verschiedenen Wegen über die vorstehenden Änderungen informiert werden. Als Information sollte neben der Nennung der neuen Kennwortrichtlinien selbst (also welche Schwellwerte existieren, wie genau komplexe Kennwörter aussehen, was die Einführung direkt für Aktionen von Seiten der Benutzer nach sich ziehen wird etc.) sollte auch festgelegt sein, in welchem Zeitraum eine selbständige Änderung des Kennworts erfolgen muß – inklusive einer Anleitung zur Änderung. So kann beispielsweise ein Zeitraum von 1 Monat als erster Zeitrahmen angegeben werden.

Nach einem Monat erfolgt eine erneute Überprüfung des Kennwortalters der Benutzer – diejenigen Benutzer, die bis dahin Ihr Kennwort nicht geändert haben, können nochmals aufgefordert werden, Ihr Kennwort zu ändern. Ggf. kann auch hier direkt das Management involviert werden. Vergesst nicht, den Mitarbeiter auch zu erklären, daß gute Kennwörter ein wichtiger Beitrag zur Computersicherheit sind.

Nachdem wir aus Phase 1 wissen, welche Accounts mit einem maximalen Kennwortalter von mehr als 999 Tagen vorhanden sind, kann man diese Benutzer ebenfalls direkt kontaktieren.

Teilt man das Vorgehen etwa auch in kleinere Einheiten auf, kann man so innerhalb von 1-2 Monaten gute Resultate für pro-aktive, also nicht technisch erzwungene Kennwortänderungen erreichen.

Mobile Benutzer, die sich selten in das Netzwerk verbinden und in der Regel keine interaktive Anmeldung im Netz durchführen, werden durch Bordmittel keine Warnungen zu ablaufenden Kennwörtern angezeigt. Sie haben auch keinen sichtbaren Weg oder Tool, um ihr Kennwort zu ändern. Sie können in der Regel nur selbst über den Sicherheitsdialog das Kennwort ändern, während sie per VPN verbunden sind. Für diese Benutzer kann zum Beispiel eine der folgenden Möglichkeiten eingesetzt werden:

1. Outlook Web-Access bietet die Möglichkeit für Kennwortänderungen ab Version 2003. In OWA 2003 muß die Funktion nachgerüstet / eingerichtet werden, ab Exchange 2007 ist sie integriert.
   Siehe zur Einrichtung: Implementing the Change Password feature with Outlook Web Access https://support.microsoft.com/kb/297121/en-us
2. Alternativ dazu können Zusatzprodukte wie etwa der Microsoft ISA Server oder 3rd Party Software Möglichkeiten zur Kennwortänderung von Benutzerkonten zur Verfügung stellen. Siehe dazu beispielsweise: Configuring and Troubleshooting the Password Change Feature in ISA Server 2006 https://technet.microsoft.com/en-us/library/cc514301.aspx
3. Clients für VPN-Verbindungen können nach der Verbindung Scripts ausführen. Damit kann das Kennwortalter geprüft werden und eine entsprechende Warnung ausgegeben werden, mit Hinweisen wie das Kennwort geändert werden kann.

Es sollte zusätzlich ein Prozess eingeführt werden, der die Benutzer, die sich nie interaktiv an der Domäne authentifizieren (und dementsprechend auch keine Warnung erhalten, daß das Kennwort ablaufen wird), auch in Zukunft automatisiert informiert, daß Ihr Kennwort ablaufen wird. Nur so können diese Benutzer rechtzeitig selbständig eine Kennwortänderung vornehmen. Es gibt mit Windows Server 2003 / 2008 / 2008 R2 keine Bordmittel dies zu gewährleisten. Es gibt jedoch einige Drittanbieter, die entsprechende Software anbieten, die vor Kennwortablauf E-Mails an die Benutzer versendet. Ggf. kann solch ein Script auch selbst entwickelt werden bzw. findet man mittels https://www.bing.com sicher einige interessante Webseiten und Forenbeiträge dazu. ;-)

Wichtig ist hier entsprechend einzuplanen, daß dieser Prozess auch in Zukunft nach der Einführung der Kennwortrichtlinien fortlaufend gelebt werden muß.

Läuft ein Kennwort in Zukunft nach Einführung des Maximalalters eines Kennworts ab, kann es der Benutzer direkt bei einem interaktiven Logon erneuern. Diese Möglichkeit besteht nicht für externe Benutzer – hier muß der Helpdesk dann ggf. die Kennwörter wieder zurücksetzen, um den betroffenen Benutzern eine Kennwortänderung z.B. über Outlook Web-Access oder den ISA Server zu ermöglichen. Zusätzlich gibt es auch Funktionen in Microsoft als auch Third Party Produkten, um ein Kennwort direkt durch den Benutzer zurückzusetzen.

Ebenfalls wichtig ist es hierbei zu bedenken, daß zu diesem Zeitpunkt in Phase 2 noch keinerlei Vorgaben in Bezug auf Kennwortlänge oder Kennworthistorie existieren. D.h. da an dieser Stelle noch keine entsprechenden Richtlinien definiert wurden, können die Benutzer die Kennwörter frei wählen. Möchte man das unterbinden, muß die Phase 2 mit Phase 4 zusammengefügt werden, d.h. erst nach Phase 3 ausgeführt werden.

Phase 3:

In Phase 3 sollte in Zusammenarbeit mit den Service-Administratoren geprüft werden, welche Accounts in der Domäne Dienstkonten sind. Diese müssen unter Umständen vor Kennwortänderungen geschützt werden – zumindest vor denen der allgemeinen Kennwortrichtlinie. Generell empfiehlt sich natürlich ein Prozess, der auch Dienstkonten zyklisch mit neuen Kennwörtern versieht. Das ist jedoch ein anderes Thema und wird hier nicht weiter angesprochen.

Grundsätzlich gibt es keine automatisierte Möglichkeit zu prüfen, ob es sich bei einem Konto um einen normalen Account oder einen Dienstaccount handelt. Dies muß also ggf. über eine interne Dokumentation oder über Scripts erfolgen, die Dienstkonten auf den Zielsystemen prüfen (etwa die Benutzer von Diensten, geplanten Tasks, Management Systemen etc.). Erst mit Windows Server 2008 R2 gibt es vom AD verwaltete Servicekonten, für die das möglich ist.

Es ist empfehlenswert, die Dienstkonten gerade während der Einführung der Kennwortrichtlinien mit dem Flag „password never expires“ zu versehen – dieses Flag „überschreibt“ für die Konten die Kennwortrichtlinie des maximalen Kennwortalters, siehe dazu auch: Managing Existing User and Group Accountshttps://technet.microsoft.com/en-us/library/bb726988.aspx

Password Never Expires Ensures the account password never expires, which overrides the normal password expiration period.

Caution : Selecting this option creates a security risk on the network. While you may want to use Password Never Expires with administrator accounts, you shouldn't use this option with normal user accounts in most cases.

Diese Aktion läßt sich automatisieren – wenn die Accounts vorher von den Administratoren korrekt identifiziert wurden. Möchten man den Prozess z.B. für eine komplette OU scripten, kann man etwa folgende Möglichkeiten in Betracht ziehen: 

1. How Can I Configure an Active Directory Account So the Password Never Expires?  https://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1031.mspx
2. dsmod user: https://technet.microsoft.com/en-us/library/cc732954(WS.10).aspx

C:\> dsmod user <DN> -pwdneverexpires yes

Die Übergabe von Accounts kann als Pipe „|“ von dsquery o.ä. erfolgen. Somit ist auch hier eine vollständige Automatisierung möglich.

Die administrativen Konten sollten hier Vorreiter und Pilotbenutzer sein. Deren Kennwörter sollten also regelmäßig geändert werden.

Update 10.09.2009: Ein Punkt ist uns beim Erstellen des Blog Eintrags dann doch durch die Lappen gegangen: Es ist möglich, das Attribut "pwdLastSet" auf den Wert "-1" zu setzen. Dieses Attribut ist die Berechnungsgrundlage für das Kennwortalter eines Benutzers.
Wird bei den relevanten Benutzern nach der oben genannten Dokumentation des Kennwortalters das Attribut "pwdLastSet" auf den Wert "-1" gesetzt, wird dies vom System automatisch in den aktuellen Zeitstempel umgewandelt. Somit greift das maximale Kennwortalter für die Einführung der Richtlinien nicht mehr ganz so hart, denn man kann nun die "Extrem-Accounts" mit Kennwortdaten jenseits der "999" Tage durchaus mit aktuellem Zeitstempel versehen.

Ein Scriptbeispiel gibt es hier: https://www.microsoft.com/technet/scriptcenter/guide/sas_usr_akke.mspx?mfr=true

Jedoch sollte dies erst nach entsprechender Dokumentation des tatsächlichen Kennwortalters erfolgen, so daß man die Benutzer direkt kontaktieren kann. Denn genau diese Benutzer sollten natürlich schnellstmöglich das Kennwort ändern und nicht eine Zeit lang davon "verschont" bleiben.

Phase 4:

In der nun folgenden Phase stellt man nun die Kennwortrichtlinien ein. Hierbei sollten zu Beginn schwache Werte eingesetzt werden.

• So sollte etwa das maximale Kennwortalter auf den Höchstwert „999“ in Tagen gesetzt werden.
• Die Account Lockout Policy sollte noch nicht eingesetzt werden, um keine Account Lockouts aufgrund technischer Probleme in der Migrationsphase zur Kennwortrichtlinie hin zu provozieren (es könnte z.B. der „Account Lockout Treshold“ auf „0“ gesetzt werden).

Kennworthistorie, minimales Kennwortalter, Zeitraum des Warnhinweises zur anstehenden Kennwortänderung und die Kennwortkomplexität können in dieser Phase wie gewünscht gesetzt werden. Sollte es über die Evaluierung in Phase 1 möglich gewesen sein, verschiedene Benutzergruppen in Bezug auf das Kennwortalter zu analysieren, dann kann hier in Gruppen gearbeitet werden. D.h. es wäre möglich, zuerst alle Benutzer mit mehr als „999“ Tagen maximalen Kennwortalters umzustellen – das ist das Mindestalter und die Gruppe, die darüber liegt, kann daher nicht mehr „verkleinert“ werden. Es sei denn, die Benutzer haben ihr Kennwort in Phase 2 schon geändert.

Sind diese Benutzer nun nach einem angemessenen Zeitraum umgestellt und die möglichen Probleme wurden behoben und dokumentiert, kann das maximale Kennwortalter verringert werden. Hier empfiehlt sich eine Auswertung wie in Phase 1, um einen sinnvollen Intervall zu wählen. Der oben genannte „dsquery user –stalepwd“ Befehl kann hier sehr gute Dienste leisten. Vom Ergebnis abhängig (und damit von den betroffenen Benutzern einer Änderung des Kennwortalters) muß dann entschieden werden, welches Kennwortalter eingesetzt werden soll. Sinnvoll ist es hier in kleinen Schritten vorzugehen, etwa 100 Tage oder 200 Tage weniger als „999“ pro Schritt.

Wichtig: Das Warnintervall vor dem Ablauf der Konten solltet Ihr somit recht hoch einstellen (z.B. 114 oder 214 Tage), so dass beim Ändern des maximalen Kennwortalters nicht die Telefone des Helpdesks glühen. Ihr solltet zusätzlich das Datum der Änderung einer Verkürzung per E-Mail oder weiteren Wegen ankündigen, so daß sich Benutzer mit Warnungen von 109 Tagen alten Kennwörtern nicht wundern, aber rechtzeitig aktiv werden.

Phase 5:

In der letzten Phase werden nun die Kennwortrichtlinien bis hin zum SOLL-Wert angezogen. Dies sollte – wie schon in Phase 4 vermerkt – in jedem Fall schrittweise erfolgen und eine Überwachung der Änderungen durchgesetzt werden.

In dieser Phase solltet Ihr auch mit Beschwerden über die „Verrückten in der IT“ rechnen und frustrierten Benutzern am Helpdesk. Davon dürften vor allem die externen und mobilen Benutzer betroffen sein. In den IT-Prozessen solltet Ihr Vorkehrungen treffen, diese Benutzer sicher mit neuen Kennwörtern zu versorgen, z.B. per Rückruf auf das Firmenhandy und Benachrichtigung des Chefs (siehe dazu auch weiter unten).

Es kann dann, nach erfolgreicher Einführung der Grund-Kennwortrichtline, falls gewünscht auch die Account Lockout Policy eingesetzt werden.

Obwohl es nicht Kernpunkt des Blog-Artikels ist, hier ein kurzer Hinweis dazu:

Die Account Lockout Policies werden oftmals viel zu gering gesetzt. So ist ein Wert von 3-5 ungültigen Anmeldeversuchen vor einer möglichen Sperrung meist kontaproduktiv. Es erfolgen bei solch geringen Schwellwerten oft ungewollte Sperrungen, was den administrativen Aufwand (und damit die Kosten) unnötig in die Höhe treibt und zusätzlich eine automatisierte Auswertung der Lockouts im Prinzip unmöglich macht. Sicherheit kann nicht allein durch Kennwortrichtlinien eingesetzt werden, es ist ein Prozess aus einer vielzahl von Maßnahmen und vor allen Dingen der Überwachung dieser Maßnahmen.

Außerdem können Locout Policies die Umgebung auch komplett lahmlegen, da alle Konten gesperrt werden können, wenn ein Angreifer einen DoS-Angriff fährt. Ausnahme ist standardmäßig der erste Domänen-Administrator jeder Domäne, siehe dazu auch: Schutz vor Account Lockouts auch für andere Konten als “Administrator”? https://blogs.technet.com/deds/archive/2008/07/28/schutz-vor-account-lockouts-auch-fuer-andere-konten-als-administrator.aspx .

Es sollte also genau geprüft werden, ob Lockouts tatsächlich eingesetzt werden sollen und falls ja, wie die Prozesse zur Entsperrung eines Accounts aussehen. Hier sollte ebenfalls ein definierter Vorgang geplant sein, etwa durch das Vorzeigen des Ausweises des Betroffenen oder die Entsperrung des Accounts durch einen Vorgesetzten des Betroffenen Benutzer oder ähnliche Vorgehen.

Wir empfehlen bei aktivierten Account Lockouts einen absoluten Minimalwert von 10 ungültigen Anmeldeversuchen in Hochsicherheitsumgebungen – wobei mit eingeschränkter Funktionalität gerechnet werden muß. In normalen Umgebungen empfehlen wir Werte zwischen 20 und 50 ungültigen Anmeldeversuchen, je nachdem, ob ein Überwachung stattfindet oder nicht (bzw. in welcher Form). Siehe dazu auch den “Windows Server 2003 Security Guide:

Table 3.2 Account Lockout Policy Settings

Sollten doch „High Security“ Werte eingesetzt werden, empfiehlt sich auch hier eine schrittweise Anpassung der Einstellungen und nicht die direkte Übernahme der starken Werte.

Mit diesen Grundüberlegungen ist man gut für eine Einführung von Kennwortrichtlinien gerüstet – nichtsdestotrotz sollte man das Vorgehen ausführlich in seiner Testumgebung geprüft haben, bevor man damit produktiv geht. Die Sperrung oder die Anmeldeverweigerung von Benutzern kann ernste Probleme nach sich ziehen, die oft sehr viel Geld kosten.

Viele Grüße
Herbert und Fabian