locked
Elevating/Accquiring the Admin Token in Administrator vs Standard Accounts in Windows RRS feed

  • Question

  • I was told to post this to TechNet from Microsoft Answers, and it best belongs in the Security Forum Category. I'm not so sure about this forum specifically,

    I've recently been confused by how UAC works between Standard accounts and Administrator accounts,

    As we all know, when UAC is turned on, UAC allows Standard Accounts or Administrator accounts in Admin Approval Mode to gain access to the administrator token in order to perform tasks that require administrative access to the machine - allowing us to switch tokens without switching users,

    However, it appears that switching tokens is not really what happens: A while ago, I ran an application that would modify the shell (explorer.exe). I ran the program in a Standard Account, but it needed elevated access: therefore, I used UAC to supply admin credentials so it could complete. I did not seen any change to the shell; I then logged into the administrator account whose credentials I used and I saw that the shell in that account had been changed, which was obviously not what I wanted

    It appeared to me that UAC was just basically a "Run-as user" type deal where it actually ran the program as that user. This meant that I wasn't just running it elevated: I was literally running the program as that user,

    My question is: is it possible for a standard account to use the administrator token but actually run the program as a standard user and use the current user's profile? Otherwise, it seems to me that if you need to do any administrator tasks, you are pretty much required to log in to an administrator account which defeats the whole purpose of UAC - since UAC runs a program as the administrator, rather than using just the administrator rights,

    Is this separation of token and profile possible? Or do all users just have to be administrators in that case? It seems to me this would account for many organizations just granting full administrator access to all users,

    Can someone please shed some light on this?

    I would like to know if it would have been possible to supply an administrator token to the said program, but run that program in the current user account, not the user account of the administrator whose credentials were supplied - in other words, would it have been possible to modify the shell in the Standard account with that program? The goal would be to launch the process as the logged in user (regardless of current privileges) with administrative rights, not as a process under an account with admin rights.

    I am not referring to Admin Approval Mode or how UAC works. I already know that if UAC is set to a secure setting, even Administrators will be prompted and unless it is turned off, administrators use the standard token by default. I am talking about when the administrator token is gained, is it possible to still run the process as the logged in user, just with the admin token? (not using Run As 'user' but maybe something like run as/with 'token'), etc... In this way, it would be using generic administrative privileges rather than one user's administrative privileges.

    Is this at all possible, or have I just pointed out a feature not in Windows by design or something?

    Would I, to achieve the goal described here, have to perhaps turn the standard account into an administrator account any time anything that requires elevation needs to be done, and then turn it back into a standard account when done? Based on comments, it appears that this is not possible and that seems to be a flaw in the OS because it makes UAC basically useless.

    Hope this makes sense,


    InterLinked CEO

    Wednesday, June 22, 2016 9:30 PM

All replies

  • It depends upon the software in question, and if that software is correctly written to operate with UAC or not.
    There is plenty of software around which doesn't properly interoperate in a SUA/LUA model and not with UAC/AAM/Session 0 isolation.

    I see that a lot :(

    This article talks about the topics a bit: https://technet.microsoft.com/en-us/library/cc772207(v=ws.10).aspx

    There is plenty of reading to be done, but my experience in our enterprise environment showed us that we needed to look outside of what Windows offers and seek 3rd party software to extend the Windows offering. We selected Avecto Privilege Guard/DefendPoint to give us the ability to elevate a whitelist of processes/applications, this allows a form of sudo on Windows, where the logged-on standard/limited user attempts an action which Windows would normally demand admin-token for, which the user cannot satisfy either natively, or, a context-switch to another user identity would mean the software doesn't operate as needed. So what we now have is this product from Avecto which essentially inspects the executing thread, compares it to a whitelist and if allowed by the whitelist it cracks open the current user token and injects the admin privilege into the token and then passes the thread on to Windows. Windows then says "why sure, you have the correct privilege to execute that".

    This solution is not without it's quirks but it has allowed us to continue our programme of "demoting" a large estate of local-admins down to standard/limited users, towards our goal of least-privilege.

    In your scenario, you are extending the shell, and the shell is a per-user thing. If the shell extension (or maybe the installer/registration for it) isn't properly UAC/AAM aware, I can see how you'd have this problem.

    If the shell extension is installed by an admin-level thread, do all other user identities on the machine then have access to the shell extension?

    If not, that may be another limitation of this shell extension (or perhaps a limitation of the installer/registration routine for this shell extension)?

    I've learnt an awful lot about this topic in the last 4 years and it certainly isn't straightforward when you are trying to get hundreds of legacy/bespoke applications written years ago for WinXP, by multiple vendors, to function in an SUA/LUA scenario.


    Don [doesn't work for MSFT, and they're probably glad about that ;]


    • Edited by DonPick Wednesday, June 22, 2016 10:02 PM
    Wednesday, June 22, 2016 10:01 PM
  • I use the shell thing as an example, but it did occur a few years back,

    I'm just wondering about Windows in general: if in an account without admin rights, you can run a process as the logged in user but give it "administrative" permission, using an administrator's credentials. From what I've seen, UAC will literally just run the process as the administrator. I want to know if you can run with a generic "system admin" token, but run the process as the current user.

    For example, if the standard user is "StandardUser" and the admin is "Admin44",

    Can I when logged in as StandardUser, at UAC, enter the credentials for Admin44 but the process continues to run as StandardUser. Would it be able to use Admin44's rights to secure a generic admin token and use that?


    InterLinked CEO

    Wednesday, June 22, 2016 10:09 PM
  • I use the shell thing as an example, but it did occur a few years back,

    I'm just wondering about Windows in general: if in an account without admin rights, you can run a process as the logged in user but give it "administrative" permission, using an administrator's credentials. From what I've seen, UAC will literally just run the process as the administrator. I want to know if you can run with a generic "system admin" token, but run the process as the current user.

    For example, if the standard user is "StandardUser" and the admin is "Admin44",

    Can I when logged in as StandardUser, at UAC, enter the credentials for Admin44 but the process continues to run as StandardUser. Would it be able to use Admin44's rights to secure a generic admin token and use that?


    InterLinked CEO


    AFAIK, No, Windows can't do that. But PG/DP *can* do that through a fairly clever manipulation of some inter-process communication which 'bends' the rules a fair bit.

    Don [doesn't work for MSFT, and they're probably glad about that ;]

    Thursday, June 23, 2016 9:31 AM