Grundregeln für den Betrieb von Active Directory Domain Controllern
VoraussetzungenEine Active Directory (AD) und dazugehörige Domain Controller (DCs) sollten für einen langfristig sicheren Betrieb über die folgenden Maßnahmen geschützt werden. Die Wirksamkeit der hier dokumentierten Maßnahmen setzt die Umsetzung der Empfehlungen aus "Grundsätzliche Hinweise zum sicheren Betrieb von Windows-Systemen" voraus. Allgemeine Hinweise
- Beachten Sie unter allen Umständen die 2-Benutzerregel: KEINE Nutzung von administrativen Konten für alltägliche Arbeiten mit Zugriff auf das Internet und E-Mail! Siehe dazu auch
- Setzen Sie KEINE gemeinsam benutzten administrativen Konten ein, sondern ordnen Sie jedem Administrator ein personalisiertes Konto für ausschließlich administrative Zwecke zu.
- Nutzen Sie möglichst passwortlose Anmeldeverfahren oder 2-Faktor-Anmeldungen.
- Melden Sie sich mit administrativen AD-Konten interaktiv ausschließlich an dafür vorgesehen Systemen an, wie z.B. speziell abgesicherte Jump-Server, und schränken Sie die Reichweite der Anmeldung administrativer AD-Konten ein (an welchen Systemen darf das administrative AD-Konto für eine interaktive Anmeldung per Konsole oder RDP-Sitzung benutzt werden).
- Die domänenweiten administrativen Gruppen sollten wenige Mitglieder enthalten, möglichst unter 3.
- Nutzen Sie die verfügbaren built-in Gruppen Administrators, Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, Server Operator und Print Operators entsprechend der benötigten Rechte für den jeweiligen administrativen Nutzer, um die Anzahl der Mitglieder vor allem in den Gruppen Administrators, Domain Admins und Enterprise Admins so klein wie möglich zu halten.
- Backupdaten von Domain Controllern können für Online-Angriffe auf eine AD benutzt werden und müssen daher sicher aufbewahrt werden. Empfohlen ist es, Sicherungen auf verschlüsselte Bitlocker-Laufwerke (z.B. VHDX-Dateien) zu speichern.
- Befolgen Sie die Empfehlungen für den Zugriff auf administrative Systeme aus
Welche Maßnahmen sind Gamechanger und warum?
Die wirksamsten Maßnahmen in Bezug auf den Schutz vor Kompromittierung einer AD durch den Missbrauch administrativer Konten sind in Kombination:
Basismaßnahmen
Isolierung vom Internet
Domain Controller sollten isoliert vom Internet betrieben werden.
Microsoft hat aufgrund ihrer Cloud-First-Strategie die bisherige Empfehlung einer strikten Trennung der Domain Controller vom Internet entschärft.
Aus
"... Cloud-powered security products are the best form of defense against modern threats. Cloud-powered security eliminates any restrictions around compute, capacity and scale. It’s no longer about considering connecting to a cloud service for the best in security, it’s about needing to.
That’s why today, we have updated the best practices around securing domain controllers against attack. Microsoft is no longer recommending that DCs should have
no internet access under any circumstances. ... To be clear from the outset, Microsoft still advocates for DCs to not have unfiltered internet access and using the internet via a browser from these servers should still be prohibited. Instead of completely isolating DCs from internet access and assuming they will never be breached, we recommend a defense in depth approach including modern threat protection to always monitor for breaches. "
Konfiguration der Windows Firewall
Führen Sie folgenden Befehl in einer administrativen PowerShell aus, um den gesamten eingehenden und ausgehenden Netzwerkverkehr z.B. auf das Subnetz 139.30.0.0/16 zu beschränken:
Zusätzlicher Einsatz von IPSec als Paketfilter Seit Windows 2000 ist IPSec für die Verschlüsselung von IP-Paketen zum Schutz des Netzwerkverkehrs als Bordmittel in Windows enthalten. Die IPSec-Funktionalität beinhaltet einen Paketfilter, welcher sich parallel zum Windows Firewall nutzen lässt.
Weitere Information zu IPSec und Windows finden Sie unter
Konfiguration von Proxy-Servern
Wichtig ist darüber hinaus auch, indirekte Zugriffe auf das Internet über Proxy-Server für die mitgelieferten Webbrowser Internet Explorer und Microsoft Edge zu unterbinden.
Dazu gehen Sie wie folgt vor: Öffnen Sie das entsprechende Gruppenrichtlinienobjekt und wechseln Sie zu
und konfigurieren Sie folgende Einstellung:
anschließend wechseln Sie zu
und konfigurieren Sie folgende Einstellung:
anschließend wechseln Sie zu
und konfigurieren Sie folgende Einstellung:
Weiterhin sollten Sie Zugriffe auf das Internet über Proxy-Server auch für die PowerShell und Systemdienste unterbinden. Führen Sie dazu folgenden Befehl in einer administrativen PowerShell aus:
Installation von Windows Updates Windows Updates sollten auf Domain Controllern über lokal betriebene Windows Update Server (WSUS) installiert werden oder manuell über lokal bereitgestellte Downloads von https://www.catalog.update.microsoft.com/Home.aspx (Microsoft Update Catalog).
Weitere Informationen unter Schutz des built-in AdministratorsInformationen zur indirekten Einschränkung der Anmeldung des built-in Administrators einer Active Directory über Gruppenrichtlinien und Benutzerrechte finden Sie in der Anleitung unter
Nach der Deaktivierung des built-in Administrators sollte auf allen Domain Controllern folgender Registry-Eintrag auf den Wert 1 konfiguriert werden, um im Falle einer Wiederherstellung der Active Directory im Notfall eine administrative Anmeldung trotz nicht verfügbaren Globalen Katalog Servers zu ermöglichen: Neuerdings empfiehlt Microsoft den built-in Administrator aktiviert zu lassen und eine Anmeldung mit dem built-in Administrator nur an der Konsole von Domain Controllern zu erlauben und zusätzlich bei der Anmeldung die Nutzung einer Smart Card zu erzwingen, s. dazu Als Grund für diese Änderung wird dort angegeben:
"In diesem Leitfaden wurde bisher empfohlen, das Konto zu deaktivieren. Diese Empfehlung wurde entfernt, da im Whitepaper zur Wiederherstellung der Gesamtstruktur das Standardadministratorkonto verwendet wird. Der Grund dafür ist, dass dies das einzige Konto ist, das die Anmeldung ohne globalen Katalogserver zulässt." Im "Whitepaper zur Wiederherstellung der Gesamtstruktur" ist zu finden unter
"Sie müssen jedoch die Wiederherstellung mit dem Standardadministratorkonto mit Rid 500 starten oder den Registrierungswert IgnoreGCFailures verwenden:
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa Value: IgnoreGCFailures Type: REG_DWORD Data:
0 – Require GlobalCatalog for logon (default)
1 – Allow logon without groups from GC"
Daher ist die bisherige Empfehlung von Microsoft "Deaktivierung des built-in Administrators" weiterhin nutzbar und vor allem praxistauglich, vorausgesetzt, Sie legen sich mindestens einen zusätzlichen Domänenadministrator an, der Mitglied der Gruppen Domain Admins, Administrators und Enterprise Admins (nur bei Root-Domänen) ist.
Passend zum Thema Die Anforderung einer Smart Card für den built-in Administrator kann durch die Einrichtung von virtuellen Smart Cards auf den Domain Controllern erfüllt werden, s. dazu
Einrichtung eines administrativen Notfallkontos (Break Glass Account)Es ist grundsätzlich empfehlenswert ein administratives Notfallkonto für die Active Directory einzurichten, welches nicht einer einzelnen Person zugeordnet ist und NUR über ein Passwort geschützt ist, für den Fall das keiner der Active Directory Administratoren verfügbar ist und/oder alternative Authentifizierungsmethoden nicht funktional sind.
Härten des LDAP-Protokolls
Öffnen Sie das entsprechende Gruppenrichtlinienobjekt, wechseln Sie zu
und konfigurieren Sie die folgenden Einstellungen:
Weiterhin sollten anonyme LDAP-Binds deaktiviert werden (möglich ab Windows Server 2019). Führen dazu Sie folgenden Befehl in einer administrativen PowerShell aus:
Weitere Informationen unter:
Erzwingen von NTLMv2Erzwingen Sie NTLMv2 auf allen Domain Controllern in Ihrer Domäne mithilfe folgender Einstellungen. Dazu gehen Sie wie folgt vor: Öffnen Sie das entsprechende Gruppenrichtlinienobjekt und wechseln Sie zu
und konfigurieren Sie folgende Einstellung:
Weitere Informationen unter
Erzwingen von SMB-SigningErzwingen Sie SMB-Signing auf allen Domain Controllern in Ihrer Domäne mithilfe folgender Einstellungen. Dazu gehen Sie wie folgt vor: Öffnen Sie das entsprechende Gruppenrichtlinienobjekt und wechseln Sie zu
und konfigurieren Sie folgende Einstellung:
Deaktivierung des Druckerwarteschlangendienstes auf Domain Controllern
Führen Sie folgenden Befehl in einer administrativen PowerShell aus, um den Druckerwarteschlangendienst zu beenden und zu deaktivieren:
Weitere Informationen unter
Einschränkung der Möglichkeit Computerkonten anzulegen
Dazu gehen Sie wie folgt vor: Öffnen Sie das entsprechende Gruppenrichtlinienobjekt und wechseln Sie zu
und konfigurieren Sie folgende Einstellung z.B. für die Gruppe "Administrators" und den Benutzer "Nutzer1" der Domäne "ROSTOCK":
Weitere Informationen unter
Deaktivierung von Multicastnamensauflösung (LLMNR) und NetBIOS-NamensauflösungDeaktivieren Sie unnötige Namensauflösungen des Betriebssystems, um die Angriffsvektoren auf die AD zu reduzieren.
Dazu gehen Sie wie folgt vor:
Deaktivieren der Multicastnamensauflösung Öffnen Sie das entsprechende Gruppenrichtlinienobjekt und wechseln Sie zu
und konfigurieren Sie folgende Einstellung: Deaktivieren der NetBIOS-Namensauflösung
Öffnen Sie das entsprechende Gruppenrichtlinienobjekt und wechseln Sie zu und konfigurieren Sie folgende Einstellung:
Weitere Informationen unter
Gamechangermaßnahmen
Alle interaktiv benutzten administrativen Konten einer Active Directory sollten Mitglied der Gruppe "Protected Users" sein.
Weitere Informationen unter So aktivieren Sie Kerberos Armoring:
Alle Domänencontroller konfigurieren
Alle Domänencontroller in diesen Domänen müssen für die Unterstützung des Kerberos-Schutzes konfiguriert werden.
Konfigurieren Sie die Gruppenrichtlinieneinstellung wie folgt:
Alle Computer konfigurieren
Alle Computer müssen wie folgt konfiguriert werden, damit sie Kerberos Armoring unterstützen.
Gruppenrichtlinieneinstellungen unter
Weitere Informationen unter
Interaktive Anmeldungen einschränken
Deaktivierung des serverseitigen NLA-Zwanges Um das serverseitige Erzwingen von NLA über Gruppenrichtlinien zu deaktivieren gegen Sie wie folgt vor:
Öffnen Sie das entsprechende Gruppenrichtlinienobjekt, wechseln Sie zu
und konfigurieren Sie die folgenden Einstellungen:
Darüber hinaus muss NLA für das jeweilig benutzte Remotedesktopprogramm deaktiviert werden, z.B. für das Microsoft Remotedesktopprogramm mstsc.exe wie folgt:
- Editieren der Datei versteckten Datei default.rdp unter "Eigene Dateien" ("My Documents") oder Dokumente (Documents)
- Hinzufügen der Zeile
enablecredsspsupport:i:0
Weitere Informationen dazu unter "Wann ist es sinnvoll Network Level Authentication (NLA) zu deaktivieren?" aus
Einschränkung der Reichweite eines AD-Kontos über die Konfiguration des userWorkstation-Attributes (nur Windows-Systeme) Die einfachste Form der Einschränkung der Reichweite eines Benutzerkontos ist die Konfiguration des userWorkstation-Attributes, welches festlegt, an welchen Computern das Benutzerkonto sich anmelden darf.
Folgender PowerShell-Befehl konfiguriert z.B. für das Benutzerkonto Nutzer1 die Computer PC01, SERVER03 und TABLET2 als zugelassene Systeme für eine Anmeldung:
Die Konfiguration ist auch per Active Directory-Benutzer und -Computer-Snap-in möglich:
Dies schränkt die Möglichkeit von Angriffen auf Anmeldeinformationen des jeweiligen Nutzers im Hauptspeicher des angegriffenen Systems auf die zugelassenen Systeme ein.
Einschränkung der Reichweite eines AD-Kontos mit Authentication Policies und Authentication Silos (empfohlen)
Authentication Policies und Authentication Silos verwalten Sie per PowerShell oder Active Directory-Verwaltungscenter, s. dazu auch Eine beispielhafte Konfiguration einer Authentication Policy ist in folgendem Snapshot dargestellt:
 Die dargestellte Authentifizierungsrichtlinie mit dem Namen "Administrators" schränkt die Anmeldung des Benutzers "admin" auf die Systeme mit dem Namen "DC1" und "DC2" ein und legt eine Gültigkeitsdauer des Kerberos-Ticket-Granting-Tickets (TGT) des Nutzers "admin" von 8 Stunden fest. Dadurch kann das Benutzerkonto "admin" zukünftig ausschließlich an den Systemen "DC1" und "DC2" interaktiv benutzt werden und nach 8 Stunden muss das Kerberos-Ticket-Granting-Ticket (TGT) des Benutzerkontos "admin" durch eine erneute interaktive Anmeldung verlängert werden. Weitere Informationen unter
