Vista/Windows 7無法登入網站及網路芳鄰

這幾天有同事針對測試主機做了一些測試及調整，陸續發生古怪狀況:

1. 部份機器使用IE連上測試網站時，確認帳號密碼都正確，但IE就是一直彈出帳密對話框，始終無法通過IIS的NT整合式認證(但基本認證可以)。出問題的機器有個共通點: OS都是Windows 7或Windows 2008。至於Windows 2003/Windows XP，則可正常登入該網站。
2. 前述無法登入IIS的機器，也無法使用網路芳鄰連上該IIS Server的分享資料夾。使用net use\\remoteserver\ipc$ /user:domain\user測試，一直彈出帳號密碼不對的訊息。

同事找到一個方法，修改Windows 7/Vista的LmCompatibilityLevel Registry(如下圖)

將其中的3改成1並重新開機，就能解決網芳無法連線及IIS無法連線的問題。

之前沒聽過這個Registry，上網爬文，找到以下關於LAN Manager Authentication Level較詳盡的說明:

• 0 - Send LM & NTLM responses:Level 0 offers the lowest level of security because LM and NTLM are considered obsolete. Clients at this setting never use NTLMv2. Servers at this setting will accept any of the three protocols.
• 1 - Send LM & NLTM - use NTLMv2 session security if negotiated: 
  Level 1 allows the use of LM and NTLMv1, so it does not eliminate the vulnerabilities inherent in those protocols. Servers at this setting will continue to accept any of the three protocols, although clients will now have the ability to step up to NTLMv2 if they're able to and the server they're connecting to asks for it.
• 2 - Send NTLM response only: 
  When level 2 is implemented across a domain, clients begin using NTLMv1 and can use NTLMv2 if the servers on the network support it. Domain controllers will again continue to accept any of the three protocols.
• 3 - Send NTLMv2 response only: 
  At level 3, domain controllers still accept any of the three protocols, but client computers so able will use only NTLMv2, ignoring LM and NTLMv1 traffic. This is the minimum security level acceptable for mixed networks on which some clients absolutely must continue to authenticate although they cannot use NTLMv2 (for example, older operating systems, such as Windows 95/98/Me, old Unix versions, Mac OS X 10.3 and earlier). Communication between servers and those older clients will still be insecure, but communication between servers and current clients (e.g., Windows 2000 or XP, Mac OS X 10.4, new Unix distributions) will be secure.
• 4 - Send NTLMv2 response only\refuse LM: 
  At level 4, clients and domain controllers ignore any LM traffic; clients only attempt to use NTLMv2, while domain controllers will accept NTLMv1.
• 5 - Send NTLMv2 response only\refuse LM & NTLM: 
  Level 5 is the highest setting. Clients and servers all actively reject LM and NTLMv1 traffic, and use only NTLMv2.

用簡單白話來解釋: LM, NTLM(v1), NTLMv2是三種不同的認證機制。LM跟NTLM很古老，安全性較差，有被輕易破解的疑慮，因此Windows Vista起(含Windows 7, Windows 2008/2008R2)預設就只使用較安全的NTLMv2(所以LmCompatibilityLevel預設為3)。

但問題是從NT SP4起，Windows就支援NTLMv2了。一般而言，需要降低到LM/NTLM多半是要配合Mac、UNIX Samba等異質平台；測試機群最古老的OS也在Windows 2000以上，理論上使用NTLMv2絕對不是問題，況且之前使用都正常，是這波調整後才出狀況。因此，雖已有解法，但它減損了系統安全程度，有點資安偏執的我還是決定鍥而不舍捉拿真凶。

在追查過程中，不經意在事件檢視器中發現可疑處 -- 網域伺服器為了配合測試被人調整了日期時間!! 我推測NTLM認證機制中應該有時間戳記註明時效以強化安全性，因此網域才需要嚴密的時間同步機制，當時間不同步時就會導致驗證失敗。如此，先前遇到的怪異現象有了合理解釋 ---

因為IIS與Client時間有差異 -> NTLMv2機制驗證失敗 -> Windows 7限定只使用NTLMv2故無法驗證、Windows XP/2003退而求其次使用LM, NTLM完成驗證

接著測試將一台Windows 7 VM的時間調成與測試網域時間相同，果然即使LmCompatibilityLevel = 3也能通過驗證，印證了我的推論。

【結論】

1. 網域中各主機的時間同步很重要，時間有差異時可能導致身份驗證失敗。
2. 當發生帳號密碼正確，卻一直無法登入時(尤其是Vista, Win7, Win2008)，請檢查是否為時間問題。
3. 若無Mac及Unix Samba等異質平台需求，建議設定LmCompatibilityLevel = 3，降低身份驗證資料被破解的風險。

You can also check this: http://kb.iu.edu/data/atvn.html