PROBLEM

Stellen Sie sich folgendes Szenario vor:

  • Ein Office 365 für Unternehmen, Office 365 für Bildungseinrichtungen oder Office 365-Geschäftskunde richtet Single Sign-On (SSO) in Active Directory Federation Services (AD FS) 2.0 ein.

  • Verbundbenutzer, die eine Verbindung innerhalb ihres Unternehmensnetzwerks herstellen, können sich von Lync 2013 aus nicht bei Skype for Business Online (früher Lync Online) anmelden, und sie erhalten die folgende Fehlermeldung:

    Die Anmeldung kann nicht möglich sein, da der Server vorübergehend nicht verfügbar ist.

Hinweis Dieses Problem gilt nur für Enterprise SSO-Benutzer, die sich mit Lync 2013 innerhalb ihres Unternehmensnetzwerks bei Skype for Business Online anmelden. Das Problem gilt nicht für Benutzer in Microsoft Lync 2010, Benutzer, die nicht in Skype for Business Online sind, oder für Benutzer, die eine Verbindung von außerhalb ihres Unternehmensnetzwerks herstellen.

LÖSUNG

Wichtig Befolgen Sie die Schritte in diesem Abschnitt sorgfältig. Wenn Sie die Registrierung falsch ändern, können schwerwiegende Probleme auftreten. Bevor Sie sie ändern, sichern Sie die Registrierung für den Fall, dass Probleme auftreten. Da es viele mögliche Ursachen gibt, ist es am besten, alle folgenden Lösungen zu durcharbeiten und dann die Konfiguration zu überprüfen.

  1. Wenn Sie eine AD FS 2.0-Verbundserverfarm bereitstellen, müssen Sie ein domänenbasiertes Dienstkonto angeben, das einen registrierten SPN benötigt, damit die Kerberos-Authentifizierung ordnungsgemäß funktioniert. Weitere Informationen finden Sie im folgenden TechNet-Wiki:

    AD FS 2.0: Konfigurieren des SPN (servicePrincipalName) für das DienstkontoDie Gründe, aus denen Sie den SPN manuell auf dem AD FS 2.0-Dienstkonto festlegen müssen, sind wie folgt:

    • Die SPN-Registrierung ist bei der Erstkonfiguration der Farm fehlgeschlagen.

    • Der Name des Verbunddienstes wurde geändert.

    • Das Dienstkonto wurde geändert.

  2. Stellen Sie sicher, dass der AD FS 2.0-Dienst unter dem domänenbasierten Dienstkonto ausgeführt wird, das im vorherigen Schritt erwähnt wurde. In der folgenden Abbildung ist TRLABV3 beispielsweise der interne Hostname, und ADFSSvc ist das Dienstkonto:alternate text

  3. Konfigurieren Sie den AD FS 2.0-Server so, dass Anforderungsheader akzeptiert werden, die größer als 40 Kilobyte (KB) sind. Dies kann erforderlich sein, wenn der Benutzer Mitglied vieler AD DS-Benutzergruppen (Active Directory Domain Services) ist. Wenn ein Benutzer Mitglied vieler AD DS-Gruppen ist, erhöht sich die Größe des Kerberos-Authentifizierungstokens für den Benutzer. Die HTTP-Anforderung, die der Benutzer an den IIS-Server (Internet Information Services) sendet, enthält das Kerberos-Token im WWW-Authenticate-Header. Daher nimmt die Headergröße mit der Anzahl der Gruppen zu. Wenn die HTTP-Header- oder Paketgröße über die in IIS konfigurierten Grenzwerte hinausansteigt, kann IIS die Anforderung ablehnen und einen Fehler als Antwort senden. Weitere Informationen finden Sie im folgenden Microsoft Knowledge Base-Artikel:

    2020943 Fehler "HTTP 400 - Ungültige Anforderung (Zu lange Anforderungsheader)" in Internet Information Services (IIS)"Wenden Sie eine der folgenden Methoden an, um dieses Problem zu umgehen:

    1. Verringern Sie die Anzahl der AD DS-Benutzergruppen, denen der Benutzer angehört.

    2. Ändern Sie die Registrierungswerte MaxFieldLength und MaxRequestBytes auf dem Server, auf dem IIS ausgeführt wird, sodass die Anforderungsheader des Benutzers nicht als zu lang angesehen werden. Diese beiden Registrierungswerte befinden sich unter dem folgenden Registrierungsunterschlüssel:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

  4. Wenn Sie mehrere AD FS 2.0-Server in einer Farm bereitgestellt haben und diese lastenausgeglichen haben, kann der Lync 2013-Client die Anforderung möglicherweise nicht an den AD FS 2.0-Server weiterleiten. Durch das Hinzufügen eines Eintrags für den AD FS 2.0-Server zur Hosts-Datei auf dem Client, der direkt auf den AD FS 2.0-Server verweist, wird die virtuelle IP des Load Balancers umgangen.

  5. Wenn die vorherigen Lösungen das Problem nicht behoben haben und eine Herabstufung auf Lync 2010 keine Option ist, führen Sie die folgenden Schritte aus, um das Problem zu umgehen. Hinweis Wenn noch kein lokales Administratorkonto auf dem Computer vorhanden ist, müssen Sie ein Konto erstellen, damit diese Lösung funktioniert.

    1. Navigieren Sie zur ausführbaren Datei Lync 2013 im Windows Explorer:

       C:\Program Files\Microsoft Office 15\root\office15 
    2. Halten Sie die Umschalttaste gedrückt, und klicken Sie dann mit der rechten Maustaste auf Lync.exe.

    3. Klicken Sie auf Ausführen als anderer Benutzer.

    4. Geben Sie die Anmeldeinformationen für ein lokales Administratorkonto auf dem Computer ein, und drücken Sie dann die Eingabetaste.

