iT邦幫忙

1

WIN SERVER 出現錯誤LOG

  • 分享至 

  • xImage

您好:
近期沒有改到任何設定
只有
目前
FILE SERVER2019 ,11/17 更新 KB5070883
11/18更新 KB890830 惡意軟體移除工具
AD 2012R2 11/18更新 KB890830 惡意軟體移除工具

PC 11.24 裝
2025-11 適用於 x64 系統 Windows 11, version 25H2 的累積更新 (KB5068861) (26200.7171)

但11.27 之後,PC登入網域,
AD SERVER都會出現錯誤LOG,但可以正常登錄
FILE SERVeR 可以存取,但也會出現 錯誤LOG

查gemini,說有可能是 更新的問題
請問前輩們是否有遇過

主旨:
	安全性識別碼:		XX\A01$
	帳戶名稱:		A01$
	帳戶網域:		
	登入識別碼:		0xE9715276

物件:
	物件伺服器:		DS
	物件類型:		group
	物件名稱:		
	控制代碼識別碼:		0x0

操作:
	操作類型:		Object Access
	存取:		控制存取
				
	存取遮罩:		0x100

FILE FERVER

已檢查網路共用物件,查看是否可授與用戶端想要的存取權。
	
主體:
	安全性識別碼:		XX\A09
	帳戶名稱:		A09
	帳戶網域:		XX
	登入識別碼:		0x2102D214

網路資訊:	
	物件類型:		File
	來源位址:		192.168.XX.XX
	來源連接埠:		2668
	
共用資訊:
	共用名稱:		
	共用路徑:		
	相對目標名稱:	099.tmp

存取要求資訊:
	存取遮罩:		0x17019F
	存取:		DELETE
				READ_CONTROL
				WRITE_DAC
				SYNCHRONIZE
				ReadData (或 ListDirectory)
				WriteData (或 AddFile)
				AppendData (或 AddSubdirectory 或 CreatePipeInstance)
				ReadEA
				WriteEA
				ReadAttributes
				WriteAttributes
				
存取檢查結果:
	DELETE:	授與者	D:(A;;0x1301bf;;;WD)
				READ_CONTROL:	授與者	D:(A;;0x1301bf;;;WD)
				WRITE_DAC:	未授與
				SYNCHRONIZE:	授與者	D:(A;;0x1301bf;;;WD)
				ReadData (或 ListDirectory):	授與者	D:(A;;0x1301bf;;;WD)
				WriteData (或 AddFile):	授與者	D:(A;;0x1301bf;;;WD)
				AppendData (或 AddSubdirectory 或 CreatePipeInstance):	授與者	D:(A;;0x1301bf;;;WD)
				ReadEA:	授與者	D:(A;;0x1301bf;;;WD)
				WriteEA:	授與者	D:(A;;0x1301bf;;;WD)
				ReadAttributes:	授與者	D:(A;;0x1301bf;;;WD)
				WriteAttributes:	授與者	D:(A;;0x1301bf;;;WD)
				

謝謝

補充DETAIL
AD 上

- System 

  - Provider 

   [ Name]  Microsoft-Windows-Security-Auditing 
   [ Guid]  {54849625-5478-4994-A5BA-3E3B0328C30D} 
 
   EventID 4662 
 
   Version 0 
 
   Level 0 
 
   Task 14080 
 
   Opcode 0 
 
   Keywords 0x8010000000000000 
 
  - TimeCreated 

   [ SystemTime]  2025-12-03T07:36:29.193400200Z 
 
   EventRecordID 302400967 
 
   Correlation 
 
  - Execution 

   [ ProcessID]  692 
   [ ThreadID]  844 
 
   Channel Security 
 
   Computer AA.DO1.com.tw 
 
   Security 
 

