Skip Ribbon Commands
Skip to main content
SharePoint

Public Pages > Pub > Skip Navigation LinksBest Practice Active Directory

Grundregeln für den Betrieb von Active Directory Domain Controllern

Table Of Contents

Voraussetzungen

Eine 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.

 Alle nachfolgend dokumentierten Maßnahmen sind in der zentral verwalteten Windows-Infrastruktur des ITMZ umgesetzt und praxistauglich.

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:

Die kombinierte Nutzung dieser Funktionalitäten führt dazu, dass die entsprechenden Konten nur noch über geschütztes Kerberos mit AES-Verschlüsselung, an festgelegten Systemen und nur für eine bestimmte Zeitspanne benutzt werden können.

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. "

Anders formuliert, solange die On-Premises Active Directory keine Cloud-Dienste nutzt, sollten Domain Controller weiterhin isoliert vom Internet betrieben werden.

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:

Get-NetFirewallrule | Get-NetFirewallAddressFilter | Set-NetFirewallAddressFilter -RemoteAddress 139.30.0.0/16


Wichtig! 

Bitte beachten Sie, die Standardreichweite von geöffneten Anwendungsports unter Windows ist weltweit (ANY).

Bei jeder Installation von zusätzlichen Rollen oder Features unter Windows Server werden eventuell zu öffnende Ports immer mit der Reichweite weltweit konfiguriert, z.B. werden bei der Installation des Internet Information Servers (IIS) die TCP-Ports 80 und 443 durch die Setup-Routinen weltweit geöffnet.


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.

Die zentral verwalteten Windows-Server des ITMZ nutzen seit Jahren den bordeigenen IPSec-Paketfilter von Windows als Basisschutz vor Angriffen aus dem Internet, indem dieser sämtlichen Internetverkehr auf IP-Ebene blockiert und sämtlichen Intranetverkehr erlaubt. Die Windows Firewall wird zusätzlich für die Feinsteuerung des Zugriffes auf benötigte Anwendungsports eingesetzt.

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

 Benutzerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Microsoft Edge -> Proxy server

und konfigurieren Sie folgende Einstellung:

 Proxy settings auf {"ProxyMode": "direct"}

anschließend wechseln Sie zu 

 Benutzerkonfiguration -> Richtlinien->Administrative Vorlagen -> Windows Components -> Internet Explorer

und konfigurieren Sie folgende Einstellung:

Disable changing connection settings = Aktiviert
Prevent changing proxy settings = Aktiviert

anschließend wechseln Sie zu 

 Benutzerkonfiguration -> Einstellungen->Windows-Einstellungen ->Registrierung

und konfigurieren Sie folgende Einstellung:

Struktur auf HKEY_CURRENT_USER
Schlüsselpfad auf Software\Microsoft\Windows\CurrentVersion\Internet Settings 
Name auf ProxyEnable
Werttyp auf REG_DWORD
Wertdaten auf 0


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:
 netsh.exe winhttp reset proxy

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).

Das ITMZ bietet einen universitätsweiten WSUS-Dienst an. Informationen dazu finden Sie unter

Weitere Informationen unter

Schutz des built-in Administrators

Der built-in Administrator einer Active Directory sollte deaktiviert werden, da sich eine Anmeldung mit diesem Konto nicht direkt auf bestimmte Computer einschränken lässt, sondern nur indirekt über Gruppenrichtlinien und Benutzerrechte, deren Durchsetzung NICHT auf jedem System garantiert werden kann, z.B. wenn ein System kompromittiert ist.

Informationen zur indirekten Einschränkung der Anmeldung des built-in Administrators einer Active Directory über Gruppenrichtlinien und Benutzerrechte finden Sie in der Anleitung unter

Wichtig!

Vergessen Sie nicht, vor der Deaktivierung des built-in Administrators mindestens einen zusätzlichen Domänenadministrator anzulegen, der Mitglied der Gruppen Domain Admins, Administrators und Enterprise Admins (nur bei Root-Domänen) ist.


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:

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


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 

 Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Sicherheitsoptionen

