IIS將舊用戶名返回給我的應用程序

Question

這是我的場景。我創建了一個使用集成Windows身份驗證的應用程序來工作。在Application_AuthenticateRequest()中，我使用HttpContext.Current.User.Identity來獲取我網站用戶的當前WindowsPrincipal。

現在，這裏是有趣的部分。我們的一些用戶最近結婚了，他們的名字也改變了。 （即用戶的NT登錄從jsmith更改爲jjones），當我的應用程序驗證它們時，IIS將我的舊登錄傳遞給我。我繼續看到jsmith傳遞給我的應用程序，直到我重新啓動我的服務器！註銷客戶端不起作用。重新啓動應用程序池不起作用。只有完全重新啓動。

有人知道這裏發生了什麼嗎？有什麼我可以用來刷新緩存給我這個問題的命令？我的服務器配置有誤嗎？

注意：我絕對不想重新啓動IIS，我的應用程序池或機器。由於這是一個生產箱，這些並不是真正可行的選擇。

---

AVID -

是的，他們的UPN與他們的登錄名一起改變。和Mark/Nick ...這是一個生產企業服務器...它不能只是重新啓動或重新啓動IIS。

---

跟進（爲後人）：

Grhm的回答得很正確。這個問題在低容量的服務器中彈出，在這些服務器中沒有很多人使用你的應用程序，但是有足夠的請求將用戶的身份保存在緩存中。這似乎說明爲什麼緩存項沒有10分鐘後默認刷新KB的關鍵部分是：

緩存條目做超時，但是機會是由應用程序重複 查詢保留現有高速緩存條目活動的最大生存期爲 。

我不完全相信在我們的代碼是什麼原因導致這（重複查詢），但爲我們工作的決議是從1周看似淫穢默認LsaLookupCacheExpireTime值切成短短小時。這對於我們來說，將用戶在現實世界中受到影響的可能性降低到基本爲零，但同時又不會對我們的目錄服務器造成極端數量的SID-Name查找。如果應用程序通過SID查找用戶信息而不是將用戶數據映射到文本登錄名，那麼更好的解決方案是IMO。 （請注意，供應商！如果您在應用程序中依賴於AD身份驗證，則需要將SID置於您的身份驗證數據庫中！）

Answer 1

我最近有類似的問題，正如Robert MacLean的answer中所述，如果您未以用戶身份登錄，AviD的組策略更改不起作用。

我發現改變了LSA查找緩存大小描述是MS KB946358工作，無需重新啓動或回收任何apppool或服務。

我發現這是作爲對這個類似問題的回答：Wrong authentication after changing user's logon name。

Answer 2

重新啓動IIS，而不是整個機器，應該有所斬斷。

Answer 3

當這些用戶的名字發生變化時，您是否只更改其NT登錄名或UPN名？ UPN名稱是專有名稱，由Kerberos使用 - 這是IWA的默認協議;但是，如果您只需在ActiveDirectory中單擊以更改其名稱，則只有NT登錄名更改 - 即使這是他們用來登錄（使用默認窗口GINA）的內容。在封面下，windows會將（新）NT登錄名稱轉換爲（舊）Kerberos名稱。這一直持續到AD被迫根據NT登錄名更新Kerberos名稱...

Answer 4

如果不是隻更改NT用戶名的問題，那麼它似乎認爲服務正在緩存舊用戶名。
您可以將其定義爲禁用，轉到本地安全設置（在管理工具中），根據版本/編輯/配置，可能與內存有關的設置是「要緩存的先前登錄次數」，以及「不允許存儲憑據...」。

其他因素來考慮：

• 域成員身份可能會影響這一點，因爲成員服務器可以繼承域設置
• 您可能還需要重新啓動整個服務器一次，這纔會影響（但那麼你將不必擔心未來的更新）。
• 登錄性能可能會受到影響。

因此，我建議您在部署生產（當然）之前先測試一下。

Answer 5

確定的AviD問題是Active Directory緩存，您可以通過registry進行控制。取決於您的解決方案Avid的組策略選項將失敗或工作，具體取決於您是否實際登錄用戶。

它如何被緩存取決於你如何在IIS上進行身份驗證。我懷疑它可能是Kerberos所以要做清除，如果它是由Kerberos造成的，你可能想嘗試使用清除選項klist，它應該清除kerberos票據，這將在下一次嘗試中強制AD到下一次嘗試並更新詳細信息。

我也建議看看實施this這是稍微複雜一些，但不太容易出錯。

Answer 6

我知道我們在過去的IIS中也存在緩存的憑據問題，在谷歌搜索幾天後，我們遇到了一個晦澀難懂的（至少對我們來說）命令，您可以使用它來查看和清除緩存的憑據。

開始 - >運行（或WINKEY + R）和類型控制keymgr.dll

這個固定我們的客戶機的問題。沒有在服務器上嘗試過，但如果它的服務器緩存憑證可能值得一試。我們的問題是我們獲得了舊的憑據，但僅在客戶端機器的基礎上。如果用戶在一臺單獨的客戶端機器上登錄，一切都很好，但如果他們在辦公桌上使用自己的機器，他們通常會使用它，並擁有緩存的舊憑證。

Answer 7

使用相關新登錄名登錄到運行IIS的服務器。這將刷新憑證而不重新啓動IIS或重新啓動服務器。

Answer 8

此鏈接"Changing the Default Interval for User Tokens in IIS"來自MicroSoft支持 應該有所幫助。

Answer 9

就像一個供參考我們有完全相同的問題。看起來對我們有用的是進入Active Directory並執行「刷新」。緊接着，我們不得不回收有此問題的Intranet網站上的應用程序池。