Erweiterte Maßnahmen
Deaktivierung von NTLM und Erzwingen von Kerberos für AD-Konten
Eine beispielhafte Konfiguration einer Authentication Policy ist in folgendem Snapshot dargestellt:

Die dargestellte Authentifizierungsrichtlinie mit dem Namen "Kerberos-Only" beschränkt die Anmeldung des Benutzers "serviceuser" auf das Anmeldeprotokoll Kerberos.
Deaktivierung von NTLM (ausgehend)Deaktivieren Sie ausgehendes NTLM auf allen Domain Controllern in Ihrer Domäne mithilfe der Gruppenrichtlinie Netzwerksicherheit: NTLM einschränken: Ausgehender NTLM-Datenverkehr. Dazu gehen Sie wie folgt vor:
Öffnen Sie das entsprechende Gruppenrichtlinienobjekt und wechseln Sie zu und konfigurieren Sie folgende Einstellung: Weitere Informationen unter Zurücksetzen des Passwortes des KRBTGT-NutzersDaher sollte das Passwort des KRBTGT-Nutzers regelmäßig (mind. einmal pro Jahr) neu gesetzt werden. Weitere Informationen dazu unter: Erzwingen der AES-Verschlüsselung für Benutzerkonten mit konfigurierten Service Principle Names (SPN)Führen Sie folgenden Befehl in einer administrativen PowerShell aus, um alle Benutzerkonten einer Domäne mit einem konfigurierten Service Principle Name zu finden: Die angezeigten Konten müssen in der Spalte msDS-SupportedEncryptionTypes den Dezimalwert 24 enthalten, damit die Benutzung der Verschlüsselungsalgorithmen AES128 und AES 256 erzwungen wird und RC4 deaktiviert ist. Führen Sie folgenden Befehl in einer administrativen PowerShell für entsprechende Konten aus, z.B. für das Konto SeviceAccount einer Domäne, um die Benutzung der Verschlüsselungsalgorithmen AES128 und AES 256 zu erzwingen:
Weitere Informationen unter: Entfernen der Gruppe "Authenticated Users" aus der Gruppe "Pre-Windows 2000 Compatible Access"Reduzieren Sie daher die Mitglieder der Gruppe "Pre-Windows 2000 Compatible Access" auf notwendige Ausnahmen, wie z.B. Dienstekonten oder Computerkonten von Anwendungen wie SharePoint, Exchange, Netapp-Systeme etc., indem Sie die Gruppe "Authenticated Users" aus der Gruppe "Pre-Windows 2000 Compatible Access" entfernen und bei Bedarf die Dienstekonten und Computerkonten der entsprechenden Anwendungen der Gruppe "Pre-Windows 2000 Compatible Access" hinzufügen. Weitere Informationen unter
Anpassen der Leserechte für die LDAP-Attribute von administrativen Benutzern und GruppenFühren Sie folgenden Befehl in einer administrativen PowerShell aus, um der Gruppe "Authenticated Users" die Leserechte für die LDAP-Attribute der administrativen Benutzer und Gruppen z.B. der Domäne "local.de" zu entziehen: Diese Konfigurationsänderung ist nach maximal 60 Minuten aktiv. Führen Sie folgenden Befehl in einer administrativen PowerShell aus, um der Gruppe "Authenticated Users" bei Bedarf wieder Leserechte für die LDAP-Attribute der administrativen Benutzer und Gruppen z.B. der Domäne "local.de" zu gewähren: Diese Konfigurationsänderung ist nach maximal 60 Minuten aktiv. Die Änderung betrifft standardmäßig folgende Gruppen einer Active Directory:
- Account Operators
- Administrator
- Administrators
- Backup Operators
- Domain Admins
- Domain Controllers
- Enterprise Admins
- Krbtgt
- Print Operators
- Read-only Domain Controllers
- Replicator
- Schema Admins
- Server Operators
Diese Anpassung versteckt faktisch die built-in administrativen Gruppen einer AD vor nicht administrativen Nutzern, außer diese befinden sich in der Gruppe "Pre-Windows 2000 Compatible Access". Die built-in administrativen Gruppen einer AD können jedoch trotzdem lokalen Gruppen von Systemen über Kommdozeilenbefehle wie net.exe group (cmd.exe/PowerShell) oder Add-LocalGroupMember (PowerShell) hinzugefügt werden, da die SID der AD und die SIDs der built-in administrativen Gruppen einer AD jedem System einer AD bekannt sind. Weitere Informationen unter Anpassung der Zugriffsrechte für neu angelegte BenutzerDarüber hinaus können Sie die Sicherheit weiter erhöhen, indem Sie im Schema der AD das Attribut defaultSecurityDescriptor der Objektklasse „User“ anpassen, um die Zugiffsrechte der Gruppe „Authentifizierte Benutzer“ auf die LDAP-Attribute eines neu angelegten Nutzerobjektes zu entfernen.
adminDescription codePage comment countryCode displayName objectSid primaryGroupID
sAMAccountName sAMAccountType sDRightsEffective showInAdvancedViewOnly sIDHistory uid
| assistant c facsimileTelephoneNumber homePhone homePostalAddress info internationalISDNNumber ipPhone l
mobile msDS-cloudExtensionAttribute1 msDS-cloudExtensionAttribute10 msDS-cloudExtensionAttribute11 msDS-cloudExtensionAttribute12 msDS-cloudExtensionAttribute13 msDS-cloudExtensionAttribute14 msDS-cloudExtensionAttribute15 msDS-cloudExtensionAttribute16 msDS-cloudExtensionAttribute17 msDS-cloudExtensionAttribute18 msDS-cloudExtensionAttribute19 msDS-cloudExtensionAttribute2 msDS-cloudExtensionAttribute20 msDS-cloudExtensionAttribute3 msDS-cloudExtensionAttribute4 msDS-cloudExtensionAttribute5 msDS-cloudExtensionAttribute6 msDS-cloudExtensionAttribute7 msDS-cloudExtensionAttribute8 msDS-cloudExtensionAttribute9 msDS-ExternalDirectoryObjectId msDS-FailedInteractiveLogonCount msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon msDS-GeoCoordinatesAltitude msDS-GeoCoordinatesLatitude msDS-GeoCoordinatesLongitude msDS-HostServiceAccount msDS-LastFailedInteractiveLogonTime msDS-LastSuccessfulInteractiveLogonTime msDS-SupportedEncryptionTypes mSMQDigests mSMQSignCertificates otherFacsimileTelephoneNumber otherHomePhone otherIpPhone otherMobile otherPager otherTelephone pager personalTitle physicalDeliveryOfficeName postalAddress postalCode postOfficeBox preferredDeliveryMethod primaryInternationalISDNNumber primaryTelexNumber publicDelegates registeredAddress st street streetAddress telephoneNumber teletexTerminalIdentifier telexNumber thumbnailPhoto userCert userCertificate userSharedFolder userSharedFolderOther userSMIMECertificate x121Address |
allowedAttributes allowedAttributesEffective allowedChildClasses allowedChildClassesEffective altSecurityIdentities cn co company department
description directReports displayNamePrintable distinguishedName division givenName initials legacyExchangeDN mail manager msDS-AllowedToDelegateTo msDS-Approx-Immed-Subordinates msDS-Auxiliary-Classes msDS-HABSeniorityIndex msDS-PhoneticCompanyName
msDS-PhoneticDepartment msDS-PhoneticDisplayName msDS-PhoneticFirstName
msDS-PhoneticLastName msDS-SourceObjectDN msExchUCVoiceMailSettings msExchUserHoldPolicies
name notes o objectCategory objectClass objectGUID otherMailbox ou proxyAddresses servicePrincipalName showInAddressBook sn systemFlags textEncodedORAddress title userPrincipalName | url wWWHomePage
|
Anpassung des Attributes defaultSecurityDescriptor der Objektklasse „User“ Das Attribut defaultSecurityDescriptor der Objektklasse „User“ kann wie folgt angepasst werden, um die Zugiffsrechte der Gruppe „Authentifizierte Benutzer“ auf die LDAP-Attribute eines neu angelegten Nutzerobjektes zu entfernen. Führen Sie dazu folgenden Befehl in einer administrativen PowerShell aus:
Anpassung des Attributes defaultSecurityDescriptor der Objektklasse „User“ rückgängig machen (Standard wiederherstellen)
Führen Sie folgenden Befehl in einer administrativen PowerShell aus, um die Zugiffsrechte der Gruppe „Authentifizierte Benutzer“ auf die LDAP-Attribute eines neu angelegten Nutzerobjektes auf die Standardzugriffsrechte zu konfigurieren:
Die nachfolgenden Tabellen dokumentieren die Anpassungen. Die Änderungen ersetzen in 4 Einträgen die Gruppe „Authenticated Users“ durch die Gruppe „SELF“.
D:
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;DA)
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;AO)
(A;;LCRPLORC;;;PS) (OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)
(OA;;CR;ab721a54-1e2f-11d0-9819-00aa0040529b;;PS)
(OA;;CR;ab721a56-1e2f-11d0-9819-00aa0040529b;;PS)
(OA;;RPWP;77b5b886-944a-11d1-aebd-0000f80367c1;;PS)
(OA;;RPWP;e45795b2-9455-11d1-aebd-0000f80367c1;;PS) (OA;;RPWP;e45795b3-9455-11d1-aebd-0000f80367c1;;PS) (OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;;RS) (OA;;RP;4c164200-20c0-11d0-a768-00aa006e0529;;RS) (OA;;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;;RS) (A;;RC;;;AU) (OA;;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;;AU) (OA;;RP;77b5b886-944a-11d1-aebd-0000f80367c1;;AU) (OA;;RP;e45795b3-9455-11d1-aebd-0000f80367c1;;AU) (OA;;RP;e48d0154-bcf8-11d1-8702-00c04fb96050;;AU) (OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD) (OA;;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;;RS) (OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA) (OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560) (OA;;RPWP;6db69a1c-9422-11d1-aebd-0000f80367c1;;S-1-5-32-561) | D: (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;DA) (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY) (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;AO) (A;;LCRPLORC;;;PS) (OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS) (OA;;CR;ab721a54-1e2f-11d0-9819-00aa0040529b;;PS) (OA;;CR;ab721a56-1e2f-11d0-9819-00aa0040529b;;PS) (OA;;RPWP;77b5b886-944a-11d1-aebd-0000f80367c1;;PS) (OA;;RPWP;e45795b2-9455-11d1-aebd-0000f80367c1;;PS) (OA;;RPWP;e45795b3-9455-11d1-aebd-0000f80367c1;;PS) (OA;;RP;037088f8-0ae1-11d2-b422-00a0c968f939;;RS) (OA;;RP;4c164200-20c0-11d0-a768-00aa006e0529;;RS) (OA;;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;;RS) (A;;RC;;;AU) (OA;;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;;PS) (OA;;RP;77b5b886-944a-11d1-aebd-0000f80367c1;;PS) (OA;;RP;e45795b3-9455-11d1-aebd-0000f80367c1;;PS) (OA;;RP;e48d0154-bcf8-11d1-8702-00c04fb96050;;PS) (OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD) (OA;;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;;RS) (OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA) (OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560) (OA;;RPWP;6db69a1c-9422-11d1-aebd-0000f80367c1;;S-1-5-32-561) |
NT AUTHORITY\SELF | Allow | This Object Only | Read Permissions,List Contents,Read All Properties,List | NT AUTHORITY\Authenticated Users | Allow | This Object Only | ReadControl | NT AUTHORITY\SYSTEM | Allow | This Object Only | Full Control | NT AUTHORITY\Account Operators | Allow | This Object Only | Full Control | RECHENZENTRUM\Domain Admins | Allow | This Object Only | Full Control | Everyone | Allow | This Object Only | ExtendedRight Change Password | NT AUTHORITY\SELF | Allow | This Object Only | ExtendedRight Receive As | NT AUTHORITY\SELF | Allow | This Object Only | Read All Properties;Write All Properties Personal Information | NT AUTHORITY\SELF | Allow | This Object Only | Read All Properties;Write All Properties Phone and Mail Options | NT AUTHORITY\SELF | Allow | This Object Only | Read All Properties;Write All Properties Web Information | NT AUTHORITY\SELF | Allow | This Object Only | ExtendedRight Send As | NT AUTHORITY\SELF | Allow | This Object Only | ExtendedRight Change Password | NT AUTHORITY\Authenticated Users | Allow | This Object Only | Read Public Information | NT AUTHORITY\Authenticated Users | Allow | This Object Only | Read Web Information | NT AUTHORITY\Authenticated Users | Allow | This Object Only | Read General Information | NT AUTHORITY\Authenticated Users | Allow | This Object Only | Read Personal Information | NT AUTHORITY\Windows Authorization Access Group | Allow | This Object Only | Read tokenGroupsGlobalAndUniversal | NT AUTHORITY\Terminal Server License Servers | Allow | This Object Only | Read All Properties;Write All Properties terminalServer | RECHENZENTRUM\Cert Publishers | Allow | This Object Only | Read All Properties;Write All Properties userCertificate | RECHENZENTRUM\RAS and IAS Servers | Allow | This Object Only | Read Logon Information | RECHENZENTRUM\RAS and IAS Servers | Allow | This Object Only | Read Remote Access Information | RECHENZENTRUM\RAS and IAS Servers | Allow | This Object Only | Read Group Membership | RECHENZENTRUM\RAS and IAS Servers | Allow | This Object Only | Read Account Restrictions |
|
NT AUTHORITY\SELF | Allow | This Object Only | Read Permissions,List Contents,Read All Properties,List | NT AUTHORITY\Authenticated Users | Allow | This Object Only | ReadControl | NT AUTHORITY\SYSTEM | Allow | This Object Only | Full Control | NT AUTHORITY\SYSTEM | Allow | This Object Only | Full Control | RECHENZENTRUM\Domain Admins | Allow | This Object Only | Full Control | Everyone | Allow | This Object Only | ExtendedRight Change Password | NT AUTHORITY\SELF | Allow | This Object Only | ExtendedRight Receive As | NT AUTHORITY\SELF
| Allow | This Object Only | Read All Properties;Write All Properties Personal Information | NT AUTHORITY\SELF | Allow | This Object Only | Read All Properties;Write All Properties Phone and Mail Options | NT AUTHORITY\SELF | Allow | This Object Only | Read All Properties;Write All Properties Web Information | NT AUTHORITY\SELF | Allow | This Object Only | ExtendedRight Send As | NT AUTHORITY\SELF | Allow | This Object Only | ExtendedRight Change Password | NT AUTHORITY\SELF | Allow | This Object Only | Read Public Information | NT AUTHORITY\SELF | Allow | This Object Only | Read Web Information | NT AUTHORITY\SELF | Allow | This Object Only | Read General Information | NT AUTHORITY\SELF | Allow | This Object Only | Read Personal Information | NT AUTHORITY\Windows Authorization Access Group | Allow | This Object Only | Read tokenGroupsGlobalAndUniversal | NT AUTHORITY\Terminal Server License Servers | Allow | This Object Only | Read All Properties;Write All Properties terminalServer | RECHENZENTRUM\Cert Publishers | Allow | This Object Only | Read All Properties;Write All Properties userCertificate | RECHENZENTRUM\RAS and IAS Servers | Allow | This Object Only | Read Logon Information | RECHENZENTRUM\RAS and IAS Servers | Allow | This Object Only | Read Remote Access Information | RECHENZENTRUM\RAS and IAS Servers | Allow | This Object Only | Read Group Membership | RECHENZENTRUM\RAS and IAS Servers | Allow | This Object Only | Read Account Restrictions
|
|
Damit anschließend auch weiterhin Zugriffskontrolllisten (ACLs) durch beliebige Benutzer der AD gepflegt werden können, z.B. beim Hinzufügen von Benutzern und Gruppen einer AD in Zugriffskontrolllisten von Freigaben, müssen Sie die Zugriffskontrollliste der Wurzel der Active Directory anpassen, um das Auslesen von dafür notwendigen LDAP-Attributen zu erlauben. Führen Sie dazu folgende Kommandos in einer administrativen PowerShell aus, beispielhaft für die Domäne "local.de": Hinweis
--% ist das stop-parsing Token der PowerShell, notwendig für die korrekte Ausführung der obigen Kommandos in einer PowerShell. Weitere Informationen unter Deaktivierung der Delegierung von administrativen KontenSetzen Sie die Kontooption "Konto ist vertraulich und kann nicht delegiert werden" für alle administrativen Konten, die sich nicht in der AD-Gruppe "Protected Users" befinden. Für Mitglieder der AD-Gruppe "Protected Users" ist die Delegierung schon deaktiviert. Führen Sie folgenden Befehl in einer administrativen PowerShell für die entsprechenden administrativen Konten aus, z.B. für den built-in Administrator einer Domäne: Weitere Informationen unter Nutzung von LAPS zur Absicherung von Windows-Systemen einer Active Directory
Die Local Administrator Password Solution (LAPS) ist eine inzwischen bordeigene Windows-Funktionalität, welche die Passwörter von lokalen administrativen Konten automatisch erneuern kann.
Dies verringert die Angriffsmöglichkeiten auf Windows-Systeme der AD, weil die Passwörter lokaler Administratoren auf jedem System unterschiedlich und zeitlich begrenzt gültig sind.
Weitere Informationen dazu unter
Angriffe auf Active Directory und deren Abwehr
Die folgende Tabelle enthält verbreitete Angriffe auf die Active Directory und deren Abwehr. AS-REPRoast
| Senden einer Kerberos AS-REQ-Anfrage für ein beliebiges Benutzerkonto an einen DC. Brute-Force-Angriff auf die per Kerberos AS-REP-Antwort übermittelten Kerberos-Daten, welche unter Benutzung des Passwort-Hashes des angegriffenen Nutzerkontos verschlüsselt wurden. Anschließender Brute-Force-Angriff auf den Passwort-Hash, um das Klartextpasswort zu ermitteln. | AD-Konto
| Erzwingen von Kerberos-Pre-authentication
| AS-REQRoast | Abfangen einer Kerberos AS-REQ-Anfrage für ein beliebiges Benutzerkonto an einen DC. Brute-Force-Angriff auf die per Kerberos AS-REQ-Antwort übermittelten Kerberos-Daten, welche unter Benutzung des Passwort-Hashes des angegriffenen Nutzerkontos verschlüsselt wurden. Anschließender Brute-Force-Angriff auf den Passwort-Hash, um das Klartextpasswort zu ermitteln. | Zugriff auf die Netzwerkkommunikation zwischen AD-Client und DC | Passwort mit ausreichender Länge mind. 15 Zeichen
Deaktivierung von RC4 und Erzwingen der AES-Verschlüsselung
| Constrained Delegation | Rechteausweitung in der angegriffenen AD durch die Benutzung von weitergeleiteten Kerberos-Tickets für beliebige Benutzerkonten, welche an Computer oder Dienste ausgeliefert werden, die für die Delegierung (Weiterleitung) von Anmeldeinformationen autorisiert wurden. | Schreiberechte für das LDAP-Attribut msDS-AllowedToDelegateTo des Computer- oder Benutzerkontos des delegierenden Computer- oder Benutzerkontos, Benutzerrecht „Ermöglichen, dass Computer- und Benutzerkonten für Delegierungszwecke vertraut wird“ (SeEnableDelegationPrivilege) Lokale Administratorrechte eines kompromittierten Systems Benutzerrecht „SeEnableDelegationPrivilege“ standardmäßig nur für die AD-Gruppe Administratoren vergeben. | Setzen der Kontooption "Konto ist vertraulich und kann nicht delegiert werden"(AccountNotDelegated) für zu schützende Konten. | DCShadow | Hinzufügen eines Domain Controllers, um diesen für Veränderungen in der AD zu benutzen, welche nicht in Event Logs protokolliert werden. | Domänenadministrator | Security Best Practice | DCSync | Kopieren von Passwort-Hashes administrativer Konten unter Benutzung der Standardreplikationsprotokolle von DCs einer AD. Anschließender Brute-Force-Angriff auf den Passwort-Hash, um das Klartextpasswort zu ermitteln. | AD-Konto mit folgenden Zugriffrechten
- Replicating Directory Changes
- Replicating Directory Changes All
- Replicating Directory Changes In Filtered Set
| Security Best Practice | Diamond Ticket | Auslesen des Passwort-Hashes des AD-Kontos krbtgt mit dessen Hilfe Kerberos Tickets für jeden Nutzer einschließlich administrativer Nutzer von DCs angefordert werden und anschließend modifiziert werden können. | Domänenadministrator oder Offline-Zugriff auf die AD-Datenbank. | Security Best Practice | Golden Ticket | Auslesen des Passwort-Hashes des AD-Kontos krbtgt mit dessen Hilfe Kerberos- Tickets für jeden Nutzer einschließlich administrativer Nutzer ohne Benutzung eines DCs erstellt werden können, jedoch nur für Nutzer der kompromittierten AD. Wenn die Root-AD kompromittiert wurde, können Kerberos Tickets für jeden Nutzer einschließlich administrativer Nutzer des gesamten AD-Baumes erstellt werden. | Domänenadministrator oder Offline-Zugriff auf die AD-Datenbank. | Security Best Practice | Kerberoasting | Abfragen eines Kerberos Service-Tickets für ein AD-Konto mit einem Service Principle Name (SPN) von einem DC. Brute-Force-Angriff auf die mit dem Passwort-Hash des AD-Kontos verschlüsselten Kerberos-Daten. Anschließender Brute-Force-Angriff auf den Passwort-Hash, um das Klartextpasswort zu ermitteln. | AD-Konto | Deaktivierung von RC4 und Erzwingen der AES-Verschlüsselung für Benutzerkonten mit konfigurierten Service Principle Names (SPN) | NTLM-Relaying | Abfangen und anschließende Wiederverwendung von NTLM-Anmeldeinformationen. | Lokale Administratorrechte eines kompromittierten Systems | Deaktivierung von NTLM SMB-Signing | Overpass the Hash | Abfangen des Passwort-Hashes eines AD-Nutzers und anschließende Wiederverwendung des Passwort-Hashes, um Kerberos-Tickets anzufordern für Anmeldungen an Diensten und Systemen. | Lokale Administratorrechte eines kompromittierten Systems | Deaktivierung von NTLM | Pass the Hash | Abfangen des Passwort-Hashes eines AD-Nutzers und anschließende Wiederverwendung des Passwort-Hashes für Anmeldungen an Diensten und Systemen. | Lokale Administratorrechte eines kompromittierten Systems | Deaktivierung von NTLM | Pass the Ticket | Abfangen des Kerberos-Tickets eines AD-Nutzers und anschließende Wiederverwendung des Kerberos-Tickets für Anmeldungen an Diensten und Systemen. | Lokale Administratorrechte eines kompromittierten Systems | Einschränkung der Reichweite einer Anmeldung und der Dauer der Gültigkeit einer erfolgreichen Anmeldung Credential Guard | Resource Based Constrained Delegation | Rechteausweitung in der angegriffenen AD durch die Benutzung von weitergeleiteten Kerberos-Tickets von beliebigen Benutzerkonten, welche an Computer oder Dienste ausgeliefert werden, die für die Delegierung (Weiterleitung) von Anmeldeinformationen autorisiert wurden. | AD-Konto mit Schreibrechten auf ein Computerkonto des Systems an welches Kerberos-Tickets weitergeleitet werden sollen. Ausführrechte auf einem zusätzlichen kompromittierten System | Setzen der Kontooption "Konto ist vertraulich und kann nicht delegiert werden"(AccountNotDelegated) für zu schützende Konten. | Silver Ticket | Auslesen des Passwort-Hashes eines Dienstekontos oder Computerkontos, um für diese Kerberos Service Tickets ohne Benutzung eines DCs zu erstellen. | Lokale Administratorrechte eines kompromittierten Systems oder AD-Konto für Angriff über Kerberoasting | Security Best Practice
Deaktivierung von RC4 und Erzwingen der AES-Verschlüsselung für Benutzerkonten mit konfigurierten Service Principle Names (SPN) | Skeleton Key
| Online-Modifizierung des LSASS-Prozesses über das Laden einer zusätzlichen DLL.
Ein Angreifer kann sich anschließend über ein Masterpasswort als beliebiger Benutzer ohne dessen Passwort authentifizieren. Vorhandene Nutzerpasswörter können weiter benutzt werden.
| Domänenadministrator
| Security Best Practice
Software Whitelisting
| Unconstrained Delegation | Rechteausweitung in der angegriffenen AD durch die Benutzung von weitergeleiteten Kerberos-Tickets für beliebige Benutzerkonten, welche an Computer oder Dienste ausgeliefert werden, die für die Delegierung (Weiterleitung) von Anmeldeinformationen autorisiert wurden. | Benutzerrecht „Ermöglichen, dass Computer- und Benutzerkonten für Delegierungszwecke vertraut wird“ (SeEnableDelegationPrivilege) - administrative Zugriffsrechte auf dem delegierenden System Benutzerrecht „SeEnableDelegationPrivilege“ standardmäßig nur für die AD-Gruppe Administratoren vergeben. Lokale Administratorrechte eines kompromittierten Systems | Setzen der Kontooption
"Konto ist vertraulich und kann nicht delegiert werden"(AccountNotDelegated) für zu schützende Konten. |
Liste der in der Tabelle verwendeten Abkürzungen - AD = Active Directory
- AES = Advanced Encryption Standard
- AS-REP = Authentication Server Response
- AS-REQ = Authentication Server Request
- DC = Domain Controller
- KDC = Kerberos Key Distribution Center
- RC4 = Rivest Cipher 4 (auch ARC4=Alleged RC4 oder Arcfour)
FAQ
Wo und wie werden Passwörter in einer AD gespeichert?
In einer AD werden Passwörter für Kerberos und NTLM als vom Passwort abgeleiteter Hash (mathematische Einwegtransformation zu einem digitalen "Fingerabdruck") pro Benutzer gespeichert.
Digest
| supplementalCredentials
| MD5
| Kerberos
| supplementalCredentials
| HMAC-SHA1/HMAC-SHA256/HMAC-384 (PBKDF2)
| NTLM
| unicodePwd
| MD4 (NTLM-Hash)
|
Warum können sich Benutzer nicht mehr anmelden, wenn der Verschlüsselungsalgorithmus RC4 deaktiviert wurde?
Kerberos benutzt Passwort-Hashes zum Verschlüsseln von Kerberos-Datenpaketen. Wenn RC4 deaktiviert wurde, kann Kerberos nur noch AES für die Verschlüsselung benutzen. Für die Verschlüsselung mit AES muss das Benutzerpasswort neu gesetzt worden sein, nachdem die AD auf Windows Server 2008 oder höher aktualisiert wurde, da AES für Kerberos erst ab Windows Vista/Windows Server 2008 verfügbar ist.
Welche Authentifizierungsprotokolle werden durch welche Anwendungsprotokolle benutzt?
Digest
| Benutzername + Passwort
| HTTP LDAP
| Ja (optional)
| Kerberos
| Benutzername + Passwort Zertifikat (Smart Card)
| HTTP LDAP RDP RPC SMB
| Ja (optional)
| Klartext
| Benutzername + Passwort
| HTTP (Basic) LDAP (Simple)
| Ja (optional)
| NTLM
| Benutzername + Passwort
| HTTP LDAP RDP RPC SMB
| Ja (optional)
|
Kostenlose Tools zum Überprüfen der Sicherheitskonfiguration einer Active Directory
Weitere Informationen
Microsoft
Andere
|