Das Adminkonto funktioniert auch am falschen Gerät

Für privilegierte Aufgaben stehen eigene Admin-Arbeitsplätze bereit. Trotzdem lässt sich das Tier-0-Konto noch an einem gewöhnlichen Notebook verwenden. Eine Betriebsanweisung beschreibt den vorgesehenen Weg, setzt ihn aber nicht technisch durch. Selbst die Mitgliedschaft in Protected Users definiert keine Liste erlaubter Herkunftsgeräte.

Hier setzen Authentication Policies an: Der Domain Controller kann bei der Ausstellung eines neuen Kerberos-Ticket-Granting-Tickets prüfen, ob das anfragende Gerät zugelassen ist. Dieser Beitrag behandelt einen begrenzten Pilot für menschliche Tier-0-Adminkonten und dedizierte Privileged Access Workstations, kurz PAWs. Dienstkonten, DC-Computerkonten und eine vollständige Silo-Architektur bleiben außerhalb dieses Changes.

Herkunft, Ziel und Anmeldeart getrennt festlegen

Das Zielbild ist konkret: Ein benanntes Pilotkonto erhält ein neues Kerberos-TGT nur über freigegebene Admin-Geräte. Die erlaubten Computer stehen in einer eng verwalteten AD-Sicherheitsgruppe, beispielsweise T0-Approved-PAWs. Gewöhnliche Clients und allgemeine Administrationsserver gehören nicht hinein.

Die Einstellung UserAllowedToAuthenticateFrom bewertet das Herkunftsgerät. Sie ist keine Liste erlaubter Zielserver und erteilt keine lokalen oder RDP-Anmelderechte. Zielzugriffe, Benutzerrechte, Firewallregeln und Trennung der Administrationsebenen müssen weiterhin passen. Ein TGT von einer erlaubten PAW darf nicht als Freigabe für beliebige Zielsysteme verstanden werden.

Protected Users ergänzt dieses Modell mit eigenen Authentifizierungsbeschränkungen. Die Mitgliedschaft und die Gerätebindung sind getrennte Kontrollen. Führen Sie beide nicht gleichzeitig neu ein: Sonst bleibt bei einem Fehler unklar, welche Änderung den Arbeitsablauf unterbricht.

Voraussetzungen vor dem Pilot nachweisen

Die Kontodomäne benötigt mindestens die Domänenfunktionsebene Windows Server 2012 R2. Das ist eine Funktionsvoraussetzung, keine Empfehlung für alte Betriebssysteme. Verwenden Sie unterstützte, gepflegte Systeme und prüfen Sie AD-Replikation, DNS, Zeitsynchronisation und Erreichbarkeit der zuständigen DCs.

Für die Geräteprüfung muss Kerberos Armoring samt der benötigten Dynamic-Access-Control-Unterstützung funktionieren:

  • Auf allen relevanten DCs: unter Computer Configuration > Policies > Administrative Templates > System > KDC die Richtlinie KDC support for claims, compound authentication and Kerberos armoring aktivieren. Für diesen Pilot genügt die unterstützende Einstellung Supported; bestehende, bewusst konfigurierte Einstellungen zuerst bewerten.
  • Auf PAWs und den kontrollierten Testgeräten: unter System > Kerberos die Richtlinie Kerberos client support for claims, compound authentication and Kerberos armoring aktivieren.
  • Die tatsächlich wirksamen GPOs prüfen. Eine konfigurierte GPMC-Ansicht allein beweist weder Verarbeitung noch einen funktionierenden Authentifizierungspfad.

Fail unarmored authentication requests ist eine weiterreichende Domänenentscheidung und für diesen begrenzten Pilot nicht erforderlich. Aktivieren Sie sie nicht beiläufig. Ebenso gehört eine notwendige Anhebung der Funktionsebene in einen eigenen vorbereiteten Change.

