Checkliste Active Directory Absicherung

Adminkonten

"Der größte Risikofaktor ist der Domain Admin!" Das ist leider wahr denn immer noch arbeiten zu viele Personen und Dienste mit zu umfangreichen Berechtigungen, weil es einfach "bequem" war, dies so einzurichten. Gerade "DomainAdmins" sind die allmächtigen Götter, die aber auch alles kaputt machen können. Ich habe schon vor vielen Jahren auf Adminkonzept dazu etwas geschrieben und hier nur die Stichpunkte.

• Benutzer mit Postfach sind keine Administratoren
  Denn ansonsten kann AdminSDHolder zuschlagen und z.B. ActiveSync verhindern
• Administratoren haben kein Postfach und greifen auf kein Postfach zu
  Hier ist AdminSDHolder weniger das Problem sondern eher, dass ein Admin versehentlich eine Malware im Postfach öffnet
• Administratoren melden sich nicht auf normalen PCs an und nutzen kein VPN mit ihrem AdminKonto
  Können Sie sicher sein, dass dort keine Malware, Keylogger o.#. auf sie wartet? Über Anmeldebeschränkungen (LogOnLocally) können Sie dies zusätzlich steuern. Auch sollten die Konten von extern nie per BruteForce o.ä. erreichbar sein, so dass ein Angreifer erst ein normale Konto kapern muss, ehe dann überhaupt weiter gehen kann und auffällt, wenn das Konto dann z.B. mehrfach angemeldet ist.
• Normale Anwender kommen nicht auf die Server Konsole
  Sie könnten damit ja Rechte von Freigaben umgehen und direkt auf Disks zugreifen. Ausnahme sind natürlich Terminal Server/Citrix-Server
• Besonders starke Kennworte für Administratoren
  Auch normale Anwender sollten starke Kennworte nutzen aber Administratoren sind noch einmal sensibler. Mittels Fine-grained Password Policy ist einiges möglich
• Nur "aktive privilegierte Konten"
  Prüfen Sie regelmäßig, welche privilegierten Konten (Admin-Benutzer aber auch Dienstkonten) sich länger nicht angemeldet haben. Vielleicht können Sie diese besser deaktivieren oder mit Ablaufdatum versehen und er bei Bedarf auf Zeit reaktivieren. z.B. für externe Dienstleister. Prüfen Sie auch, ob Dienste als GMSA - Group Managed Service Account gestartet werden können.
  Und natürlich gilt immer: "Weniger ist mehr"
• "Protected Group" und Delegation
  Schützen Sie ihre Administratoren z.B. durch die Mitgliedschaft in der Gruppe und so NTLM zu verhindern. Achten Sie zudem darauf, dass diese Konten z.B. nicht für Kerberos - Constraint Delegation genutzt werden können.
• Member in Administrativen Gruppen
  Die Schema-Admin-gruppe sollte leer sein und wer mehr als 2-3 DomainAdmins hat, hat kein Adminkonzept. In "Exchange Servers" sollten auch nur Server sein. Prüfen Sie ihre Berechtigungsgruppen auf falsche Mitglieder und prüfen Sie auch einmal AdminSDHolder.
• Protokollierung
  Aktivieren sie die Überwachung für An/Abmeldungen. Denkbar ist auch ein Auditing auf Änderungen bei administrative Gruppen.
  

Die Liste könnte ich noch weiter führen.

• Adminkonzept
• AdminSDHolder
• Tier 0/1/2 Security ist nicht alles

Windows Versionen

Natürlich kann ich noch Windows XP-Clients mit Windows 2008DCs betreiben und genau solche Umgebungen habe ich auch 2024! noch gefunden. Da ist es aber schon Glück, dass nichts passiert ist, wenn Windows XP kann nur unsichere SMB1, TLS 1.2 ist per Default nicht aktiv, MD5 noch unterstützt. Das sind Extrembeispiele aber wenn sie Systeme ohne Support und Updates weiter betreiben, dann sollte sie eine schriftliche Risikoabschätzung habe, die die Gründe beschreibt. Ich bin sehr sicher, dass im Fall des Falles keine Versicherung einspringt und persönliche Haftungen schmerzhaft sind.

AD Backup und Restore

