Zur Beachtung - Anleitungen

Bitte beachten Sie, daß die bereitgestellten Informationen zum Zeitpunkt der Erstellung im Rahmen von durchgeführten Arbeiten dokumentiert und validiert wurden. In einer geänderten Systemumgebung können für die Schritte Anpassungen erforderlich sein. Dies gilt insbesonders, falls die Informationen Workarounds oder Fehlerbehebungen betreffen. Die Informationen sind entsprechend spezifisch für die Systemumgebung und Version der Systeme zum Zeitpunkt der Arbeiten. Schritte, die sich für uns von selbst erschließen, sind ggf. nicht in den Anleitungen enthalten. Dasselbe gilt auch für konzeptionelle Anleitungen. Diese sind für spezifische Umgebungen und spezifische Erfordernisse erstellt und müssen vor Anwendung überprüft werden, ob sie für die angedachte Umgebung passend sind. Die Verwendung erfolgt auf eigene Gefahr.

Wir raten in jedem Fall dazu, vorab ein Backup in einem Umfang zu erstellen, der die Wiederherstellung der Systeme im Fehlerfall sichert. Dies betrifft bei Active-Directory-integrierten Diensten auch das Active-Directory.

 

(23.10.2026)

Viele Sicherheitsfirmen verlangen in ihren standardisierten Auditbewertungen Mindestlängen von 15 oder mehr Zeichen.

Kürzere Kennwörter wirken in zweifacher Hinsicht problematisch: erstens sind sie durch ihre Länge mit gängiger Hardware in sehr kurzer Zeit durch Hashvergleiche ermittelbar und zweitens nimmt die Anzahl sehr oft genutzter Standardkennwörter mit zunehmender Kennwortlänge ab.

Eine höhere Mindestlänge schließt, genauso wie Komplexitätsanforderungen, viele oft verwendete Kennwörter aus. Allerdings bringt eine weitere Erhöhung nur begrenzten Sicherheitsgewinn bei steigendem Aufwand für die Benutzer.

Auf dieses Spannungsfeld zielt der Einsatz von MFA ab. Dieser ist jedoch ggf. nicht immer möglich oder praktikabel. Zudem ist das Kennwort meist erster Faktor, was den Schutz bei kompromittiertem Kennwort ausschließlich vom zweiten Faktor abhängig macht.