- EventData 

  SubjectUserSid S-1-5-21-1409082233-2000478354-725345543-16672 
  SubjectUserName USERA$ 
  SubjectDomainName DO1 
  SubjectLogonId 0xf9938337 
  ObjectServer DS 
  ObjectType %{bf967a9c-0de6-11d0-a285-00aa003049e2} 
  ObjectName %{6e211015-e1b1-45b2-92c1-1f1c2fe30695} 
  OperationType Object Access 
  HandleId 0x0 
  AccessList %%7688  
  AccessMask 0x100 
  Properties --- {771727b1-31b8-4cdf-ae62-4fe39fadf89e} {612cb747-c0e8-4f92-9221-fdd5f15b550d} {bf967a9c-0de6-11d0-a285-00aa003049e2}  
  AdditionalInfo - 
  AdditionalInfo2  

FILER SERVER

- System 

  - Provider 

   [ Name]  Microsoft-Windows-Security-Auditing 
   [ Guid]  {54849625-5478-4994-a5ba-3e3b0328c30d} 
 
   EventID 5145 
 
   Version 0 
 
   Level 0 
 
   Task 12811 
 
   Opcode 0 
 
   Keywords 0x8010000000000000 
 
  - TimeCreated 

   [ SystemTime]  2025-12-03T07:40:09.534166800Z 
 
   EventRecordID 4566245 
 
   Correlation 
 
  - Execution 

   [ ProcessID]  4 
   [ ThreadID]  8452 
 
   Channel Security 
 
   Computer SERV.DO1.com.tw 
 
   Security 
 

- EventData 

  SubjectUserSid S-1-5-21-1409082233-2000478354-725345543-16650 
  SubjectUserName FS470 
  SubjectDomainName DO1 
  SubjectLogonId 0x315e418f 
  ObjectType File 
  IpAddress 192.168.20.10 
  IpPort 3913 
  ShareName \\*\FIS 
  ShareLocalPath \??\F:\FIS 
  RelativeTargetName   .....\EA5ACD76.xlsx
  AccessMask 0x1f019f 
  AccessList 
  AccessReason 

2025.12.08補上

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> 
  <EventID>4771</EventID> 
  <Version>0</Version> 
  <Level>0</Level> 
  <Task>14339</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8010000000000000</Keywords> 
  <TimeCreated SystemTime="2025-12-08T02:09:48.550167600Z" /> 
  <EventRecordID>302830985</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="692" ThreadID="12764" /> 
  <Channel>Security</Channel> 
  <Computer>DC2.xxx.com.tw</Computer> 
  <Security /> 
  </System>
- <EventData>
  <Data Name="TargetUserName">US509</Data> 
  <Data Name="TargetSid">S-1-5-21-1409082233-2000478354-725345543-16652</Data> 
  <Data Name="ServiceName">krbtgt/xxx</Data> 
  <Data Name="TicketOptions">0x40810010</Data> 
  <Data Name="Status">0x18</Data> 
  <Data Name="PreAuthType">2</Data> 
  <Data Name="IpAddress">::ffff:192.168.20.100</Data> 
  <Data Name="IpPort">9290</Data> 
  <Data Name="CertIssuerName" /> 
  <Data Name="CertSerialNumber" /> 
  <Data Name="CertThumbprint" /> 
  </EventData>
  </Event>
  
  
  --------------------------------
  
  - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> 
  <EventID>4776</EventID> 
  <Version>0</Version> 
  <Level>0</Level> 
  <Task>14336</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8010000000000000</Keywords> 
  <TimeCreated SystemTime="2025-12-07T23:09:39.398114300Z" /> 
  <EventRecordID>302813356</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="692" ThreadID="844" /> 
  <Channel>Security</Channel> 
  <Computer>DC2.xxx.com.tw</Computer> 
  <Security /> 
  </System>
- <EventData>
  <Data Name="PackageName">MICROSOFT_AUTHENTICATION_PACKAGE_V1_0</Data> 
  <Data Name="TargetUserName">FA1044</Data> 
  <Data Name="Workstation">FA1044</Data> 
  <Data Name="Status">0xc000006a</Data> 
  </EventData>
  </Event>
  
--------------------------------  
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 個回答

3
Ray
iT邦大神 1 級 ‧ 2025-11-28 13:48:13

