Pseudo-Admin vs Run as Administrator?

  • Thread starter Thread starter Gerry Hickman
  • Start date Start date
G

Gerry Hickman

Hi,

What's the difference between installing / running a program as the
Pseudo-Admin - and accepting UAC prompts, as opposed to launching the
process with "Run as Administrator"?

Am I right in thinking "Run as Administrator" does not actually run as
the "MACHINE\Administrator" account (because it's been disabled)?
 
Hello,

The behavior of run as administrator depends on the type of user account as
well as group policy settings.

In Windows Vista, when a user logs in the system creates two security access
tokens for the user. One is their "normal" access token, granting them all
the privileges and group memberships they are supposed to have. The other is
a "filtered" token, which only grants them the "default" privileges normal
users need and ignores the user's membership in the administrators group
when determining access to a resource (except for deny permissions, these
are never ignored).

When UAC is turned on, the access token given to a running program depends
on how much privileges the programs requests. For legacy applications that
do not specifiy what privileges they need (they do not include a manifest or
have not been identified by the Windows app-compat database), they will
always receive the filtered token.

When you right-click an application and click Run As Administrator:

1) If the user is logged in as an administrator AND group policy action is
set to "consent"

All the user has to do to run the program is click the "Continue" button.

The unfiltered user token created when the user logged in contains all the
privileges that the program is requesting. In this case, all Windows does is
run the program with the unfiltered token instead of the filtered token.

2) If the user is NOT logged in as an administrator OR the user is an admin
and group policy is set to "credentials"

In this case, an administrator is required to log in, because either the
unfiltered token of the user does not have all the privielges the program is
requesting (because the user is not an administrator), or group policy has
been set saying an administrator must always log in when running a program
requesting admin privileges, even if the logged-in user is an administrator.

Here, the elevated token is not used. Windows impersonates the administrator
account used to authenticate with the elevation prompt and runs the
application from the user account of that administrator, and NOT from the
user account that is currently logged in.

This is the same behavior you would find using the Run As command from
Windows XP.

In neither situation does the program run from the user profile of the
disabled administrator account, unless you enable the account and use it to
authenticate with a UAC prompt requesting credentials.
 
Whoops, I guess I didn't actually answer your question :).

The behavior of using Run As Administrator on a program is equivalent to
running a program that is marked as requires administrator privileges.
 
Hi Jimmy,

OK, the first post I understand about the filtered token, much of the
rest is too confusing to worry about right now. I'll try to pull out two
key points for clarification:

1. Does the filtered token nonsense only occur with INTERACTIVE
Pseudo-Admin logins to the local machine? In other words if I start a
process form a remote Win2k box on a Domain Joined Vista box, it will
run as what ever I tell it to run as (provided it has access) and UAC
will be ignored even when I perform privileged operations such as
telling it to reboot or clearing the security log?

2. When I choose "Rus as Administrator", you've already said the
Administrator profile will NOT be used. My question is, which user is
running this process; is it the Pseudo Admin, MACHINE\Gerry, or is it
the real (disabled) built-in MACHINE\Administrator account?

In the case of #1, I did quite a bit of testing today and nothing
triggered UAC. Interesting as hackers will probably use the same
technique, but also good because easier to fix 1000 hacked machines.

In the case of #2, I'd be very concerned if the genuine local
Administrator profile was NOT being used, which you appear to be saying
it won't. Any corporate would need to be absolutely clear which profile
was going to be loaded by which remote process for any kind of
installation, and also they'd need to know that profile will still exist
in three years time when you need to uninstall stuff. In my last build,
I used the build-in Administrator account for this and the All Users
profile. I like the security of it, because it can only access LOCAL
resources.
 
1. Does the filtered token nonsense only occur with INTERACTIVE
Pseudo-Admin logins to the local machine? In other words if I start a
process form a remote Win2k box on a Domain Joined Vista box, it will
run as what ever I tell it to run as (provided it has access) and UAC
will be ignored even when I perform privileged operations such as
telling it to reboot or clearing the security log?
Click to expand...

First, to be clear, using Remote Desktop to connect to a computer behaves
exactly as if you were sitting in front of the remote terminal with respect
to UAC (I'm sure you already know this, but I want to add this here just for
the sake of completeness :).

Before moving on to how it works via network-based authentication, I would
like to clarify how UAC works when logged in interactively ...

Instead of thinking of the admin accounts as "pseudo admin", think of them
as "admin with confirmation". The admin accounts have all the privileges that
they would have in XP ... the only difference is, in Vista, only the
processes you allow can use the admin privileges.

Processes designed for Vista will automatically ask for this privilege when
they run if they need it (Windows needs your permission to continue, the UAC
dialog). Or, to force a program to have admin power, you can right-click it
and click run as administrator.

The point I am getting at, is when you are logged in as an administrator,
Run As Administrator does not run the program inside of another user profile.
It runs inside of YOUR user profile.

The only time impersonation is done is when you are running inside of a
standard user account or you have changed the default UAC settings. In this
case, a program that prompts for permission or right-clicking and clicking
Run As Administrator will prompt for an admin to log in in order to continue.

In this case - where it prompts for a log in - the program will be running
inside of the user profile of the admin who authenticated with the dialog.

To sum it up - If it asks for CONSENT (Continue or Cancel) it runs inside of
your account - If it asks for CREDENTIALS (log in to continue) it runs inside
of whatever account authenticates with the dialog.

Now, on to how it behaves over the network ...

