Share via


登入和探索的常見問題

上次修改主題的時間: 2009-07-20

在疑難排解登入問題時,首先要確定的是使用者輸入的資訊是否正確。接著確認使用者帳戶目前作用中且可使用 Office Communications Server。如果問題不是出在使用者資訊,請檢查伺服器端的設定。從伺服器端檢查登入時,首先要確定用戶端連線設定是設為自動設定或手動設定。本節將從使用者和伺服器的觀點,說明一般在登入期間會發生的問題。

不正確的使用者資訊

下列案例將說明和使用者帳戶或使用者登入時所輸入之資訊相關的常見登入問題。

不正確的登入位址

使用者在嘗試登入 Communicator 時可能會看到「無法登入 Communicator」訊息。您所輸入的登入位址、使用者名稱或密碼不正確,或驗證服務與此版本的程式不相容。

常見的是,使用者在登入時所輸入的登入位址,與使用者 Active Directory 內容中指定的 SIP URI 不相符。系統管理員為允許使用者使用 Office Communications Server 而進行啟用作業時,會決定 SIP URI 格式。SIP URL 可以從使用者的電子郵件地址、使用者主要名稱、使用者完整名稱或安全性帳戶管理員 (SAM) 帳戶 (舊版 Windows 作業系統使用的登入名稱) 產生。使用者應該使用正確的 SIP URI 格式再登入一次。

使用者帳戶未啟用 Office Communications Server

如果使用者輸入的 SIP URI 格式正確而登入仍失敗,網路系統管理員應確認已啟用使用者帳戶、已允許使用者使用 Office Communications Server,以及帳戶密碼未過期或未重設。

如需如何啟用使用者帳戶的詳細資訊,請至 Microsoft Office Communications Server 2007 R2 技術文件庫,參閱位於<作業>之<管理 Office Communications Server 2007 R2>中的<管理使用者帳戶>文件 (英文),網址為 https://go.microsoft.com/fwlink/?Linkid=144479

使用者沒有設定檔資料夾的權限

如果個別使用者收到表示伺服器無法使用的錯誤,請開啟 Communicator 的 Windows 事件記錄,並查看 Windows 事件追蹤記錄。記錄中可能會顯示此資訊:在 C:\Documents and Settings\<使用者名稱>\Local Settings\Application Data\Microsoft 中建立 Communicator 資料夾時發生「拒絕存取」錯誤。若要解決此問題,您可授與使用者適當的 Communicator 資料夾權限。

手動設定的登入失敗

透過手動設定進行登入時,登入失敗的原因通常是用戶端 [進階連線設定] 中的伺服器名稱不正確。在用戶端的事件檢視器中,您可能會看到「Communicator 因為錯誤 10061 而無法連線至伺服器 192.168.0.2 (192.168.0.2) 的連接埠 5060」,其中指出用戶端無法連線之伺服器的 IP 位址。或者,會提到伺服器呈現的伺服器不符合正確的主機名稱。通常造成這些錯誤的原因是使用者在用戶端 [進階連線設定] 對話方塊中輸入的是伺服器 IP 位址。

應該在 [進階連線設定] 對話方塊中輸入伺服器 FQDN,而不是伺服器 IP 位址或 NetBIOS 名稱。

在採用手動設定進行連線設定時,必須知道用戶端和 Office Communications Server 間的連線是否需要 TLS。如果需要 TLS,必須在 [進階連線設定] 中選取 TLS 選項,且必須指定伺服器 FQDN (而不是伺服器 IP 位址或 NetBIOS 名稱),如此伺服器名稱才能符合所使用的憑證。

如果對伺服器的連線要使用 TCP,請確認 Office Communications Server 集區內容中已設定 TCP 聆聽連接埠 5060。

自動設定的登入失敗

使用自動設定,可能會發生 DNS 設定、憑證或伺服器名稱方面的問題。

DNS 設定

如果使用自動設定,請確認發行至 DNS 的伺服器名稱受伺服器憑證支援。如需有關建立 DNS 記錄以允許探索用戶端和伺服器,和支援用戶端自動登入 (如果組織要求支援的話) 此方面的詳細資訊,請參閱 Microsoft Office Communications Server 2007 R2 文件<網域名稱系統 (DNS) 需求>(英文),網址為 https://go.microsoft.com/fwlink/?linkid=146936

若用戶端已設定要進行自動登入,請確認已準備適當的 DNS SRV 記錄。若使用 TLS 連線,請加入下列 SRV 記錄,並將其對應至伺服器的主機記錄:

_sipinternaltls._tcp.<網域> (透過連接埠 5061)。

Dd637123.note(zh-tw,office.13).gif附註:
如果 SIP 網域和 Office Communications Server 網域不同,我們建議您建立主機記錄 sip.<網域>,而不是 Office Communications Server 主機記錄。

若使用 TCP 連線,請加入下列 SRV 記錄,並將其對應至伺服器的主機記錄:

_sipinternal._tcp.<網域> (透過連接埠 5060)

