Was Sie über anspruchsbasierte Authentifizierung in SharePoint 2010 wissen sollten: dauerhafte Sitzungen sind ERFORDERLICH

  • Article

Veröffentlichung des Originalartikels: 28.10.2011

Hallo Leute, jetzt bin auch ich Opfer einer Anomalie der anspruchsbasierten Authentifizierung geworden, von der ich wünschte, sie wäre mir klarer gewesen. Es geht um einen so fundamentalen Aspekt der Bereitstellung, dass ich ihn unbedingt hier allgemein bekannt machen möchte, damit Ihnen nicht dasselbe passiert.

Einfach ausgedrückt, MÜSSEN Sie bei Verwendung der anspruchsbasierten Authentifizierung in Ihrer Lastenausgleichslösung Affinität verwenden. Dies ist in TechNet beschrieben, aber nur als kurze Randbemerkung und nicht nachdrücklich genug. Der Artikel findet sich unter https://technet.microsoft.com/en-us/library/cc288475.aspx und besagt Folgendes:

Hinweis: Wenn Sie die auf SAML-Token basierende Authentifizierung mit Active Directory-Verbunddiensten in einer SharePoint Foundation 2010-Farm verwenden, die mehrere Webserver in einer Konfiguration mit Lastenausgleich aufweist, könnten Leistung und Funktionalität beim Anzeigen von Clientwebseiten beeinträchtigt werden. Wenn das Authentifizierungstoken durch Active Directory-Verbunddienste dem Client bereitgestellt wird, wird dieses Token für jedes Seitenelement mit eingeschränkten Berechtigungen an SharePoint Foundation 2010 übermittelt. Falls die Lösung mit Lastenausgleich keine Affinität verwendet, wird jedes geschützte Element für mehrere SharePoint Foundation 2010-Server authentifiziert, was zur Ablehnung des Tokens führen kann. Nach der Ablehnung des Tokens wird der Client zur erneuten Authentifizierung durch SharePoint Foundation 2010 an den Server mit Active Directory-Verbunddiensten umgeleitet. Ein Server mit Active Directory-Verbunddiensten kann in diesem Fall mehrere Anforderungen ablehnen, die in einem kurzen Zeitraum erfolgen. Dieses Verhalten ist beabsichtigt und soll vor einem Denial-of-Service-Angriff schützen. Für den Fall, dass die Leistung beeinträchtigt wird oder Seiten nicht vollständig geladen werden, sollten Sie eventuell für den Netzwerklastenausgleich die einfache Affinität festlegen. Dadurch werden die Anforderungen für SAML-Token auf einen einzelnen Webserver beschränkt.

Ich gebe zu, dass ich das nicht zur Kenntnis genommen oder nicht ernst genug genommen habe, aber ich poste es jetzt, damit es Ihnen nicht genau so geht. Ich habe die entscheidenden Wörter in dem Hinweis kursiv gesetzt (außerdem sollte das kein Hinweis sein, sondern in fetten Großbuchstaben geschrieben werden). Wenn Sie keine Affinität verwenden, werden Probleme der folgenden Art auftreten:

  • Sie werden möglicherweise zufällig zurück auf eine Anmeldeseite umgeleitet.
  • Sie gelangen möglicherweise in eine Authentifizierungsschleife, die die Active Directory-Verbunddienste veranlasst, die Anforderung wegen eines Denial-of-Service-Angriffs (DOS) abzulehnen, wie der Hinweis besagt.
  • Anhand einer Ablaufverfolgung der Aktivität können Sie möglicherweise erkennen, dass Ihr fedauth-Cookie von SharePoint auf einen abgelaufenen Wert gesetzt wurde und dann die Anforderungen erneut an die Active Directory-Verbunddienste gestellt wurden. Diese haben Ihnen dann aus unersichtlichen Gründen entweder kein Nicht-abgelaufen-Cookie ausgestellt oder dieses wurde von SharePoint in ein Abgelaufen-Cookie transformiert. Dadurch wird der oben beschriebene DOS-Zyklus ausgelöst. Rückblickend erkenne ich jetzt, dass ich in der Vergangenheit schon einige Anfragen zu diesem Problem erhielt und dass möglicherweise das Fehlen von dauerhaften Sitzungen die Ursache war.

Kurz gesagt, es sollte keine Zweifel und keine Unklarheiten zu dieser Frage geben – wenn Sie in SharePoint 2010 die anspruchsbasierte Authentifizierung verwenden, MÜSSEN SIE IHR LASTENAUSGLEICHSMODUL MIT AFFINITÄT VERWENDEN!

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Make Sure You Know This About SharePoint 2010 Claims Authentication - Sticky Sessions Are REQUIRED.