Monitor a Folder in FileServer for User Addition/Removal

Have a situation where we have a high security level folder on the File server giving access to a particular Group.

We recently found that some unwanted/authorised Users have been added to this Group granting them access to this folder and subfolders.

How do I set up a Monitor in SCOM to Alert me if a user is Added/Removed from this Folder.

Do i setup monitoring at AD Level since the access Group is from AD or do I monitor from FileServer Level as users can be added explicitly or do I monitor both sides?

I have implemented Monitoring of AD group Modification to monitor Domain Admins group membership additions in SCOM.

I would like to do something similar but not sure where to start off from.

Please note, I do not want to monitor File Sizes or changes to Permissions.
Trying to monitor user addition and removal from a Folder.

Hi SaiyadRa,

Are you looking to trigger an alert if someone changes the file system/folder permissions? Or, is there a security group in the file system permissions and you want to be alerted if the membership of that group changes?

If I understand your question properly, you’re looking for the first one; an alert if the file system/folder permissions change. I quickly looked through the guide for the Windows Server File and iSCSI Services MP and I didn’t see anything that might be helpful. You could do a custom monitor with a short PowerShell script.

Use Get-Acl to pull the folder permissions and a regular expression to filter for the accepted values. Alerts can be triggered if there is anything that doesn’t match that RegEx. I put this together and tested it quickly. It worked as expected:

# Set the path that is being monitored
$MonitoredPath = "C:\Windows"

# Set the accepted users and groups for the ACL
# If multiple users/groups are accepted, separate with a pipe character |
$AcceptedACLEntries = "System|Users|TrustedInstaller"

Write-Host "Checking file system permissions for: " $MonitoredPath
Write-Host "Acceptable users and groups:`n"
$AcceptedACLEntries.Split("|")
Write-Host "`n"

# Building a property bag for SCOM so the data gathered by the script can be added to the alert.
$ScomAPI = New-Object -comObject "MOM.ScriptAPI"
$PropertyBag = $ScomAPI.CreatePropertyBag()

# Get the users and groups from the monitored path's ACL 
$ACL_MonitoredPath = (Get-Acl -Path $MonitoredPath).Access.IdentityReference

# Initialize a variable to store any improper permissions
$ImproperPermissions = $null

# Look at each entry in the list
ForEach ($ACL in $ACL_MonitoredPath) {

	# If the entry in the list does not match the accepted entries, write it to the console and add to the property bag
	If ($ACL -notmatch $AcceptedACLEntries) {
		Write-Host -ForegroundColor Red "Improper permission found: " $ACL

		# Add the improper permission's Value attribute to a list that can be shown in the alert description
		$ImproperPermissions += $ACL.Value + "`n"
	}
	Else {
		Write-Host -ForegroundColor Green "Acceptable permission found: " $ACL
	}
}

# If improper permissions were found (i.e. $ImproperPermissions is not null), set the state to "Bad" and add the liste of improper permissions to the property bag
If ($ImproperPermissions -ne $null) {
	$PropertyBag.AddValue("State","Bad")
	$PropertyBag.AddValue("MonitoredPath",$MonitoredPath)
	$PropertyBag.AddValue("Permission",$ImproperPermissions)
}

# Else, if there are no improper permissions (i.e. $ImproperPermissions is still null), set the state to "Good"
ElseIf ($ImproperPermissions -eq $null) {
	$PropertyBag.AddValue("State","Good")
}

# Return the property bag
$PropertyBag

Then, for the alert configuration:

Healthy Expression:
	Property[@Name="State"]  Equals  Good

Unhealthy Expression:
	Property[@Name="State"]  Equals  Bad

Alert Description:

	Improper file system permissions have been found.

	Monitored path: $Data/Context/Property[@Name="MonitoredPath"]$
	Improper permissions:
	$Data/Context/Property[@Name="Permission"]$

When an alert was triggered, the description looked like this:

Alert: FileSystemTest
Source: MyServer.Domain.com
Path: Not Present
Last modified by: System
Last modified time: 5/29/2020 8:51:52 AM
Alert description: Improper file system permissions have been found.

Monitored path: C:\Windows
Improper permissions:
CREATOR OWNER
BUILTIN\Administrators
BUILTIN\Administrators
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES

That script looks at C:\Windows but you could change the path to any file or folder. A UNC path works too. I think that might get you close to what you need.

Hi Steve,

Going through some more articles and getting advice, what do you think of this approach:

Folder level permission change
a) Create an audit policy to audit folder permission change

To use auditing, you’ll need to do the following:

  1. In the local policy (or applicable GPO) of the computer, enable Success audits via one of the following:
    • Computer Configuration | Policies | Windows Settings | Security Settings | Local Policies | Audit Policy | Audit Object Access
    • Computer Configuration | Policies | Windows Settings | Security Settings | Advanced Audit Policy Configuration | Audit Policies | Object Access | Audit File System
  2. Enable auditing on your directory by right-clicking on the directory in Windows Explorer and selecting Properties | Security | Advanced | Auditing | Edit... | Add.... Next, enter Everyone as the security principal to audit. Last, check the "Successful" box for "Change permissions".
b) Create a event rule to monitor event 4663 or 4670

 

Active Directory Level

I am thinking of monitoring the AD Group member as well so I could use something like:

Group scope

Adding a member ( Event ID )

Removing a member ( Event ID )

Global

4728

4729

 

Can someone confirm if this will work?

I don’t have much experience with Audit Policies but alerting on an event ID is easier than the script-based monitor that I posted. That would also tell you which account made the changes and that is good information to have. I think that approach would work well.