When you authenticate with a Windows Vista machine, everything works exactly
as it did in XP ... (drumroll) ... EXCEPT with the case of local
administrators. In Vista, by default, local administrators CANNOT use their
admin powers over the network. DOMAIN ADMINISTRATORS, however, are not
limited at all, and work exactly like they did in XP.

Over the network, everything runs under the account that you are
authenticated with; however, with local administrators, by default, they are
not allowed to use their admin powers. Everything else works as expected.
2. When I choose "Rus as Administrator", you've already said the
Administrator profile will NOT be used. My question is, which user is
running this process; is it the Pseudo Admin, MACHINE\Gerry, or is it
the real (disabled) built-in MACHINE\Administrator account?
Click to expand...

It is MACHINE\Gerry, the administrator.

The only time "Run As Administrator" runs the process under a different
account is if you are logged in as a standard user or are using non-default
UAC settings.

Regardless of what happens, processes will always, *ALWAYS* run inside the
account of whoever authenticated. Regardless of if its over a network or
interactive. If you don't authenticate when a process runs, it is running
under your account. If someone else authenticates in order to get the program
to run, then it runs under THEIR account.
In the case of #1, I did quite a bit of testing today and nothing
triggered UAC. Interesting as hackers will probably use the same
technique, but also good because easier to fix 1000 hacked machines.
Click to expand...

Could you be more specific? UAC prevents programs from doing anything
admin-related. If something doesn't prompt for UAC, it CANNOT do an
admin-related task.
In the case of #2, I'd be very concerned if the genuine local
Administrator profile was NOT being used, which you appear to be saying
it won't. Any corporate would need to be absolutely clear which profile
was going to be loaded by which remote process for any kind of
installation, and also they'd need to know that profile will still exist
in three years time when you need to uninstall stuff.
Click to expand...

There is no hocus-pocus going on, lol... the account things are running
under is the one you authenticate with. This always holds true.
In my last build,
I used the build-in Administrator account for this and the All Users
profile. I like the security of it, because it can only access LOCAL
resources.
Click to expand...

- JB
 
Hi Jimmy,

Thanks for info below.

Here's a more simple question. Does "Run as Administrator" actually run
as MACHINE\Administrator?

I'm guessing the answer is NO! The account sits there disabled?

So why have something that says "Run as Administrator".
 
It depends on if the present user is an administrator or a standard user. If
the present user is an administrator then when using Run as administrator
the process is run in the context of the present user with full admin
privileges. If the present user is a standard user then the process will get
the full privileges and run in the context of whatever user you supply
credentials for.

I'm guessing it says "Run as administrator" because "Run with administrator
privileges" was too long and possibly confusing to Windows users. Maybe it
should have just said "SU".

I know it's really not the same, just joking :-)
 
Hi Jimmy,
When you authenticate with a Windows Vista machine, everything works exactly
as it did in XP ... (drumroll) ... EXCEPT with the case of local
administrators. In Vista, by default, local administrators CANNOT use their
admin powers over the network.
Click to expand...

But they can't in earlier Windows versions either? I mean if you log
into an XP box as MACHINE\Administrator you don't have any access to
network resources until to NET USE them and supply connection credentials?

What _does_ seem different in Vista is you can't use local Admin
credentials on MACHINE1 when connecting from MACHINE2 in a Workgroup
scenario? This could be an issue if you need to remotely join 2000 Vista
boxes to a domain after a Virus has trashed the secure channel...
DOMAIN ADMINISTRATORS, however, are not
limited at all, and work exactly like they did in XP.
Click to expand...

This is the interesting bit, and this is what surprised me when doing
the testing, I was able to do lots of things to the box using a DOMAIN
ADMIN account without any UAC problems.

However, what about DELEGATED Admins, when you use Active Directory you
can set Admin delegation to specific OUs. Do the delegated accounts work
the same as DOMAIN ADMIN accounts?
 
Hi Jimmy,

Hello :)
But they can't in earlier Windows versions either? I mean if you log into
an XP box as MACHINE\Administrator you don't have any access to network
resources until to NET USE them and supply connection credentials?
Click to expand...

Well, you are not given access to a resource until you authenticate with
that computer, true; but, what I am getting at here, is that on Vista, once
you authenticate with the vista machine as an administrator local to that
box over the network, your resulting access token is filtered in the same
way that it would be if you were logged in at the console with UAC enabled
and ran a program that did not request admin power.

For example: you have an admin account set up on VISTAMACHINE, and log in to
VISTAMACHINE from your other computer XPMACHINE via the network (net use or
whatnot), and try to access VISTAMACHINE's administrative share C$.
Technically you have access to that share; however, due to the token
filtering, you are returned access denied, since the system is ignoring the
fact that you are an administrator.
What _does_ seem different in Vista is you can't use local Admin
credentials on MACHINE1 when connecting from MACHINE2 in a Workgroup
scenario?
Click to expand...

You can use the credentials to authenticate; however, they will not have any
admin privileges assigned to them.
This could be an issue if you need to remotely join 2000 Vista boxes to a
domain after a Virus has trashed the secure channel...
Click to expand...

You're right. Luckily, this setting can be changed to allow admins to use
their admin powers over the network.
This is the interesting bit, and this is what surprised me when doing the
testing, I was able to do lots of things to the box using a DOMAIN ADMIN
account without any UAC problems.

However, what about DELEGATED Admins, when you use Active Directory you
can set Admin delegation to specific OUs. Do the delegated accounts work
the same as DOMAIN ADMIN accounts?
Click to expand...

Great question! I don't know, and I don't have a domain set up to test this
at the moment. I believe the correct behavior would be to allow this to
work.


--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/
 
Back
Top