und konfigurieren Sie die folgenden Einstellungen:

Domänencontroller: Anforderungen an das LDAP-Serverkanal-Bindungstoken = Immer
Domänencontroller: Signaturanforderungen für LDAP-Server = Signatur erforderlich
Netzwerksicherheit: Signaturanforderungen für LDAP-Clients = Signatur erforderlich


Weiterhin sollten anonyme LDAP-Binds deaktiviert werden (möglich ab Windows Server 2019). Führen dazu Sie folgenden Befehl in einer administrativen PowerShell aus:

$RootDSE = Get-ADRootDSE
$ObjectPath = 'CN=Directory Service,CN=Windows NT,CN=Services,' + $RootDSE.ConfigurationNamingContext
Set-ADObject -Identity $ObjectPath -Add @{ 'msDS-Other-Settings' =  'DenyUnauthenticatedBind=1' }


Weitere Informationen unter:

Erzwingen von NTLMv2

Erzwingen 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 

Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Sicherheitsoptionen


und konfigurieren Sie folgende Einstellung:

Netzwerksicherheit: LAN Manager-Authentifizierungsebene = Nur NTLMv2-Antworten senden. LM und NTLM verweigern
Netzwerksicherheit: Minimale Sitzungssicherheit für NTLM-SSP-basierte Clients (einschließlich sicherer RPC-Clients) = NTLMv2-Sitzungssicherheit erfordern und 128-Bit-Verschlüsselung erfordern
Netzwerksicherheit: Minimale Sitzungssicherheit für NTLM-SSP-basierte Server (einschließlich sicherer RPC-Server) = NTLMv2-Sitzungssicherheit erfordern und 128-Bit-Verschlüsselung erfordern


Weitere Informationen unter

Erzwingen von SMB-Signing

Erzwingen 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 

Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Sicherheitsoptionen

und konfigurieren Sie folgende Einstellung:

Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) = Aktiviert
Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) = Aktiviert

Deaktivierung des Druckerwarteschlangendienstes auf Domain Controllern

Führen Sie folgenden Befehl in einer administrativen PowerShell aus, um den Druckerwarteschlangendienst zu beenden und zu deaktivieren:

sc.exe stop spooler
sc.exe config spooler start= disabled

Einschränkung der Möglichkeit Computerkonten anzulegen

Standardmäßig darf jeder Benutzer Computerkonten in einer Domäne anlegen. Ändern Sie diese Konfiguration, indem Sie das Benutzerrecht "Hinzufügen von Arbeitsstationen zur Domäne" auf notwendige Ausnahmen beschränken.

Dazu gehen Sie wie folgt vor:
Öffnen Sie das entsprechende Gruppenrichtlinienobjekt und wechseln Sie zu 

 Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Sicherheitseinstellungen -> Zuweisen von Benutzerrechten

und konfigurieren Sie folgende Einstellung z.B. für die Gruppe "Administrators" und den Benutzer "Nutzer1" der Domäne "ROSTOCK":

 Hinzufügen von Arbeitsstationen zur Domäne = Administrators, ROSTOCK\Nutzer1 

Weitere Informationen unter

Deaktivierung von Multicastnamensauflösung (LLMNR) und NetBIOS-Namensauflösung

Deaktivieren 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 

Computerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Netzwerk -> DNS-Client

und konfigurieren Sie folgende Einstellung:

Multicastnamensauflösung deaktivieren = Aktiviert


Deaktivieren der NetBIOS-Namensauflösung

Öffnen Sie das entsprechende Gruppenrichtlinienobjekt und wechseln Sie zu 

Computerkonfiguration -> Einstellungen->Windows-Einstellungen ->Registrierung

und konfigurieren Sie folgende Einstellung:

Struktur auf HKEY_LOCAL_MACHINE
Schlüsselpfad auf  SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Name auf EnableNetbios
Werttyp auf REG_DWORD
Wertdaten auf 0

Weitere Informationen unter


Gamechangermaßnahmen


Härtung von Konten über Mitgliedschaft in der Protected Users-Gruppe