Dennoch lassen sich Umgebungen mit kürzeren Kennwörtern auch ohne zweiten Faktor durch zusätzliche externe Mechanismen, z.B. durch Einsatz von Microsoft Entra ID bei Cloudanmeldungen1, weitgehend härten:

  1. Aufwand für die Ermittlung von Kennwörtern für administrative Zugänge erhöhen
    1. Geräte- und systemspezifische Kennwörter werden nur für die Administration verwendet, sind eineindeutig, über einen Generator erzeugt und hinreichend lang (15 Zeichen, wir erzeugen aktuell 20)
    2. Verwenden von eineindeutigen Kennwörtern für Geräte- und Systemzugänge, die nicht Benutzern zugeordnet sind.
    3. Analoges gilt für Kennwörter von Dienstkonten, sofern für Dienste nicht gruppenverwaltete Dienstkonten verwendet werden
    4. Keine Verwendung von Administratorkonten für Dienste und Sicherstellung, daß Administrationskonten keine registrierten SPNs besitzen, damit für diese Konten keine Kerberos-Servicetickets angefordert werden können.
    5. Kerberos-Vorauthentifizierung für alle Konten aktiviert lassen, soweit diese nicht für Mechanismen verwendet werden, die dazu nicht kompatibel sind.
  2. Aufwand für die Ermittlung von Kennwörtern im Allgemeinen erhöhen
    1. Komplexe Kennwörter erzwingen
    2. Anzahl zwischengespeicherter Anmeldungen bei Clients auf 1 reduzieren und bei Servern auf 0. Für Mobilgeräte bedeutet das, daß nach Anmeldung eines Technikers zwingend der Benutzer wieder angemeldet werden muß, während Verbindung zu einem Domänencontroller besteht.
    3. BitLocker aktivieren. Dies verhindert, daß bei Diebstahl einfach der Systemdatenträger ausgebaut werden kann und an einem anderen Rechner auf die Sicherheitsdatenbank zugegriffen werden kann.
    4. Über Kennwortrichtlinien Kontosperren bei fehlgeschlagenen Authentifizierungen einrichten und manuelle Freigabe durch einen Administrator aktivieren. Ein Angreifer sperrt damit zwar alle Konten, hilft damit aber auch, den Angriff auf einer persönlichen Ebene zu erkennen.
    5. Verwendung eines Kennwortfilters, z.B. Lithnet Password Protection, zur Verhinderung der Verwendung von vielverwendeten Kennwörtern. Bei nachträglicher Einrichtung wirkt das nur gegen neu gesetzte Kennwörter (genauso, wie nachträglich aktivierte Kennwortrichtlinien). Zur Identifikation nicht konformer Kennwörter sind verschiedene quelloffene Werkzeuge verfügbar, Lithnet Password Protection bringt ein eigenes PowerShell-Modul mit, welches komplementär durch DSInternals Test-PasswordQuality ergänzt werden kann.
    6. Deaktivierung von RC4-HMAC nach Prüfung, ob es Konten ohne AES-Schlüssel gibt und welche Konten unter Verwendung von RC4 authentifizieren.
    7. Ablage von Kennwörtern nur verschlüsselt mit hinreichend langen Masterkennwörtern. Lokal kann dafür z.B. KeePass verwendet werden, zentral sysPass.
  3. Reduzierung der zugreifbaren Systemzugänge
    1. Netzwerksegmentierung mit dazwischenliegender Firewall. Grob: Administrativsysteme getrennt von Infrastrukturgeräten, getrennt von Infrastrukturservern, getrennt von Servern, getrennt von Clients, getrennt von Druckern, getrennt von Geräten, getrennt von DMZ, getrennt von RRAS, getrennt von Gastnetzen. Bei Bedarf weiter unterteilen. Das ist im ersten Moment nicht relevant für die Kennwortlänge, verhindert aber Zugriffe auf andere Systeme.
    2. Wichtig, deswegen separat: Domänencontroller nicht ins Client-Subnet.
    3. Zusätzlich entsprechende Verwendung und entsprechende Konfiguration der lokalen Gerätefirewalls
    4. Verwendung separater Administratoren für Domäne, Server und Clients. PC-Administratoren haben keine Rechte im Netzwerk und auf Servern, Serveradministratoren haben keine Rechte auf Clients und im Netzwerk. Dies setzt Anmeldebeschränkungen voraus.
  4. Verhinderung von Broad- und Multicastverkehr und Sicherung der Authentizität von Antworten auf notwendige Anfragen
    1. Deaktivierung von mDNS, LLMNR und NBT-NS. Dies weist Systeme an, keine diesbezüglichen Broad- und Multicasts im lokalen Subnet zu senden und verhindert so, daß ein anderes System entsprechende Anfragen abfangen kann (GPO). Dies schließt die häufigsten Wege des Abgreifens von Authentifizierungsmeldungen durch Drittsysteme.
    2. Sofern möglich SMB-Signing erzwingen.
    3. Sofern möglich, LDAP-Signing erzwingen.
    4. Sofern möglich, Channel Binding aktivieren.
    5. EPA für Webdienste aktivieren. Auf Exchange erfolgt das mit dem Extended-Protection-Script, Probleme sind bei Einsatz eines IIS-Reverse Proxies mit ARR und demselben Zertifikat auf Exchange und dem Proxy nicht zu erwarten (machen wir so).
    6. Deaktivierung des Spoolers auf Domänencontrollern.
    7. Einrichtung eines IPv6-DHCP-Servers für Clients, Deaktivierung der Berücksichtigung von IPv6-RA für Server mit festen IPv6-Adressen und Priorisierung von IPv4 über IPv6 (GPO).
    8. Switchseitig DHCPv6 und IPv6 RA auf zugelassene Ports/VLANs beschränken und Neighbor Discovery Inspection aktivieren. Analog für IPv4 DHCP-Snooping und DAI aktivieren. Zusätzlich in der lokalen Firewall DHCP, DHCPv6 und RA blockieren, außer für die eigenen Server und Router.
    9. Switchseitig und ggf. an Firewallroutern für Router statische Bindung (IPv6) und statische ARP-Einträge (IPv4) nutzen. Vorsicht bei VMs, da ändern sich ggf. die MAC-Adressen.
    10. Automatische Proxyerkennung deaktivieren und Proxyserver fest hinterlegen
  5. Verhinderung von freiem Internetverkehr. Das betrifft alle Protokolle und alle Ports, auch ICMP. Webzugriff ausschließlich spezifiziert endpunktbezogen (Quelle und Ziel) oder über einen authentifizierenden Proxy, der selbst auch TLS-Datenverkehr aufbricht und prüft.
  6. DNS-Filter einsetzen oder kaskadierte DNS-Infrastruktur, die mit bedingten Weiterleitungen arbeitet.
  7. Beschränkung des Zugriffs auf einzelne Systeme nach Notwendigkeit: Clients nicht auf Clients, Server nicht auf Server außer benötigte Dienste 
  8. Möglichst Verwendung smartcardbasierter Authentifizierungsmethoden für die Anmeldung an Windows, VPN, Websites und Exchange. Über im TPM gespeicherte virtuelle Smartcards ist das auf jedem Client möglich. Eingesetzt werden sollte das in jedem Fall für mobile und remote Systeme. Smartcard bzw. TPM wirken intrinsisch als zweiter Faktor, die PIN als erster. Hinweis: Microsoft hat virtuelle Smartcards abgekündigt. Ein Termin für die Entfernung steht nicht fest, aktuelle Versionen unterstützen die Funktionalität. Die Funktion erfordert die Verwendung von Certificate Services als Enterprise CA.
  9. Permanente Logprüfung der DCs und Systeme auf fehlgeschlagene Authentifizierungsversuche oder häufig ausgeführte Authentifizierungsanfragen oder Anforderungen von Kerberostickets, z.B. durch Wazuh.