Wenn ihr AD "verloren" wurde, was durch den Ausfall aller DCs, aber auch einen Konfigurationsfehler oder Hackerangriff passieren kann, dann ist eine Wiederherstellung eines bekannten Zustands oft besser als ein Neuaufbau. Dazu müssen Sie aber ihr Backup regelmäßig machen und die Schritte der Wiederherstellung dokumentiert haben. Es hilft nichts, wenn sie dank 802.1x mit Radius am AD nicht mehr ins Netzwerkkommen und der Windows DHCP/DNS-Server keine Adressen verteilt und eine Anmeldung am VMWare vCenter mangels AD nicht mehr möglich ist. Das sind nur ein paar Beispiele.

DCs absichern

Die Domain Controller sind das Herz des AD und wenn ein Angreifer an oder sogar auf den DC kommt, dann ist ihr gesamtes System in Gefahr. Daher sollten Sie ein paar Dinge besser lassen, insbesondere je größer ihre Firma ist. Bei sehr kleinen Firmen kann ich schon verstehen, dass Sie vielleicht Dienste auf Servern kombinieren.

• RDP-Zugang
  Der Zugriff per RDP oder jegliche andere Software auf die Konsole oder eine Session auf dem Server muss stark gesichert sein. DAs kann eine Firewall im Netzwerk oder auch auf dem Server selbst sein, die den Zugriff auf den RDP-Port auf ausgewählte Clients beschränkt. Zudem sollte die erweiterte Sicherheit aktiv bleiben.
• Druckserver
  Ein Domain Controller sollte kein Spooler sein, denn über die Installation von Treibern und andere Lücken kann das AD geschwächt werden. Siehe dazu auch PrintNightmare Print Spooler Exploit
• Zusatzdienste (DNS, DHCP, PKI)
  Überlegen Sie sich mehrfach, ob sie solche Dienste mit auf dem DC kombinieren. Sicher sind gerade DNS und DHCP auch "Infrastrukturdienste" aber spätestens wenn Sie die Verwaltungsberechtigungen auf verschiedene Personen verteilen wollen, sollten dies auch eigene Systeme sein. Eine PKI auf einem DC nutze ich nur in einem Test-Labor um z.B. Zertifikat für Computer auszustellen. Sobald Sie mit der PKI aber mehr machen, sollten Sie diese separat aufstellen. Eine PKI lebt meist länger als ein DC.
• Firewall
  "Normalerweise" ist auf jeden Windows Server die eingebaute Firewall aktiv und erlaubt generell nur die Erreichbarkeit von Diensten, die von einem privilegierten Benutzer installiert wurden. Eine fremde Software kann nicht mal so einfach eine eingehende Verbindung öffnen. Aber die Standardeinstellungen beschränken weder ausgehende Verbindungen (Ausgehende Firewall ) noch werden eingehende Verbindungen anhand der Source-IP beschränkt. Das ist für einen DC auch nicht einfach, wenn man mal von RDP absieht. Dennoch sollten Sie mal darüber nachdenken ob z.B. jeder dann den Agent der Monitoring-Lösung zur Überwachung oder den Backup Agent zur Sicherung erreichen muss. Auch die ADWS-Services könnten beschränkt werden.

Auch hier gibt es noch viele weitere Möglichkeiten wie SecureBoot, Bitlocker, IPSec, Berechtigungen von Backup, Antivirus und Monitoring, Schutz virtueller Server gegen "Clone" etc. die speziell bei Domaincontrollern zu diskutieren sind. 

SMB1 Abschaltung

SMB ist das primäre Protokoll zum Zugriff auf Dateien über Freigaben und quasi seit Windows for Workgroups im Einsatz. Aber es hat einige Evolutionsschritte durchlaufen, um neue Funktionen zur halten und Lücken zu schließen. Aber auch hier ist "Rückwärtskompatibilität" das KO-Schlagwort, um sich um die Abschaltung der alten Versionen zu drücken. Windows XP und frühere können nur SMB1 und wer SMB1 abschaltet, sperrt diese Systeme komplett aus. Aber für die Fälle gibt es Lösungen (Siehe Alte Clients) und sollte sie nicht hindern. Neuere Windows Server Versionen haben SMB1 per Default abgeschaltet.

• SMB1 Abschaltung
• Active Directory Hardening Series - Part 2 – Removing SMBv1
  https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/active-directory-hardening-series-part-2-removing-smbv1/ba-p/3988317

LDAP Signing und TLS

Die primäre Schnittstelle zum Lesen aber auch Ändern von AD-Objekten ist LDAP und es wäre doch bitte, wenn ein Angreifer ihre Sitzung übernehmen kann. Dagegen können Sie sich besser schützen, denn per Default erlaubt das AD auch ein LDAP-Zugriff und Anmeldung über Port 389 und nicht nur LDAPS mit TLS-Schutz.