Inventarisieren Sie die wirklichen Adminwege: lokale PAW-Anmeldung, RSAT, PowerShell Remoting, RDP, Managementportale und Zwischenstationen. Bei Remote-Anmeldungen kann ein anderer Rechner den neuen TGT anfordern als der zunächst sichtbare Arbeitsplatz. Der RDP-Clientname allein beschreibt den Kerberos-Herkunftspfad nicht zuverlässig.

Eine kleine Gerätefreigabe vorbereiten

Beginnen Sie mit einem eigens angelegten Testkonto ohne produktive Privilegien, zwei freigegebenen PAWs und einem separaten verwalteten Negativtestgerät. Dieses Gerät erhält die technische Kerberos-Unterstützung, aber keine Mitgliedschaft in der Freigabegruppe. So wird eine fehlende Geräteberechtigung getestet, nicht bloß ein inkompatibler Client.

In die Gruppe kommen Computerobjekte der geprüften PAWs. Halten Sie den Pilot ohne Gruppenverschachtelung übersichtlich. Dokumentieren Sie außerdem, wer die Gruppe, ihre ACLs und die enthaltenen Computerobjekte verändern darf. Wer ein gewöhnliches Gerät in die Freigabe aufnehmen kann, beeinflusst die Schutzgrenze.

Prüfen Sie vor Änderungen, ob bereits eine direkte Authentication Policy oder ein Authentication Policy Silo am Konto hinterlegt ist. Überschreiben Sie eine bestehende Zuordnung nicht stillschweigend.

Das folgende Beispiel liest nur Konfiguration und Gruppenmitglieder. Ersetzen Sie Namen und DC durch den freigegebenen Pilotbereich; die Abfragen gehören auf eine vertrauenswürdige Adminstation mit dem Modul ActiveDirectory.

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
Import-Module ActiveDirectory

$dc = 'dc01.example.com'
$pilotUser = 't0-paw-pilot'
$pawGroup = 'T0-Approved-PAWs'

Get-ADDomain -Server $dc |
    Select-Object DNSRoot, DomainMode