微軟的問題怎麼會去問對手 Google 的 Gemini?
當然是要問自家的 M365 Copilot 才知道內幕啊...
(微軟有很多內部文件是沒有公開, 無法被搜尋的)


Windows 11 25H2 11 月累積更新 KB5068861近期被社群與媒體回報:網路共用/SMB 行為有回歸或搜尋問題,以及安裝時的錯誤;雖然並未阻止網域登入,但可能在連線或驗證過程產生額外的錯誤事件(例如 SMB 或認證子系統的警告/失敗後重試)。

2025 年的安全強化(自 24H2 起)提高 SMB 簽章的預設要求。部分環境若 NAS/檔案伺服器或舊端點未完全支援,就會出現「能用但拋錯」的情況(例如檔案瀏覽器搜尋失效、簽章驗證警告等)

簡單講:

KB5068861 + 近年的 SMB/認證強化,可能讓你的環境在登入與存取時:
「雖然仍成功完成,但多了警告/錯誤事件」。

1.確認 SMB 簽章策略(Client/Server)

於用戶端:開啟 本機安全性原則 → 安全性選項

「Microsoft network client: Digitally sign communications (if server agrees)」
「Microsoft network client: Digitally sign communications (always)」
先將 if server agrees=Enabled、always=Disabled(或依你既有 GPO 設定),避免因為「始終要求」而對舊裝置造成警告。

於檔案伺服器(Server 2019):確認 SMB 簽章需求是否與用戶端一致,並在共用上開啟/關閉簽章以測試事件是否消失。(背景:24H2/25H2 的預設更嚴格)。

2.測試網路共用搜尋/索引

從受影響用戶端,在檔案總管對檔案伺服器分享資料夾做搜尋;若搜尋失效或延遲且伴隨伺服器端 SMB 錯誤事件,暫時視為 KB5068861 的已知回歸。可先以 重建索引 / 使用 UNC 直接列舉作權宜,並評估是否要暫退該更新於少數機器。

3.檢查 AD 登入相關事件

在 **DC(2012 R2)**的事件檢視器:

安全性(Security):留意 Kerberos(4768/4769/4771)、NTLM(4624/4776) 的失敗/重試。
系統(System):Netlogon、LSA、KDC 或 SMBServer 的錯誤/警告。
若有 STATUS_INVALID_SIGNATURE(0xc000a000)、STATUS_LOGON_FAILURE(0xc000006d) 等,通常與 SMB/認證強化的相容性有關。

4.確認網路設定與 NLA 狀態

少數更新後會出現網路檔案/印表共用暫時失效或網路設定轉為 Public,導致登入/探索階段拋事件。可確認 Network Location Awareness(NLA) 服務延遲啟動與相依性(Netlogon/DNS),避免 DC/檔案伺服器在開機初期誤套用錯誤的防火牆設定。

5. 收集用戶端錯誤碼

若用戶端有 Windows Update 安裝錯誤(例如 0x80070306/0x800f081f/0x800f0983),雖然你已安裝成功,但其他端點若失敗也會造成行為不一致。可用 Catalog 或 Media Creation Tool重灌該更新以保持一致性。


如果可以貼上 Log 的 Event ID, Source, Error Code 比較方便收斂方向.

看更多先前的回應...收起先前的回應...
noway iT邦研究生 1 級 ‧ 2025-11-30 09:25:11 檢舉

前輩 您好:
感謝您的回覆指導
1.您說 貼上 Log 的 Event ID, Source, Error Code 比較方便收斂方向;
我於原貼的資料還不夠,還是需要從哪邊提供資訊?

2.單純事件檢試器LOG一堆,一般都看錯誤,是否有個人認知上異常,現在這若是誤警,相對造成查閱困擾

麻煩您了
謝謝

Ray iT邦大神 1 級 ‧ 2025-11-30 17:10:30 檢舉

以這個事件為例:

Source = USB-USBHUB3
Event ID = 196
Error Code = 在這個畫面上看不到, 要選進上面的 Detail 頁籤才有, 但不是每個 Event 都有 Error Code, 也可能沒有.

