Authentifizierungsrichtlinien und -silos für Tier-0-Konten

Anmeldeverweigerungs-GPOs sind das Rückgrat des Tierings, werden aber von jedem Zielcomputer selbst durchgesetzt. Greift eine GPO nicht, liegt ein Server in der falschen OU oder kontrolliert ein Angreifer einen Rechner und ignoriert einfach dessen lokale Richtlinie, akzeptiert die Domäne ein Tier-0-Kennwort oder einen Tier-0-Hash trotzdem. Authentifizierungsrichtlinien und -silos verlagern diese Entscheidung auf den KDC: Ein Tier-0-Konto erhält ein TGT nur von einem zugelassenen Gerät – unabhängig davon, was das Gerät selbst meint.

Dieser Leitfaden erklärt, wie Authentifizierungssilos tatsächlich ausgewertet werden, welche Voraussetzungen gelten (einschließlich Kerberos Armoring), wie Sie ein Tier-0-Silo aufbauen, es im Überwachungsmodus ausrollen und überprüfen. Den kurzen Überblick finden Sie in Tier 0 und privilegierter Zugriff. Hier geht es um die Umsetzung.

Wie Richtlinien und Silos funktionieren

Zwei Objekttypen liegen unter CN=AuthN Policy Configuration,CN=Services in der Konfigurationspartition:

• Authentifizierungsrichtlinie (msDS-AuthNPolicy): Pro Objekttyp (Benutzer, Computer, Dienst) legt sie eine TGT-Lebensdauer und zwei in SDDL formulierte Bedingungen fest: allowed to authenticate from (welche Geräte das TGT des Kontos anfordern dürfen) und allowed to authenticate to (welche Konten Diensttickets für diesen Dienst anfordern dürfen).
• Authentifizierungsrichtliniensilo (msDS-AuthNPolicySilo): gruppiert Konten und weist je Objekttyp eine Richtlinie zu. Die Mitgliedschaft ist zweiseitig: Das Silo führt zugelassene Mitglieder in msDS-AuthNPolicySiloMembers, und jedes Konto verweist in msDS-AssignedAuthNPolicySilo auf sein Silo. Beides ist erforderlich.

Wenn sich ein Silomitglied authentifiziert, fügt der KDC dem TGT einen Silo-Claim hinzu. Eine Richtlinienbedingung kann dann festlegen: „Das Gerät, das dieses TGT anfordert, muss Mitglied des Silos Tier0 sein.“ Da die Geräteidentität aus dem eigenen TGT des Computers stammt, das für das FAST-Armoring verwendet wird, hängt die Funktion durchgängig von Armoring- und Claims-Unterstützung ab.

Jede Richtlinie und jedes Silo hat ein Enforce-Flag. Ohne dieses wertet der KDC die Regeln aus und protokolliert, was fehlgeschlagen wäre, lässt die Anfrage aber zu. Dieser Überwachungsmodus ist der Kern eines sicheren Rollouts.

Voraussetzungen

• Domänenfunktionsebene Windows Server 2012 R2 oder höher, und auf jedem DC läuft Windows Server 2012 R2 oder neuer.
• KDC-Unterstützung für Claims und Armoring auf allen DCs: Computer Configuration > Policies > Administrative Templates > System > KDC > KDC support for claims, compound authentication and Kerberos armoring auf Enabled mit Supported. Springen Sie für dieses Projekt nicht auf Always provide claims oder Fail unarmored authentication requests.
• Clientunterstützung auf jedem Gerät im Silo: Computer Configuration > Policies > Administrative Templates > System > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring auf Enabled. Windows 8 / Server 2012 und neuer unterstützen das.
• Die Mitgliedschaft in Protected Users für dieselben Tier-0-Konten wird dringend empfohlen. Sie erzwingt AES, blockiert NTLM und Delegierung und setzt ein Standard-TGT von 240 Minuten, was das Silo ergänzt. Siehe Protected Users.
• Eine vollständige Inventur der Tier-0-Konten und -Geräte, einschließlich PAWs und Tier-0-Jump-Servern.