Die Mitgliedschaft in der AD-Gruppe "Protected Users" erhöht die Sicherheit bei der Benutzung der entsprechenden Benutzerkonten, wie z.B. Domänen-Administratoren, wie folgt:
  • NTLM ist deaktiviert.
  • Die Verwendung der DES- und RC4-Verschlüsselungsalgorithmen in Kerberos-Pre-Authentication sind deaktiviert.
  • Uneingeschränkte und eingeschränkte Kerberos-Delegierungen sind deaktiviert.
  • Die automatische Erneuerung von Kerberos-Tickets ist deaktiviert.
  • Kerberos-Anmeldungen sind nur noch vier Stunden gültig.

Alle interaktiv benutzten administrativen Konten einer Active Directory sollten Mitglied der Gruppe "Protected Users" sein.

Wichtig! 

Dienstekonten sollten NICHT der Gruppe "Protected Users" hinzugefügt werden, da deren Kerberos-Anmeldung dann nur vier Stunden gültig ist und nicht automatisch erneuert wird.

Weitere Informationen unter

Aktivierung Kerberos Armoring (Kerberos-Schutz)

Kerberos Armoring ist Teil des Standards RFC 6113. Kerberos Armoring erhöht den Schutz vor Offline-, Spoofing- und Downgradeangriffen auf Kerberos.

Computer und Benutzer müssen Domänen angehören, in denen Windows Server 2012 oder höher in der Domänenfunktionsebene Windows Server 2012 oder höher ausgeführt wird.

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:

KDC-Unterstützung für Ansprüche, Verbundauthentifizierung und Kerberos Armoring = Immer Ansprüche bereitstellen

unter 

Computerkonfiguration -> Richtlinien ->  Administrative Vorlagen -> System -> KDC

Alle Computer konfigurieren

Alle Computer müssen wie folgt konfiguriert werden, damit sie Kerberos Armoring unterstützen.

Aktivieren Sie die 

Kerberos-Clientunterstützung für Ansprüche, Verbundauthentifizierung und Kerberos Armoring = Aktiviert

Gruppenrichtlinieneinstellungen unter 

Computerkonfiguration->Administrative Vorlagen->System->Kerberos

Weitere Informationen unter

Einschränkung der Reichweite einer Anmeldung und der Dauer der Gültigkeit einer erfolgreichen Anmeldung

Interaktive Anmeldungen einschränken

Interaktive Anmeldungen mit administrativen Konten einer AD, z.B. über die Konsole oder das Remotedesktopprotokoll (RDP), sollten grundsätzlich nur an vertrauenswürdigen Systemen erfolgen, die sich ausschließlich unter administrativer Kontrolle befinden.

Dies lässt sich über die Einschränkung der Reichweite (an welchen Systemen kann das jeweilige Konto benutzt werden) umsetzen. 

Zusätzlich kann die Dauer der Gültigkeit einer Kerberos-Anmeldung (Ticket-Granting-Ticket Lifetime) von administrativen Konten mittels der Funktionalität „Authentication Policies" konfiguriert werden.

Deaktivierung des serverseitigen NLA-Zwanges

Wichtig!  

Damit die für eine RDP-Anmeldung benutzten Endgeräte NICHT auch für eine interaktive Anmeldung des jeweiligen administrativen Kontos zugelassen werden müssen, ist es notwendig, Network Level Authentication (NLA) für administrative RDP-Server (z.B. administrative Jump-Server, DCs etc.) zu deaktivieren.

Dadurch muss die interaktive administrative Anmeldung nicht zusätzlich auf dem benutzten Endgerät erfolgen und kann ausschließlich auf die entsprechenden administrativen RDP-Server beschränkt werden.

Um das serverseitige Erzwingen von NLA über Gruppenrichtlinien zu deaktivieren gegen Sie wie folgt vor:

Öffnen Sie das entsprechende Gruppenrichtlinienobjekt, wechseln Sie zu 

Computerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Windows-Komponenten -> Remotedestopdienste -> Remotedesktopsession-Host -> Sicherheit

und konfigurieren Sie die folgenden Einstellungen:

