Intreprindere single sign-on unic utilizatorii în Office 365 puteți conecta la Lync Online din interiorul rețelei lor corporative

Traduceri articole Traduceri articole
ID articol: 2839539 - View products that this article applies to.
Măriți totul | Reduceți totul

PROBLEMA

Luați în considerare următorul scenariu:
  • Un Microsoft Office 365 pentru întreprinderi, Microsoft Office 365 pentru educa?ie sau Microsoft Office 365 pentru afaceri mărime medie client stabilește sign-on unic (SSO) în serviciile de Federația Active Directory (AD FS) 2.0.
  • Federate utilizatori care se conectează la interiorul lor rețea puteți conecta la Lync Online la Lync 2013, și primesc următorul mesaj de eroare:
    Imposibil de făcut sign in - server temporar indisponibil.
Notă Această problemă se aplică numai pentru utilizatorii Enterprise SSO care conecta la Microsoft Lync Online utilizând Microsoft Lync 2013 din interiorul rețelei lor corporative. Problema nu se aplică utilizatorilor Microsoft Lync 2010, utilizatorii care nu sunt pe Lync Online sau de utilizatori care se conectează la în afara rețelei lor corporative.

SOLUȚIE

Important Urmați pașii din această secțiune cu atenție. Grave probleme ar putea apărea dacă modificați registry incorect. Înainte de a modifica face o copiere de rezervă registry pentru restaurare în cazul în care apar probleme.

Pentru că există mai multe cauze posibile, este mai bine pentru a lucra prin toate următoarele soluții, și apoi verificați configurația.
  1. Când implementați un AD FS 2.0 Federația ferma de fermă de servere, trebuie să specificați un cont de serviciu bazate pe domeniu care are nevoie un SPN înregistrați pentru a activa autentificarea Kerberos să funcționeze corect. Pentru mai multe informații, consultați următoarele TechNet wiki:
    AD FS 2.0: Cum să configurați SPN (NumePrincipalServiciu) pentru contul de serviciu
    Motivele că va trebui să setați manual SPN AD FS 2.0 serviciu cont sunt după cum urmează:
    • SPN înregistrarea nu a reu?it în timpul configurării inițiale a exploatației.
    • Federația serviciu nume a fost schimbat.
    • Contul de serviciu a fost schimbat.
  2. Asigurați-vă că AD FS 2.0 consolidare servicii se execută sub contul de serviciu bazate pe domeniu, care a fost menționat în pasul anterior. De exemplu, în imaginea de mai jos, TRLABV3 este nume de sign-in de gazdă interne și ADFSSvc este contul de serviciu:

    Reduceți imagineaMăriți imaginea
    Ecran shot de AD FS 2.0 Windows Service Properties, arătând în contul bazate pe domeniu

  3. Configura AD FS 2.0 server pentru a accepta cererea anteturile mai mari decât 40 kiloocteți (KO). Va trebui să facă acest lucru, atunci când utilizatorul este un membru al mai multe grupuri de utilizator consolidare servicii de domeniu Active Directory (AD DS). Atunci când un utilizator este un membru al mai multor grupuri AD DS, crește dimensiunea de simbolul de autentificare Kerberos pentru utilizator.

    Cererea HTTP care trimite utilizatorul la serverul Internet Information Services (IIS) conține simbolul Kerberos în antetul WWW-Authenticate. Prin urmare, antet dimensiune crește numărul de grupuri de creșteri. În cazul în care antet HTTP sau pachete mărime crește dincolo de limitele care sunt configurate în IIS, IIS poate respinge cererea și trimite o eroare ca răspuns. Pentru mai multe informații, consultați următorul articol din bază de cunoștințe Microsoft:
    2020943 "HTTP 400 - Bad cerere (solicitare antet prea lung)" eroare în Internet Information Services (IIS)
    Pentru a rezolva această problemă, utilizați una dintre următoarele metode:
    1. Reduce numărul de grupuri de utilizatori AD DS, care utilizatorul este membru.
    2. Schimba MaxFieldLength și valorilor de registry MaxRequestBytes pe serverul care execută IIS astfel încât anteturile de solicitarea utilizatorului nu sunt considerate prea mult marcă de timp. Aceste valori de registry două se află în următoarea subcheie de registry:
      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
  4. Dacă ați desfășurat multiple AD FS 2.0 fermă de servere într-o fermă și să le încărcați echilibrat, client Lync 2013 ar putea orienta cererea de AD FS 2.0 server. Adăugând o intrare pentru AD FS 2.0 server pentru fișierul Hosts pe client că punctele de direct la AD FS 2.0 server va ocoli IP virtuală de echilibrare.
  5. Dacă soluțiile anterioare nu rezolva problema și declasarea Lync 2010 nu este o opțiune, urmați acești pași pentru a remedia problema.

    Notă În cazul în care un cont de local administrator nu există deja pe computer, trebuie să creați unul pentru această soluție să funcționeze.
    1. Navigați 2013 Lync 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 alt utilizator.
    4. Introduceți acreditările pentru un cont de local administrator pe computer, și apoi apăsați Enter.