# Funktionsebene und Betriebssysteme der DCs prüfen
(Get-ADDomain).DomainMode
Get-ADDomainController -Filter * | Select-Object HostName, OperatingSystem

Designentscheidungen

Klären Sie drei Fragen, bevor Sie etwas anlegen.

Umfang des Silos. Beginnen Sie mit einem Silo für menschliche Tier-0-Administratoren und die von ihnen genutzten Geräte. Widerstehen Sie der Versuchung, in der ersten Iteration Dienstkonten, Entra-Connect-Synchronisierungskonten oder Backupkonten aufzunehmen. Deren Authentifizierungsmuster sind schwerer vorherzusagen, und ein Fehler dort ist ein Ausfall statt eines verärgerten Admins. Ein zweites Silo für Tier-0-Dienstkonten kann folgen, sobald das erste einige Monate stabil läuft.

TGT-Lebensdauer. Ein kürzeres TGT begrenzt, wie lange ein gestohlenes Ticket wiederverwendet werden kann. Vier Stunden (240 Minuten) entsprechen dem Protected-Users-Standard und passen zu einer Admin-Arbeitssitzung. Kürzere Werte erzeugen vor allem erneute Anmeldeaufforderungen ohne nennenswerten Gewinn; längere machen einen Teil des Nutzens zunichte. Ist ein Konto sowohl in Protected Users als auch einer Richtlinie zugeordnet, gilt die Lebensdauer der Richtlinie.

Welche Richtung eingeschränkt wird. Allowed to authenticate from in der Benutzerrichtlinie ist die Tiering-Kontrolle: Sie hält Tier-0-Anmeldeinformationen von Geräten niedrigerer Tiers fern. Allowed to authenticate to in einer Computer- oder Dienstrichtlinie ist die Umkehrung: Sie schränkt ein, welche Konten Diensttickets für Tier-0-Server erhalten. Diese zweite Kontrolle ist wirkungsvoll für dedizierte Tier-0-Systeme wie einen PAM-Tresor oder den Verwaltungshost einer Offline-CA, würde auf DCs aber jeden Benutzer der Domäne blockieren – wenden Sie sie dort also nicht an.

Das Tier-0-Silo im Überwachungsmodus aufbauen

Das Muster: ein Silo, eine Benutzerrichtlinie, die einschränkt, von wo sich Tier-0-Benutzer authentifizieren dürfen, und eine Computerrichtlinie für die Tier-0-Geräte selbst (meist nur Lebensdauer, keine einschränkenden Bedingungen).

$siloName = 'Tier0-Silo'

# Bedingung: Das Gerät, das das TGT anfordert, muss Mitglied des Silos Tier0 sein
$fromSilo = "O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == `"$siloName`"))"

# Benutzerrichtlinie: 4-Stunden-TGT, nur von Silogeräten. Noch kein -Enforce: Überwachungsmodus.
New-ADAuthenticationPolicy -Name 'Tier0-Users' `
    -Description 'Tier 0 admins: TGT only from Tier 0 devices' `
    -UserTGTLifetimeMins 240 `
    -UserAllowedToAuthenticateFrom $fromSilo `
    -ProtectedFromAccidentalDeletion $true

# Computerrichtlinie für PAWs und Tier-0-Server: keine Bedingungen, Standardlebensdauer
New-ADAuthenticationPolicy -Name 'Tier0-Computers' `
    -Description 'Tier 0 devices' -ProtectedFromAccidentalDeletion $true

# Silo im Überwachungsmodus
New-ADAuthenticationPolicySilo -Name $siloName `
    -UserAuthenticationPolicy 'Tier0-Users' `
    -ComputerAuthenticationPolicy 'Tier0-Computers' `
    -ServiceAuthenticationPolicy 'Tier0-Computers' `
    -ProtectedFromAccidentalDeletion $true

