Enterprise sign-on unic utilizatorii din Office 365 nu pot face sign in la Skype pentru afaceri online din interiorul rețelei lor corporative

Problemă

Luați în considerare următorul scenariu:

• Un Office 365 pentru întreprinderi, Office 365 pentru educație, sau Office 365 Business client stabilește sign-on unic (SSO) în consolidare servicii de Federația Active Directory (AD FS) 2,0.

• Federated utilizatorii care se conectează din interiorul lor corporative rețea nu se poate conecta la Skype pentru afaceri online (formerly Lync online) la Lync 2013, și primesc următorul mesaj de eroare:

  Imposibil de făcut sign in deoarece serverul este indisponibil temporar.

Notă Această problemă se aplică numai pentru utilizatorii Enterprise SSO care se conectează la Skype pentru afaceri online utilizând Lync 2013 din interiorul rețelei lor corporative. Problema nu se aplică utilizatorilor Microsoft Lync 2010, utilizatorii care nu sunt pe Skype pentru afaceri online sau utilizatorii care se conectează din afara rețelei lor corporative.

Soluţie

Importante Urmați pașii din această secțiune cu atenție. Probleme grave ar putea apărea dacă modificați registry incorect. Înainte de a modifica, spate sus registru pentru restaurare în cazul în care apar probleme. Deoarece există multe cauze posibile, cel mai bine este să lucrați prin toate soluțiile următoare și apoi să Verificați configurația.

1. Când implementați o fermă AD FS 2,0 Federation server, trebuie să specificați un cont de serviciu bazat pe domeniu care are nevoie de un SPN înregistrat pentru a permite autentificarea Kerberos să funcționeze corect. Pentru mai multe informații, consultați următorul wiki TechNet:

   AD FS 2,0: se configurează SPN (servicePrincipalName) pentru contul de serviciuMotivele pentru care poate fi nevoie să setați SPN manual pe contul de serviciu AD FS 2,0 sunt după urmează:

   • Înregistrarea SPN nu a reușit în timpul configurării inițiale a fermei.

   • Numele serviciului federalizare s-a modificat.

   • Contul de serviciu s-a modificat.

2. Asigurați-vă că serviciul AD FS 2,0 se execută sub contul de serviciu bazat pe domeniu care a fost menționat în pasul anterior. De exemplu, în imaginea următoare, TRLABV3 este nume de sign-in de gazdă internă, și ADFSSvc este contul de serviciu:

3. Configurați AD FS 2,0 Server pentru a accepta solicitarea anteturi care sunt mai mari decât 40 kiloocteți (KO). Este posibil să trebuiască să faceți acest lucru atunci când utilizatorul este membru al multor grupuri de utilizatori Active Directory Domain Services (AD DS). Când un utilizator este membru al multor grupuri AD DS, dimensiunea simbolului de autentificare Kerberos pentru utilizatorul crește. Solicitarea HTTP care utilizatorul trimite la serverul Internet Information Services (IIS) conține simbolul Kerberos în antetul WWW-Authenticate. De aceea, dimensiunea antet crește ca numărul de grupuri crește. Dacă antetul HTTP sau dimensiunea pachetului crește dincolo de limitele care sunt configurate în IIS, IIS poate respinge solicitarea și trimite o eroare ca răspuns. Pentru mai multe informații, consultați următorul articol din baza de cunoștințe Microsoft:

   2020943 "http 400-Bad Request (cerere antet prea lung)" eroare în Internet Information Services (IIS)Pentru a evita această problemă, utilizați una dintre metodele următoare:

   1. Reduceți numărul de grupuri de utilizatori AD DS de care utilizatorul este membru.

   2. Modificați MaxFieldLength și valorile de registry MaxRequestBytes pe serverul care execută IIS, astfel încât utilizatorul ' s cerere anteturi nu sunt considerate prea lung. Aceste două valori de registry se află sub următoarea subcheie de registry:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

4. Dacă ați implementat mai multe servere AD FS 2,0 într-o fermă și să le încărcați echilibrat, clientul Lync 2013 poate fi incapabil să direcționeze solicitarea la serverul AD FS 2,0. Adăugarea unei intrări pentru serverul AD FS 2,0 la fișierul Hosts pe client care indică direct la serverul AD FS 2,0 va ocoli IP virtual al balancer de încărcare.

5. Dacă soluțiile anterioare nu rezolvă problema și declasarea Lync 2010 nu este o opțiune, urmați acești pași pentru a rezolva problema. Notă Dacă un cont de administrator local nu există deja pe computer, va trebui să creați unul pentru ca această soluție să funcționeze.

   1. Răsfoiți la Lync 2013 executabil în Windows Explorer:

       C:\Program Files\Microsoft Office 15\root\office15 

   2. Țineți apăsată tasta Shift și apoi faceți clic dreapta pe Lync. exe.

   3. Faceți clic pe Executare ca utilizator diferit.

   4. Introduceți acreditările pentru un cont de administrator local pe computer, apoi apăsați Enter.

MAI MULTE INFORMAȚII

Această problemă se produce de obicei din cauza unei misconfiguration în AD FS 2,0. Alte consolidare servicii, ar fi Microsoft Exchange Online poate funcționa corect în ciuda acestei configurații. Cauzele obișnuite sunt listate aici:

• ServicePrincipalName (SPN) nu este configurat corect. Motivele pentru aceasta includ următoarele:

  • Înregistrarea SPN nu a reușit în timpul configurării inițiale a fermei.

  • Numele serviciului federalizare s-a modificat.

  • Contul de serviciu s-a modificat.

• Serviciul AD FS 2,0 nu se execută sub contul de serviciu corect.

• Antetul solicitării de la Lync 2013 este respinsă de IIS și AD FS 2,0 Server, deoarece antetul este prea mare. Această problemă poate apărea deoarece contul de utilizator este un membru al prea multe grupuri de utilizatori AD DS.

• AD FS 2,0 fermă de servere este de încărcare echilibrată și solicitarea nu ajunge la serverul AD FS 2,0.

Pentru mai mult ajutor cu implementarea AD FS 2,0 pentru utilizarea cu SSO în Office 365, consultați următorul site web TechNet:

Planificarea și implementarea AD FS pentru utilizare cu sign-on unicÎn cazul în care utilizatorul este un membru al prea multe grupuri AD DS, următoarea intrare este introdusă în jurnalele de sign-in Microsoft Online Services asistent de urmărire (aceste jurnale sunt de obicei amplasate în 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> 

Mai ai nevoie de ajutor? Accesați comunitatea Microsoft.