Kerberos im LOCAL SYSTEM Kontext und NTLM Fallback

Hallo zusammen, Fabian schreibt. In der letzten Zeit hatte ich mehrfach bei Kundenanfragen mit einer bekannten Fragestellung zu tun, die mit Kerberos Authentifizierung im SYSTEM Kontext und NTLM Fallbacks zu tun hat. Daher an dieser Stelle ein, zwei Zeilen dazu.

Gleich zu Beginn der Hinweis, daß das Thema nicht nur auf Zertifikate und Autoenrollment anzuwenden ist, sondern eine generelle Kerberos / NTLM Fragestellung ist. Aber am Autoenrollment Beispiel läßt es sich sehr gut verdeutlichen.

Konkret traten bei einigen Kunden von uns Probleme bei Zertifikat-Autoenrollment im SYSTEM / Maschinen Kontext auf, während dessen Benutzer problemlos Zertifikate beantragen konnten. Der Fehler im Application Event Log beim Autoenrollment der Maschine lautete dann meist:

Event Type: Error
Event Source: AutoEnrollment
Event Category: None
Event ID: 13
Date: 1/1/2010
Time: 8:01:45 AM
User: N/A
Computer: CLIENT1
Description: Automatic certificate enrollment for local system failed to enroll for one Computer certificate (0x80070005). Access is denied.

Trifft man auf ein “0x80070005 Access is denied” beim Autoenrollment, ist bis Windows Server 2008 R2 häufig die erste Vermutung, daß ein DCOM Problem vorliegt – jedoch zeigte sich nach einigen Tests, daß das Problem nicht an dieser Stelle zu suchen war.

Um zu prüfen, wann es zu dem “Acces is denied” kommt, kann man beim Zertifikat-Autoenrollment beispielsweise zuallererst einmal prüfen, ob Benutzer und Computer betroffen sind. Dazu setzt man einen “CA-Ping” mittels “certutil.exe” auf die Ziel-CA ab, um zu schauen, ob diese erreichbar ist. Diese Prozedur geschieht einmal im Benutzer-Kontext und einmal im SYSTEM-Kontext auf einer betroffenen Maschine:

Benutzer Kontext:

C:\> certutil -ping -config DMW2K8R201.forest1.test\EntRootCA
Connecting to DMW2K8R201.forest1.test\EntRootCA ...
Server "EntRootCA" ICertRequest2 interface is alive
CertUtil: -ping command completed successfully.

Aha, der Benutzerkontext erhält also keine Fehler. Wie sieht es nun mit dem Maschinen / SYSTEM Kontext aus?

Dazu müssen wir uns zuerst in den SYSTEM Kontext heben. Recht einfach geht das (auch unter 2008 und höher) mit dem Tool “PsExec”:

C:\> psexec.exe \\localhost –s cmd

Nun befindet man sich im SYSTEM Kontext der Maschine und setzt denselben certutil-Befehl noch einmal ab.

SYSTEM Kontext:

C:\Windows\system32> certutil -ping -config DMW2K8R201.forest1.test\EntRootCA
Connecting to DMW2K8R201.forest1.test\EntRootCA ...
Server could not be reached: The RPC server is unavailable. 0x800706ba (WIN32: 1722)
CertUtil: -ping command FAILED: 0x800706ba (WIN32: 1722)
CertUtil: The RPC server is unavailable.

Ok, das ist der Hinweis, den man benötigt: Im Benutzerkontext funktioniert der Zugriff, um Maschinen Kontext jedoch nicht. Hier können, je nach dem konkretem Problem, verschiedene Fehler ausgegeben werden – so etwa der “RPC server is unavailable” Fehler oder ein “Access denied” etc.

Der nächste Schritt zur Eingrenzung des Problems kann sein, einen Netzwerktrace vom fehlschlagenden Request (und am besten einen Gut-Fall zum Vergleich) zu generieren. Dazu löscht man erst einmal den Kerberos Cache (jeweils im Benutzer- als auch im SYSTEM Kontext):

C:\> klist purge

Nun startet man den Trace und führt die certutil-Kommandos erneut aus. Im Netzwerktrace des Fehlerfalles kann man dann im beschriebenen Szenario folgende Fehlermeldungen finden:

0.000000 08:15:07 01.01.2010 1595 0.000000 {TCP:70, IPv4:25} 10.10.10.20 10.10.10.10 KerberosV5 KerberosV5:TGS Request Realm: forest1.test Sname: RPCSS/DMW2K8R201.forest1.test

0.000009 08:15:07 01.01.2010 1596 0.000000 {TCP:70, IPv4:25} 10.10.10.10 10.10.10.20 KerberosV5   KerberosV5:KRB_ERROR - KDC_ERR_S_PRINCIPAL_UNKNOWN (7)

Das ist in diesem Kontext eine interessante Meldung – denn scheinbar haben wir hier ein Kerberos Problem. Der Kerberos Service Principal Name "RPCSS/DMW2K8R201.forest1.test"kann nicht gefunden werden - da RPCSS einen Alias für HOST darstellt (es sei denn, er wurde manuell angelegt, um etwa auf ein bestimmtes Benutzer- oder Computerkonto zu mappen), scheint es bei der Suche nach dem HOST SPN zum Problem zu kommen. Unter Umständen fehlt für die Zielmaschine (also die Certificate Authority) ein HOST Eintrag. Siehe zu SPN Aliasen auch: Setspn Remarks: Active Directory https://technet.microsoft.com/en-US/library/cc773381(WS.10).aspx

Direkt im Anschluß findet man dann meist ein Paket wie dieses:

Frame: Number = 1680, Captured Frame Length = 199, MediaType = ETHERNET
- MSRPC: c/o Auth3: Call=0x2
- Auth3:
[…]
- AuthVerifier:
AuthType: RPC_C_AUTHN_WINNT - NTLM authentication will be used.
[…]
- AuthValue:
- NLMP: NTLM AUTHENTICATE MESSAGE, Workstation: W2008C
Signature: NTLMSSP
[…]
- DomainName: Length: 0, Offset: 80
[…]
- UserName: Length: 0, Offset: 80
[…]

Genau hier liegt das Problem: Kann ein Client Kerberos beim Zugriff auf den Server (bei unserem Beispiel die CA) nicht nutzen, wird das benötigte Kerberos-Dienstticket nicht ausgestellt werden. Es erfolgt daher ein Fallback auf NTLM. Das Problem entsteht nun bei diesem Fallback – denn bis Windows Server 2008 R2 wird bei Diensten im “LOCAL SYSTEM” Kontext kein Benutzername mittels NTLM gesendet – es wird anstatt dessen eine “NULL Session” verwendet. Genau das sieht man im Netzwerktrace: “DomainName” als auch “UserName” hat eine Länge von “0” – enthält also keine Daten.

Ausnahmen sind Applikationen bzw. Dienste, die das Mitsenden des Benutzernamens explizit anfordern (zum Beispiel SMB “Session Setup & X” etc.).

Somit versucht sich in unserem Beispiel die Maschine mittels NTLM anonym anzumelden – und genau das scheitert mit den Standardeinstellungen von Windows Server 2003 Umgebungen und aufwärts.

Ab Windows 7 / Windows Server 2008 R2 wurde dieses Verhalten (neben anderen Veränderungen im Bereich Kerberos / NTLM) standardmäßig geändert – es wird nun auch bei Diensten im “LOCAL SYSTEM” Kontext der “Benutzername” der Maschine gesendet – also etwa “Clientname$” anstatt der NULL Session. Somit erfolgt der Authentifizierungsversuch nicht anonym und der Zugriff erfolgt mittels NTLM auch authentifiziert.

Beeinflussen kann man dieses Verhalten ab Windows 7 / Windows Server 2008 R2 mit den folgenden beiden Einstellungen:

GPO: Computer Configuration \ Policies \ Windows Settings \ Security settings \ Local Policies \ Security Options: “Network Security: Allow Local System to use computer identity for NTLM”
Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\UseMachineId
GPO: Computer Configuration \ Policies \ Windows Settings \ Security settings \ Local Policies \ Security Options: “Network Security: Allow Local System Null session fallback”
Registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\MSV1_0\allownullsessionfallback

Siehe dazu auch: Changes in NTLM Authentication https://technet.microsoft.com/en-us/library/dd566199(WS.10).aspx

Jedoch ist dies nicht “die Lösung” für das oben genannte Problem – denn NTLM soll auch weiterhin nur als Fallback dienen und nicht als “Standard-” Authentifizierungsprotokoll. Das bedeutet, daß für den erfolgreichen Kerberos Zugriff das zugrunde liegende Problem behoben werden sollte – nämlich der fehlende SPN hinzugefügt wird.

Im Beispiel von oben kann dies etwa durch einen “Domain Admin” mittels “SETSPN” geschehen – er setzt für das betroffene Maschinenkonto der CA im AD einfach den fehlenden SPN:

C:\> setspn –A HOST/dmw2k8r201
C:\> setspn –A HOST/dmw2k8r201.forest1.test

Wie immer sollte vor dem Setzen von SPNs geprüft werden, ob unter Umständen schon eine andere Maschine denselben SPN aufweist – im Beispiel von oben ist das jedoch nicht sehr wahrscheinlich. Siehe dazu auch:

321044    Event ID 11 in the System log of domain controllers
https://support.microsoft.com/default.aspx?scid=kb;EN-US;321044

Fazit:

• Selbst wenn man es erst indirekt bemerkt, kann in einer Umgebung NTLM anstatt Kerberos verwendet werden – wenn nämlich Probleme beim Kerberos Zugriff auftreten. Dies sollte fortwährend geprüft werden (etwa durch Überwachung der Ereignisprotokolle etc.), denn sonst führt ein solches Problem häufig zu Folgefehlern oder wird erst sehr spät bemerkt.

• Auch bei Umgebungen mit disjoined DNS Namespaces kann dies zu Problemen führen, denn standardmäßig werden nur die SPNs des primary DNS Suffixes einer Maschine im AD registriert. Hier muß man also entweder auch den disjoined DNS Namen der Maschine manuell hinzufügen oder aber die Maschine mit einem zusätzlichen DNS Suffix ausstatten, so daß die Registrierung der SPNs mit disjoined DNS Namespace zukünftig automatisch passiert. Ansonsten wird kein Kerberos genutzt, sondern NTLM.

• In Windows 7 / Windows Server 2008 R2 hast sich das Standardverhalten in Bezug auf NTLM NULL Sessions bei "LOCAL SYSTEM" Diensten verändert – es sollte daher explizit geprüft werden, wie die Authentifizierung bzw. über welches Protokoll die Authentifizierung stattfindet. Ein guter Ansatzpunkt dafür ist auch das seit Windows Server 2008 R2 bereitstehende NTLM Logging:

  NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7 https://blogs.technet.com/askds/archive/2009/10/08/ntlm-blocking-and-you-application-analysis-and-auditing-methodologies-in-windows-7.aspx

Viele Grüße
Fabian