Benutzerauthentifizierung mit Authentifizierung auf Netzwerkebene für Remoteverbindungen ist erforderlich = Deaktiviert


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.

Wichtig!

Nur bei Windows-Systemen wirksam, jedoch nicht z.B. bei Linux-Systemen.

Folgender PowerShell-Befehl konfiguriert z.B. für das Benutzerkonto Nutzer1 die Computer PC01, SERVER03 und TABLET2 als zugelassene Systeme für eine Anmeldung:

set-ADUser nutzer1 -LogonWorkstations pc01,server03,tablet2

Die Konfiguration ist auch per Active Directory-Benutzer und -Computer-Snap-in möglich:

SecureAD01.png

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)

Um die Reichweite einer Kerberos-Anmeldung und zusätzlich die Dauer der Gültigkeit einer erfolgreichen Kerberos-Anmeldung (Ticket-Granting-Ticket Lifetime) von Konten einer Active Directory zu konfigurieren, kann die Funktionalität „Authentication Policies" genutzt werden.

Authentication Policies und Authentication Silos sind seit Windows Server 2012 R2 verfügbar und somit ab Windows Server 2012 R2 und ab Windows 8.1 einsetzbar. 

Andere Betriebssysteme wie Linux oder MacOS können die Funktionalität nutzen, wenn sie Kerberos Armoring/Flexible Authentication Secure Tunneling (FAST) unterstützen.


Wichtig!

Die Voraussetzung der Nutzung von Authentication Policies und Authentication Silos ist die domänenweite Aktivierung von Kerberos Armoring, s. dazu

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:
SecureAD02.png

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

Über die Funktionalität „Authentication Policies" können Konten in das Kerberos-Protokoll gezwungen werden ohne die Notwendigkeit von regelmäßigen interaktiven Anmeldungen durch die Mitgliedschaft in der Gruppe "Protected Users". Dies ist ein Sicherheitsgewinn vor allem für Dienstekonten, die nicht Mitglied in der Gruppe "Protected Users" sein können.


Wichtig!

Die Voraussetzung der Nutzung von Authentication Policies und Authentication Silos ist die domänenweite Aktivierung von Kerberos Armoring, s. dazu

Eine beispielhafte Konfiguration einer Authentication Policy ist in folgendem Snapshot dargestellt:

SecureAD03.png

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 

Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Sicherheitsoptionen

und konfigurieren Sie folgende Einstellung:

Netzwerksicherheit: NTLM: Ausgehender NTLM-Datenverkehr zu Remoteservern = Alle verweigern

Zurücksetzen des Passwortes des KRBTGT-Nutzers

Das AD-Konto KRBTGT ist das Konto des Dienstes Kerberos Key Distribution Center (KDC) der DCs einer AD.

Der Kerberos-Schlüssel (Password-Hash) dieses Kontos wird benutzt, um die ausgelieferten Ticket-Granting-Tickets (TGTs) jedes authentifizierten Nutzer- und Computer-Kontos einer AD symmetrisch zu verschlüsseln.

Daher 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ür alle Active Directory-Benutzerkonten für die Service Principle Names konfiguriert sind, z.B. Dienstekonten für SQL-Server, muss der Verschlüsselungsalgorithmus RC4 deaktiviert werden, um Kerberos-Angriffe (z.B. Kerberoasting) auf deren Passwörter zu unterbinden.

Führen Sie folgenden Befehl in einer administrativen PowerShell aus, um alle Benutzerkonten einer Domäne mit einem konfigurierten Service Principle Name zu finden:

Get-ADObject -ldapfilter "(&(objectcategory=user)(servicePrincipalName=*)(!(samaccountname=krbtgt)))" -Properties samaccountname,DistinguishedName,msDS-SupportedEncryptionTypes | sort-object -Property samaccountname | ft samaccountname,DistinguishedName,msDS-SupportedEncryptionTypes

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:

Set-ADUser -Identity ServiceAccount -KerberosEncryptionType AES128,AES256

Entfernen der Gruppe "Authenticated Users" aus der Gruppe "Pre-Windows 2000 Compatible Access"

