企業單一登入使用者在 Office 365 無法登入 Skype 從線上商務的公司網路內

問題

請試想下列情況:

  • 對於 Office 365 教育或 Office 365 商業客戶的企業,Office 365 設定單一登入 (SSO) 在 Active Directory 聯盟服務 (AD FS) 2.0。

  • 從連線公司網路內的聯盟的使用者無法登入 Skype 商務線上 (先前 Lync 線上) 從 Lync 2013,並且收到下列錯誤訊息:

    無法登入,因為伺服器暫時無法使用。

附註這個問題只能套用至企業 SSO,使用者登入 Skype 線上商務的公司網路內使用從 Lync 2013。Microsoft Lync 2010,都不在線上商務的 Skype 的使用者或連線從他們的公司網路外部的使用者上的使用者不能問題。

方案

重要 仔細遵循本章節中的步驟。如果您不當修改登錄,可能會發生嚴重的問題。之前您修改後,還原登錄備份,萬一發生問題。由於有許多可能的原因,最好在逐步使用所有下列的解決方案,並確認組態。

  1. 當您部署 AD FS 2.0 同盟伺服器伺服陣列中,您必須指定網域為基礎的服務帳戶需要已註冊的 SPN,若要啟用 Kerberos 驗證,才能正確運作。如需詳細資訊,請參閱下列的 TechNet wiki:

    AD FS 2.0: 如何設定服務帳戶的 SPN (servicePrincipalName)您可能必須手動設定 SPN,AD FS 2.0 的服務帳戶的原因如下所示:

    • SPN 註冊失敗期間的陣列初始設定。

    • 聯盟服務名稱已變更。

    • 已變更服務帳戶。

  2. 請確定 AD FS 2.0 服務在前一個步驟所述的網域為基礎的服務帳戶下執行。例如,在下列影像中,TRLABV3 是內部主機名稱,而 ADFSSvc 是服務帳戶:alternate text

  3. 設定 AD FS 2.0 的伺服器,無法接受大於 40 位元組 (KB) 的要求標頭。您可能必須執行這項操作,使用者若是許多 Active Directory 網域服務 (AD DS) 使用者群組的成員。許多的 AD DS 群組的成員使用者時,會增加使用者的 Kerberos 驗證語彙基元的大小。使用者傳送至網際網路資訊服務 (IIS) 伺服器的 HTTP 要求會包含在 WWW 驗證標頭中的 Kerberos 語彙基元。因此,標頭大小會隨著群組增加的數目。如果 HTTP 標頭或封包大小增加超過在 IIS 中設定的限制,IIS 就可能會拒絕的要求,並為回應傳送錯誤。如果您需要更多資訊,請參閱下列微軟知識庫文件:

    2020943 「 HTTP 400-錯誤的要求 (太長的要求標頭) 」 網際網路資訊服務 (IIS) 」 中的錯誤若要解決這個問題,請使用下列其中一個方法:

    1. 減少 AD DS 使用者群組的使用者所屬的成員的數目。

    2. 變更 MaxFieldLength 和 MaxRequestBytes 登錄值,以便使用者的要求標頭被視為不太長,執行 IIS 的伺服器上。這些兩個登錄值位於下列登錄子機碼下:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

  4. 如果您已經部署多個 AD FS 2.0 伺服器伺服陣列中的,並讓它們載入平衡、 Lync 2013 用戶端可能無法將要求導向到 AD FS 2.0 伺服器。加入項目為 AD FS 2.0 伺服器用戶端直接指向 AD FS 2.0 的伺服器上的 Hosts 檔案將會略過負載平衡器的虛擬 IP。

  5. 如果先前的解決方案沒有解決問題,降級到 Lync 2010 不可行,請依照下列步驟執行,以暫時解決這個問題。附註如果本機系統管理員帳戶不存在電腦上,您必須建立另一個則用於此方案才能運作。

    1. 瀏覽至可執行檔,在 Windows 檔案總管的 Lync 2013:

       C:\Program Files\Microsoft Office 15\root\office15 
    2. 按住 Shift 鍵,並用滑鼠右鍵按一下 Lync.exe。

    3. 按一下 [以不同的使用者身分執行]。

    4. 在電腦上,輸入本機系統管理員帳戶的認證,然後按 Enter 鍵。

其他相關資訊

這個問題通常起因於 AD FS 2.0 中有錯誤設定。儘管這種組態中,其他的服務,例如 Microsoft Exchange Online 可能正常運作。此處列出的一般原因:

  • ServicePrincipalName (SPN) 未正確設定。這樣做的原因包括下列各項:

    • SPN 註冊失敗期間的陣列初始設定。

    • 聯盟服務名稱已變更。

    • 已變更服務帳戶。

  • AD FS 2.0 服務不在正確的服務帳戶下執行。

  • 要求標頭,從 Lync 2013 是拒絕 IIS 和 AD FS 所 2.0 的伺服器因為標頭太大。因為使用者帳戶是太多的 AD DS 使用者群組的成員,就會發生這個問題。

  • AD FS 2.0 的伺服器陣列是負載平衡,並要求無法到達的 AD FS 2.0 伺服器。

如需有關部署 AD FS 2.0 使用與在辦公室 365 的 SSO,請參閱下列的 TechNet 網站:

規劃、 部署 AD FS,使用於單一登入在的情況下太多的 AD DS 群組的成員使用者時下列項目隨即匯入 Microsoft 線上服務登入小幫手] 的追蹤記錄檔 (這些記錄檔通常位於 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> 

是否仍需要協助? 前往 Microsoft Community

Need more help?

Expand your skills
Explore Training
Get new features first
Join Microsoft Insiders

Was this information helpful?

Thank you for your feedback!

Thank you for your feedback! It sounds like it might be helpful to connect you to one of our Office support agents.

×