• LDAP Security: LdapEnforceChannelBinding
• Event 2887, Event 2889 und LDAP Signing
• LDAP Security
  Bewerten sie die Risiken eines LDAP-Servers und nutzen sie z.B. TLS
• Active Directory Hardening Series - Part 3 – Enforcing LDAP Signing
  https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/active-directory-hardening-series-part-3-enforcing-ldap-signing/ba-p/4066233

PAC Signing

Tatsächlich konnte ein Angreifer quasi ein vom KDC ausgestelltes Tiket nehmen, ändern und die Signatur anpassen, damit es von anderen Server as "Gültig" anerkannt wird. Erst die PAC-Signierung verhindert diesen Missbrauch und sollte auf jeden Fall aktiviert werden. Seit 10 Okt 2023 sollte diese der Default sein aber stellen Sie sicher, dass der KRB-Ke auch AES nutzt.

• PAC Signing mit Kerberos
• Windows Security Changes 2023

Kerberos Key Rollover

Alle Domain Controller stellen über die "KDC"-Funktion entsprechende Kerberos Tickets aus. Das KDC hat dazu aber auch ein "Geheimnis", welches sich alle Server der Domain teilen. Das Konto des "krbtgt"-Kontos ist besonders zu schützen und sollte laut Microsoft mindestens einmal im Jahr auch geändert werden .Wenn Sie den Verdacht haben, dass ein Angreifer irgendwie die Daten erhalten hat, z.B. über ein Backup-Band, DC-Snapshot o.ä., dann sollte Sie das Kennwort zweimal ändern, um sogenannte "Golden Ticket"-Angriffe abzuwehren.

• KRBTGT Key Rollover

Kerberos RC4 Abschaltung

Die Verschlüsselung und Signierung von Kerberos-Tickets kann über verschiedene Verfahren erfolgen. MD5 ist mittlerweile per Default deaktiviert aber das auch 2024 noch per Default mögliche RC4-Verfahren gilt schon als "knackbar" und sollte nicht mehr genutzt werden. Die meisten Server und Clients bieten schon lange AES128/AES256 an aber noch kann ein Angreifer z.B. ein "Downgrade" erzwingen. Prüfen Sie, ob sie bei Kerberos auch RC4 auf dem Server abschalten können. Sogar Windows XP kann AES.

• Kerberos RC4 Abschaltung
• Kerberos Encryption
• Kerberos Password setzen (KPASSWD)
• RC4 - Nein Danke
• Active Directory Hardening Series - Part 4 – Enforcing AES for Kerberos
  https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/active-directory-hardening-series-part-4-enforcing-aes-for/ba-p/4114965

RPC Sealing

Seit 11 Juli 23 sollte auch diese Lücker per Default auf allen Server mit aktuellen Updates geschlossen sein. Wenn Sie natürlich noch etwas ältere Patchstände oder gar Windows Versionen nutzen (z.B. 2008/2012/2021R2), dann wird es höchste Zeit für ein Upgrade.

• RPC Sealing

LM/NTLM Abschaltung

In vielen Umgebungen werden als falsch verstandener "Rückwärtskompatibilität" immer noch schwache Anmeldeverfahren wie LM oder NTLM genutzt, die normalerweise niemand mehr braucht. Aktivieren Sie das Logging auf den Servern und schauen sie, wer noch nicht NTLMv2 oder Kerberos nutzt. Zuerst sollten Sie sicherstellen, dass alle Server NTLMv2 mit anbieten und dann auf den Clients nach und nach NTLMv1 verbieten. Wenn dann auf den Servern keine alten Anmeldungen mehr erscheinen, dann stellen Sie den Server auf "LM/NTLM abweisen" um.

Denken Sie dabei auch an Systeme wie z.B. Radius, die bei der Nutzung von PAP/MSCHAP/MSCHAPv2 per Default mit NTLM arbeiten. Erst EAP-MSCHAPv2 und PEAP nutzt NTLMv2. Sie können aber Radius auch sagen, dass er NTLMv2 für die anderen Protokolle nutzen soll:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\Enable NTLMv2 Compatibility:DWORD=1

Vielleicht können wir in naher Zukunft komplett auf NTLM verzichten und alles über Kerberos absichern.

