Enterprise single sign-on användare i Office 365 kan inte logga in på Skype för Business Online från inuti företagsnätverket

VIKTIGT: Denna artikel har översatts av Microsofts programvara för maskin-översättning och möjligen efterredigerats via CTF-teknologi av Microsofts community istället för av en professionell mänsklig översättare. För att du på ditt eget språk skall få tillgång till samtliga Knowledge Base-artiklar erbjuder Microsoft både mänskligt översatta såväl som maskinöversatta artiklar samt artiklar som efterredigerats av en community. En maskinöversatt artikel likväl som en artikel som blivit efterredigerad av en community är dock inte alltid helt perfekt, då de kan innehålla misstag i ordförrådet, syntax- och grammatikfel. Microsoft är inte ansvarigt för några felaktigheter, misstag eller skador orsakade av felöversättningar eller för våra kunders bruk av innehållet. Microsoft uppdaterar ofta sin programvara för maskinöversättning samt de verktyg som förbättrar den maskinöversatta efterredigeringen.

Den engelska versionen av artikeln är följande: 2839539
PROBLEMET
Föreställ dig följande:
  • En Office 365 för företag, Office 365 för utbildning eller Office 365 för medelstora företag kund konfigurerar enkel inloggning (SSO) i Active Directory Federation Services (AD FS) 2.0.
  • Federerade användare som ansluter från inuti företagsnätverket logga inte in på Skype för Business-Online(formerly Lync Online) från Lync 2013 och visas följande felmeddelande:
    Det går inte att logga in eftersom servern är inte tillgänglig för tillfället.
Obs! Det här problemet gäller bara för Enterprise SSO användare loggar in på Skype för Business Online med hjälp av Lync 2013 från i företagsnätverket. Problemet gäller inte för användare av Microsoft Lync 2010, användare som inte är på Skype för Business Online eller användare som ansluter från utanför företagsnätverket.
LÖSNING
Viktigt Följ noga anvisningarna i detta avsnitt. Om du ändrar registret på felaktigt sätt kan det uppstå allvarliga problem. Innan du ändrar det. Säkerhetskopiera registret för återställning om det uppstår problem.

Eftersom det finns många möjliga orsaker, är det bäst att arbeta med följande lösningar och kontrollera konfigurationen.
  1. När du distribuerar en AD FS 2.0-federationsserver servergruppen måste du ange ett domänbaserat tjänstkonto som behöver en registrerade SPN för att aktivera Kerberos-autentisering ska fungera korrekt. Mer information finns i följande TechNet-wikin:Skäl att kanske du måste manuellt ange SPN-namnet på tjänstkontot för AD FS 2.0 är följande:
    • Det gick inte att registrera SPN under den inledande konfigurationen av servergruppen.
    • Federationstjänsten namn har ändrats.
    • Kontot har ändrats.
  2. Kontrollera att AD FS 2.0-tjänsten körs under kontot domänbaserade service som nämnts i föregående steg. Till exempel TRLABV3 är interna värdnamnet i följande bild och ADFSSvc är kontot:

    Skärmbild av AD FS 2.0 Windows Service egenskaper visar kontot domänbaserade
  3. Konfigurera AD FS 2.0-servern ska acceptera begärandehuvuden som är större än 40 kB (Kilobyte). Du kan behöva göra detta när användaren är medlem i flera användargrupper i Active Directory DS (AD DS). När en användare är medlem i flera grupper i AD DS, ökar storleken på Kerberos-Autentiseringstoken för användaren.

    HTTP-begäran som användaren skickar till servern för Internet Information Services (IIS) innehåller Kerberos-token i WWW-Authenticate-huvud. Filhuvudets storlek ökar därför som antalet grupper ökar. Om HTTP-huvud eller paketstorlek ökar utöver de gränser som konfigureras i IIS, IIS avvisa ansökan och skicka ett fel som svar. Mer information finns i följande artikel i Microsoft Knowledge Base:
    2020943 "HTTP 400 - Bad Request (Request Header too long)" error in Internet Information Services (IIS)
    Undvik det här problemet genom att använda någon av följande metoder:
    1. Minska antalet grupper i AD DS som användaren är medlem i.
    2. Ändra MaxFieldLength och MaxRequestBytes registervärden på servern som kör IIS så att användarens begärandehuvuden inte anses vara för lång. Dessa två registervärden finns under följande registerundernyckel:
      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
  4. Om du har distribuerat flera AD FS 2.0-servrar i en servergrupp och låta dem läsa Balanserad, 2013 Lync-klienten kan inte direkt begäran till AD FS 2.0-servern. Lägga till en post för AD FS 2.0-servern i Hosts-filen på den klient som pekar direkt på AD FS 2.0-servern kommer att kringgå den virtuella IP-Adressen för belastningsutjämningen.
  5. Så här löser problemet om lösningarna som tidigare inte lösa problemet och nedgradering till Lync 2010 inte är ett alternativ.

    Obs! Om lokala administratörskontot inte redan finns på datorn, måste du skapa en för den här lösningen fungerar.
    1. Bläddra till den körbara i Utforskaren Lync 2013:
       C:\Program Files\Microsoft Office 15\root\office15
    2. Håll ned SKIFT och högerklicka sedan på Lync.exe.
    3. Klicka på Kör som annan användare.
    4. Ange autentiseringsuppgifterna för ett lokalt administratörskonto på datorn och tryck sedan på RETUR.
MER INFORMATION
Det här problemet uppstår oftast på grund av en felaktig konfiguration i AD FS 2.0. Andra tjänster som Microsoft Exchange Online kan fungera trots denna konfiguration. Troliga orsaker finns här:
  • ServicePrincipalName (SPN) är inte korrekt konfigurerad. Anledningen till detta är följande:
    • Det gick inte att registrera SPN under den inledande konfigurationen av servergruppen.
    • Federationstjänsten namn har ändrats.
    • Kontot har ändrats.
  • AD FS 2.0-tjänsten inte körs under kontot korrekt.
  • Begärans huvud från Lync 2013 har avvisats av IIS och AD FS 2.0-servern eftersom huvudet är för stor. Det här problemet kan uppstå eftersom användarkontot är medlem i för många grupper i AD DS-användare.
  • AD FS 2.0-servergruppen är belastningsutjämnade och begäran inte nå AD FS 2.0-servern.
Mer information om hur du distribuerar AD FS 2.0 för användning med enkel inloggning i Office 365 finns i följande TechNet-webbplats:I fall när användaren är medlem i för många grupper i AD DS, anges följande post i de Microsoft Online Services Sign-In Assistant spårningsloggar (dessa loggar lagras vanligtvis i 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>

Behöver du hjälp? Gå till den Office 365-Community webbplats.

Varning: Den här artikeln har automatöversatts

Egenskaper

Artikel-id: 2839539 – senaste granskning 05/01/2015 17:44:00 – revision: 11.0

Skype for Business Online

  • o365022013 o365 o365e o365a o365m kbgraphxlink kbgraphic kbmt KB2839539 KbMtsv
Feedback