@USER in einer allowed to authenticate from-Bedingung bezieht sich auf das Gerätekonto, das die Anfrage panzert, nicht auf den Admin. Das ist beabsichtigt und die häufigste Quelle von Verwirrung beim Lesen dieser Richtlinien.

Mitglieder zuweisen

Fügen Sie Tier-0-Benutzer, PAWs, Tier-0-Jump-Server und – falls Admins sich an DC-Konsolen anmelden – die DCs selbst hinzu. Jedes Mitglied benötigt beide Schritte:

$members = @(
    Get-ADGroupMember 'Tier0-Accounts' | ForEach-Object { Get-ADUser $_ }
    Get-ADGroupMember 'Tier0-Devices'  | ForEach-Object { Get-ADComputer $_ }
)

foreach ($m in $members) {
    # Konto im Silo zulassen (msDS-AuthNPolicySiloMembers)
    Grant-ADAuthenticationPolicySiloAccess -Identity $siloName -Account $m
    # Konto auf das Silo verweisen lassen (msDS-AssignedAuthNPolicySilo)
    Set-ADAccountAuthenticationPolicySilo -Identity $m -AuthenticationPolicySilo $siloName
}

Nehmen Sie in der ersten Phase keine Dienstkonten, gMSAs oder Break-Glass-Konten in dieses Silo auf. Break-Glass-Konten sollten außerhalb des Silos bleiben, streng überwacht, mit ihrem Kennwort in einem physischen Tresor.

Überwachungsdaten sammeln

Silo-Entscheidungen werden auf DCs in dedizierten Betriebsprotokollen erfasst, die standardmäßig deaktiviert sind:

# Auf jedem DC ausführen
wevtutil sl "Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController" /e:true
wevtutil sl "Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController" /e:true

In AuthenticationPolicyFailures-DomainController sind die Ereignisse des Überwachungsmodus 305 (ein TGT wäre von der Richtlinie abgelehnt worden) und 306 (ein Dienstticket wäre abgelehnt worden). Ihre Gegenstücke im Erzwingungsmodus sind 105 und 106, und 101 protokolliert eine durch eine Richtlinie blockierte NTLM-Authentifizierung. Lassen Sie den Überwachungsmodus mindestens einen vollständigen Admin-Zyklus laufen, einschließlich Monatsabschluss, Patchnächten und Bereitschaftsrotationen.

Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{
        LogName = 'Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController'
        Id      = 305, 306
    } -ErrorAction SilentlyContinue
} | Select-Object MachineName, TimeCreated, Id, Message

Jeder Treffer ist entweder ein Admin, der sich von einem Nicht-Tier-0-Gerät authentifiziert (ein zu behebendes Prozessproblem), oder ein Tier-0-Gerät, das im Silo fehlt (ein zu behebendes Mitgliedschaftsproblem).

Erzwingen

Sobald das Überwachungsprotokoll ruhig ist, erzwingen Sie zuerst die Richtlinie, dann das Silo:

Set-ADAuthenticationPolicy -Identity 'Tier0-Users' -Enforce $true
Set-ADAuthenticationPolicySilo -Identity 'Tier0-Silo' -Enforce $true

Erzwingen Sie an einem Dienstagmorgen mit einem Admin an einer DC-Konsole, nicht an einem Freitagabend. Falls etwas schiefgeht, wirkt -Enforce $false auf dem Silo, sobald es repliziert ist.

Eine Richtlinie mit allowed to authenticate from-Bedingungen blockiert für ihre Benutzer auch NTLM-Netzwerkanmeldungen, sofern Sie diese nicht explizit über die Richtlinieneinstellung UserAllowedNTLMNetworkAuthentication erlauben. Lassen Sie das für Tier 0 deaktiviert.