• NTLM Deaktivierung
• NTLM MITM mit Edge / PIKABOT
• NTLM-Anmeldung
• The evolution of Windows authentication
  https://techcommunity.microsoft.com/t5/windows-it-pro-blog/the-evolution-of-windows-authentication/ba-p/3926848
• NTMLv1 und VPN/Radius
  https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/rras-vpn-connections-fail-ms-chapv2-authentication
• VPN connections fail when using MS-CHAPv2
  https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/rras-vpn-connections-fail-ms-chapv2-authentication
• Active Directory Hardening Series - Part 1 – Disabling NTLMv1
  https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/active-directory-hardening-series-part-1-disabling-ntlmv1/ba-p/3934787
• How to Disable NTLM Authentication in Windows Domain
  https://woshub.com/disable-ntlm-authentication-windows/

Extended Protection

Aber selbst mit NTLMv2 sind sie nicht zwingend "sicher", denn auch hier sind MITM-Attacken möglich und erst Anfang 2024 hat Microsoft z.B. in Exchange die Default-Einstellungen entsprechend angepasst, damit über den IIS dieser Angriff nicht mehr möglich ist. Prüfen Sie diese Einstellung aber auch auf anderen Webservern, die NTLM anbieten

• IIS Extended Protection
• Exchange Extended Protection
• CVE-2024-21410 Betrachtung

TLS Aktivieren (RDP, LDAP etc.)

Wenn der DC wirklich nur DC ist, dann sind Zugriff per SMB2, Kerberos etc per Default recht gut gesichert. Aber LDAP (389 TCP) und GC (3268/TCP) lauschen auf Anfragen ohne Verschlüsselung. Sicher haben die meisten DCs ein "SelfSigned"-Zertifikat für LDAPS aber dem vertraut niemand und damit ist kein Man in the Middle (MITM)-Schutz möglich. Nutzen die die Change alle Zugriffe per TLS auf TLS 1.2 oder höher abzusichern und ein gültiges Zertifikat zu nutzen. Das kann auch eine interne private PKI sein. Sorgen Sie in dem Zuge auch dafür, dass ihre intern PKI sicher ist (Siehe Cert Logon Unsicherheit (KB5014754))

• TLS 1.2 Enforcement
• Cert Logon Unsicherheit (KB5014754)
• LDAP Security
  Bewerten sie die Risiken eines LDAP-Servers und nutzen sie z.B. TLS
• Configuring a Certificate Template for Domain Controllers
  https://www.gradenegger.eu/en/configuring-a-certificate-template-for-domain-controllers/

Pre Windows 2000 Group

Diese Gruppe ist nur dafür da, damit Mitglieder fast "alle" Felder im AD lesen dürfen. Ansonsten könnten Programme ein Problem bekommen, die noch auf NT4-APIs zugreifen und nicht mit den Standardrechten des ADs zurecht kommen. Ich kenne keine Software und die Gruppe sollte immer leer sein. Sie müssen Sie ja nicht gleich löschen.

AD dsHeuristics

Wussten Sie, dass per Default jeder Domain Benutzer bis zu 10 Computer in eine Domain aufnehmen kann und dann als "Owner" dieses AD-Objekte auch umfangreich ändern kann, z.B. SPN ändern und ein Zertifikat für das Konto anfordern kann? Das sollten Sie umgehend ändern und in dem Zuge auch die Einstellungen von dsHeuristics prüfen und ggfls. anpassen.

• AD dsHeuristics
• Cert Logon Unsicherheit (KB5014754)

Security Tools

Wir sprechen hier über Einstellungen aus Servern und in Konfgurationen. Da liegt es nahe, die fraglichen Einstellungen durch eine Software auslesen und überprüfen zu lassen. Am Anfang kann das manuell erfolgen, um dann die Punkte anzugehen. Interessant könnte eine automatische regelmäßige Überprüfung mit aktualisierten Regeln sein, so dass das Sicherheitsniveau hoch bleibt. Es gibt sogar kostenfreie Tools zum "Selbst-Assessment", die ich jedem ans Herz legen möchte, wenn Sie keinen Dienstleister mit einer Analyse beauftragen wollen. Sie erhalten so relativ schnell einen ersten Überblick. Beachten Sie aber auch, dass die Tools erst einmal die "einfachen" Dinge prüfen. Erwarten Sie keine Analyse ihres Dateiserver oder Exchange Server über falsch gesetzte Zugriffsrechte von Benutzern. Für das Active Directory und Domain Controller sind Sie aber einer guter Startpunkt.

• Ping Castle
• Purple Knight