分析:

發生問題的 Server name 為 Proxy, 所以正確註冊的Server Name 為 HOST/proxy.domain.com.

如果有其他電腦註冊此 HOST/proxy.domain.com 就會出現此錯誤 Kerberos Event ID: 11

解決 Kerberos Event 11 Duplicate SPN做法如下:

使用  ldifde 撈出網域中所有SPN 來比對

1.開啟 Dos command執行以下指令:

ldifde -f spn.txt -d "dc=domain,dc=com"  -r "serviceprincipalname=host/proxy*"

2.執行後, 請檢視 spn.txt .

dn: CN=ServerA,CN=Computers,DC=domain,DC=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: computer
cn: ServerA
distinguishedName: CN=ServerA,CN=Computers,DC=domain,DC=com
instanceType: 4
whenCreated: 20120207052445.0Z
whenChanged: 20120221091504.0Z
uSNCreated: 310137326
uSNChanged: 310786524
name: ServerA
objectGUID:: urgwg8lua0OqP5xTKUEH4w==
userAccountControl: 69632
pwdLastSet: 129742892969622361
primaryGroupID: 515
objectSid:: AQUAAAAAAAUVAAAAU7kUoC2TmURv0MGOgTEAAA==
sAMAccountName: ServerA$
sAMAccountType: 805306369
dNSHostName: proxy.domain.com
servicePrincipalName: HOST/proxy.domain.com
servicePrincipalName: HOST/ServerA
objectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=domain,DC=com
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 129739717790891547

DC端 Event Log:

DC1:
02/20/2012 09:06:19 AM  錯誤 DC1.domain.co 11  Microsoft-Windows-Kerberos-Key-D N/A N/A 處理 Kerberos 驗證要求時，KDC 遇到重複的名稱。重複的名稱是 host/proxy.domain.com(類型為 DS_SERVICE_PRINCIPAL_NAME)。這可能造成驗證錯誤或降級到 NTLM。為避免發生這個狀況，請移除在 Active Directory 中 host/proxy.domain.com的重複項目。

DC2:
02/20/2012 10:01:43 AM  錯誤 DC2.domain.co 11  Microsoft-Windows-Kerberos-Key-D N/A N/A 處理 Kerberos 驗證要求時，KDC 遇到重複的名稱。重複的名稱是 host/proxy.domain.com(類型為 DS_SERVICE_PRINCIPAL_NAME)。這可能造成驗證錯誤或降級到 NTLM。為避免發生這個狀況，請移除在 Active Directory 中 host/proxy.domain.com的重複項目。

DC3:
02/21/2012 08:06:20 AM  錯誤 DC3.domain.co 11 Microsoft-Windows-Kerberos-Key-D N/A N/A 處理 Kerberos 驗證要求時，KDC 遇到重複的名稱。重複的名稱是 host/proxy.domain.com(類型為 DS_SERVICE_PRINCIPAL_NAME)。這可能造成驗證錯誤或降級到 NTLM。為避免發生這個狀況，請移除在 Active Directory 中 host/proxy.domain.com的重複項目。

1. 自2003 SP1起, 我們提供了一個與NTLM認證相關的新機制:

如果使用者通過NTLM認證方式與DC之間建立session, 並且在這個session中修改了密碼;

那麼當使用者再次通過網路驗證的方式提供舊密碼並且訪問資源時, 舊密碼仍然可用;

具體可以參考: http://support.microsoft.com/kb/906305/en-us

關於NTLM與網路認證的相關資料:

1) NTLM認證的相關資料:

http://msdn.microsoft.com/en-us/library/aa378749(v=vs.85).aspx

http://technet.microsoft.com/en-us/library/cc783005(WS.10).aspx

NTLM與Keberos屬於兩種不同的協定, 與Logon方式無關;

2) 關於網路驗證方式:

KB 906305中涉及到的”網路驗證 - network authentications”, 這裡指的是”不通過Console視窗方式, 為Network Logon”;

比如, 我們最常見的, 在Console視窗通過鍵盤輸入密碼之後Logon到機器上, 屬於”互動式”(Interactive)的Logon;

而通過網路的方式, 遠端的訪問某些資源, 比如訪問共用資料夾, 就屬於網路訪問; OWA屬於網路訪問.

2. 預設情況下, 舊密碼的有效期為60分鐘;

我們可以通過以下鍵值來控制該時間的長度. 在所有DC上修改以下註冊表鍵值:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Name: OldPasswordAllowedPeriod

