Kerberos Lockscreen

Auf der Seite Kerberos Wireshark habe ich einige Mitschnitte von Kerberos auf dem Kabel beschrieben. In dem Zuge ist mir ein Verhalten mit dem Windows Client aufgefallen, welche ich hier beschreibe.

Unlock = neue Tickets

Bei der Analyse von Kerberos Tickets auf dem Client mittels KLIST ist mit ein komisches Verhalten aufgefallen. Wenn ich mich neu anmelde, bekomme natürlich ein neues TGT und auch ein Ticket für den Client, auf dem ich gerade arbeite. Aber nachdem ich die Sitzung gesperrt und wieder entsperrt habe, waren komplett andere Tickets vorhanden und einige Tickets verschwunden.

Vor dem Sperren Nach dem Sperren 
C:\>klist

Current LogonId is 0:0x18b5d218

Cached Tickets: (4)

#0>     Client: Administrator @ CARIUS.DE
        Server: krbtgt/CARIUS.DE @ CARIUS.DE
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x60a10000
        Start Time: 2/23/2023 11:05:07 (local)
        End Time:   2/23/2023 21:04:42 (local)
        Renew Time: 3/2/2023 11:04:42 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x2 -> DELEGATION
        Kdc Called: DC01.carius.de

#1>     Client: Administrator @ CARIUS.DE
        Server: krbtgt/CARIUS.DE @ CARIUS.DE
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000
        Start Time: 2/23/2023 11:04:42 (local)
        End Time:   2/23/2023 21:04:42 (local)
        Renew Time: 3/2/2023 11:04:42 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: DC01.carius.de

#2>     Client: Administrator @ CARIUS.DE
        Server: cifs/dc01 @ CARIUS.DE
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a50000
        Start Time: 2/23/2023 11:05:07 (local)
        End Time:   2/23/2023 21:04:42 (local)
        Renew Time: 3/2/2023 11:04:42 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: DC01.carius.de

#3>     Client: Administrator @ CARIUS.DE
        Server: LDAP/DC01.carius.de/carius.de @ CARIUS.DE
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a50000
        Start Time: 2/23/2023 11:04:42 (local)
        End Time:   2/23/2023 21:04:42 (local)
        Renew Time: 3/2/2023 11:04:42 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: DC01.carius.de
 
C:\>klist tickets

Current LogonId is 0:0x18b5d218

Cached Tickets: (2)

#0>     Client: Administrator @ CARIUS.DE
        Server: krbtgt/CARIUS.DE @ CARIUS.DE
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000
        Start Time: 2/23/2023 12:24:56 (local)
        End Time:   2/23/2023 22:24:56 (local)
        Renew Time: 3/2/2023 12:24:56 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: DC01

#1>     Client: Administrator @ CARIUS.DE
        Server: host/hyperv.carius.de @ CARIUS.DE
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000
        Start Time: 2/23/2023 12:24:56 (local)
        End Time:   2/23/2023 22:24:56 (local)
        Renew Time: 3/2/2023 12:24:56 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: DC01.carius.de

Das hat mein Interesse geweckt.

Wireshark

Da ich zur gleichen Zeit an der Seite Kerberos Wireshark gearbeitet habe, habe ich auch hier nachgeschaut und konnte die Neuausstellung der Tickets bestätigen. Sie sehen auch auf dem KDC mit Wireshark passend dazu die neuen Request für ein TGT und ein Service Ticket:

Da stellt sich natürlich die Frage, was ein Skript macht, welches im Hintergrund bei einem gesperrten PC arbeitet.

Prüfung

Der einfachste Weg ist die Ausgabe per KLIST mit einem kleinen PowerShell Skript, welches de Kerberos Ticketcache zu den verschiedenen Zeitpunkten ausgibt.

