背景：
很早就發現域控的CPU長期飆在60-80%之間，日誌服務是CPU佔用大頭，改小日誌的最大大小也沒有用，域控使用了paloalto和 SXF的單點登錄功能，所以我雖然確定肯定是兩個的其中一個，但是一直沒有實錘。
使用Stack Trace我只能確認是日誌查詢導致的
由於日誌的查詢是通過WMI進行的，所以在找到一些WMI TRACE相關的信息後，我抓了一小段時間WMI TRACE爲ETL文件，然後使用windows message analyzer 把需要的字段提取出來，生成一個CSV，然後在EXCEL裏面進行查看。
- 白色背景的查詢1，似乎沒有太規則的規律，查詢間隔時間最小似乎是1s,但是大的間隔也有5s ,2s左右居多。
select __RELPATH, InsertionStrings from Win32_NTLogEvent where ((Logfile = "security" AND (((EventCode = 672 OR EventCode = 4624) OR EventCode = 540) OR EventCode = 4768)) AND RecordNumber > 939574642)- (Yellow)色背景的查詢2 （唉，這博客的關鍵詞太優（cu）雅（fang)），查詢間隔大概是14-15s.
select __RELPATH, EventIdentifier, InsertionStrings, TimeGenerated from Win32_NTLogEvent where (((((((((EventIdentifier = 4624 OR EventIdentifier = 4768) OR EventIdentifier = 4769) OR EventIdentifier = 4770) OR EventIdentifier = 540) OR EventIdentifier = 672) OR EventIdentifier = 673) OR EventIdentifier = 674) AND LogFile = "Security") AND TimeGenerated >= "20190906013740.751000+000")找到真兇
是的上面的查詢1，頻率很高，可能是真兇，但是這個查詢是誰發出的呢？能否跟到IP地址？
使用netsh trace 進行抓包，使用Windows Message Analyzer進行分析，先篩選WMI，然後點中其中一條，點最前面的加號，一直跟到ip 模塊，然後把SourceAddress 顯示成列，把strquery 單獨顯示成一列，大致如下圖。真兇找到。
後記
以爲在網頁上把下面的設置禁用，刪除配置的域控列表，就可以禁用日誌查詢了，結果抓包後不是這樣的，SXF 是堅持要幹活，AD的日誌查詢還是一直在繼續，估計釜底抽薪的辦法，只能把SXF用的賬號給改個密碼或者把賬號禁用了。
我驗證了我的想法，然後發現確實有效，我只想說，做人真的要矜持。。。。。。。。。。。
禁用了SXF用的AD賬號一段後，又開啓後，DC的CPU表現圖如下：
附加下Palo Alto的查詢配置（可更改的）