檢查嚴格名稱

如果用戶端使用自動設定進行登入且要求 TLS,EnableStrictDNSNaming 原則設定有時會導致連線失敗。當 Communicator 設定要進行自動 TLS 連線,此原則能讓 Office Communicator 在使用 SIP 通訊服務時,安全地傳送和接收立即訊息。此原則不會影響 Windows .NET 或 Microsoft Exchange Server 服務。許多對 EnableStrictDNSNaming 原則的誤解大多是因為對此原則的說明不夠清楚所致。若此原則的設定不正確,會導致在 TLS 交涉和用戶端登入期間發生未預期的問題。對此原則的正確說明如下:

如果您將 EnableStrictDNSNaming 原則設為 [啟用],只有在伺服器名稱符合使用者的 SIP URI 網域,或伺服器 FQDN 為 sip.<URI 網域> 時,Communicator 用戶端才能連線至伺服器。例如,如果使用者的 SIP URI 為 someone@contoso.com,Communicator 只能連線至下列伺服器:

  • contoso.com
  • sip.contoso.com

如果您沒有設定此原則,或是將其設為 [停用],Communicator 用戶端可以連線到任何其 FQDN 結尾為使用者 SIP URI 網域的 SIP 伺服器。例如,Communicator 可與名稱為 sip.division.contoso.com 或 lc.contoso.com 的伺服器通訊。缺點是攻擊者可使用偽造的伺服器名稱 (如 attacker.contoso.com),來回應用戶端發出的初始 DNS 查詢。不設定或停用此原則,會提高您受到攔截式 (man-in-the-middle) 攻擊的機率。

停用此原則的原因可能是組織具有多個子網域,或在建立憑證時需要允許非嚴格伺服器名稱的彈性。

若要啟用此原則,請確認 SIP 伺服器的 FQDN 符合下列其中一個嚴格名稱格式。

Dd637123.note(zh-tw,office.13).gif附註:
您可在「電腦設定」和「使用者設定」中設定此原則設定,但系統會優先使用「電腦設定」中的原則設定。

外部使用者無法登入

如果內部使用者可登入但外部使用者卻不行,則可能是驗證通訊協定的設定不正確、登入時所指定的連接埠不正確,或是伺服器端的加密設定有問題。

將驗證通訊協定設為 NTLM 和 Kerberos

Office Communications Server 2007 R2 根據使用者所在位置使用 Kerberos 或 NTLM 驗證通訊協定。Kerberos 通訊協定需要用戶端連線至 Active Directory,其適用對象為具有 Active Directory 認證的內部使用者。具有 Active Directory 認證且從企業防火牆外連線進來的外部使用者則使用 NTLM。

如果外部使用者無法加以驗證,請確認 Office Communications Server 前端伺服器內容中的驗證通訊協定設為 [NTLM 及 Kerberos]

用戶端手動登入連接埠 5061,Access Edge Server 在連接埠 443 聆聽

從企業防火牆外連線進來的用戶端會使用連接埠 443 和 Edge Server 進行 SIP 通訊。有時用戶端設定成要使用手動設定來連線至伺服器,但外部伺服器的連接埠設定不正確。例如,用戶端透過手動設定要連線至伺服器的連接埠 5061,而 Access Edge Server 卻在連接埠 443 聆聽,則連線會失敗。檢查用戶端 [外部伺服器名稱或 IP 位址] 底下的 [進階連線設定],確認入口是指定為連接埠 443,如 sip.domain.com:443。

如果您使用群組原則指定外部伺服器名稱,同樣也是指定連接埠 443。

NTLMMINCLIENTSEC 和 NTLMMINSERVERSEC 不相符

組織可能使用本機原則和群組原則,在 Windows Server 網域中設定特定的安全性設定,以協助增加網路的安全性。NTLMv2 驗證設定即是其中的一種,其可設定成要求伺服器和用戶端間的連線要加密。如果用戶端的設定和伺服器端的設定不相符,將無法進行通訊。

NTLMv2 驗證設定位於下列登錄:

HKey_Local_Machine\System\CurrentControlSet\Control\Lsa\MSV1_0ntlmminclientsec

HKey_Local_Machine\System\CurrentControlSet\Control\Lsa\MSV1_ ntlmminserversec

有時伺服器的設定是要求加密,而用戶端則沒有。在此情況下,前端伺服器不會傳遞用戶端的 NTLM 要求。主要會受到此情況影響的是外部使用者,因為 NTLM 是外部使用者唯一可用來登入的驗證通訊協定。例如,如果伺服器金鑰值設為 0x20080030,其指定 128 位元加密,而用戶端未設定,則用戶端將無法登入。您應確認此金鑰在用戶端的設定符合伺服器的設定。

如需詳細資訊,請參閱 Microsoft 知識庫文件 823659<修改安全性設定和使用者權限指派可能會導致的用戶端、服務和程式不相容問題>(英文),網址為 https://go.microsoft.com/fwlink/?linkid=147230