Wer SharePoint mit Kerberos einrichten muss, der kennt vielleicht folgenden Fehler:

HTTP Error 401.1 – Unauthorized: Access is denied due to invalid credentials. Internet Information Services (IIS)

In meinem Fall lag es an falsch gesetzten SPNs.

Ein Kerberos Ticket wird normalerweise für einen bestimmten Dienst ausgestellt. Um einen Dienst zu identifizieren, muss ein eindeutiger Name (SPN) vergeben werden. Dieser Name muss bei dem Konto hinterlegt werden, unter welchem der Dienst ausgeführt wird.

In der SharePoint Welt heißt das: Unser Dienst ist die Webanwendung, die unter dem Account im zugehörigen ApplicationPool ausgeführt wird. Also muss hier der SPN hinterlegt werden. Und wie heißt nun dieser SPN? Klassische Antwort KDA (=kommt drauf an)

Um eine SharePoint Seite zu öffnen gibt man im Browser eine URL ein. Der Browser holt sich dann beim Key Distribution Center (KDC) ein Kerberos Ticket und muss dabei angeben, auf welchen SPN diese ausgestellt werden soll. Da der Browser sich sinnvollerweise nicht mit einem Popup meldet und den User dazu befragt, generiert er aus der eingegebenen URL den SPN. Beim IE kann man nun über einige Registry Keys einstellen, wie dies von statten geht.

So kann über die RegistryKey FEATURE_INCLUDE_PORT_IN_SPN_KB908209 und FEATURE_USE_CNAME_FOR_SPN_KB911149 eingestellt werden, ob die Portnummer bzw. der CNAME für den SPN verwendet werden soll. Untersucht habe ich das bisher für IE 6 und IE 7. Zu IE 8 (insbesondere auf Windows 7) habe ich keine validen Aussagen.

Beispiel:

URL der SharePoint Site ist: http://unserPortal:123/default.aspx, unserPortal ist ein CNAME und zeigt auf den Rechner mit Hostname Server1

Das kann sich auch durchaus nochmal unterscheiden, wenn ein Proxy verwendet wird.

Schwierig ist das festlegen der SPN auch deswegen, weil wir ja nicht nur an den Browser denken müssen. Wie verhalten sich andere Anwendungen, die mit SharePoint kommunizieren? z.B. Office, SPD, .NET Framework, Managemnt Tools usw ….

Zu diesem Thema empfehle ich auch den Beitrag von Michel Barnveld: The reason why KB911149 and KB908209 are not the solution!

Zumindest Office hat sich in unseren Tests auch der o.g. RegistryKey bedient und die Einstellungen jeweils berücksichtigt. Ansonsten muss man sich die Kerberos Logs anschauen und ausprobieren, welcher SPN angefragt wird …. Kling komisch, ist aber (leider) so.