Type:   DWord

Value: (in minutes)

3. 設計這一機制的原因:

考慮到有些環境中的網路條件不夠理想, 修改之後的密碼不一定能夠立刻複製到所有DC上;

因此我們設計了這一機制, 以降低複製延遲對驗證的影響;

4. 關於緩存(Cache):

如果我們在密碼群組策略中啟用了”Enforce Password History”, 那麼在DC上, 會生成一個用於保存歷史密碼的緩存;

如果我們在Default Domain Controller上啟用該策略, 那麼所有DC上都會有該緩存, 這個緩存會用來保存舊的密碼;

這一機制的目的是比較使用者的新密碼與舊密碼的相似程度,  防止用戶長期使用一些相似的密碼;

5. 您可以在測試環境進行以下測試:

停止DC上的Kerberos Key Distribution Center, 這將導致Keberos驗證不再可用; 如果環境中只有一台DC, 那麼用戶端訪問這台DC時將使用NTLM驗證;

順利登陸後, 修改密碼;

然後從用戶端進行網路訪問, 比如通過IP位址訪問DC的共用資料夾: \\192.168.1.1\sysvol

如果網路正常, 那麼會出現彈窗, 輸入舊密碼, 確認是否能夠訪問;

我們的環境中進行了上述測試, 可以訪問, 說明舊密碼在這種網路訪問的情況下仍然可用. 測試結果符合KB 906305的描述.

6. 除了KB 906305中的描述以外, 密碼修改的複製延遲也會導致舊密碼登錄成功;

如果用戶端登錄時聯繫了某些DC, 而這些DC沒有接收到新的密碼, 那麼舊密碼也可以成功登陸;

我們可以在DC上運行以下命令, 檢查密碼的修改情況:

repadmin /showobjmeta <DC Name> <User Distinguished Name> > meta.txt & meta.txt

可以通過pwdlastSet鍵值的上次修改時間來確定這台DC上的密碼修改時間;

然後, 我們可以檢查DC之間的複製, 以確認新密碼是否已經同步到所有DC上;

問題徽狀：

您已經安裝了防毒軟體，並且正常執行，但是Windows 7行動作業中心判斷仍未安裝

您已經安裝了防毒軟體，並且正常執行，但是Windows 7行動作業中心判斷防毒軟體已關閉

解決方法：

如果您有以上的徵狀，請嘗試安裝以下的修正程式確認這個問題是否能被解決

The system health report does not detect installed antivirus applications in Windows 7

http://support.microsoft.com/kb/2482947

問題描述︰

gpupdate /force 處理電腦原則時發生下列警告:

Windows 無法套用 Group Policy Files 設定。Group Policy Files 設定可能有自己的記錄檔。請按一下 [其他資訊] 連結。

Windows 無法套用 Group Policy Registry 設定。Group Policy Registry 設定可能有自己的記錄檔。請按一下 [其他資訊] 連結。

Windows 無法套用 IP Security 設定。IP Security 設定可能有自己的記錄檔。請按一下 [其他資訊] 連結。

Windows 無法記錄群組原則無法延伸 <IP Security> 的原則結果組 (RSoP) 資訊。群組原則設定已成功套用至電腦或使用者，但是管理工具無法正確報告。

Windows 無法套用 Group Policy Power Options 設定。Group Policy Power Options 設定可能有自己的記錄檔。請按一下 [其他資訊]連結。

解決方法︰

1.請找到根目錄下\users\All Users\Microsoft\Group Policy\History\<GUID>\Preferences

2.請備份

備份後請瀏覽這些目錄下最底層的xml檔案

請刪除後再執行GPupdate /force重新下載

參考

正在執行 Windows 7 或 Windows Server 2008 R2 的電腦上的某些群組原則喜好設定沒有順利套用

http://support.microsoft.com/kb/979731

問題描述︰

DNS Event 4000 4013

經research與DC自己的security channel有關，電腦帳號密碼與AD上的不mach

經使用指令netdom resetpwd /server： Replication_Partner_Server_Name /userd： domainname \ administrator_id /passwordd: *

Replication_Partner_Server_Name:使用自己的電腦名稱

其他參考資料：

如何在網域控制站降級失敗後，移除 Active Directory 中的資料

http://support.microsoft.com/kb/216498/zh-tw

使用 Ntdsutil.exe 抓取或傳輸 FSMO 角色到網域控制站

http://support.microsoft.com/kb/255504/zh-tw