您好:
近期沒有改到任何設定
只有
目前
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
架構主機 AD1.xx.com.tw
網域命名主機 AD1.xx.com.tw
PDC AD1.xx.com.tw
RID 集區管理員 AD1.xx.com.tw
基礎結構主機 AD1.xx.com.tw
命令已經成功完成。
目前 我這台DC9 ,與 DC2 查到的都是
AD1 這一台
平常 我跟 DC2 這台做資料交換
但DC9 無直接連AD1
DC2 可以直接連AD1
YY1_2019 是誰? YY6 呢?