Common scenario: you log on with your Windows domain account, which you have removed from the Administrators group (as well as from Power Users, Backup Operators, etc.). When you need to perform tasks that require elevated privileges, you use RunAs to start a program with the local Administrator account. You quickly realize two things:
- The program running as local Administrator cannot access network resources, since your local account is recognized only on your own computer; and
- Any per-user settings apply to the local Administrator’s profile, not to the profile you normally work with.
The first problem often occurs when installing software from a network share, or an ActiveX control from an intranet site that uses Windows authentication. An area where the second problem crops up is with applications that assume that it will be installed by the same user who will use it. Some apps also have a “run-once” problem, in which the app needs to be executed one time with admin privileges. For some, such as Windows Messenger 4.x, each user has to run it one time with admin privs.
The per-user settings problem also occurs with the Power Options applet in Control Panel, which modifies both per-machine and per-user settings. When you use it from an unprivileged account, an error occurs writing the per-machine settings, so the per-user settings never get written. When you use it from the local admin account, the per-user settings you write are for the local admin account, not the account you normally use.
There are a number of ways to address the network access problem. The first of these that I’ll describe also addresses the user profile problem.
Elevating your normal account to admin
The only effective way I know of to address the user profile issue is to make your “normal” account an administrator. The trick is to do it for the least amount of time necessary.
The long and painful way
Using an admin account, you can add your normal account into the Administrators group, but that change doesn’t take effect until the next time you log on. If you’ve tried this, you’ve probably noticed that it’s a pain to add your domain user account into the Administrators group using the GUI – first you need to use RunAs to run the Computer Management / Local Users and Groups console; you then get prompted for network credentials to resolve the domain names because your local admin account isn’t recognized. And then when you’re done with all that, your current logon still doesn’t have admin privileges because changes to groups and privileges only take effect on subsequent logons. Finally, you need to remember to remove yourself from the Administrators group and then log back in again to make that change take effect.
“MakeMeAdmin”
MakeMeAdmin.cmd addresses all of these issues. When you run it, you get a Command Prompt running under your normal user account, but in a new logon session in which it is a member of the Administrators group. This Command Prompt and any programs started from it use your regular profile, authenticate as you on the network, but have full local admin privileges. All other programs continue to run with your regular, unprivileged account.
How does it work? Remember a moment ago when I mentioned that changes to groups and privileges take effect only on subsequent logons? The critical thing to understand is that you do not actually need to log out in order to log on. If you use RunAs to start a process with your current account, it creates a new logon session and builds a new token, taking into account group memberships in effect at that instant. MakeMeAdmin.cmd invokes RunAs twice, prompting you first for your local admin password, then for your current account password. The bit that runs as local administrator does the following:
- Adds your current account to the local Administrators group (using NET LOCALGROUP, avoiding the problem of needing network credentials to resolve names);
- Invokes RunAs to start a new instance of cmd.exe using your current account, which is at this instant a member of Administrators;
- Removes your current account from the local Administrators group.
The result of the second step is a Command Prompt running in a new logon session, with a brand new token representing your current account, but as a member of Administrators. The third step has no effect on the new cmd.exe’s token, in the same way that adding your account to Administrators does not affect any previously running processes.
The zip file also includes a less-privileged version, MakeMePU.cmd, which temporarily elevates you to Power Users instead of Administrators.
|
A very brief bit about processes and tokens
I’ll try to keep this as brief and broad-brush as possible. What follows is not 100% accurate and complete, but if you’re unfamiliar with the concepts I think you might find it helpful:
- Every program in Windows runs in a “process”. A process may display zero or more windows. You can see a list of the running processes by starting Task Manager and clicking on the “Processes” tab. If you click on the “Applications” tab, then right-click on one of the items listed there and choose “Go To Process”, it will show you which process that “application” is running in.
- A “token” identifies a user, the Windows groups that user belongs to, and a set of system privileges, such as the ability to change the computer’s clock. When a user logs on (including with RunAs), the system creates a new token for the user, determining at that time what groups the user is a member of and which privileges the user should have. Once a token is created, one can’t add or (generally) remove any groups or privileges from the token.
- Every process always has a token. In almost all cases, its token is a copy of that of its parent process (the process which started it).
- Whenever a process tries to access a securable object (such as a file or a registry key), an access check is performed by comparing the process’ token to the “access control list” (ACL) of the object. The result of that access check determines whether the requested access is allowed or denied.
|
Addressing the network resource access issue
If you prefer to use the local administrator account, but need to use your domain account for network access, there are a couple of other approaches:
From your local admin Command Prompt, you can simply NET USE to authenticate to the specific resources you need to access. You need to authenticate separately this way for every remote computer you wish to access. NET USE is logon-session specific, so any connections established in one Command Prompt affect only processes started within the same RunAs session.
Another commonly used approach is to use RunAs with /netonly. The /netonly option starts the target process in a new logon session with the current token, but with the account you specify for all SSPI-based network access. You can kind of think of it as implicitly calling NET USE for every remote computer you try to access. Here’s how you might use it (ignore word-wrapping – this should be one line):
runas /u:%COMPUTERNAME%\Administrator "runas /netonly /u:%USERDOMAIN%\%USERNAME% cmd.exe"
(If you have renamed your builtin Administrator account, change “Administrator” to the new name.)
As with MakeMeAdmin, RunAs is used twice and you’ll get prompted for two passwords: that of the local Administrator, and that of your current account. What you’ll get is a Command Prompt running under the local Administrator account, using the local Administrator profile, but authenticating on the network with your domain account. (Confusingly, the title bar will say that you’re running as the domain user rather than as the local administrator.)
Tradeoffs of MakeMeAdmin vs. using the builtin Administrator account
Personally, I prefer using MakeMeAdmin. The main issues I have run into with MakeMeAdmin are 1) telling privileged from unprivileged apps, 2) Explorer issues, and 3) issues with objects created while running with elevated privilege.
1. Telling privileged from unprivileged apps
In two previous posts, I echoed Keith Brown's suggestion to change the admin’s background bitmap for Explorer and Internet Explorer so that you could tell your admin windows from your non-admin ones. But with MakeMeAdmin, you can have different IE and Explorer windows all running as “you”, but some with administrator privileges and others not. The background bitmap settings are associated with user accounts, not with privilege levels, so they don’t help you in this scenario.
I promised to provide a solution. It’s called PrivBar and it adds a toolbar to your IE and Explorer windows that lets you know at a glance at what privilege level that particular instance is running. At this point I will have to postpone it to a future post – this post is already very long and very overdue! I will try to post it really soon!
2. Explorer issues
If you want to start explorer.exe from a MakeMeAdmin context, you need to set the Separate Process flag for your normal account, and you must start explorer.exe with /root, in the command line unless there are no other Explorer windows running. For more information, read my post about using RunAs with Explorer, paying close attention to “More info about Explorer’s Separate Process flag” and the references to explorer.exe command line options.
3. Objects created while running with elevated privilege
Normally, when a user creates a securable object, such as a file, folder, or registry key, that user becomes the “owner” of the object and by default is granted Full Control over it. Prior to Windows XP, if the user was a member of the Administrators group, that group, rather than the user, would get ownership and full control. The user still had ownership and control over the object by being a member of Administrators. But if you created objects while a member of Administrators and then were removed from the group, your subsequent use of those objects could be limited or completely denied. Windows XP introduced a configurable option whether ownership and control of an object created by an administrator would be granted to the specific user or to the Administrators group. The default on XP is to grant this to the object creator; the default on Windows Server 2003 is to grant it to the Administrators group.
I’m not on the Windows team and was not party to the thinking that went into exposing this option and establishing its defaults. My guess is that it was that on the server, all admins are equal. If I’m an admin on a server and I create an object and am later reassigned or leave the company, any other admin should be able to access and manage the objects I created without any trouble. A workstation, however, is more likely to be a single-user device. Objects I create on my computer, such as documents, should remain under my control even if I change myself from a Computer Administrator to a Limited User (to use XP Home Edition’s terminology). I think this makes a lot of sense.
However, MakeMeAdmin changes things. If I use MakeMeAdmin to install programs, my normal account will be granted ownership and full control over the installation folder, the program executable files, and any registry keys the installation program creates. Those access rights will remain even when I am no longer running with administrator privileges. That’s not what I want at all. I want to be able to run the app, create and modify my own data files, but not to retain full control over the program files after I have installed it. For this reason, I changed the “default owner” setting on my computer to “Administrators group”.
To view or change this setting, open “Local Security Policy” in Administrative Tools, or run secpol.msc. You need to be an admin to use this tool. In the left pane, browse to Security Settings \ Local Policies \ Security Options. The policy name is “System objects: Default owner for objects created by members of the Administrators group”. The allowable settings are “Administrators group” or “Object creator”.
Coming Real Soon
- PrivBar
- Running with a restricted token (what does “protect my computer and data from unauthorized program activity” actually mean)
- ???
SFC
