Access Denied für Share Zugriff im Computer Kontext mit Kerberos Fehler 3, Code 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN

Hallo, hier nun mal wieder euer Rolo mit einem Thema, welches in letzter Zeit öfters mal hochgekommen ist. Auch diesmal geht es um Kerberos…

Dieses Problem Szenario tritt auf, wenn eine Applikation oder Dienst, konfiguriert für Local System oder Network Service Kontext, Zugriff auf ein Share benötigt. Typisches Beispiel ist der SMS Client oder Site Server Zugriff auf das SMS Distribution Share. Die Symptome sind dann auch, daß es mit einem User Konto immer funktioniert.

Durchgeführter Test für dieses Szenario, Zugriff von SERVERSMS01 auf \\SERVERSMS02\SMS_DP$:

  • Mstsc /console (Terminal Server RDP Verbindung auf SERVERSMS01)
  • At <soon> /interactive CMD.EXE (öffnet neuen Console Command Prompt im System Kontext)
    In diesem Prompt:
  • Dir \\SERVERSMS02\SMS_DP$ -> Zugriff über NetBios Namen bringt “Access Denied”
  • Dir \\SERVERSMS02.server.contoso.com\SMS_DP$ -> FQDN Zugriff funktioniert


Insofern Auditing auf dem SERVERSMS02 aktiviert ist, findet man dort dann ein Logon Event 540 mit NTLM für NT AUTHORITY\ANONYMOUS LOGON

Event Type: Success Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID:
540
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: SERVERSMS02
Description:
Successful Network Logon:
User Name:
Domain:
Logon ID: (0x0,0x1CCA3)
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package:
NTLM
Workstation Name: SERVERSMS01

Wenn Kerberos Event Logging am SERVERSMS01 angeschaltet ist, siehe KB 262177 “How to enable Kerberos event logging”, http://support.microsoft.com/default.aspx?scid=kb;EN-US;262177, bekommt man einen passenden Eintrag für den SPN CIFS/ der für den Share Zugriff verwendet wird:

Type: Error
Source: Kerberos
Category: None
Event ID: 3
Description: A Kerberos Error Message was received: on logon session
Error Code: 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN
Server Realm: contoso.com
Server Name: CIFS/SERVERSMS02.contoso.com
Target Name: CIFS/SERVERSMS02.contoso.com@contoso.com

Diese bekommt man allerdings auch für den eingangs beschriebenen User Zugriff.
Hierbei ist zu berücksichtigen, daß der gesuchte SPN CIFS/SERVERSMS02.contoso.com Windows intern auf HOST/ abgebildet wird. Bei einer Kontrolle mit “SETSPN -L SERVERSMS02″ bestätigt sich, daß der eigentliche FQDN SPN, also HOST/SERVERSMS02.contoso.com, so nicht existiert.

Was steckt nun dahinter?
Bei einem „Ping SERVERSMS02“, welcher das Primary DNS Suffix client.contoso.com besitzt, kann man feststellen, daß bei der DNS Namensauflösung contoso.com verwendet und auch aufgelöst wird (durch die sogenannte DNS Devolution). Es ist jedoch so, daß der so gebildete FQDN Name dann als SPN beim Kerberos TGS Request gesucht wird. Für den FQDN ist jedoch nur HOST/SERVERSMS02.server.contoso.com registriert. D.h. den gesuchten SPN gibt es nicht. Für User Konten wird dann Fallback auf NTLM mit dem User Konto gemacht, welcher dann auch funktioniert. Für Computerkonten hingegen erfolgt der Fallback mit NTLM jedoch immer als Anonymous, was man auch in den Security Events feststellen konnte. Mit der anonymen Anmeldung hat man jedoch keine Zugriffsberechtigung auf das Share. So kommt es im Computer Kontext zu dem beobachteten Access Denied. Die Verwendung des FQDN wäre also eine generelle Lösung – Leider läßt das SMS Konfigurationsinterface die Eingabe eines FQDN aber nicht zu.

Wieso gibt es nun den SPN nicht?
Wie dargestellt wurden die Server auch in der DNS Parent Zone manuell registriert, damit sie Forest Wide besser erreichbar sind. Es gibt also für SERVERSMS02 den DNS Host Eintrag SERVERSMS02.server.contoso.com als auch SERVERSMS02.contoso.com. Der Eintrag in der DNS Root Zone ist jedoch als SPN nicht abgebildet. Beim Zugriff über \\SERVERSMS02.contoso.com\SMS_DP$ hat man dann das beschriebene Problem.
Der durch die Namensauflösung bestimmte SPN für den Kerberos TGS Request ist so für das Server Konto nicht abgebildet.

Es ist jedoch durchaus supportet, diesen SPN manuell nachzutragen:
SETSPN -A HOST/SERVERSMS02.contoso.com SERVERSMS02
Aus Wartungsgründen sollten man aber die Anzahl solcher SPN Einträge für FQDN Aliase möglichst gering halten, und sich eher Gedanken zur Platzierung von Ressourcen in der Domänen Infrastruktur machen.

Fazit: Beim Erstellen manueller DNS Host Records für Server Ressourcen in DNS Zonen, in denen die Server eigentlich nicht registriert sind, muß man die passenden SPNs ebenfalls manuell nachpflegen, sonst kann Kerberos nicht korrekt funktionieren.

…und damit verabschiede ich mich auch gleich in den Urlaub, bei dem Wetter in Bayern z.Z. ist es ja auch kaum auszuhalten…
Servus, Rolo