Kerberos: Probleme nach Schema-Update auf Server 2012 R2

Nach einem Schema-Update von Windows 2008 R2 auf Windows 2012 R2 gab es ein Problem mit einer älteren Anwendung unter Windows 7. Der Domain Functional Level wurde nicht verändert.

Die Anwendung prüfte scheinbar beim Starten mit Hilfe von Kerberos, ob der Benutzer bestimmte Gruppenmitgliedschaften hat. Was die Anwendung genau macht, war uns leider nicht bekannt, da wir nicht in den Quellcode sehen konnten.

Neue Well-Known SIDs durch Schema-Update

Normalerweise gibt es so gut wie nie Probleme mit einem Schema-Update. Aber in diesem Fall war das Problem reproduzierbar. Es stellte sich heraus, dass bei dem Schema-Update einige neue Well-Known SIDs hinzukamen.

Hinzu kamen unter anderem die SIDs

• S-1-18-1
• S-1-18-2

Die SIDs werden in das Token geschrieben, um zu unterscheiden, ob der Client sich über eine zentrale Authentifizierungsstelle mit Client-Credentials (S-1-18-1) oder über einen Service (S-1-18-2) angemeldet hat.
Mehr zu Well-Known SIDs gibt es hier: Microsoft MSDN – Well-Known SIDs
 

Problem bei 2008 R2 und 2012 R2 Domain Controllern

Die SIDs werden wohl nur ausgestellt, wenn sich der Client gegen einen 2012 R2 Domain Controller authentifiziert. Aus diesem Grund tritt das Problem bei einer Domäne mit 2008 R2 DCs und 2012 R2 DCs nur manchmal auf.

Das eigentliche Problem ist, dass Windows 7 Clients die SIDs nicht unterstützen.
Bei dem Versuch die SIDs zu verarbeiten tritt folglich ein Fehler auf.
 

Nachvollziehen des Fehlers mit PSGETSID

Man kann das Fehlschlagen relativ einfach mit dem Befehl “psgetsid” in einer Powershell oder cmd nachstellen.
PsGetsid.exe ist Teil der PsTools von Sysinternals und kann bei Microsoft heruntergladen werden:
Webseite: PsTools (Sysinternals)

Dieser Vorgang prüft allerdings NICHT, ob der Client tatsächlich von dem Problem betroffen ist.
 

Client mit GPRESULT prüfen

Ob der Client vom Problem betroffen ist, lässt sich zum Beispiel mit Bordmitteln über ein gpresult /h prüfen:
In der Liste der Gruppenmitgliedschaften taucht bei betroffenen Windows 7 Clients z.B. der Eintrag “S-1-18-1” auf:

Client mit “Get SIDS from Token” prüfen

Ein noch etwas eleganterer Weg wäre das Skript aus meinem letzten Artikel (Kerberos-Token mit PowerShell auslesen). Bei betroffenen Clients dann wird folgendes ausgegeben:

Lösung und Hotfix

Microsoft hat das Problem mittlerweile anerkannt und einen Hotfix veröffentlicht, welcher das Problem behebt:
https://support.microsoft.com/en-us/kb/2830145

Der Hotfix wurde von uns erfolgreich bei dem Kunden verteilt und das Problem nach dem Schema-Update wurde behoben. Um zu testen ob der Hotfix funktioniert kann z.B. wieder ein gpresult /h durchgeführt werden. Der Eintrag “S-1-18-1” sollte verschwinden:

Nun noch einmal der Test mit “get-sids-from-token.ps1” (Folgen Sie dem Link für eine detaillierte Erklärung)
Die SID ist nun ebenfalls nicht mehr im Token gelistet: