Das A und O der Passwortrichtlinien
Passwörter. Das leidige Thema, das jeder kennt und doch im heutigen Dschungel von IT-Sicherheitslösungen, mit denen man beschossen wird, gern mal in Vergessenheit gerät. Doch letzten Endes sind genau diese eines der simpelsten und wichtigsten Punkte, die in einer Domäne sitzen müssen.
Warum? Was kann denn bei schwachen Passwörtern groß passieren? Tatsächlich ist es simpel und doch kompliziert. Kurz und simpel gesagt können schwache Passwörter schneller geknackt werden durch Brute-Force-Angriffe.
Brute-Force-Angriffe sind Methoden, bei denen ein Angreifer mithilfe von „grober Kraft“, wie die Wort-für-Wort-Übersetzung lautet, versucht, ein Passwort zu erraten. Hierzu nutzt er beispielsweise ein Programm, das jede erdenkliche Kombination von Buchstaben, Zahlen und Sonderzeichen durchprobiert und als Passwort eingibt, bis schließlich die richtige Variation gefunden wird und der Login gelingt. Die Wahrscheinlichkeit ist hoch, dass der Angreifer „Dictionaries“ verwendet. Bei besonders schwachen Passwörtern wie „Passwort123“ wird der Login in den Account dem Angreifer höchstwahrscheinlich gelingen. „Dictionaries“ (oder auch Wörterbücher) sind vorab erstellte Tabellen oder Listen mit vielen bekannten und häufig genutzten Passwörtern. Diese „Dictionaries“ variieren in Größe und Inhalt. Beispiele hierfür sind Passwörter wie „Passwort“, „Passwort123“, „qwertz“, „password“ usw. Wenn ein Angreifer diese Methode verwendet, spricht man von einem „Dictionary Attack“ (oder Wörterbuch-Angriff).
Kommen wir also nun zum eingemachten Teil! Wir schauen uns an, wie man die Passwörter konfigurieren kann. In diesem Fall sprechen wir von dem Einstellen von Passwörtern in einer Active Directory-Windows Domäne.
Grob gesehen haben wir hier die Möglichkeit, entweder Richtlinien per Gruppenrichtlinienobjekten zu verteilen oder Drittanbietersoftware zu benutzen. Wir nutzen hier die dritte Methode: den „Passwort Settings Container“ im Active Directory Administration Center. Damit erstellen wir FGPP (fine grained password policy), die wir auch in den GPO ohne schöne GUI finden können. Wir kommen dahin, indem wir auf unseren DC in den Server Manager gehen. Dort klicken wir auf „Tools“ oben rechts in der Ecke. Dann klicken wir auf „Active Directory Administrative Center“.
Hier öffnet sich das Administrative Center. Wir klicken dann auf der linken Seite auf den Pfeil neben unserer Domäne. Dann öffnet sich ein Fenster in dem wir auf „System“ und dann auf „Passwort Settings Container“ klicken.
Im Anschluss haben wir eine leere Seite. In dieser klicken wir mit einem Rechtsklick in das Fenster, jetzt auf „New“ und dann auf „Password Settings“.
Nun öffnet sich ein vordefinierter Wizard, in dem wir verschiedene Einstellungsmöglichkeiten haben.
Wir gehen nun Schritt für Schritt diese Einstellungen durch.
Festhalten, es geht los!
Fangen wir also mit dem Namen an.
Der Name sollte unser geringstes Problem sein, obwohl ich hier empfehle der Namensgebung treu zu bleiben und einen schön klaren und definierten Namen zu wählen, denn wie wir wissen ist das alte Regeln wiederfinden genauso wichtig, wie das neue Erstellen.
Als zweites folgt die Priorität. Diese ist hilfreich, im Falle, dass wir mehrere FGPPs auf z.B. einem User haben. Diese sagt aus, dass die Regel mit der niedrigsten Priorität genutzt wird.
Nun kommt die Option des Erzwingens von einer minimalen Länge des Passworts. Diese ist ja eine der wichtigsten Attribute eines guten Passworts. Hier empfiehlt sich je nach Wichtigkeit der Accounts ein Passwort von 8 bis 32 Zeichen zu nutzen.
Es folgt eine weitere wichtige Eigenschaft: Die Passwort Historie. Diese sagt aus, wie viele Passwörter aus der Vergangenheit gemerkt und geblockt werden sollen. Der Wert muss zwischen 1 und 1024 liegen. Auch hier empfiehlt es sich nach Wichtigkeit des Kontos zu entscheiden. Das Minimum hier sollte 24 sein.
Nun kommt ein weiterer wichtiger Punkt. Nun gut, eigentlich sind alle Punkte wichtig, aber manche dann doch mehr als andere. Dieser Punkt also dreht sich um die Komplexitätsanforderungen und sagt aus, dass 3 der 5 verschiedenen Zeichentypen (Groß- und Kleinbuchstaben, Ziffern, Sonderzeichen und Unicode) benutzt werden sollen und, dass keine Teile des Namens im Passwort zu finden sind.
Hier lohnt es sich zu erwähnen, dass € oder Pfund nicht als Sonderzeichen gelten. Zudem es hier auch wichtig ist die Mitarbeiter zu schulen, anstatt nur auf von der Technik abhängig zu machen, dass die Passwörter sicher sind. Im besten Fall sorgt die Technik dafür, dass die Passwörter sicher sein müssen, aber die Nutzer nur sichere Passwörter erstellen. Also Sonderzeichen, Zahlen, lange Passwörter, keine leichten Passphrasen (dasPasswort123$), Groß- und Kleinbuchstaben, etc..
Der nächste Punkt sagt, dass das Passwort mit entschlüsselbarer Verschlüsselung gespeichert werden soll. Wofür auch immer da ein usecase für existiert, wollen wir das doch definitiv nicht. Denn eine umkehrbare Verschlüsselung erlaubt dem Angreifer ein Konto zu kompromittieren und das Netzwerk zu erforschen.
Nun kommt der Punkt des Schützens des Objekts gegen versehentliches Löschen.
Aus Erfahrung kann ich sagen, dass es Wert ist diesen Haken zu setzen, aber das Löschen des Objekt später etwas mehr Zeit in Anspruch nehmen kann.
Es folgt das minimal Passwortalter. Also die Anzahl der Tage in denen der Nutzer das Passwort nicht ändern kann (in Tagen). So kann man verhindern, dass der Nutzer das Passwort mehrmals am selben Tag ändert. Hier empfiehlt sich der Wert 1. Gibt es da Probleme, kann der Administrator da natürlich trotzdem anpassen.
Und nun des jeden Administrators Liebling. Das maximale Alter eines Passworts (in Tagen).
Hier empfiehlt es sich je nach Gruppe zu entscheiden. Empfehlungen vom BSI lauten, dass ein Passwort nicht geändert werden muss. Dies sollte aber im Einzelfall entschieden werden.
Hat ein Angreifer das Passwort eines Nutzers hat der den Zugriff auf dessen Konto. Wird dieses Passwort aber geändert, verliert er den Zugriff. Umso öfter es geändert wird, umso schneller. Oder haben Sie schonmal etwas von 2 Faktor Authentfizierung gehört? ;)
So kann auch das Knacken von Passwörtern online mit z.B. in der Cloud gemieteter Rechenleistung abgeschwächt werden. Es können damit dann alte Pakete geknackt werden, aber keine neuen. Sicher gibt es da auch besserer Wege, wie z.B. das „perfect forwarded secrecy“, aber das ist ein anderes Rabbit hole.
Jetzt kommen wir zum Thema „Lockout“. Wir empfehlen definitiv den Haken zu setzen.
Anzahl von falschen Anmeldungsversuchen bis zur Sperre.
Hier empfehlen wir einen Wert von 5 bis 20 Versuchen. Je nach Nutzer oder Gruppen für die diese Passwörter gelten und wie sehr man seinen Mitarbeitern verzeiht das Passwort falsch einzutippen.
Nun die Regel die aussagt nach wie vielen Minuten der Zähler von falschen Anmeldeversuchen.
Hier bietet sich 30 an.
Als letztes dieser Sektion haben wir die Anzahl der Minuten für den Lockout.
Auch hier bietet sich 30 Minuten an. Denn wer das Passwort 20 Mal falsch eingibt, sollte auch 30 Minuten warten können, oder dem Administrator ein wichtiges Ticket schreiben / ihn anrufen und nach Hilfe fragen. So erzieht man seine Nutzer auch vorsichtiger und geduldiger bei der Eingabe von Daten zu sein.
Alternativ bietet es sich auch an für sehr wichtige Gruppen die zweite Option zu wählen: bis ein Administrator das Konto wieder freischaltet. Das ist eine sichere Möglichkeit, sollte aber im Einzelfall entschieden werden, da es erhebliche Einschränkungen im Betrieb mit sich bringt.
Damit haben wir die FGPP erstellt und müssen jetzt nur noch die Berechtigungen erledigen. Es bietet sich auch an hier die Beschreibung zu nutzen, vor allem, wenn man verschiedene FGPPs im Einsatz hat.
Falls dies nicht genug für Ihre Ansprüche ist, oder es zu aufwendig, bietet es sich an hier Drittanbieter in Erwägung zu ziehen.
Nun haben wir also die Regel erstellt. Doch da stellt sich ein Problem in den Weg. Diese Regel greift nur bei Nutzern, die ein Passwort erstellen. Also bei allen anderen Nutzern, bei denen z.B. das Passwort nicht geändert werden muss oder die es gerade erst geändert haben, trifft dies nicht zu.
Wir müssen also entweder warten bis die, die das Passwort schon geändert haben es wieder ändern müssen (was aber die nicht betrifft, deren nie abläuft), oder die Nutzer dazu zwingen das Passwort jetzt zu ändern.
Hier ein Skript für PowerShell zum anzeigen von Informationen zu den Passwörtern in einer .CSV Datei:
Measure-Command {Import-Module ActiveDirectory$Users = Get-ADUser -filter * -searchbase "OU=zzz_Benutzer,OU=Benutzer,OU=bsp-Name,DC=bsp-Computer,DC=local"foreach ($User in $Users) { Set-ADUser -Identity $User -CannotChangePassword $false -PasswordNeverExpires $false -ChangePasswordAtLogon $true }}
Hiermit werden folgende Felder überschrieben für: Kann Passwort nicht ändern, Passwort läuft nie ab (bietet sich an abzuschalten, wenn nicht gebraucht). Diese sind Optional.
Es wird auch eingestellt, dass das Passwort beim nächsten Login geändert wird.
Hier kann man auch eine ganze OU nehmen als Filter und da nach Namen „*“ filtern.
Somit werden also alle Passwörter beim nächsten Login geändert.
Hier aber eine Warnung nochmal sicher zu gehen, ob das auch so ok ist und alle Passwörter geändert werden dürfen / sollen / können. Allein schon hier kann viel kaputt gehen. Vor allem bei Service Nutzern.
Azure AD Passwort Einstellungen
Man kann von Azure halten, was man will, aber eine übersichtliche Oberfläche und ein großes Angebot an Möglichkeiten hat es auf jeden Fall.
Microsoft Azure Active Directory hat grundlegende Standard-Voraussetzungen an ein Passwort.
Die meisten dieser Einstellungen sind nicht veränderbar, wenn man Cloud-only Konten nutzt.
Hat man aber Azure AD Premium hat man schon ein paar mehr Optionen.
Azure Active Directory gibt uns eine Menge Möglichkeiten unseren Zugang zu schützen.
Diese findet man unter dem Modul „Azure Active Directory“ und dann unter „Security“-> “Authentifizierungsmethoden“-> “Richtlinien“.
Zum Beispiel das Einstellen und Nutzen von dem Microsoft Defender, Zertifikatsbasierte Authentifizierung, Sprachanrufe oder einmalige Passwörter per E-Mail.
Des Weiteren kann man auch Passwortregeln einstellen.
Z.B. hier unter unter dem Modul „Azure Active Directory“ und dann unter „Security“->“Authentifizierungsmethoden“->“Kennwortschutz“:
Wie man hier sieht, kann man den Schwellenwert für fehlerhafte Anmeldeversuche angeben, bis das Konto gesperrt wird und wie lange es gesperrt bleiben soll.
Zudem kann man eine benutzerdefinierte Liste mit gesperrten Passwörtern nehmen.
Unter „Kennwortschutz für Windows Server Active Directory“ ist es möglich eine global gespeicherte Liste mit Passwörtern zum Sperren zu nutzen, wenn der Agent dafür auf den Systemen installiert ist. Diese Option ist aber etwas tiefgehender (Für interessierte hier der KB Eintrag von Microsoft: Bereitstellen des lokalen Azure AD-Kennwortschutzes - Microsoft Entra | Microsoft Learn).
Trotz allen ist Microsofts aktuelle Empfehlung Passwortlose Authentifizierung zu nutzen.
Hier sieht man eine schöne Darstellung:
Das war es. Wir haben also Optionen und Methoden gesehen Passwörter zu konfigurieren in Azure AD und on Premise AD.
Zudem haben wir Möglichkeiten kennengelernt, mit denen wir Passwörter verstärken können oder sie gar ablösen.
Ich hoffe der Artikel hat Dir geholfen, oder Du konntest zumindest ein oder zwei neue Anreize mitnehmen, darüber nachdenken, oder sie sogar in Deiner Domäne implementieren.
Du möchtest mehr erfahren?
Melde Dich gerne telefonisch unter 07266 447 97 90 bei uns oder nutze unser Kontaktformular! Wir freuen uns auf Dich!