Why is the user an Admin if they do not follow rules for what is allowed on servers?

If you make the use a standard user, and allow the standard user access through RDP, you can target them with a normal workstyle and accomplish this, similar to what you would do on regular endpoints.

This will of course not work on servers with infrastructure functions etc. Domain controllers, DNS etc. as users would need an accounts that has permissions to control those functions and features.

But for application servers hosting 3rd party apps and solution this might be a good option.

Preliminary testing on my end shows that when I right click a directory → Properties → Sharing tab →  select “Advanced Sharing”, that “shpafact.dll” is being loaded via a COM class.

While we cannot control DLLs in this way as they are not executable, we can target COM classes. The specific object being called is the “Sharing Elevated Virtual Factory”. You can see these details of the COM CLSID from the event itself, e.g.:

 File Name: C:\Windows\System32\shpafact.dll
 Description: Windows Shell LUA/PA Elevation Factory Dll
 COM CLSID: {72A7994A-3092-4054-B6BE-08FF81AEEFFC}
 COM AppID: {72A7994A-3092-4054-B6BE-08FF81AEEFFC}
 COM Display Name: Windows File Sharing

If I build a block rule targeting this COM class, then yes I am unable to advance past the “Advanced Sharing...” button from a folder’s properties:

So is this possible? At least in this way, yes. However, I have not fully tested all of the impacts of blocking the “Sharing Elevated Virtual Factory”, so I would be hesitant to advise this as it may lead to unexpected behavior.

Another thing to note is that the GUI is only one method to enable Sharing on a directory. My above example does not block an Admin using PowerShell (for example) to accomplish the same thing:

So you would need to consider all different avenues an Admin user may enable sharing on an otherwise unprotected directory.

I was able to replicate this same over workstations side , Downside is that for the folder if anyone creates the sharing folder as shown above then if the user has full permissions to the respective folder . Then anyone under that domain , will be able to access the network share and can make some changes to any file in that location causing application working issues.

@Neil  , will it be good to create same blocker which was created above?

I have not tested this recently, but over a year ago, we’ve also blocked the easy ways to create shared folders on Windows Clients with these 2 rules:
1. Via filename : c:\windows\system32\shrpubw.exe
2. Via CLSID: {72A7994A-3092-4054-B6BE-08FF81AEEFFC} 

No unexpected behavior experienced since then.