您好:
近期沒有改到任何設定
只有
目前
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>
--------------------------------
微軟的問題怎麼會去問對手 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
同步檔案伺服器設定,避免強制簽章導致重試。
除了以上之外, 我這邊已經沒有其他經驗可以分享了.
您好:
謝謝您的指導
我查看
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:可以看到有問路安全的項目,

目前比較好奇的是
DC1:Default Domain Policy ,點選後,是自己的policy
DC2:Default Domain Policy ,點選後,是主要DC的policy
這是不同步的原因嗎?
謝謝
有可能你的 GPO 沒同步喔, 用系統管理員身分測一下:
dcdiag /a
repadmin /showrpel
您好:
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
你的 AD Infrastructure 已經掛了; 先查目前 FSMO 在誰身上? (每一台 DC 都查)
netdom show fsmo
如果五個 FSMO 都很一致在同一台上面的話, 先把所有 DC 的 DNS 設定都指向那台, 不要有其他的 DNS 混在裡面, 然後 DC 依序重開機 (一台登入完畢再開下一台, 不要同時重開), 全部都重開完之後先放置 24 小時, 然後再重新做一次上面的 dcdiag 才會準確.
根據 dcdiag 列出來的 Event log 編號, 從 Event log 裡面找出來對應的 Error, 一條一條去解, 一直解到 dcdiag 沒有錯誤為止.
您好:
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
YY1_2019 是誰? YY6 呢?
YY1_2019 PDC
YY6 可以直接連到 YY1_2019
DC9 似乎無法直接同步於 YY1_2019
但可以 跟YY6 交換
那就先把 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 , 如果做了甚麼動作造成她出現紅黃警告, 那個動作就必須回滾撤銷, 讓他保持乾淨的狀態.