Bekannte Kerberos-Konfigurationsprobleme (SharePoint Server 2010)

  • Artikel

 

Gilt für: SharePoint Server 2010

Letztes Änderungsdatum des Themas: 2016-11-30

Kerberos-Authentifizierung und Nicht-Standardports

Es gibt ein bekanntes Problem mit Kerberos-Clients (u. a. .NET Framework, Internet Explorer 7 und 8), die beim Versuch der Authentifizierung mit für Kerberos aktivierten Webanwendungen, die für Nicht-Standardports (andere Ports als 80 und 443) konfiguriert sind, keine ordnungsgemäßen Dienstprinzipalnamen bilden. Die Ursache des Problems ist, dass der Client den Dienstprinzipalnamen in der TGS-Anforderung nicht ordnungsgemäß bildet, da die Angabe ohne Portnummer erfolgt (wie beim Sname der TGS-Anforderung gesehen).

Beispiel:

Wenn die Webanwendung unter http://intranet.contoso.com:1234 ausgeführt wird, fordert der Client ein Ticket für den Dienst mit dem Dienstprinzipalnamen http/intranet.contoso.com anstatt http/intranet.contoso.com:1234 an.

Einzelheiten zu diesem Problem finden Sie in den folgenden Artikeln:

Registrieren Sie zum Umgehen dieses Problems Dienstprinzipalnamen mit und ohne Portnummer. Beispiel:

  • http/intranet

  • http/intranet.contoso.com

  • http/intranet:12345

  • http/intranet.contoso.com:12345

Es wird empfohlen, den Nicht-Standardport zu registrieren, um sicherstellen, dass bei Behebung des Problems in einem künftigen Service Pack oder Hotfix die Anwendungen, die die Problemumgebung verwenden, weiter funktionieren.

Beachten Sie, dass diese Problemumgehung bei folgenden Bedingungen nicht funktioniert:

  • Am Nicht-Standardport werden mehrere Webanwendungen ausgeführt.

  • Die Webanwendungen sind entweder an den Hostnamen des Servers oder denselben Hostheader (an unterschiedlichen Ports) gebunden.

  • Die IIS-Anwendungspools der Webanwendung verwenden unterschiedliche Dienstkonten.

Wenn diese Bedingungen zutreffen, führt das Befolgen der Empfehlung in dieser Problemumgehung zu doppelten Dienstprinzipalnamen, die bei verschiedenen Dienstkonten registriert sind, wodurch die Kerberos-Authentifizierung nicht mehr funktioniert.

Wenn es mehrere Websites mit einem gemeinsamen Hostnamen gibt, der an mehreren Ports verwendet wird, und Sie unterschiedliche IIS-Anwendungspoolidentitäten für die Webanwendungen verwenden, kann die Kerberos-Authentifizierung nicht für alle Websites verwendet werden. (Eine Anwendung kann mit Kerberos arbeiten, während die anderen ein anderes Authentifizierungsprotokoll benötigen.) Damit Kerberos bei diesem Szenario für alle Anwendungen verwendet werden kann, müssen Sie einen der folgenden Schritte ausführen:

  1. Alle Webanwendungen unter einem gemeinsamen Dienstkonto ausführen

  2. Jede Website mit einem eigenen Hostheader ausführen

Kerberos-Authentifizierung und DNS CNAMEs

Es gibt ein bekanntes Problem mit Kerberos-Clients (u. a. .NET Framework, Internet Explorer 7 und 8), die versuchen, sich mit für Kerberos aktivierten Diensten zu authentifizieren und für die eine Auflösung mithilfe von DNS CNAMEs anstatt mithilfe von A-Einträgen konfiguriert ist. Die Ursache des Problems ist, dass der Client in der TGS-Anforderung den Dienstprinzipalnamen nicht ordnungsgemäß bildet, da er unter Verwendung des Hostnamens (A-Eintrag) anstatt des Aliasnamens (CNAME) erstellt wird.

Beispiel:

A-Eintrag: wfe01.contoso.com

CNAME: intranet.contoso.com (als Alias zu wfe01.contoso.com)