Standardmäßig befindet sich die Gruppe "Authenticated Users" in der Gruppe "Pre-Windows 2000 Compatible Access". Dies erlaubt es jedem in der Domäne angemeldeten Benutzer sämtliche LDAP-Attribute aller AD-Objekte auszulesen.

Dies ist für den Betrieb der Active Directory nicht zwingend notwendig.

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 Gruppen

Standardmäßig ist es der Gruppe "Authenticated Users" erlaubt, sämtliche LDAP-Attribute aller administrativen Benutzer und Gruppen einer Active Directory auszulesen.

Dies ist für den Betrieb der Active Directory nicht notwendig.

Fü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:

 dsacls.exe 'CN=AdminSDHolder,CN=System,DC=local,DC=de' /R 'S-1-5-11'

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:

 dsacls.exe 'CN=AdminSDHolder,CN=System,DC=local,DC=de' /G 'S-1-5-11:RPRCLC'

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 Benutzer

Darü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.

Standardmäßig dürfen Mitglieder der Gruppe „Authentifizierte Benutzer“ die folgenden LDAP-Attribute jedes AD-Nutzers lesen (ausgelesen mit dem Tool adfind, s. dazu unter Weitere Informationen).

Dies ist für den Betrieb der Active Directory nicht zwingend notwendig.

 

adfind.exe -sc findpropsetrg:"General Information"

dn:CN=General-Information,CN=Extended-Rights,CN=Configuration,
DC=local,DC=de

>rightsGuid: 59ba2f42-79a2-11d0-9020-00c04fc2d3cf

adfind.exe -sc propsetmembersl:"59ba2f42-79a2-11d0-9020-00c04fc2d3cf"

adfind.exe -sc findpropsetrg:"Personal Information"

dn:CN=Personal-Information,CN=Extended-Rights,CN=Configuration,
DC=local,DC=de

>rightsGuid: 77B5B886-944A-11d1-AEBD-0000F80367C1

adfind.exe -sc propsetmembersl:"77b5b886-944a-11d1-aebd-0000f80367c1"

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

 

 

adfind.exe -sc findpropsetrg:"Public Information"

dn:CN=Public-Information,CN=Extended-Rights,
CN=Configuration,DC=local,DC=de

>rightsGuid: e48d0154-bcf8-11d1-8702-00c04fb96050

adfind.exe -sc propsetmembersl:"e48d0154-bcf8-11d1-8702-00c04fb96050"

adfind.exe -sc findpropsetrg:"Web Information"

dn:CN=Web-Information,CN=Extended-Rights,
CN=Configuration,DC=local,DC=de

>rightsGuid: E45795B3-9455-11d1-AEBD-0000F80367C1

adfind.exe -sc propsetmembersl:"E45795B3-9455-11d1-AEBD-0000F80367C1"

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:

$schemaDN = (Get-ADRootDSE).schemaNamingContext
$userClass=Get-ADObject -SearchBase $schemaDN -Filter 'cn -eq "user"'
$userClass | Set-ADObject -Replace @{defaultSecurityDescriptor = '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)'} 


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:

$schemaDN = (Get-ADRootDSE).schemaNamingContext
$userClass=Get-ADObject -SearchBase $schemaDN -Filter 'cn -eq "user"'
$userClass | Set-ADObject -Replace @{defaultSecurityDescriptor = '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)'


Die nachfolgenden Tabellen dokumentieren die Anpassungen. Die Änderungen ersetzen in 4 Einträgen die Gruppe „Authenticated Users“ durch die Gruppe „SELF“.

defaultSecurityDescriptor (original )defaultSecurityDescriptor (angepasst)

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)

 

defaultSecurityDescriptor (original )

 Nutzer/Gruppe
 Typ
 Reichweite
 Zugriffsrecht