Event ID 是 Windows 追蹤錯誤的主要源頭, 線索要從這裡開始追, 微軟內部的文件分類法, 也是以 Event ID 作為分類搜尋的關鍵字.

noway iT邦研究生 1 級 ‧ 2025-12-03 15:48:45 檢舉

謝謝前輩指導
我補上2個右邊頁籤XML 檔
沒有看到ERROR 字眼

Ray iT邦大神 1 級 ‧ 2025-12-04 21:11:12 檢舉

DC 上的 Event 4662

來源:Microsoft-Windows-Security-Auditing
事件類型:Object Access(DS)
ObjectType:{bf967a9c-0de6-11d0-a285-00aa003049e2} → 這是 Active Directory Object(通常是使用者或電腦帳號)。
AccessMask 0x100 → 對 AD 物件的「讀取屬性」權限。
SubjectUserName USERA$ → 這是電腦帳號(尾巴有 $),代表電腦在登入網域時,嘗試讀取 AD 物件屬性。

結論:這不是登入失敗,而是電腦在登入後,對 AD 物件做屬性查詢(例如群組成員資格)。事件 4662 通常是「成功的存取」稽核,非錯誤。

→ 如果你看到的是「錯誤」或「警告」,要再確認 Status 欄位,但目前貼的內容看起來是正常的 Object Access Audit。


File Server 上的 Event 5145

來源:Microsoft-Windows-Security-Auditing
事件類型:檔案共用存取(SMB)
ShareName:\*\FIS
AccessMask 0x1f019f → 這是「讀取、寫入、刪除、屬性修改」等綜合權限。
SubjectUserName FS470 → 使用者帳號。
IpAddress 192.168.20.10 → 用戶端 IP。

結論:5145 是「檔案共用存取嘗試」的稽核事件,通常在 Object Access Audit 稽核指標被開啟時會大量出現。它本身不是錯誤,而是記錄每次 SMB 存取。

→ 如果你覺得這是「錯誤」,要看是否有 Failure 或 Status 欄位,目前貼的內容看起來是成功的存取。


✅ 下一步建議:

請再確認是否有 Failure Audit 或 Status != 0x0 的事件(例如 4771、4776、SMBServer 錯誤)。

如果只是 4662 和 5145,這是「正常的成功存取稽核」, 不是錯誤,可以透過 GPO 調整 Audit Policy 減少噪音:

Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Object Access → Audit Directory Service Access / Audit File Share
改成「失敗」或關閉「成功」稽核,避免大量事件。


我懷疑真正的「錯誤」在 System 頻道(SMBServer 或 Netlogon),或 Security 頻道的 4771(Kerberos 預認證失敗)。

你可以再貼 System 頻道的 SMBServer / Netlogon 錯誤事件,或 Security 頻道的 4771/4776,判斷是否跟 KB5068861 的 SMB 簽章強化有關?

noway iT邦研究生 1 級 ‧ 2025-12-08 11:01:25 檢舉

您好:
謝謝您的指導,的稽核失敗
我看DC 上有4771 與 4776
但 FILE SERVER 上沒有 4771 與 4776 ,只有4625 與5154
我貼於1樓
謝謝

Ray iT邦大神 1 級 ‧ 2025-12-08 13:07:08 檢舉

事件分析

4771 (Kerberos Pre-Authentication Failed)

Status = 0x18 → 表示「密碼錯誤」或「憑證不正確」
常見原因:
使用者輸入錯誤密碼
或 電腦帳號密碼不同步(可能因為長時間休眠、重置後未更新)
也可能是 Kerberos 與 NTLM 混用導致重試

4776 (NTLM Authentication Failed)

Status = 0xc000006a → 「錯誤密碼」
這通常是:
使用者輸入錯誤密碼
或某些服務(例如舊版 SMB、應用程式)嘗試用舊憑證驗證

4625 (Logon Failed) 在 File Server

代表有登入失敗,但如果同時有成功登入事件,可能是重試後成功。


為什麼更新後才大量出現?

KB5068861 (Windows 11 25H2) + SMB 簽章強化

→ 可能導致:
Kerberos 驗證更嚴格,失敗重試次數增加
某些舊應用程式或服務改用 NTLM,觸發 4776

