Restricting Management for User Accounts and Local Groups
The Block Local User Management and Block Local Group Management actions prevent specific sets of Win32 API functions from being called. The following functions are blocked from being called:
- NetUserAdd()
- NetUserChangePassword()
- NetUserDel()
- NetUserModalsSet()
- NetUserSetGroups()
- NetUserSetInfo()
- NetLocalGroupAdd()
- NetLocalGroupAddMember()
- NetLocalGroupSetInfo()
- NetLocalGroupDel()
- NetLocalGroupDelMember()
- NetLocalGroupSetMembers()
- NetLocalGroupAddMembers()
- NetLocalGroupDelMembers()
Any process these restrictive actions have been applied to will be unable to call those functions. It makes no difference if the program is .NET (for example, C#) or native code, nor does it make any difference if it is PowerShell (for example, powershell.exe, powershell_ise.exe, pwsh.exe), any of the administrative utilities that are installed along with Windows (for example, the NET command, mmc.exe) or any third-party supplied application program.
In practical terms, when these actions are applied to both C:\Windows\System32\NET.EXE and C:\Windows\System32\NET1.EXE, then the following usages of the NET command (for example, NET command executed from within CMD.EXE or any edition of PowerShell) will be blocked:
- NET USER
/ACTIVE:<yes|no> - NET USER
/COMMENT:" " - NET USER
/DELETE - NET USER
/ADD - NET LOCALGROUP
/ADD - NET LOCALGROUP
/DEL - NET LOCALGROUP
/COMMENT:" " - NET LOCALGROUP
/DELETE - NET LOCALGROUP
/ADD
Likewise, when these actions are applied to any edition of PowerShell, the following cmdlets will be prevented from executing properly:
- Disable-LocalUser
- Enable-LocalUser
- New-LocalUser
- Remove-LocalUser
- Rename-LocalUser
- Set-LocalUser
- Add-LocalGroupMember
- New-LocalGroup
- Remove-LocalGroup
- Remove-LocalGroupMember
- Rename-LocalGroup
- Set-LocalGroup
In .NET, all classes under the System.DirectoryServices.AccountManagement namespace that manage user accounts (UserPrincipal) and/or local groups (GroupPrincipal) are subject to the same restrictions as those classes ultimately make use of the Win32 API functions for which access has been restricted. This is important note as all editions of PowerShell are capable of directly invoking .NET class methods as well as being capable of dynamically compiling & executing C# code, which can then utilize PInvoke to make direct calls to functions in any DLL written in any language and compiled with any development tools.
Finally, C:\Windows\System32\mmc.exe is the host program in which numerous Windows administration tools are executed when their respective snap-in, as identified by a file with a .mmc extension, are loaded into MMC. If these actions are applied to mmc.exe when a specific snap-in is present on the command line, such as compmgmt.msc, (the Computer Management snap-in), then that instance of MMC is also prevented from performing user and local group management operations.
The important thing to remember is that any process that these restrictive actions are applied to will be blocked from making the "forbidden" function calls, regardless of any level of elevation that the process has. Careful attention should be paid to the configuration of policies to ensure that these actions are being applied to elevated processes which are capable of calling arbitrary functions in any available DLL or capable of creating elevated child processes running other programs that are, in turn, capable of make the same types of function calls.