How to tell if my user account is a privileged account?

0

I'm looking for a nuts and bolts answer to this, so if that means digging in to SDDL (or whatever...I want to SEE the "token"), I'm ok with that.

UAC policy settings have two consent behavior options:

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode User Account Control: Behavior of the elevation prompt for standard users

How can I tell (while logged in as the user) if a user account is currently assigned an admin token so that it is not considered a standard user account or if it's an admin not in admin approval mode?

lightwing

Posted 2017-01-11T15:20:47.130

Reputation: 83

I did find the whoami /all command, but I don't think this is helping. Unless, I can use the SeImpersonatePrivilege to tell me this. I'm not sure if having this privilege is related to being an admin in admin approval mode or not. I did see this when running the command under a command prompt that was executed as administrator and using a domain account with local admin rights. The same account does not have this privilege when launching a command window only as that user. – lightwing – 2017-01-11T15:30:24.033

Just verify which usergroup they are in. – Ramhound – 2017-01-11T15:47:48.157

But that doesn't tell me if it currently has the full administrator token in the case where the account is an admin and UAC is on. I think I just found my answer though... https://blogs.msdn.microsoft.com/sqlupdates/2015/05/20/understanding-user-account-control-uac-a-brief-summary/

– lightwing – 2017-01-11T16:13:01.577

@lightwing It'd be nice to see your answer posted here. – Clijsters – 2017-01-11T18:44:32.847

@Clijsters soon as I have one. There's some stuff I found about certain security event log entries, but I can't find them on my devices (eventid 4688 and 4689), despite clearly entering my creds to gain the elevated token. The link I shared above, I tweaked the powershell script to get it to work, but it's not returning any data. I think the answer does lie somewhere within the event log, just haven't found it yet. – lightwing – 2017-01-11T19:25:51.967

Tested it with Get-EventLog -LogName Security | Where-Object InstanceId -EQ 4688 and it returned events. Keep in mind that Message ist language dependend. eg. It would never work on my german machine... – Clijsters – 2017-01-12T11:02:53.437

Good point. I discovered last night that you have to have Audit process tracking enabled (which we apparently don't), or you'll never see any 4688 or 4689 events. locally: secpol.msc security settings -> local policies -> audit policy -> Audit Process Tracking – lightwing – 2017-01-12T12:40:59.140

Answers

0

Best solution I could find so far is a combination of things:

  • whoami /all

    1. look for builtin\administrators group membership

  • check security event log for eventids 4688 and 4689

    1. Be sure to turn on Audit Process Tracking locally: secpol.msc security settings -> local policies -> audit policy
    2. Get-EventLog -LogName Security | Where-Object {($_.eventid -eq 4688) -or ($_.eventid eq 4689)}
    3. Look for the token elevation type in the message of these events:
  • "%%1936" Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account or a service account.
  • "%%1937" Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator. An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group.
  • "%%1938" Type 3 is a limited token with administrative privileges removed and administrative groups disabled. The limited token is used when User Account Control is enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator.

Thanks to @Clijsters comments above, and to the author of the blog entry here: https://blogs.msdn.microsoft.com/sqlupdates/2015/05/20/understanding-user-account-control-uac-a-brief-summary/

Note on the powershell script in the blog: her script doesn't work if you copy and paste it. You'll need to do some tweaking of your own.

Note on Windows OS versions: Regarding Windows Vista and 7, I'm finding differing information regarding the event log entries. The above findings are based on my testing on Windows 10. Searching around the internet, in Windows 7 and Vista, the event log entries appear to be more straight forward regarding the Token Elevation Type data as described in the "How do I audit elevation?" section of this article: http://programming4.us/security/646.aspx Rather than obfuscating the token type, Win7/Vista apparently give it to you straight as a 1, 2, or 3. YMMV

lightwing

Posted 2017-01-11T15:20:47.130

Reputation: 83

Asked: 2017-01-11T15:20:47.130

Viewed: 1 734 times

Active: 2017-01-12T13:09:47.397