網路延遲或 NLA 啟動順序問題

→ 開機時,電腦帳號驗證失敗一次,後續成功,但仍記錄失敗事件
(這個我常遇到: 就是有多個連線管道同時啟用(LAN/Wifi/VPN...等等), 只有其中一個可以正確與 AD 驗證, 偏偏這個可以驗證的連線, 排在比較晚啟動, 導致先跑去用其他不能驗證的網路, 於是就留下這個紀錄, 直到正確的網路連通之後, 他就正常)


如何處理?

確認是否只是「噪音」

如果使用者最終能登入,且沒有功能異常,這些事件只是「失敗重試」。
可透過 Audit Policy 調整,只記錄「失敗」或降低成功事件。

檢查電腦帳號密碼同步

在 DC 上執行:

nltest /dsgetdc:<domain>
nltest /sc_verify:<domain>

如果有錯誤,重置電腦帳號 (這是 Powershell 指令):

Reset-ComputerMachinePassword

檢查 GPO:Kerberos 與 NTLM 設定

Network security: LAN Manager authentication level

→ 設為「Send NTLMv2 response only. Refuse LM & NTLM」
Kerberos policy:確認時鐘同步(偏差 < 5 分鐘)
(時間問題我也常遇到, Client和Server不能誤差太大)

SMB 簽章策略(避免更新後相容性問題)

在 GPO:

Microsoft network client: Digitally sign communications (if server agrees) → Enabled
Microsoft network client: Digitally sign communications (always) → Disabled

同步檔案伺服器設定,避免強制簽章導致重試。


除了以上之外, 我這邊已經沒有其他經驗可以分享了.

noway iT邦研究生 1 級 ‧ 2025-12-10 09:27:10 檢舉

您好:
謝謝您的指導
我查看
nltest /dsgetdc:
nltest /sc_verify:
都沒問題

目前
Network security: LAN Manager authentication level
→ 設為「Send NTLMv2 response only. Refuse LM & NTLM」

有2台DC,都有出現LOG
DC1:Network security: 沒有 本機原則可以去看 網路安全的項目
DC2:可以看到有問路安全的項目,

https://ithelp.ithome.com.tw/upload/images/20251210/20104095BYcTEdQ4Dt.png

目前比較好奇的是
DC1:Default Domain Policy ,點選後,是自己的policy
DC2:Default Domain Policy ,點選後,是主要DC的policy
這是不同步的原因嗎?

謝謝

Ray iT邦大神 1 級 ‧ 2025-12-10 14:05:37 檢舉

有可能你的 GPO 沒同步喔, 用系統管理員身分測一下:

dcdiag /a
repadmin /showrpel
noway iT邦研究生 1 級 ‧ 2025-12-18 09:41:03 檢舉

您好:
repadmin /showrepl ,目前看,與複寫主機連線,嘗試成功
dcdiag /a 就一堆ERR
類似如下
謝謝

正在啟動測試: DAAREvent
無法查詢伺服器 YY6.xxx.com.tw 的事件記錄檔 DAA Replication,錯誤是 0x6ba "RPC 伺服器無法使用。"
......................... YY6 未通過測試 DAAREvent

正在啟動測試: KnowsOfRoleHolders
警告: YY1_2019 是 Schema Owner,但沒有回應 DS RPC 繫結。
警告: YY1_2019 是 Schema Owner,但沒有回應 LDAP 繫結。
警告: YY1_2019 是 Domain Owner,但沒有回應 DS RPC 繫結。
警告: YY1_2019 是 Domain Owner,但沒有回應 LDAP 繫結。
警告: YY1_2019 是 PDC Owner,但沒有回應 DS RPC 繫結。
警告: YY1_2019 是 PDC Owner,但沒有回應 LDAP 繫結。
警告: YY1_2019 是 Rid Owner,但沒有回應 DS RPC 繫結。
警告: YY1_2019 是 Rid Owner,但沒有回應 LDAP 繫結。
警告: YY1_2019 是 Infrastructure Update Owner,但沒有回應 DS RPC 繫結。
警告: YY1_2019 是 Infrastructure Update Owner,但沒有回應 LDAP 繫結。
......................... AA-AD 未通過測試 KnowsOfRoleHolders