NT AUTHORITY\SELFAllowThis Object OnlyRead Permissions,List Contents,Read All Properties,List
NT AUTHORITY\Authenticated UsersAllowThis Object OnlyReadControl
NT AUTHORITY\SYSTEMAllowThis Object OnlyFull Control
NT AUTHORITY\Account OperatorsAllowThis Object OnlyFull Control
RECHENZENTRUM\Domain AdminsAllowThis Object OnlyFull Control
EveryoneAllowThis Object OnlyExtendedRight Change Password
NT AUTHORITY\SELFAllowThis Object OnlyExtendedRight Receive As
NT AUTHORITY\SELFAllowThis Object OnlyRead All Properties;Write All Properties Personal Information
NT AUTHORITY\SELFAllowThis Object OnlyRead All Properties;Write All Properties Phone and Mail Options
NT AUTHORITY\SELFAllowThis Object OnlyRead All Properties;Write All Properties Web Information
NT AUTHORITY\SELFAllowThis Object OnlyExtendedRight Send As
NT AUTHORITY\SELFAllowThis Object OnlyExtendedRight Change Password
NT AUTHORITY\Authenticated UsersAllowThis Object OnlyRead Public Information
NT AUTHORITY\Authenticated UsersAllowThis Object OnlyRead Web Information
NT AUTHORITY\Authenticated UsersAllowThis Object OnlyRead General Information
NT AUTHORITY\Authenticated UsersAllowThis Object OnlyRead Personal Information
NT AUTHORITY\Windows Authorization Access GroupAllowThis Object OnlyRead tokenGroupsGlobalAndUniversal
NT AUTHORITY\Terminal Server License ServersAllowThis Object OnlyRead All Properties;Write All Properties terminalServer
RECHENZENTRUM\Cert PublishersAllowThis Object OnlyRead All Properties;Write All Properties userCertificate
RECHENZENTRUM\RAS and IAS ServersAllowThis Object OnlyRead Logon Information
RECHENZENTRUM\RAS and IAS ServersAllowThis Object OnlyRead Remote Access Information
RECHENZENTRUM\RAS and IAS ServersAllowThis Object OnlyRead Group Membership
RECHENZENTRUM\RAS and IAS ServersAllowThis Object OnlyRead Account Restrictions

 

defaultSecurityDescriptor (angepasst)
 Nutzer/Gruppe
 Typ
 Reichweite
 Zugriffsrecht
NT AUTHORITY\SELFAllowThis Object OnlyRead Permissions,List Contents,Read All Properties,List
NT AUTHORITY\Authenticated UsersAllowThis Object OnlyReadControl
NT AUTHORITY\SYSTEMAllowThis Object OnlyFull Control
NT AUTHORITY\SYSTEMAllowThis Object OnlyFull Control
RECHENZENTRUM\Domain AdminsAllowThis Object OnlyFull Control
EveryoneAllowThis Object OnlyExtendedRight Change Password
NT AUTHORITY\SELFAllowThis Object OnlyExtendedRight Receive As
NT AUTHORITY\SELF
AllowThis Object OnlyRead All Properties;Write All Properties Personal Information
NT AUTHORITY\SELFAllowThis Object OnlyRead All Properties;Write All Properties Phone and Mail Options
NT AUTHORITY\SELFAllowThis Object OnlyRead All Properties;Write All Properties Web Information
NT AUTHORITY\SELFAllowThis Object OnlyExtendedRight Send As
NT AUTHORITY\SELFAllowThis Object OnlyExtendedRight Change Password
NT AUTHORITY\SELFAllowThis Object OnlyRead Public Information
NT AUTHORITY\SELFAllowThis Object OnlyRead Web Information
NT AUTHORITY\SELFAllowThis Object OnlyRead General Information
NT AUTHORITY\SELFAllowThis Object OnlyRead Personal Information
NT AUTHORITY\Windows Authorization Access GroupAllowThis Object OnlyRead tokenGroupsGlobalAndUniversal
NT AUTHORITY\Terminal Server License ServersAllowThis Object OnlyRead All Properties;Write All Properties terminalServer
RECHENZENTRUM\Cert PublishersAllowThis Object OnlyRead All Properties;Write All Properties userCertificate
RECHENZENTRUM\RAS and IAS ServersAllowThis Object OnlyRead Logon Information
RECHENZENTRUM\RAS and IAS ServersAllowThis Object OnlyRead Remote Access Information
RECHENZENTRUM\RAS and IAS ServersAllowThis Object OnlyRead Group Membership
RECHENZENTRUM\RAS and IAS ServersAllowThis Object OnlyRead 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":