Das Silo selbst überwachen

Einmal erzwungen, ist das Silo eine Tier-0-Kontrolle, und Manipulationen daran sind ein Angriffssignal. Mit aktivierter Audit Directory Service Changes auf den DCs erzeugen Änderungen an msDS-AssignedAuthNPolicySilo auf Konten sowie an den Richtlinien- und Siloobjekten in der Konfigurationspartition das Ereignis 5136. Alarmieren Sie bei jeder solchen Änderung außerhalb eines Änderungsfensters sowie bei jedem Ereignis 105 oder 106 im Erzwingungsmodus für ein Tier-0-Konto – das bedeutet entweder einen Fehler oder jemanden, der eine Tier-0-Anmeldeinformation vom falschen Ort aus nutzen will.

Überprüfen

# Silokonfiguration und Erzwingungsstatus
Get-ADAuthenticationPolicySilo -Identity 'Tier0-Silo' -Properties * |
    Select-Object Name, Enforce, UserAuthenticationPolicy, ComputerAuthenticationPolicy, msDS-AuthNPolicySiloMembers

# Jedes Tier-0-Konto ist dem Silo zugewiesen
Get-ADGroupMember 'Tier0-Accounts' | Get-ADUser -Properties msDS-AssignedAuthNPolicySilo |
    Where-Object { -not $_.'msDS-AssignedAuthNPolicySilo' } | Select-Object SamAccountName
# Sollte nichts zurückgeben

Testen Sie anschließend funktional. Melden Sie sich auf einer PAW mit einem Tier-0-Konto an und führen Sie klist aus: Die Endzeit des TGT sollte die Lebensdauer von 240 Minuten widerspiegeln. Versuchen Sie von einem Standardarbeitsplatz ein runas /user: mit demselben Konto: Es muss fehlschlagen, und der DC sollte Ereignis 105 zusammen mit einem 4768-Fehler mit Ergebniscode 0xC (KDC_ERR_POLICY) protokollieren. Dokumentieren Sie beide Tests als Nachweis für Audits.

Was dabei bricht

• Admins an Nicht-Tier-0-Geräten: Jede Tier-0-Anmeldung von einem Laptop, einem Tier-1-Server oder einem Helpdesk-Arbeitsplatz schlägt fehl. Das ist das Ziel, bringt aber am ersten Tag jede undokumentierte Gewohnheit ans Licht.
• Geplante Aufgaben und Dienste, die als Silomitglieder laufen, schlagen fehl, wenn sie auf einem Gerät außerhalb des Silos laufen. Verlagern Sie sie auf gMSAs außerhalb von Tier 0 oder nehmen Sie den Host bewusst in Tier 0 auf.
• Nicht-Windows- und Legacy-Clients ohne Armoring-Unterstützung (ältere Linux-Systeme, macOS-Werkzeuge, Netzwerkgeräte, die AD-Anmeldeinformationen eines Admins nutzen) können sich nicht als Silomitglieder authentifizieren.
• Gesamtstrukturübergreifende Administration: Geräte-Claims werden standardmäßig nicht über Vertrauensstellungen übertragen. Tier-0-Admins einer Gesamtstruktur lassen sich daher ohne zusätzliche Claim-Transformation nicht per Silo auf Geräte einer anderen Gesamtstruktur beschränken.
• DC-Wiederherstellung: Bei einer Gesamtstrukturwiederherstellung, in der DCs neu aufgebaut werden, gilt das Silo weiterhin. Halten Sie ein dokumentiertes Break-Glass-Konto außerhalb des Silos bereit, wie im Plan zur Gesamtstrukturwiederherstellung beschrieben.

Weiterführende Lektüre: Kerberos & Authentifizierung für die Armoring- und Verschlüsselungsschicht unter den Silos, Privileged Access Workstations für die Geräte, die Sie ins Silo aufnehmen, und der Überblick zum Bereich Tier 0.