Claims Based Authentication, IIS 401 und Access Denied.

Claims Based Authentication ( CBA ) - Authentifizierung der nächsten Dimension, neu, toll und das beste: es gibt keinen Grund es NICHT zu tun!!! Sagt zumindest Microsoft, ich zitiere:

There are no additional steps to implement Windows authentication when you use the claims-based authentication mode.

So Stand es zumindest zum Veröffentlichung-Datum dieses Artikels auf TechNet geschrieben. Leider muss diese Prophezeiung erst noch in Erfüllung gehen. Ich wurde die letzten Tage doch ziemlich arg von der CBA gebeutelt. Ich brauche Forms zur Anmeldung, das funktioniert nur mit CBA. Was tun, wenn die CBA Windows integriert nicht funktioniert?
Die Problemstellung ist, das Benutzer vom IIS einen HTTP Fehler 401 bekommen, wenn Sie auf SharePoint zugreifen. Access Denied vom IIS, nicht vom SharePoint. Zugreifen können Benutzer das Portal über verschiedene URLs, http://1111, https://1111,  http://1111.domain.local usw. und so fort. Mein Alternate Access Mapping sah dabei wie folgt aus:

 

Jede URL ist in einer eigenen Zone. Nachstellen konnte ich, dass die Authentifizierung immer nur über eine dieser URLs funktioniert hat, und zwar:

• Für jeden Nutzer die gleiche URL,
• Bis zum nächsten IIS Reset, 
• Nach einem IIS Reset funktioniert der Zugriff über eine zufällige URL.

 Nach Stunden des Troubleshootings habe ich folgendes Alternate Access Mapping ausgetestet:

  Alle URLs sind auf eine Zone eingetragen ( "Add Internal URLs" ). Und siehe da, die Authentifizierung funktioniert über jede URL! Da in der Zwischenzeit der Microsoft Support eingeschaltet war und das Problem nicht kannte/ lösen konnte, bleibt mir nur der Schluss: Es ist ein Bug, eine Windows Authentifizierung mit CBA, die einen Zonen-Wechsel nicht verkraftet kann nicht "Work as designed" sein! Das waren meine Rahmenbedingungen:

• Es handelt sich um eine SharePoint Farm, allerdings nur ein Web Frontend Server,
• Stand CU Dezember 2010,
• Classic Authentifizierung funktionierte ohne Probleme,
• Problem trat sowohl bei NTLM als auch bei Kerberos auf

Für meine Lösung reicht der "Workaround" aus dem zweiten Screenshot, zumindest in diesem Fall. Mehr Zeit möchte ich auch nicht in weiteres Troubleshooting zum weiteren Eingrenzen des Problems investieren. Sollte ein kommendes CU den Fehler beheben, werde ich es vermerken. Sollte jemand von euch weitere Infos zu diesem Problem haben, freue ich mich über jedes Kommentar. Falls nicht hoffe ich, dass ich dem ein oder anderen wenigsten einige Stunden Troubleshooting ersparen kann!

Good Luck,

Andreas