admin管理员组文章数量:1305167
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.
Share Improve this question edited Feb 5 at 22:36 mklement0 441k68 gold badges702 silver badges919 bronze badges asked Feb 3 at 21:23 user66001user66001 9071 gold badge15 silver badges37 bronze badges 11 | Show 6 more comments1 Answer
Reset to default 1You 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.
本文标签:
版权声明:本文标题:powershell - How to determine if user has admin rights, but script not running elevated - Stack Overflow 内容由网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:http://www.betaflare.com/web/1741797178a2398003.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
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:30CN=Domain Admins,CN=BuiltIn...
orCN=Administrators,CN=BuiltIn,...
is a local Administrator @mklement0 – Santiago Squarzon Commented Feb 3 at 22:13