Wichtig ist, daß bei Absicherungen, die mit unterschiedlicher Methodik dasselbe Problem adressieren, nicht nur eine eingesetzt wird, z.B. sollten sowohl lokale Firewall, als auch Edge-Firewall aktiviert und konfiguriert werden. Zudem ist der Charakter der Liste nicht „alles oder nichts“: die erste Verteidigungslinie ist der Perimeter und die Kennwortsicherheit. Ohne Kommunikationsweg ins Internet scheitern die meisten automatisierten Angriffe, ohne Zugriff auf Anmeldeknotenpunkte ist keine Prüfung von Kennwörtern über diese möglich und ohne zwischengespeicherte Anmeldeinformationen können eben diese nicht zum Vergleich mit errechneten verwendet werden und ein Angreifer muß diese Werte anderweitig abgreifen. Jede geschlossene Lücke erhöht die Komplexität eines Algorithmus, der ohne Anbindung nach außen funktionieren muß und damit den Aufwand für einen Angreifer.

Hinsichtlich der Kennwortlänge stellt sich die Frage, wie schnell Kennwörter ermittelt werden können. Hierzu werden bei Online-Angriffen zwei Methoden verwendet, Wörterbücher und systematisches Durchprobieren (Brute Force). Wörterbuchangriffe verwenden Listen mit häufig verwendeten Kennwörtern und ergänzen diese ggf. durch angefügte gebräuchliche Zeichen. Die entscheidenden Hebel hierfür sind die Erzwingung komplexer Kennwörter, das Prüfen der Kennwörter auf häufig verwendete inkl. der Anfügung von häufig verwendeten Zeichen, das Verhindern der Verwendung von Kennwörtern mit dem Benutzernamen oder Teilen davon und die Einrichtung von automatischer Kontosperren bei Authentifizierungsfehlern. Bei Offline-Angriffen auf extrahierte Hashes ist die Kennwortlänge entscheidend. Diese Angriffe erfordern aber die Kompromitierung oder Einbindung von Geräten im Netz. Brute-Force-Angriffe prüfen alle möglichen Kombinationen nacheinander. Je länger ein Kennwort ist und je geringer die Anzahl möglicher Prüfungen pro Zeiteinheit, um so weniger erfolgversprechend sind diese. 

