Guten Tag zusammen,
wir stellen in einem Einführungsprojekt gerade ein seltsames Verhalten unserer Clients (Windows 7, IE 9 und 10) im Zusammenhang mit der ADFS-Authentifizierung und SharePoint 2013 fest. Ursprung aller unserer Untersuchungen war die Tatsache, dass
- wie so oft - die Funktion "Open with Explorer", sprich WebDAV bzw. die "Explorer View" in Dokumentenbibliotheken mit unterschiedlichen Fehlerverhalten nicht funktionierte. Nach langem Testen kamen wir zu der Erkenntnis, dass der Webclient
zum Öffnen der Explorer View Zugriff auf das im ADFS-Authentifizierungsprozess erstellte
FedAuth-Cookie verwenden muss. Dieses wird in den Ordner C:\Users\username\AppData\Roaming\Microsoft\Windows\Cookies abgelegt, wenn die Seite, die man ansurft, nicht im "Geschützen Modus" des Internet Explorer läuft. Wenn der "Geschützte
Modus" nämlich aktiv ist, wird das FedAuth-Cookie im "Isolated Cache" abgelegt, dem Ordner
C:\Users\username\AppData\Roaming\Microsoft\Windows\Cookies\Low. Ist letzteres der Fall, kann der Webclient das Cookie nicht verwenden und läuft in einen Authentifizierungsfehler. Der Internet Explorer selbst und auch Office 2013 kann sehr wohl dieses
Cookie auch im "Isolated Cache" verwenden, daher funktioniert die Anmeldung an den SharePoint-Server sowie auch das Handling von Dateien (Auschecken, Einchecken) ganz wunderbar, nur zum Beispiel die WebDAV-Ansicht bzw. - am Rande erwähnt - auch SkyDrive
Pro nicht. In diversen Blogs habe ich auch gelesen, dass man auf jeden Fall diese "Persistent Session Cookies" auf dem Client auf jeden Fall benötigt, um WebDav und SkyDrive Pro vernünftig zu nutzen. Unter anderem hier (http://blog.skadefro.dk/2011/10/sharepoint-and-webdavpart-2.html):
SharePoint will standardly run with Persistent Cookies, but you can change this though PowerShell. Set UseSessionCookies to $true or $false. If you need to work with SharePoint though Office or WebDAV you need to set this to $false (default).
Also, unser Erkenntnisprozess war so weit, dass wir sagen konnten: Ja, wir brauchen dieses Cookie und es darf nicht im "Isoltated Cache" liegen, sprich man sollte die Seite in eine IE-Zone aufnehmen, in der der "Geschützte Modus" inaktiv
ist.
Einige Wochen später nehmen wir uns dieser Kompatibilitätstests erneut an. Wir haben dabei für SharePoint-Farm genau das oben genannte Verhalten
UseSessionCookies auf $true setzen müssen (Sicherheitsgründe), sprich es werden bei der Anmeldung nun keine persistenten Cookies mehr in den Cache des Clients geschrieben. Damit dürfte - das war auch das Ergebnis unserer früheren Tests - die
WebDAV- und SkyDrive-Funktionalität gar nicht mehr gegeben sein, der gesunde Menschenverstand will es so.
Nun, jetzt kommt das eigentlich Verwirrende: Es geht "plötzlich" ohne Macken in beiden Browsern (IE 9 und IE 10), obwohl die persistenten Cookies deaktiviert wurden (UseSessionCookies = $true) und nachweislich auch keine
Cookies mehr geschrieben werden. Die Explorer-Ansicht funktioniert plötzlich ganz wunderbar, ohne Cookies, damit auch egal, ob im Geschützen Modus oder nicht.
Unsere einzige Erklärung, und damit befrage mal die Community: Microsoft hat innerhalb der letzten beiden Patch-Zyklen auch Kompatibilitätsupdates entweder dediziert oder versteckt in irgendwelchen
ominösen Updatepaketen herausgebracht, die das gesamte Authentifizierungsverhalten des Clients in Bezug auf WebDAV ändern. Es waren bei uns sehr viele Updates, die in der Zwischenzeit auf den Client gekommen sind und es ist ziemlich schwer, diese auf
einen Zusammenhang hin zu analysieren, zumal nur die sicherheitsrelevanten Updates einigermaßen gut dokumentiert sind. Bei vielen anderen Updatepakten steht nur plump: "Wir haben hier und da ein bisschen was verbessert und kompatibler gemacht, installiere
das mal besser, musste aber nicht!"
Nachvollziehbar wäre eine solch tiefgreifende Änderung/Vereinfachung des Verhalten schon, da ja auch Microsoft selbst mit Office365 ähnliche Probleme mit vielen Kunden haben dürfte. Der Verzicht auf persistente Cookies bei Erhaltung der Funktionalität erhöht
ja zumindest oberflächlich betrachtet auch die Sicherheit...
Ich hoffe, ihr versteht meine Ausführungen und die von uns angestellten Schlussfolgerungen. Wer uns einen KB-Artikel nennt, in dem das vermutete "Kompatibilitätsupdate" beschrieben ist, wird von mir mal auf einen Kaffee mit Sahnetorte nach Berlin
eingeladen (Reise und Übernachtung zahlt ihr aber selbst ^^). Vielleicht sind wir aber ja auch vollkommen auf dem Holzweg und ihr kennt die wahren Gründe? Fakt ist: Die Explorer-Ansicht funktioniert jetzt plötzlich und wir können uns nicht erklären, warum
das so ist!
Vielen Dank für eure Unterstützung in advance!
Michael
