Exclude a list of IP ranges

I have been given a task of removing “everyone” from our network shares. I have the powershell script for this as it seemed to be pretty straightforward. However, when I implemented this as a Configuration Baseline a problem was found. There are systems that were unable to complete their daily tasks when the “everyone” permission was removed. We monitored the situation and I have now been given a list of IP addresses that should be excluded from the remove “everyone” CB. Problem is, I don’t know how to include a list of excluded IP´s in my powershell script. Here is what I have so far but I would like someone to tell me if I am on the correct path.

$ExcludedIPs =  "10.145.0.0/16","10.146.0.0/16"
$IPAddress = [System.Net.Dns]::GetHostAddresses($env:COMPUTERNAME) | Select-Object -ExpandProperty IPAddressToString
$Shares = (Get-SmbShare |Where-Object {($_.Name  -notmatch ".+\$") -and ($IPAddress -notin $ExcludedIPS)} | Get-SmbShareAccess | Where-Object {$_.AccountName -eq "Everyone"})
IF ($Shares -ne $null)
 {Get-SmbShare | Where-Object {($_.Name  -notmatch ".+\$") -and ($IPAddress -notin $ExcludedIPS)} | Get-SmbShareAccess | Where-Object {$_.AccountName -eq "Everyone"} | ForEach-Object {Revoke-SmbShareAccess -name $_.name -AccountName $_.AccountName -Force}}
ELSE
 {}

It is actually common best practice to have “everyone” on the shares permissions and manage the access rights on the file system side - not the share side. :man_shrugging:t4:

?? I didn’t get this. Shares actually do not have any IP address setting. :thinking:

That will probably not work as you might think it does. For that to work $IPAddress would need to be an exact member of the array represented by $ExcludedIPS. So for example blue would be found in (blue,red,green) but not in (Color blue, color red, color green).

I agree with Olaf based on what you share. Not sure why you want to remove “everyone” from the share permissions. NTFS permissions actually control if you see, read, write, delete etc. Even with “everyone” left in the share permission, if your NTFS permissions are set correctly, “everyone” will not have access to “everything”.

There is no way to say remove “everyone” except from this IP. Doesn’t work that way.

Typically, when you have to remove “everyone”, you replace “everyone” with a new group that has a naming convention that makes it clear it is for the share and holds the share permissions. To simplify, you also then create a group to hold the NTFS permission and then nest that group into the “share group”.

This prevents you from having to remember to add user and service accounts to two groups, you add them to the NTFS group only. But you could keep the groups separate and just remember to add users to the two group. All about the politics in your organization and management decisions around security, regardless of if they make sense or not.

Permissions can be a real pain to wrap your head around, but once you do, you can do some pretty cool stuff. When I managed our file server, I was told to reduce the number of shares. I started creating a single share for common projects. One such was ITAR governed project. which means users from project A CANNOT see data for project B…EVER.

I still only used one share, but based on NTFS permissions people would only ever see their project. even though there were multiple folders below the shared one, if you were not a member of the project, you didn’t even see the folders you didn’t have access too. So, it wasn’t a case of they could see the “root” folders but not access, they couldn’t even see them because of the NTFS permissions.

You may not be able to change your management’s directive, but it is not about the share permissions, rather it is ALL about the NTFS permissions if you want to be secure.

1 Like

Thanks Olaf, the idea is that the Configuration Baseline would only be deployed to computers in a certain IP range. I agree that removing everyone isn’t the best solution. I will chat with management again.

Yes, you make very valid points. I will try to address this issue with management again.