Auch wenn kürzere Kennwörter zugelassen werden, so ist es immer sinnvoll, auf Benutzer hinzuwirken, ein längeres, leicht merkbares Kennwort zu erzeugen. Bewährt haben sich in der Praxis zwei Methoden:

  1. Ein Wort oder eine Wortfolge mit persönlichem Bezug, in dem Groß- und Kleinschreibung gewechselt wird, Zeichen und Zeichenklassen gegeneinander ausgetauscht und Ziffern und Sonderzeichen eingefügt. Beispiel: „Urlaub auf Teneriffa“ wird zu „UrlaubAufTeneriffa“ wird zu „Url4ußAuf13neriffa“ wird zu „-Url4u6Auf!3neriffa!“. Nebeneffekt: 20 Zeichen. Solche Ersetzungen werden vor allem für Standardkennwörter und allgemeine Begriffe von Angreifern geprüft, wichtig ist daher eine hinreichende Varianz. "DasIstEinScheixxPasswort" ist z.B. ein ebensolches.
  2. Eine Kombination aus Sätzen oder Worten mit persönlichem Bezug, aber ohne Bezug zueinander. Beispiel: „Mein Name ist nicht Egon Olsen.“ kombiniert mit „Ich mag keine Nudeln.“ kombiniert mit „Unser Hund braucht eine Wurmkur.“ Wird zu „Mein Name ist keine Nudeln Wurmkur.“

Hinsichtlich der Mindestlänge für Kennwörter können Listen häufig verwendeter Kennwörter ausgewertet werden. Zur Ermittlung eines optimalen Verhältnisses zwischen Sicherheit (so lang wie möglich) und Komfort (so kurz wie möglich) wurden Listen mit geleakten Kennwörtern ausgewertet. Über die geprüften Listen (Top 1.000.000 Kennwörter deutsch) und (Top 100.000 Kennwörter NCSC) ergibt sich aus dem Anteil der durch die Mindestlänge ausgeschlossenen Kennwörter geteilt durch die Mindestlänge eine optimale Mindestlänge von 10-13. Ein zusätzlichen Zeichen lohnt sich, solange es mehr Kennwörter ausschließt, als bisher je Zeichen ausgeschlossen wurden. Wir haben in der Vergangenheit 10 Zeichen als Mindestlänge gewählt, mittlerweile aber auf 12 korrigiert.

Länge min. PWs kürzer Anteil Ant. je L. PWs außerhalb Ant.
2 114 0,0011 0,0006 99725
3 347 0,0035 0,0012 99492
4 1472 0,0147 0,0037 98367
5 3537 0,0354 0,0071 96302
6 8438 0,0845 0,0141 91401
7 34777 0,3483 0,0498 65062
8 54683 0,5477 0,0685 45156
9 80418 0,8055 0,0895 19421
10 90667 0,9081 0,0908 9172
11 97704 0,9786 0,0890 2135
12 98630 0,9879 0,0823 1209
13 99182 0,9934 0,0764 657
14 99386 0,9955 0,0711 453
15 99506 0,9967 0,0664 333
16 99606 0,9977 0,0624 233
17 99685 0,9985 0,0587 154
18 99715 0,9988 0,0555 124
19 99746 0,9991 0,0526 93
20 99766 0,9993 0,0500 73
21 99794 0,9995 0,0476 45
22 99806 0,9997 0,0454 33
23 99815 0,9998 0,0435 24
24 99818 0,9998 0,0417 21
25 99821 0,9998 0,0400 18
26 99824 0,9998 0,0385 15
27 99837 1,0000 0,0370 2
28 99838 1,0000 0,0357 1
33 99839 1,0000 0,0303 0


1bei Hybridumgebungen übernimmt lokal im Firmennetz der lokale DC die Authentifizierung