您好：
近期沒有改到任何設定
只有
目前
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>
--------------------------------
已邀請的邦友 {{ invite_list.length }}/5
微軟的問題怎麼會去問對手 Google 的 Gemini?
當然是要問自家的 M365 Copilot 才知道內幕啊...
(微軟有很多內部文件是沒有公開, 無法被搜尋的)
Windows 11 25H2 11 月累積更新 KB5068861近期被社群與媒體回報：網路共用／SMB 行為有回歸或搜尋問題，以及安裝時的錯誤；雖然並未阻止網域登入，但可能在連線或驗證過程產生額外的錯誤事件（例如 SMB 或認證子系統的警告/失敗後重試）。
2025 年的安全強化（自 24H2 起）提高 SMB 簽章的預設要求。部分環境若 NAS/檔案伺服器或舊端點未完全支援，就會出現「能用但拋錯」的情況（例如檔案瀏覽器搜尋失效、簽章驗證警告等）
簡單講：
KB5068861 + 近年的 SMB/認證強化，可能讓你的環境在登入與存取時:
「雖然仍成功完成，但多了警告/錯誤事件」。
於用戶端：開啟 本機安全性原則 → 安全性選項
「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 的預設更嚴格）。
從受影響用戶端，在檔案總管對檔案伺服器分享資料夾做搜尋；若搜尋失效或延遲且伴隨伺服器端 SMB 錯誤事件，暫時視為 KB5068861 的已知回歸。可先以 重建索引 / 使用 UNC 直接列舉作權宜，並評估是否要暫退該更新於少數機器。
在 **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/認證強化的相容性有關。
少數更新後會出現網路檔案/印表共用暫時失效或網路設定轉為 Public，導致登入/探索階段拋事件。可確認 Network Location Awareness（NLA） 服務延遲啟動與相依性（Netlogon/DNS），避免 DC/檔案伺服器在開機初期誤套用錯誤的防火牆設定。
若用戶端有 Windows Update 安裝錯誤（例如 0x80070306/0x800f081f/0x800f0983），雖然你已安裝成功，但其他端點若失敗也會造成行為不一致。可用 Catalog 或 Media Creation Tool重灌該更新以保持一致性。
如果可以貼上 Log 的 Event ID, Source, Error Code 比較方便收斂方向.
前輩 您好：
感謝您的回覆指導
1.您說 貼上 Log 的 Event ID, Source, Error Code 比較方便收斂方向；
我於原貼的資料還不夠，還是需要從哪邊提供資訊?
2.單純事件檢試器LOG一堆，一般都看錯誤，是否有個人認知上異常，現在這若是誤警，相對造成查閱困擾
麻煩您了
謝謝
以這個事件為例:
Source = USB-USBHUB3
Event ID = 196
Error Code = 在這個畫面上看不到, 要選進上面的 Detail 頁籤才有, 但不是每個 Event 都有 Error Code, 也可能沒有.
Event ID 是 Windows 追蹤錯誤的主要源頭, 線索要從這裡開始追, 微軟內部的文件分類法, 也是以 Event ID 作為分類搜尋的關鍵字.
謝謝前輩指導
我補上2個右邊頁籤XML 檔
沒有看到ERROR 字眼
來源：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。
來源：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 簽章強化有關?
您好：
謝謝您的指導，的稽核失敗
我看DC 上有4771 與 4776
但 FILE SERVER 上沒有 4771 與 4776 ，只有4625 與5154
我貼於1樓
謝謝
Status = 0x18 → 表示「密碼錯誤」或「憑證不正確」
常見原因：
使用者輸入錯誤密碼
或 電腦帳號密碼不同步（可能因為長時間休眠、重置後未更新）
也可能是 Kerberos 與 NTLM 混用導致重試
Status = 0xc000006a → 「錯誤密碼」
這通常是：
使用者輸入錯誤密碼
或某些服務（例如舊版 SMB、應用程式）嘗試用舊憑證驗證
代表有登入失敗，但如果同時有成功登入事件，可能是重試後成功。
→ 可能導致：
Kerberos 驗證更嚴格，失敗重試次數增加
某些舊應用程式或服務改用 NTLM，觸發 4776
→ 開機時，電腦帳號驗證失敗一次，後續成功，但仍記錄失敗事件
(這個我常遇到: 就是有多個連線管道同時啟用(LAN/Wifi/VPN...等等), 只有其中一個可以正確與 AD 驗證, 偏偏這個可以驗證的連線, 排在比較晚啟動, 導致先跑去用其他不能驗證的網路, 於是就留下這個紀錄, 直到正確的網路連通之後, 他就正常)
如果使用者最終能登入，且沒有功能異常，這些事件只是「失敗重試」。
可透過 Audit Policy 調整，只記錄「失敗」或降低成功事件。
在 DC 上執行：
nltest /dsgetdc:<domain>
nltest /sc_verify:<domain>
如果有錯誤，重置電腦帳號 (這是 Powershell 指令)：
Reset-ComputerMachinePassword
→ 設為「Send NTLMv2 response only. Refuse LM & NTLM」
Kerberos policy：確認時鐘同步（偏差 < 5 分鐘)
(時間問題我也常遇到, Client和Server不能誤差太大)
在 GPO：
Microsoft network client: Digitally sign communications (if server agrees) → Enabled
Microsoft network client: Digitally sign communications (always) → Disabled
同步檔案伺服器設定，避免強制簽章導致重試。
除了以上之外, 我這邊已經沒有其他經驗可以分享了.
iThome鐵人賽
看影片追技術