Wenn der Client eine Authentifizierung mit http://intranet.contoso.com versucht, bildet der Client den Dienstprinzipalnamen nicht ordnungsgemäß und fordert ein Kerberos-Ticket für http/wfe01.contoso.com anstatt für http/intranet.contoso.com an.

Einzelheiten zu dem Problem finden Sie in den folgenden Artikeln:

https://support.microsoft.com/kb/911149/de

https://support.microsoft.com/kb/938305/de

Konfigurieren Sie zum Umgehen dieses Problems für Kerberos aktivierte Dienste mit DNS A-Einträgen anstatt CNAME-Aliasen. Der im Knowledge Base-Artikel erwähnte Hotfix korrigiert dieses Problem für Internet Explorer, aber nicht für .NET Framework (das von Microsoft Office SharePoint Server für die Webdienstkommunikation verwendet wird).

Kerberos- und Kernelmodusauthentifizierung

Hinweis

Die Kernelmodusauthentifizierung wird von SharePoint Server 2010-Produkten nicht unterstützt. Diese Angaben dienen ausschließlich zu Informationszwecken.

Ab Internetinformationsdienste 7.0 (IIS) gibt es mit der Kernelmodusauthentifizierung eine neue Authentifizierungsmöglichkeit. Wenn eine IIS-Website für die Kernelmodusauthentifizierung konfiguriert ist, werden die Anforderungen des Clients automatisch durch HTTP.sys und nicht durch den Arbeitsprozess des Anwendungspools authentifiziert. Da HTTP.sys im Kernelmodus ausgeführt wird, ergibt sich eine bessere Leistung, wenn auch mit ein wenig mehr Komplexität hinsichtlich der Konfiguration von Kerberos. Der Grund ist, dass HTTP.sys unter der Identität des Computers und nicht unter der des Arbeitsprozesses ausgeführt wird. Wenn HTTP.sys ein Kerberos-Ticket empfängt, wird automatisch versucht, das Ticket mithilfe des Entschlüsselungsschlüssels (bzw. geheimen Schlüssels) des Servers und nicht mithilfe des Schlüssels der Identität zu entschlüsseln, unter der der Arbeitsprozess ausgeführt wird.

Wenn ein einzelner Webserver für die Kernelmodusauthentifizierung konfiguriert ist, funktioniert Kerberos ohne zusätzliche Konfiguration oder Dienstprinzipalnamen, da der Server automatischen einen Host-Dienstprinzipalnamen registriert, wenn er der Domäne hinzugefügt wird. Wenn mehrere Webserver dem Lastenausgleich unterliegen, funktioniert die Standardkonfiguration der Kernelmodusauthentifizierung nicht bzw. zwischenzeitlich nicht, da der Client keine Möglichkeit hat sicherzustellen, dass das in der TSG-Anforderung empfangene Dienstticket mit dem Server funktioniert, der die Anforderung authentifiziert.

Gehen Sie zum Umgehen dieses Problems wie folgt vor:

Kerberos- und sitzungsbasierte Authentifizierung

Bei der Verwendung der Kerberos-Authentifizierung mit IIS 7.0 oder höher kommt es ggf. zu mehr Authentifizierungsdatenverkehr, was an die Windows-Authentifizierungseinstellungen in IIS liegen kann, insbesondere an Folgendem:

AuthPersistNonNTLM

Optionales boolesches Attribut.

Gibt an, ob IIS automatisch alle Nicht-NTLM-Anforderungen (z. B. Kerberos) erneut authentifiziert, auch diejenigen über dieselbe Verbindung. Falls True, werden mehrere Authentifizierungen für dieselben Verbindungen aktiviert.

Der Standardwert ist False.

Hinweis

Die Einstellung False bedeutet, dass der Client für dieselbe Verbindung nur einmal authentifiziert wird. IIS speichert ein Token oder Ticket auf dem Server für eine TCP-Sitzung, das eingerichtet bleibt.

authPersistSingleRequest

Optionales boolesches Attribut.

Die Einstellung True gibt an, dass die Authentifizierung nur für eine einzelne Anforderung über eine Verbindung gilt. IIS setzt die Authentifizierung am Ende jeder Anforderung zurück und erzwingt die erneute Authentifizierung für die nächste Anforderung der Sitzung.

