I was contacted by a customer who ran into an issue deploying the FSSO collector agent on a member server, and they were having difficulty getting it to communicate with the Domain Controller. Normally deploying the FSSO collector is a piece of cake, and documented well enough that it didn't justify it's own "how to" on this blog. But in this case I have seen some odd behavior, and I couldn't quite wrap my head around it.
The Problem
The customer contacted me explaining the issue, one of the first things I check is the ability to access the event logs using the event viewer on the member server:
This will help us rule out any permissions issues. To my surprise, we were able to access the Domain Controller(DC) just fine. So something was definitely going on. Further investigation of the FSSO Agent logs revealed some trouble in communication:
10/12/2021 00:08:53 [ 7760] [E][EPPoller]Could not open the event log on:dc.my.domain.local (e=1764)Hmm... This is indeed troubling, despite having the correct privileges, the FSSO agent isn't able to establish communication with the DC. So after some googling of error 1764 I came across a Microsoft KB article (KB5003671) explaining that in order to address CVE-2021-31958 the Event Log API had to be updated, however this doesn't impact Event Viewer communication.
They key here is that both the server the FSSO collector resides on, and the DC need to either have the patch applied (recommended - CVEs and all) or not applied (Please patch your systems). It appeared that this was breaking due to the fact that one of the systems - which we found to be the Domain Controller after the fact - did not have the patch applied. Just as a side note the DC was running 2012 R2, and the member server was running Server 2019 - check your patches before you go running down this path. Being a newly deployed and patched server the FSSO collector server already had the update installed.
Once we applied the patch to the DC, the errors went away. But we weren't done yet, we still weren't getting user logins. After some troubleshooting with TAC (Thank you Fortinet TAC for coming through here), we realized that the FSSO collector defaults to legacy login event IDs for logins. As per the Fortinet KB Article TAC referred us to, the collector log levels are as such: • 0 - polls: 672, 680, 4768, 4776 - this is the default subset.
• 1 - polls: 672, 673, 680, 4768, 4769, 4776.
• 2 - polls: 672, 673, 680, 4768, 4769, 4776, 4624 (EventID 4624 was added to default polling in Windows 2016 for better support of MacOS and newer Windows server platforms)
• <EventID1;EventID2;...;EventIDn> - polls info from specific Event ID or IDs. e.g 4768;4769;4624
So by setting the polling to 2 (essentially monitoring everything supported) we were ensuring we were capturing all the supported logon IDs. After we applied this the login events started appearing!
Hopefully this helps someone else from going crazy trying to chase things down. Thank you for reading. Madman out!
コメント