正在執行分割測試的位置 : xx
正在啟動測試: CheckSDRefDom
......................... xx 通過測試 CheckSDRefDom
正在啟動測試: CrossRefValidation
擷取分割 (DC=xx,DC=com,DC=tw) 的交互參照 (CN=xx,CN=Partitions,CN=Configuration,DC=xx,DC=com,DC=tw)
的資訊時,發生下列錯誤:
LDAP 錯誤 0x3a (58)。
......................... xx 未通過測試 CrossRefValidation

正在執行企業測試的位置 : xxx.com.tw
正在啟動測試: LocatorCheck
警告: DcGetDcName(PDC_REQUIRED) 呼叫失敗,錯誤 1355
找不到網域主控站。
做為 PDC 角色的伺服器已關閉。
......................... xxx.com.tw 未通過測試 LocatorCheck
正在啟動測試: Intersite
在站台 NewTaipei 執行站台間輸入複寫測試:
......................... xxx.com.tw 通過測試 Intersite

Ray iT邦大神 1 級 ‧ 2025-12-18 14:07:56 檢舉

你的 AD Infrastructure 已經掛了; 先查目前 FSMO 在誰身上? (每一台 DC 都查)

netdom show fsmo

如果五個 FSMO 都很一致在同一台上面的話, 先把所有 DC 的 DNS 設定都指向那台, 不要有其他的 DNS 混在裡面, 然後 DC 依序重開機 (一台登入完畢再開下一台, 不要同時重開), 全部都重開完之後先放置 24 小時, 然後再重新做一次上面的 dcdiag 才會準確.

根據 dcdiag 列出來的 Event log 編號, 從 Event log 裡面找出來對應的 Error, 一條一條去解, 一直解到 dcdiag 沒有錯誤為止.

noway iT邦研究生 1 級 ‧ 2025-12-18 16:51:51 檢舉

您好:
C:\Users\s.AA>netdom query fsmo
架構主機 YY1_2019.xx.com.tw
網域命名主機 YY1_2019.xx.com.tw
PDC YY1_2019.xx.com.tw
RID 集區管理員 YY1_2019.xx.com.tw
基礎結構主機 YY1_2019.xx.com.tw
命令已經成功完成。

目前 我這台DC9 ,與 YY6 查到的都是
YY1_2019 這一台 PDC

平常 我跟 YY6 這台做資料交換
但DC9 無直接連YY1_2019
YY6 可以直接連YY1_2019

Ray iT邦大神 1 級 ‧ 2025-12-18 17:23:29 檢舉

YY1_2019 是誰? YY6 呢?

noway iT邦研究生 1 級 ‧ 2025-12-19 10:17:36 檢舉

YY1_2019 PDC
YY6 可以直接連到 YY1_2019
DC9 似乎無法直接同步於 YY1_2019
但可以 跟YY6 交換

Ray iT邦大神 1 級 ‧ 2025-12-19 13:51:44 檢舉

那就先把 YY1_2019 這台上面的 Event log 全部清零 (排除造成 Error 的根因), 清到 Log 裡面沒有黃色和紅色標記出現為止. 如果上面有安裝除了 DC 以外的角色, 也要全部移除或終止(包含 File Sharing, Printe Server...等, 通通不能有, 防毒也要關掉或移除)

等他持續跑 24hr 都沒有再出現 Error 之後, 先將其他的 DC 降級 (Demote 到 Member Server 角色), 過 24hr 後確認 YY1_2019 沒有紅黃警告, 再一台一台加回來, 每加回一台都要先停 24hr 觀察是否會出現紅黃警告? 確認沒有才能加下一台進來.

過程中要不斷檢查 YY1_2019 的 Event log , 如果做了甚麼動作造成她出現紅黃警告, 那個動作就必須回滾撤銷, 讓他保持乾淨的狀態.

我要發表回答

立即登入回答