Start-Transcript .\kerbtest.log
Write-Host "KerbTest - KLIST1 vor dem Sperren"
KLIST >> .\klist1-vorsperre.txt
Write-Host "KerbTest - Bitte PC jetzt sperren" -nonewline
$logonuicount = (Get-Process -Name logonui | ?{!$_.hasexited}).count
while ((Get-Process -Name logonui | ?{!$_.hasexited}).count -eq $logonuicount ) {
   start-sleep -seconds 1
   write-host "." -nonewline
}
Write-host "Locked"
Write-Host "KerbTest - KLIST2 nach dem Sperren"
KLIST >> .\klist2-gesperrt.txt
start-sleep -seconds 5
Write-Host "KerbTest - SMB-Zugriff"
get-item \\dc01\netlogon | out-null
Write-Host "KerbTest - KLIST3 nach SMB Zugriff"
KLIST >> .\klist3-gesperrtSMB.txt
Write-Host "KerbTest - Warte auf Entsperren"
while ((Get-Process -Name logonui | ?{!$_.hasexited}).count -ne $logonuicount ) {
   start-sleep -seconds 1
   write-host "." -nonewline
}
Write-Host "KerbTest - KLIST4 nach dem Entsperren"
KLIST >> .\klist4.entsperrt.txt
Write-Host "KerbTest - Ende"
Stop-Transcript

Schon an der Dateigröße können Sie sehen, dass sich hier im gesperrten Zustand etwas geändert hat.

Analyse

Aber erst ein Blick in die Dateien liefert Details.

Tickets Property Vor Sperrung Gesperrt Nach SMB Zugriff Nach Entsperrung

#0

 Server
StartDate
Ticket Flags
Cache Flags		 KRBTGT
2/23/2023 13:07:59
0x40e10000
0x1 -> PRIMARY		 KRBTGT
 2/23/2023 13:07:59
0x40e10000
0x1 -> PRIMARY		 KRBTGT
2/23/2023 13:08:58
0x60a10000
0x2 -> DELEGATION		 KRBTGT
2/23/2023 13:09:55
0x40e10000
0x1 -> PRIMARY

#1

 Server
StartDate
Ticket Flags
Cache Flags		 CLIENT
2/23/2023 13:07:59
0x40e10000		 CLIENT
2/23/2023 13:07:59
0x40e10000		 KRBTGT
2/23/2023 13:07:59
0x40e10000
0x1 -> PRIMARY		 CLIENT
2/23/2023 13:09:55
0x40e10000

#2

 Server
StartDate
Ticket Flags
Cache Flags

<na>

<na>

 CIFS
2/23/2023 13:08:58
0x40e10000
0

<na>

#3

 Server
StartDate
Ticket Flags
Cache Flags

<na>

<na>

 CLIENT
2/23/2023 13:07:59
0x40e10000
0

<na>

Es gibt hier drei Übergänge:

  • Angemeldet -> Gesperrt
    Die Daten zeigen, dass beim Wechsel von Standard auf "gesperrt" erst einmal nichts passiert. Es werden keine Tickets verworfen oder gelöscht
  • Aktivität bei Gesperrt
    Wenn nun ein Programm im gesperrten Zustand auf einen Netzwerkdienst zugreift, dann fordert es nicht nur ein Serviceticket für das Ziel an, sondern auch noch ein neue TGT mit dem Flag "Delegation". Die bestehenden Tickets bleiben aber beide erhalten
  • Gesperrt -> Entsperrt
    Wenn der PC wieder entsperrt wird, dann werden alle bisherigen Tickets verworfen und neue TGT und Client-Tickets ausstellen.

Ein Client kann also auch im gesperrten Zustand weiter mit Kerberos arbeiten, aber nutzt ein eigenes TGT dafür. Allerdings wirkt sich eine Neuausstellung eines TGT nicht auf die dem Client bekannten Gruppenmitgliedschaften des Anwender aus.

Sonderfall: Keine Connection

Dann wollte ich wissen wann der Client das TGT genau wegwirft. Ich habe mich dazu auf einem Client angemeldet und die Tickets mit KLIST ausgegeben. Danach habe ich auf dem DC per Windows Firewall die Kommunikation dieses Clients mit dem KDC unterbunden und den Client gesperrt und wieder entsperrt. Das Ergebnis weicht nun vom ersten Test ab:

Vor dem Sperren Nach dem Sperren 
C:\>klist

PS C:\Temp> klist

Current LogonId is 0:0x18b5d218

Cached Tickets: (2)

#0>     Client: Administrator @ CARIUS.DE
        Server: krbtgt/CARIUS.DE @ CARIUS.DE
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 2/23/2023 14:07:04 (local)
        End Time:   2/24/2023 0:07:04 (local)
        Renew Time: 3/2/2023 14:07:04 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: DC01