WEITERE INFORMATIONEN

Dieses Problem tritt in der Regel aufgrund einer Fehlkonfiguration in AD FS 2.0 auf. Andere Dienste wie Microsoft Exchange Online funktionieren trotz dieser Konfiguration möglicherweise ordnungsgemäß. Die üblichen Ursachen sind hier aufgeführt:

  • Der ServicePrincipalName (SPN) ist nicht ordnungsgemäß konfiguriert. Die Gründe hierfür sind:

    • Die SPN-Registrierung ist bei der Erstkonfiguration der Farm fehlgeschlagen.

    • Der Name des Verbunddienstes wurde geändert.

    • Das Dienstkonto wurde geändert.

  • Der AD FS 2.0-Dienst wird nicht unter dem richtigen Dienstkonto ausgeführt.

  • Der Anforderungsheader von Lync 2013 wird von IIS und dem AD FS 2.0-Server abgelehnt, da der Header zu groß ist. Dieses Problem kann auftreten, weil das Benutzerkonto Mitglied von zu vielen AD DS-Benutzergruppen ist.

  • Die AD FS 2.0-Serverfarm ist lastbalanced, und die Anforderung erreicht den AD FS 2.0-Server nicht.

Weitere Hilfe zur Bereitstellung von AD FS 2.0 zur Verwendung mit SSO in Office 365 finden Sie auf der folgenden TechNet-Website:

Planen und Bereitstellen von AD FS für die Verwendung mit Single Sign-OnWenn der Benutzer Mitglied einer zu vielen AD DS-Gruppen ist, wird der folgende Eintrag in die Ablaufverfolgungsprotokolle des Anmeldeassistenten für Microsoft Online Dienste eingegeben (diese Protokolle befinden sich in der Regel in C:" MSOSSPTrace):

##TestHook: URL-https://<ADFSServer>/adfs/services/trust/2005/windowstransport@transport.cpp_245..........<HTML><HEAD><TITLE>Bad Request</TITLE><META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD><BODY><h2>Bad Request - Request Too Long</h2><hr><p>HTTP Error 400. The size of the request headers is too long.</p></BODY></HTML> 

Weitere Hilfe erforderlich? Besuchen Sie die Microsoft Community.

Benötigen Sie weitere Hilfe?

Ihre Office-Fähigkeiten erweitern
Schulungen erkunden
Neue Funktionen als Erster erhalten
Microsoft Insider beitreten

War diese Information hilfreich?

Wie zufrieden sind Sie mit der Übersetzungsqualität?
Was hat Ihre Erfahrung beeinflusst?

Vielen Dank für Ihr Feedback!

×