I stopped my last blog post on Windows File Shares noting that there was still more to do. Monitoring Windows File Shares is a three part puzzle:
We have already handled the first two, so this blog post is all about the final one – monitoring permission changes.
Let’s first consider how one would do this generically. As with the file shares, there is a WMI class for monitoring permissions, but it’s harder to use. You need to do it on a per-share basis, like this:
gwmi Win32_LogicalShareSecuritySetting -Filter "Name='$shareName'"
The Win32_LogicalShareSecuritySetting is a complex beast. Fortunately, we only need to know a couple of things. The most important one is the security descriptor. You can get the security descriptor like this:
$ss = gwmi Win32_LogicalShareSecuritySetting -Filter "Name='$shareName'" $sd = $ss.InvokeMethod('GetSecurityDescriptor',$null,$null)
Once you have the security descriptor, the ACLs are in a property called DACL (which is actually an array – one for each entry in the ACL), and the user or group is embedded in another property inside the DACL called Trustee. If you need more information on this object, I suggest reading the excellent blog post by Andrew Buford.
To aid me in this, I created a short script. You can download it from github. It contains two cmdlets that are fairly central to this process – Get-NetShare encapsulates WMI call for obtaining the list of network shares. I use this to feed into the Gte-NetShareSecurity cmdlet, which produces more objects. Now I can do the following:
Get-NetShare | Get-NetShareSecurity
There is more going on within the script though, as it is meant to be run as part of the SA-ModularInput-PowerShell addon. Specifically, it encapsulates the logic from last week for emitting the shares only when they change. I’ve done a few changes – I’ve added a checksum field so that I only have to store and check the checksum. I’ve also added a type – is it a new share, updated share or just a periodic emission? Finally, I’ve handled deletions as well by checking the cache against the current list of shares.
I do pretty much the same thing for the permissions. In the file share example, the share name is the primary key. In the permissions example, we have to construct a primary key – I’ve used the share name and the Security ID (SID) of the user or group as the primary key. Other than that, it’s exactly the same code.
One final note – since this script is outputting two different types of data, I leverage a feature of the SA-ModularInput-PowerShell that allows me to set the source type within the object. The property for this is called SplunkSourceType. You can use Add-Member to add this to the objects you are emitting.
If you are going to .conf 2013 next week, feel free to stop by the Microsoft booth on the third floor in the Apps Showcase and chat with me about Microsoft, PowerShell and getting data into Splunk.