MAI MULTE INFORMAȚII

Această problemă apare, de obicei din cauza unei misconfiguration în AD FS 2.0. Alte consolidare servicii precum Microsoft Exchange Online să funcționeze corect, în ciuda această configurație. Cauzele obișnuite sunt enumerate aici:
  • NumePrincipalServiciu (SPN) nu este configurat corect. Motivele pentru aceasta include următoarele:
    • SPN înregistrarea nu a reu?it în timpul configurării inițiale a exploatației.
    • Federația serviciu nume a fost schimbat.
    • Contul de serviciu a fost schimbat.
  • AD FS 2.0 serviciu nu se execută în contul serviciu corect.
  • Antetul de cerere la Lync 2013 este respins de IIS și AD FS 2.0 server deoarece antet 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 ferma de fermă de servere este echilibrată de încărcare, și cererea nu este ajungând AD FS 2.0 server.
Pentru mai mult ajutor cu implementarea AD FS 2.0 pentru utilizare cu SSO în Office 365, consultați următoarele site-ul TechNet:
Planificarea și implementarea AD FS pentru utilizare cu sign-on unic
În cazul când utilizatorul este membru al prea multe grupuri AD DS, următoarea intrare este înscris în jurnalele de urmărire Microsoft Online Services Sign-In Asistent (aceste jurnale sunt, de obicei, situat î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>

Încă mai aveți nevoie de ajutor? Du-te la Birou 365 comunitare .

Proprietă?i

ID articol: 2839539 - Ultima examinare: 26 iunie 2014 - Revizie: 10.0
Se aplică la:
  • Microsoft Lync Online
Cuvinte cheie: 
o365022013 o365 o365e o365a o365m kbgraphxlink kbgraphic kbmt KB2839539 KbMtro
Traducere automată
IMPORTANT: Acest articol este tradus cu ajutorul software-ului Microsoft de traducere automată ?i poate fi corectat prin intermediul tehnologiei Community Translation Framework (CTF). Microsoft oferă articole traduse automat, post-editate de comunitate ?i articole traduse de oameni, pentru a permite accesul la toate articolele din Baza noastră de cuno?tin?e în mai multe limbi. Articolele traduse automat ?i post-editate pot con?ine gre?eli de vocabular, sintaxă ?i/sau gramatică. Microsoft nu este responsabil de inexactită?ile, erorile sau daunele cauzate de traducerea gre?ită a con?inutului sau de utilizarea acestuia de către clien?i. Găsi?i mai multe informa?ii despre traducerea în colaborare la http://support.microsoft.com/gp/machine-translation-corrections/ro.
Face?i clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 2839539

Trimite?i feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com