Der Standardwert ist False.

Anweisungen zum Konfigurieren der Authentifizierungspersistenz in IIS 7.0 finden Sie unter Möglicherweise verlangsamte Leistung, wenn Sie die integrierte Windows-Authentifizierung mit Kerberos-Authentifizierungsprotokoll in IIS 7.0 verwenden und Implementierung der Zugriffssteuerung.

Kerberos-Authentifizierung und Probleme mit doppelten/fehlenden Dienstprinzipalnamen

Beim Konfigurieren der Kerberos-Authentifizierung kann es leicht passieren, dass doppelte Dienstprinzipalnamen konfiguriert werden, insbesondere wenn Sie SetSPN -A oder das ADSI Edit-Tool (adsiedit.msc) zum Erstellen Ihrer Dienstprinzipalnamen verwenden. Generell wird empfohlen, zum Erstellen von Dienstprinzipalnamen SetSPN -S zu verwenden, da der Parameter -S nach einem doppelten Dienstprinzipalnamen sucht, bevor der angegebene Dienstprinzipalname erstellt wird.

Wenn Sie in Ihrer Umgebung doppelte Dienstprinzipalnamen vermuten, rufen Sie den Befehl SetSPN -X auf, um alle doppelten Dienstprinzipalnamen in Ihrer Umgebung abzurufen (nur unter Windows 2008 und höher). Wenn Dienstprinzipalnamen zurückgegeben werden, sollten Sie untersuchen, warum die Dienstprinzipalnamen registriert wurden, und nicht benötigte Duplikate löschen. Wenn Sie zwei Dienste haben, die mit zwei unterschiedlichen Identitäten ausgeführt werden, und beide denselben Dienstprinzipalnamen nutzen, müssen Sie einen dieser Dienste entweder für die Verwendung eines anderen Dienstprinzipalnamens konfigurieren oder beide eine gemeinsame Dienstidentität verwenden lassen.

Wenn Sie vermuten, dass ein Dienstprinzipalname nicht bzw. nicht im erforderlichen Format registriert wurde, können Sie den Befehl SetSPN -Q <Dienstprinzipalname einfügen> aufrufen, um zu prüfen, ob ein bestimmter Dienstprinzipalname vorhanden ist.

Maximale Größe des Kerberos-Tokens

In bestimmten Umgebungen sind Benutzer ggf. Mitglieder vieler Active Directory-Gruppen, wodurch sich die Größe ihrer Kerberos-Tickets erhöhen kann. Wenn die Tickets zu groß werden, kann die Kerberos-Authentifizierung misslingen. Weitere Informationen zum Anpassen der maximalen Tokengröße finden Sie unter Neue Lösung für Probleme mit Kerberos-Authentifizierung, wenn Benutzer mehreren Gruppen angehören (https://support.microsoft.com/kb/327825/de).

Hinweis

Beachten Sie beim Anpassen der maximalen Tokengröße, dass bei Festlegung einer maximalen Tokengröße über den Maximalwert der Registrierungseinstellung hinaus, es ggf. zu Kerberos-Authentifizierungsfehlern kommt. Als maximale Tokengröße sollte 65535 (dezimal) bzw. FFFF (hexadezimal) nicht überschritten werden.

Hotfixes für die Kerberos-Authentifizierung für Windows Server 2008 und Windows Vista

Kerberos-Authentifizierung misslingt bei Verwenden des AES-Algorithmus auf einem Computer mit Windows Server 2008 oder Windows Vista mit dem Fehlercode 0X80090302 oder 0x8009030f (https://support.microsoft.com/kb/969083/de)

Sie müssen ggf. auf allen Computern mit Windows Server 2008 und Windows Vista in Ihrer Umgebung einen Hotfix für die Kerberos-Authentifizierung installieren. Dazu zählen alle Computer mit SharePoint Server 2010, SQL Server bzw. Windows Server 2008, bei denen sich SharePoint Server mithilfe der Kerberos-Authentifizierung authentifizieren möchte. Befolgen Sie die Anweisung auf der Supportseite zum Anwenden des Hotfix, wenn die dokumentierten Symptome in Ihrer Umgebung auftreten sollten.