I am making some fundamental changes to a Windows Server 2003 / 2008 environment. On the Unix side, my security constraints are simple:

  1. Users who should have admin rights are in a special group ("wheel" or similar).
  2. When those users log onto those machines, they still don't have admin rights, until they explicitly execute a command with those admin rights ("sudo command" or "su").
  3. Even when they do execute the command with "su" (sort of like "runas"), they still need to enter a password: their own.

In this system, I can control who has admin privileges (by group membership), prevent them from accidentally executing something with admin privileges by accident (by requiring "su" or "sudo"), and never reveal a core "Administrator" (i.e. "root") password, since they are asked for their own.

How do I do the equivalent on Windows Server? The options as I see it are:

  1. Add user to local administrators account: But then everything they do is as admin, risking error.
  2. Require them to do "runas Administrator": But then they have to know the Administrator password, which I do not want shared around.

Is there any solution wherein I can simultaneously: control who has access by group membership; prevent them from accidentally doing damaging things by requiring a separate password; prevent them from ever knowing the Administrator password?


First off, only administrators should get admin access so unless there is a HUGE (I can't think of a good one) reason they need it, then it should be left to the admins; there are rare occasions when a regular user gets admin privs, and even then I'm usually skeptical about why they need it.

Second, you can accomplish what you want to do by using Group Membership in Windows. You didn't say that you were using Active Directory so I'm not sure if you have a domain and are doing that, but you can create Security Groups and add individual user accounts to them. See here. I wouldn't add users to the local administrators group on the server individually as this will get messy and be hard to keep track of down the road, and it will make for a lot of headache for you and potential security issues. What I would do, as mentioned above, is to create a Security Group and add the members that you want to have admin access to this group. You'd create two user accounts for your users; one for regular login, and then a 2nd account that was only used for elevated actions. You'd add the users "higher/privileged" account into the Security Group, then, you can put this group in an elevated local group membership on the actual server say Power Users for example. This will allow them to perform a lot of functions without being admins. Sometimes the group will need local admin access and at that point you can put the group into that local admin group on the server.

As far as Run As Administrator, you don't have to do that all the time. The best way to have people run things without knowing the Administrator, or any administrator, password is to use Shift+Right-click and then select Run as different user, or Right-click and Run as Administrator. You'd first want to create a separate user for them that has higher rights, or elevated rights as mentioned above(this elevated user would be added to the Security Group again as mentioned above) as then this user could be used to run things that require elevation all the while being logged in with a normal/standard user account. See my screenshot:

enter image description here

That should take care of what you're wanting to do as far as running things as admin. One final note I might add is to keep UAC on. If you do this, the users will be required to type in their (elevated) password and not an admin password for things that they do on the server. It is a pain when you have to type it in a lot, but for security it's worth it.

| improve this answer | |
  • this is exactly what the other 2 suggested. You are right, we are running AD, and we will add them to a servers admin group, which will have local admin privileges. – deitch May 15 '14 at 14:35
  • RE: Run as Administrator, any administrative credentials will do. If the account you're logged in on doesn't have administrative credentials, you'll be prompted for both a username and password, and can input an administrative account there. Your post doesn't really make this clear. – HopelessN00b May 15 '14 at 14:36
  • And in this case, I am talking about sysadmins. Good security practice is for sysadmins not to have a production/system account password, only to run things as their own account. I want to extend this to sysadmins. – deitch May 15 '14 at 14:36
  • 1
    @deitch Yup, this is exactly what we do at $[dayjob]. All us IT folks have normal user accounts and administrative accounts. Log into everything as limited users, and execute the Run as Administrator option for anything that needs elevation. local admin users are not used unless they have to be (domain trust broken, etc.) – HopelessN00b May 15 '14 at 14:39
  • 2
    @HopelessN00bGeniusofnetwork, so RunAsAdministrator doesn't mean, "Run as Administrator account", it means "Run as any account that has Administrator privileges, as long as you can provide credentials for any such account"? – deitch May 15 '14 at 15:03

Leave their standard account as 'standard'. Create them a privileged second account and add that to the various Administrative groups. Use 'runas' with the privileged account. (You may find it useful to disable interactive logons with the admin account, but then again - this will probably get annoying).

| improve this answer | |
  • 1
    I get it. So you have 2 accounts: Sobrique and SobriqueA. SobriqueA is blocked from logging into any systems on a console/remote, can only do runas. SobriqueA is member of a group with admin privileges. User logs on as Sobrique, then does "runas SobriqueA" which requires SobriqueA password, and all such commands run with full admin privileges. It is a bit convoluted, but could be worse. – deitch May 15 '14 at 14:33
  • 2
    That is correct. – Brad Bouchard May 15 '14 at 14:37
  • 1
    +1 for addressing disable interactive logons. Otherwise users would just login with the administrator credentials and be subject to OP's worry about every action as an admin. – Byron C. Jun 12 '14 at 22:50

In Server 2003, you'd need to use the Run As... option to run as an account with administrative privileges.

With Server 2008+, you use UAC, and/or the Run as Administrator option you suggested. This doesn't require knowing the password to the [local] administrative account - any administrative credentials will do.

So you'd add their accounts to the local administrative groups, or better, from a security point of view, create separate administrative accounts and add them to the local administrative groups. Then, when they need to run something with administrative privileges, UAC will prompt for administrative credentials and/or they'd use the Run As.../Run as Administrator option.

| improve this answer | |
  • This is very similar to @sobrique's answer. So Win thinks of accounts as either having admin privileges or not? And it doesn't have a concept of "this account has the right to run things as admin if it explicitly asks and reauthenticates"? – deitch May 15 '14 at 14:34
  • 1
    Basically, no. Windows has a bunch of security rights - usually those rights are given to a group (because per user is nasty). Membership of the group confers the rights. What's common practice is just logging in using an admin account, because it's easy - but that doesn't mean it's right. We've got local user accounts and domain admin accounts that we use to log into management servers (which have assorted Windows management tools installed). – Sobrique May 15 '14 at 14:41
  • You could fiddle with 'secpol.msc' and configure a custom rights profile - grant access to a 'not exactly Administrators' group, and add the basic user accounts to that. But you will probably still trip over a need for a 'proper' admin account anyway. – Sobrique May 15 '14 at 14:44
  • 1
    @deitch Well, that's essentially what UAC is/allows. It allows you to run as administrative account, but be prompted for anything that requires "elevation." (Split-token authentication.) It's not technically a matter of Windows creating a "Administrator or not administrator" dichotomy, but that running something as an administrator is such a common feature that it's given a specific menu option. In most cases, this option is not strictly necessary (you could always just run as another user, who happens to be an administrator), but it's just more convenient to have that menu option there. – HopelessN00b May 15 '14 at 14:44
  • 1
    Well, John will still need to know the credentials for an administrative account to run something as an administrator - it just doesn't have to be the administrator account. – HopelessN00b May 15 '14 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.