非活動 IIS 應用程式集區因快取認證導致服務帳戶遭鎖定

XieJie 60 信譽點數
2026-10-06T08:46:45.9366667+00:00

生產環境中的網域服務帳戶因非活動 IIS 應用程式集區仍保留舊的快取認證,導致帳戶反覆遭到鎖定。請問要如何追蹤並確認這些錯誤密碼驗證嘗試的來源,以找出持續觸發帳戶鎖定的 IIS 應用程式集區或服務?

Windows 商務版 | Windows 365 企業版
0 則留言 沒有留言

2 個回答

排序依據: 最新
  1. Jason Nguyen Tran 29,785 信譽點數 獨立顧問
    2026-10-13T06:50:33.7766667+00:00

    我想跟進確認一下,您的問題是否已經解決。如果您還需要更多資訊,歡迎隨時回覆。 如果上述資訊對您有所幫助,歡迎點擊 「Accept Answer」,幫助社群中的其他使用者找到解決方案。謝謝!

    此回答有幫助嗎?

    0 則留言 沒有留言

  2. Jason Nguyen Tran 29,785 信譽點數 獨立顧問
    2026-10-06T15:14:11.57+00:00

    您好,

    在 IIS 環境中,服務帳戶反覆遭到鎖定,通常是由應用程式集區(Application Pools)、Windows 服務、排程工作(Scheduled Tasks)或快取的認證所造成。即使服務帳戶已經更新密碼,這些元件仍可能持續使用舊密碼嘗試進行驗證。

    建議先從網域控制站(Domain Controller)的 Security 記錄開始,尋找 Event ID 4740(Account Lockout)。此事件通常可以協助識別觸發帳戶鎖定的工作站或伺服器。確認來源伺服器後,可以進一步檢查相同時間點附近的 Event ID 4625(Failed Logon) 與 Event ID 4776(NTLM Authentication Failure),以判斷是哪個帳戶及程序(Process)持續產生失敗的驗證嘗試。

    在受影響的 IIS 伺服器上,請檢查所有 Application Pools,並確認其設定的 Identity。一個常見情況是,某個 Application Pool 仍使用舊的服務帳戶密碼,即使該網站目前並未使用。除此之外,也建議檢查 Windows Services、Scheduled Tasks、IIS Virtual Directories、應用程式組態檔,以及任何可能仍儲存舊認證的對應網路資源(Mapped Network Resources)。

    如果仍無法明確判斷來源,我也建議啟用 Netlogon Debugging,或使用 Microsoft 提供的 Account Lockout and Management Tools。這些工具可以大幅縮短將驗證失敗事件與實際負責的 Application Pool、Service 或 Process 進行關聯分析所需的時間。

    確認造成問題的元件後,請更新其中儲存的認證資訊,重新啟動(Recycle)受影響的 Application Pool,並持續監控環境,以確認帳戶鎖定事件不再發生。在許多情況下,清理未使用的 Application Pools,以及在適當的情境下將服務帳戶改為使用 gMSA(Group Managed Service Account),也能有效降低未來再次發生類似問題的機率。

    希望以上資訊對您有所幫助。如果您認為這個回答解決了您的問題,請點選 「Accept Answer」,讓我知道這個解決方案對您有所幫助。

    Jason

    此回答有幫助嗎?

    0 則留言 沒有留言

您的回答

答案可由問題作者標示為「已接受」,而由仲裁者標示為「推薦」,這可協助使用者知道答案解決了作者的問題。