#1>     Client: Administrator @ CARIUS.DE
        Server: host/hyperv.carius.de @ CARIUS.DE
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 2/23/2023 14:07:04 (local)
        End Time:   2/24/2023 0:07:04 (local)
        Renew Time: 3/2/2023 14:07:04 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: DC01.carius.de
 
PS C:\> klist

Current LogonId is 0:0x18b5d218

Cached Tickets: (1)

#0>     Client: Administrator @ CARIUS.DE
        Server: krbtgt/CARIUS.DE @ CARIUS.DE
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000
        Start Time: 2/23/2023 14:07:04 (local)
        End Time:   2/24/2023 0:07:04 (local)
        Renew Time: 3/2/2023 14:07:04 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: DC01
 

Mein Host-Ticket wird weg geworfen aber nicht mein TGT. Anscheinend löscht Windows beim Entsperren das alte TGT erst, wenn es ein neues TGT erhalten hat.

Disabled User

Wenn ich meinen Desktop sperre und das Konto dann deaktiviert wird, dann kann ich wenige Sekunden später den Desktop nicht mehr entsperren. Der KDC lehnt aktiv die Ausstellung eines neuen TGT ab.

Der Windows Desktop meldet auch, dass mein Konto gesperrt ist.

Wenn ich in dem Zustand nun die Netzwerkverbindung des Clients zum KDC unterbinde, dann kann ich mich nicht anmelden.

Anscheinend hat schon der erste Versuch dafür gesorgt, dass die "SperrInformation" lokal hinterlegt wurde. Ich wollte nun natürlich etwas mehr erfahren und habe wieder mit Sperrung und Entsperrung gearbeitet und ein nicht ganz verständliches Verhalten gesehen.

Aktion

Beschreibung

Reguläre Anmeldung

Der Benutzer war aktiv und hat sich angemeldet und ein TGT mit 10h Gültigkeit bekommen. Soweit nicht ungewöhnlich.

Konto deaktiviert

Ich habe das AD-Konto deaktiviert aber der Benutzer war natürlich noch angemeldet. Er konnte sogar noch auf andere Server zugreifen, d.h. der Anwender konnte mit seinem TGT auch weitere Servicetickets anfordern. Das fand ich erst einmal suspekt. Ich dachte der KDC prüft den Kontostatus noch mal ab

Client sperren

Dann habe ich den Client gesperrt und das Check-Skript lief im Hintergrund weiter. Auch hier konnte der Client sogar ein neues TGT bekommen und per Kerberos auf den Server zugreifen.

Der Trace zeigt aber, dass es schon Fehlermeldungen von, die aber nicht verhindern, dass auf Paket 188 der KDC eine Antwort gibt.

Client entsperren

Ich konnte sogar den Desktop entsperren, wohl das AD Konto gesperrt war

Erneut Sperren und  entsperren

Erst nach der zweiten Sperrung hat mein Client gesagt, dass das Konto gesperrt sei

Anscheinend ist der KDC nicht in Echtzeit mit dem AD verbunden, denn wenn ich ein Konto per MMS sperre, dann kann ich einige Sekunden noch weiterhin Tickets erhalten. Anscheinend akzeptiert der KDC einen Ticket-Request mit einem gültigen TGT noch einige Zeit, was die Tests durch eine unbekannte Wartezeit aufwändig macht.

Bewertung

Ich bin lange Zeit davon ausgegangen, dass ein Client bei der Anmeldung einmal ein TGT bekommt und dieses durch aus einige Stunden gültig ist. Ein "Sperren" eines ´Clients müsste also gar keine neue Ausstellung erforderlich machen und auch ein Entsperren müsste nichts ändern. Dennoch geht zumindest Windows 2016 den Weg, dass Skripte im gesperrten Zustand ein neues TGT mit dem Typ "Delegation" anfordern und dann ein Serviceticket nutzen. Wenn dies nicht möglich ist, z.B. weil der KDC nicht erreichbar ist, dann werden dennoch alle anderen Tickets verworfen aber das alte TGT beibehalten. Das verzögerte Verhalten bei deaktivierten AD-Konten hat mich dann doch etwas irritiert. Bei Gelegenheit muss ich da noch mal genauer hinschauen.

Weitere Links