Get-ADUser -Identity $pilotUser -Server $dc -Properties `
    'msDS-AssignedAuthNPolicy', 'msDS-AssignedAuthNPolicySilo' |
    Select-Object SamAccountName,
        'msDS-AssignedAuthNPolicy', 'msDS-AssignedAuthNPolicySilo'

Get-ADGroupMember -Identity $pawGroup -Server $dc |
    Select-Object Name, ObjectClass, DistinguishedName

Die Ausgabe bestätigt weder effektive Gruppenrechte noch Kerberos Armoring. Sie liefert eine überprüfbare Ausgangsliste. Änderungen an Computermitgliedschaften müssen repliziert und im Anmeldekontext des Computers angekommen sein; planen Sie dafür einen kontrollierten Neustart der Testgeräte.

Die Richtlinie ausdrücklich im Auditmodus anlegen

Öffnen Sie im Active Directory Administrative Center die Kontodomäne und unter Authentication > Authentication Policies eine neue Richtlinie, beispielsweise T0-PAW-Pilot. Wählen Sie ausdrücklich Only audit policy restrictions. Der ADAC-Dialog kann eine neue Richtlinie standardmäßig auf Durchsetzung stellen; verlassen Sie sich nicht auf einen vermuteten Standardwert. Audit schreibt echte AD-Konfiguration, blockiert aufgrund dieser Richtlinie aber noch nicht.

Bearbeiten Sie im Benutzerbereich die Bedingungen für die Geräte, von denen eine Anmeldung erfolgen darf. Wählen Sie im Bedingungseditor die Gruppenbedingung Member of any und die vorbereitete Gruppe T0-Approved-PAWs. Gemeint ist die Gruppenmitgliedschaft des Herkunftscomputers. Die Bezeichnung User im Editor darf nicht dazu verleiten, hier stattdessen eine Gruppe der Administratoren zu prüfen.

Lassen Sie die grafische Oberfläche den Sicherheitsdeskriptor erzeugen und prüfen Sie anschließend die dargestellte Bedingung. Kopieren Sie keine fremde SDDL-Zeichenfolge mit unbekannten SIDs. Zusätzliche Zielbeschränkungen und Änderungen der TGT-Laufzeit bleiben im ersten Schritt unkonfiguriert.

Ordnen Sie die Richtlinie anschließend im Abschnitt Policy ausdrücklich dem Testbenutzer zu. Nur das Anlegen der Richtlinie oder die Aufnahme der PAW in eine Gruppe aktiviert noch keine Prüfung für das Benutzerkonto. Kontrollieren Sie nach Replikation die Zuordnung auf den DCs, die den Pilot bedienen.

Authentication Policy Silos können später mehrere Konten und passende Richtlinien zusammenfassen. Für diesen kleinen Pilot genügt die direkte Zuordnung. Ein späterer Silo-Rollout muss Zugriffsfreigabe, tatsächliche Kontozuordnung und Durchsetzungszustand gesondert prüfen; eine bloße Silo-Mitgliederliste ist kein Wirksamkeitsnachweis.

Audit mit einem absichtlichen Negativtest beweisen

Aktivieren beziehungsweise prüfen Sie auf den zuständigen DCs den Kanal Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController und seine zentrale Weiterleitung. Führen Sie die Tests mit neuen Anmeldesitzungen und nachvollziehbaren Zeitpunkten durch.

  1. Erlaubte PAW: Das Testkonto erhält ein neues TGT. Prüfen Sie die Ausstellung und den tatsächlich angesprochenen DC.
  2. Nicht freigegebenes Testgerät: Die Anmeldung darf im Auditmodus noch funktionieren. Erwartet wird Ereignis 305 für die verletzte Herkunftsbedingung.
  3. Auswertung: Konto, Gerät und Richtlinie im Ereignis müssen zum Test passen. Die Meldung muss auch im zentralen Monitoring ankommen.

Ein leeres Protokoll ist kein Abnahmenachweis. Es kann ebenso für fehlende Zuordnung, nicht erfasste DCs oder einen ungeeigneten Testpfad stehen. Unterscheiden Sie außerdem 305 für die Herkunftsprüfung von 306 für Einschränkungen bei Service-Tickets; Letzteres ist nicht die hier konfigurierte Kontrolle.

Nach diesem Funktionsnachweis folgt ein einzelnes ausgewähltes produktives Adminkonto auf ausschließlich vertrauenswürdigen Geräten. Prüfen Sie über einen repräsentativen Betriebszeitraum auch Wartung, Schichtwechsel und Wiederanmeldung. Produktive Tier-0-Zugangsdaten gehören für einen Negativtest niemals auf einen gewöhnlichen Arbeitsplatz.

Durchsetzen, abnehmen und gezielt zurückrollen

Schalten Sie erst nach geklärten Auditbefunden und getestetem Notfallzugang die Pilotrichtlinie auf Durchsetzung. Wiederholen Sie die Positiv- und Negativtests mit dem nicht privilegierten Testkonto: Neue TGT-Ausstellung von einer erlaubten PAW funktioniert; der kontrollierte Versuch vom nicht freigegebenen Gerät wird abgewiesen und erzeugt 105. Prüfen Sie danach die tatsächlichen administrativen Aufgaben mit dem produktiven Adminkonto ausschließlich auf freigegebenen PAWs, nicht nur den Windows-Anmeldebildschirm.

Bereits ausgestellte Tickets und bestehende Sitzungen werden durch den Schalter nicht automatisch widerrufen. Testen Sie mit frischen Sitzungen. Wenn ein vorgesehenes Gerät ausfällt, muss eine zweite freigegebene PAW oder ein separat geschützter Notfallweg erreichbar sein.

Der eingebaute Domänenadministrator mit RID 500 ist von Authentication Policies ausgenommen, auch bei einer Silo-Zuordnung. Er ist deshalb kein geeigneter Negativtest. Diese Ausnahme ersetzt keinen getesteten Notfallzugang: Kontozustand, Anmelderechte und weitere Kontrollen wirken weiterhin.

Der vorbereitete Rollback setzt gezielt die Pilotrichtlinie auf Audit zurück oder stellt die dokumentierte vorherige Kontozuordnung wieder her. Warten Sie die Replikation ab und prüfen Sie einen neuen Anmeldeversuch. Löschen Sie nicht vorschnell die Richtlinie und nehmen Sie nicht pauschal weitere Geräte in die Freigabe auf. Beides erschwert Ursachenanalyse und sauberen Wiederanlauf.

Vorteile der Gerätebindung

  • Die erlaubte Herkunft wird am DC geprüft und hängt nicht allein von einer lokalen Anmelderichtlinie ab.
  • Eine kleine Gerätefreigabe macht privilegierte Arbeitswege überprüfbar.
  • Audit und gezielte Negativtests erlauben eine Einführung mit nachvollziehbaren Abnahmekriterien.
  • Die zusätzliche Kontrolle ergänzt Protected Users, PAW-Härtung und Anmelderechte, ohne produktive Berechtigungen pauschal zu erweitern.

Nachteile und technische Grenzen

  • Die Verfügbarkeit gepflegter PAWs und funktionierender DC-Verbindungen wird für die Administration wichtiger. Ersatzgeräte benötigen einen vorbereiteten Aufnahmeprozess.
  • Der Herkunftstest ist kein Integritätsnachweis für die PAW. Ein kompromittiertes freigegebenes Gerät bleibt ein erhebliches Risiko.
  • NTLM kann die Kerberos-Gerätebedingung nicht erfüllen und unter Durchsetzung scheitern; Ereignis 101 ist dafür relevant. Ein sauberer 305-Audit ersetzt keine separate Prüfung von NTLM-Abhängigkeiten.
  • LDAP Simple Bind, Offline-Anmeldung und bereits vorhandene Tickets werden durch diesen Audit nicht vollständig abgebildet. Behandeln Sie diese Pfade ausdrücklich separat; leiten Sie aus Gerätebindung keinen universellen Schutz jeder Kennwortnutzung ab.
  • Die Kontrolle ersetzt weder MFA noch Zielautorisierung, EDR oder die Absicherung von Richtlinien- und Gruppenadministratoren.

Typische Fehler vor der nächsten Welle beseitigen

Häufig stehen Benutzer statt Computer in der Freigabe, die Richtlinie bleibt ohne Kontozuordnung oder ein alter Computer-Anmeldekontext verdeckt eine Gruppenänderung. Ebenso problematisch sind nicht erfasste DCs und Tests mit bestehenden TGTs.

Ein anderer Fehler ist, bei jedem RDP- oder Toolproblem sofort den beteiligten Server freizugeben. Klären Sie zuerst, welches System tatsächlich authentifiziert und ob dieser Arbeitsweg zum Tier-0-Modell gehört. Eine wachsende Freigabeliste kann sonst genau die Trennung aufheben, die eingeführt werden sollte.

Projekt-Checkliste

  • [ ] Pilotkonten, PAWs, Testgerät und fachlichen Eigentümer benennen.
  • [ ] Funktionsebene, Replikation und Kerberos-Unterstützung nachweisen.
  • [ ] Bestehende Policy- und Silo-Zuordnungen erfassen.
  • [ ] Computergruppe und ihre Änderungsrechte prüfen.
  • [ ] Richtlinie ausdrücklich auf Audit setzen und gezielt zuordnen.
  • [ ] Ereignis 305 mit einem ungefährlichen Negativtest bis ins Monitoring nachweisen.
  • [ ] Reale Adminwege und separate NTLM-/LDAP-Abhängigkeiten prüfen.
  • [ ] Ersatz-PAW, Notfallzugang und Rollback vor Durchsetzung testen.
  • [ ] Neue TGT-Ausstellung positiv und negativ unter Durchsetzung abnehmen.
  • [ ] Aufnahme, Austausch und Entfernung von Geräten regelmäßig kontrollieren.