dsacls.exe --% "dc=local,dc=de" /G "Authenticated Users:RP;displayName" /I:T
dsacls.exe --% "dc=local,dc=de" /G "Authenticated Users:RP;distinguishedName" /I:T
dsacls.exe --% "dc=local,dc=de" /G "Authenticated Users:RP;name" /I:T
dsacls.exe --% "dc=local,dc=de" /G "Authenticated Users:RP;objectCategory" /I:T
dsacls.exe --% "dc=local,dc=de" /G "Authenticated Users:RP;objectClass" /I:T
dsacls.exe --% "dc=local,dc=de" /G "Authenticated Users:RP;objectGUID" /I:T
dsacls.exe --% "dc=local,dc=de" /G "Authenticated Users:RP;objectSid" /I:T
dsacls.exe --% "dc=local,dc=de" /G "Authenticated Users:RP;sAMAccountName" /I:T
dsacls.exe --% "dc=local,dc=de" /G "Authenticated Users:RP;sAMAccountType" /I:T


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 Konten

Standardmäßig können alle Konten einer Active Directory delegiert werden.

Die Delegierung ermöglicht es einem Computer oder Dienst, die Anmeldeinformationen für ein Konto, das sich beim Computer oder Dienst authentifiziert hat, anderen Computern zu präsentieren, um Dienste im Namen des Kontos zu erhalten, wenn dem entsprechenden Computerkonto oder Dienstekonto die Delegierungsrechte durch einen Domänenadministrator eingeräumt wurden oder ein Nutzer Schreibrechte auf ein Computerkonto besitzt.

Wenn Sie die Kontooption "Konto ist vertraulich und kann nicht delegiert werden" für ein domänenbasiertes Konto aktivieren, können die Anmeldeinformationen des Kontos nicht anderen Computern oder Diensten im Netzwerk angeboten werden, wodurch Angriffe eingeschränkt werden, die die Delegierung nutzen, um die Anmeldeinformationen des Kontos auf anderen Systemen zu verwenden.

Setzen 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:

 Set-ADUser Administrator -AccountNotDelegated:$true


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.

Angegriffene Funktionalität oder Angriffsname Kurzbeschreibung Minimal benötigte Zugriffsrechte Abwehr (Blockierung)
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 DCPasswort mit ausreichender Länge mind. 15 Zeichen

Deaktivierung von RC4 und Erzwingen der AES-Verschlüsselung
Constrained DelegationRechteausweitung 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.

 DCShadowHinzufü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 TicketAuslesen 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-KontoDeaktivierung von RC4 und Erzwingen der AES-Verschlüsselung für Benutzerkonten mit konfigurierten Service Principle Names (SPN)
NTLM-RelayingAbfangen und anschließende  Wiederverwendung von NTLM-Anmeldeinformationen.Lokale Administratorrechte eines kompromittierten Systems

Deaktivierung von NTLM

SMB-Signing

Overpass the HashAbfangen 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 SystemsDeaktivierung von NTLM
Pass the HashAbfangen des Passwort-Hashes eines AD-Nutzers und anschließende Wiederverwendung des Passwort-Hashes für Anmeldungen an Diensten und Systemen.Lokale Administratorrechte eines kompromittierten SystemsDeaktivierung von NTLM
Pass the TicketAbfangen 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 DelegationRechteausweitung 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 TicketAuslesen 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 DelegationRechteausweitung 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.

 Authentifizierungsprotokoll
 LDAP-Attribut
 Hash-Algorithmus
 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?

 Authentifizierungsprotokoll
 Anmeldemethode
 Anwendungsprotokolle
  Datenverschlüsselung
 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

Bei Fragen oder Hinweisen zu diesem Dokument melden Sie sich bitte per E-Mail bei joerg.maletzky(at)uni-rostock.de.