powershell - How to determine if user has admin rights, but script not running elevated - Stack Overflow

I have tried various solutions online (some not very clear on whether they are for detecting script being elevated, as opposed to script running under a user that doesn't need to supply creds to UAC to elevate). Like the below. They show false when running under a domain admin account, not elevated. Likewise (obviously) a domain account without any admin rights. They both show true when running elevated though.

PS C:\Users\xxxxxxxxx.adm> (new-object security.principal.windowsprincipal([security.principal.windowsidentity]::getcurrent())).isinrole([security.principal.windowsbuiltinrole]::administrator)


PS C:\Users\xxxxxxxxx.adm> (([security.principal.windowsidentity]::getcurrent().groups).value -contains 'S-1-5-32-544')

How can I achieve the check needed?

Note: In my environment, helpdesk admin privileges are provided by a double nested group, not domain admins, added to the adminstrator group on the workstations.

I have tried various solutions online (some not very clear on whether they are for detecting script being elevated, as opposed to script running under a user that doesn't need to supply creds to UAC to elevate). Like the below. They show false when running under a domain admin account, not elevated. Likewise (obviously) a domain account without any admin rights. They both show true when running elevated though.

PS C:\Users\xxxxxxxxx.adm> (new-object security.principal.windowsprincipal([security.principal.windowsidentity]::getcurrent())).isinrole([security.principal.windowsbuiltinrole]::administrator)


PS C:\Users\xxxxxxxxx.adm> (([security.principal.windowsidentity]::getcurrent().groups).value -contains 'S-1-5-32-544')

How can I achieve the check needed?

Note: In my environment, helpdesk admin privileges are provided by a double nested group, not domain admins, added to the adminstrator group on the workstations.

• powershell
• administrator
• elevation

Share Improve this question Follow edited Feb 5 at 22:36 mklement0 443k6868 gold badges710710 silver badges927927 bronze badges asked Feb 3 at 21:23 user66001user66001 91511 gold badge1515 silver badges3737 bronze badges 11

• 2 AD Roles, like Domain Admin is unrelated to the command you're running. IsInRole will check if the User running a process has the specified role (Administrator in this case). If you want to see if X user could elevate the process you could check if he is a member of the Administrators group: Get-LocalGroupMember Administrators – Santiago Squarzon Commented Feb 3 at 21:30
• For a Domain Joined computer you should also check if the user is a members of the built-in AD group, since an AD admin could make themselves owner of the object – Santiago Squarzon Commented Feb 3 at 21:36
• See if the solution in this answer helps. – mklement0 Commented Feb 3 at 21:40
• 1 A member of the Administrators built-in AD Group is already a local Administrator for any computer joined to that Domain. So technically any user that is recursive member of CN=Domain Admins,CN=BuiltIn... or CN=Administrators,CN=BuiltIn,... is a local Administrator @mklement0 – Santiago Squarzon Commented Feb 3 at 22:13
• 1 @mklement0 Bingo! False for regular user. True for admin user not running Powershell elevated. True also for admin user running Powershell elevated! Want to copy that answer into here, to 1) Save folks maybe missing the solution in a link, in a comment, and 2) To give you some props with an accepted answer for your time, unlike the other Answer? – user66001 Commented Feb 4 at 14:59

 |  Show 6 more comments

1 Answer 1

Sorted by: Reset to default 2

You can adapt the solution from this answer to a conceptually related question (the linked solution allows you to perform the same test for any given user, not just the current one):

# Load the required assembly (a no-op if already loaded).
# NOTE: No longer needed in PowerShell 7, where this assembly is preloaded.
Add-Type -AssemblyName System.DirectoryServices.AccountManagement

# See if the well-known SID of the local Administrators group
# is among the SIDs of the groups that the user is a member of,
# either directly or indirectly.
[DirectoryServices.AccountManagement.UserPrincipal]::Current.
  GetAuthorizationGroups().SID.Value -contains 'S-1-5-32-544'

In essence, this tells you whether the current user account is an administrator on the local machine in principle and whether it can therefore run as itself when elevation is requested.