Windows Server Hacks: Disable "Run As"by Mitch Tulloch, author of Windows Server Hacks03/16/2004 |
While the Secondary Logon feature can help administrators do their jobs more securely, you may not want ordinary users to have access to this feature.
Most administrators prefer to perform their system administration tasks comfortably seated in their office instead of standing, freezing to death in a noisy air-conditioned server room. By installing the Windows Server 2003 Administration Tools Pack on a Windows XP Professional workstation with Service Pack 1 applied, administrators have access to the full slate of administrative tools (both GUI and command-line) and can administer their back-room servers remotely from their quiet, heated office. (A similar set of tools is available on the Windows 2000 Server product CD for administering Windows 2000 servers from Windows 2000 Professional workstations).
Once these tools are installed, best practice dictates that administrators should have two user accounts: a Domain Admins account for performing administrative tasks, and a Domain Users account for ordinary work like browsing the Web, writing reports, and checking email.
The value of the "Run As" command then becomes obvious when an administrator is in the middle of writing a report and suddenly is called on to reset his boss' password. Instead of having to save his work, log out, log on as administrator, reset the password, log off, log on with his ordinary account, and resume working on his report, he can instead simply open a command prompt and type:
runas /user:admin_account\domain "mmc C:\Windows\system32\dsa.msc"
Once he does that, he can supply his password when prompted to open the Active Directory Users and Computers console using admin level credentials, use this console to reset the boss' password, and then close the console and resume writing his report.
But what if you don't want ordinary users to have access to the Run As feature on their own desktop machines?
|
Related Reading Windows Server Hacks |
Active Directory
If you're running Active Directory on your network, then a simple way to disable Run As on Windows XP desktops is to use the new Software Restriction Policies feature of Group Policy in Windows Server 2003. To do this, create a Group Policy Object (GPO) for this purpose and link it to the organizational unit (OU) where users' desktop computers reside. Then open the GPO in the Group Policy Editor and locate the following node in the console tree:
Computer Configuration/Windows Settings/Security Settings/Software Restriction Policies
Right-click on this node and select New Software Restriction Policies, as shown in Figure 1 below:

Figure 1. Configuring Software Restriction Policies for all computers in the Boston OU.
This creates a default set of Software Restriction Policies that you can now configure further. To prevent the runas.exe command from executing on the computers affected by this GPO, right-click on Additional Rules and select New Path Rule, as shown in Figure 2:

Figure 2. Creating a new path rule.
Now type the path to runas.exe and make sure the policy is set to disallowed, as shown in Figure 3:

Figure 3. Disallowing execution of runas.exe on the computers affected by the policy.
|
More on Software Restriction Policies Software Restriction Policies is a powerful feature of Windows Server 2003 and Windows XP, but it has lots of intricacies you need to be aware of. For a quick tour of this feature see article 324036 in the Microsoft Knowledge Base, and for a more detailed look at how the feature works see this paper on Microsoft TechNet. And for an example of a practical application of using the feature to prevent common spyware and adware programs from running on user machines, see this article by Rod Trent on myITforum. |
Once Group Policy has been updated during its next refresh cycle (or force an immediate update with gpupdate /force) users on the affected machines won't be able to use the Run As command to start programs using alternate credentials.
By the way, if you prefer to apply this policy to specific users instead of computers, use a GPO linked to an OU where the user accounts reside and configuring Software Restriction Policies using User Configuration instead of Computer Configuration, such as:
User Configuration/Windows Settings/Security Settings/Software Restriction Policies
Workgroup
For standalone Windows XP or Windows Server 2003 machines in a workgroup environment Group Policy isn't available. However, you can disable Run As by hacking the Registry instead. Simply use Regedit.exe to locate the following key on each machine:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer
Then create a new DWORD value named HideRunAsVerb and assign it a value of 1.
Shameless Plug
Finally, for a detailed look at the capabilities and limitations of Run As see Hack #1 "Use Run As to Perform Administrative Tasks" in my new book Windows Server Hacks.
Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.
Return to WindowsDevCenter.com.
Showing messages 1 through 11 of 11.
-
Some false assumptions here...
2004-03-17 23:03:49 sajaraki [View]
-
Some false assumptions here...
2004-03-18 09:21:35 Mitch Tulloch |
[View]
As for disabling Run As using Software Restriction, it *does* work. Even though the "Run As" option is still available when you right-click on a program in Explorer, you can't Run As a program using alternate credentials if you're an ordinary user logged on to the machine, you can only run programs using your own credentials. -
Some false assumptions here...
2004-03-18 05:46:12 Mitch Tulloch |
[View]
It's *true* you can configure a Local GPO on a standalone machine, but you'd have to do it manually on every machine in your workgroup, which kind of negates the advantages of using Group Policy ;)
As for the registry setting only hiding the menu item, I guess a smart user can always find a way if there is one. I agree though that sound password policies are the foundations of good security, but I would still like an easy way of completely disabling secondary logon for ordinary users...
-
How does this help security?
2004-03-17 14:15:44 sbonds [View]
Forgive my ignorance, but how does this improve security? The security is in the password of the administrative user. Without that "ordinary users" won't be able to use "Run As" to do anything malicious.
-- Steve
-
How does this help security?
2004-03-17 14:43:38 Mitch Tulloch |
[View]
Defense in depth i.e. another layer of security. Power Users also have some administrative privileges and if you make some users members of the Power Users group and one of them should let their password be compromised, well...
Also, the whole idea of having RunAs available on an ordinary user's desktop machine is a bit dangerous. The idea is convenience i.e. an administrator can run a program on a user's machine to fix something without requiring the user log off first. Imagine if a trojan was running on the user's machine when you did this... -
How does this help security?
2004-03-18 12:01:23 Mitch Tulloch |
[View]
Another reason I like to disable RunAs is because of the new /savecred option on XP Professional desktops, see this NTBUGTRAQ posting for more:
http://archives.neohapsis.com/archives/ntbugtraq/2003-q3/0069.html
-
Doesn't always work
2004-03-17 11:01:29 nasseam [View]
Software Restriction Policies path rules have good intentions but are a horrible means of file security. I once set path rules on a network to prevent certain chatting and file-sharing programs from running but the rules only worked for a few users. Why? Because path rules check for the exact path and filename so some users just copied the files somewhere else or renamed them.
This brings us to a good point in server lockdown: don't base any security policy on unawareness. These policies are easily recognizable and usually have the phrases "but most users" or "the majority of users won't" in them. These are true hacks in the sense that they don't solve the real problem but just workaround them.
A better means of disabling runas would be to set ACL permissions or to use a hash rule (also available using Software Restriction Policies). A hash rule solves the problem of copying or renaming because it is a hash of the actual bytes. -
Doesn't always work
2004-03-17 11:58:22 Mitch Tulloch |
[View]
Good suggestion, a hash rule might be better here, thanks! Because of Windows File Protection you can't move runas.exe to another folder but you can still copy it and run the copied version of the command.
I like the idea of modifying the ACL for runas.exe to remove the Read & Execute permissions for Authenticated Users. How would you deploy this change to a group of XP machines in a domain? -
Doesn't always work
2004-03-18 12:48:37 jmbwi [View]
Use cacls.exe in a batch file that runs during login to change the permissions on each machine when a user logs in. -
Doesn't always work
2004-07-22 04:47:45 Mysidia [View]
So what happens when the user brings in a disk with runas.exe from some other machine or downloads a copy of runas or other program that does what RunAs is doing (with different hash) from some other location?
It doesn't seem like using software restrictions policies is going to get you very far unless you take a whitelisting or digital signing approach, and block everything else by default.
You're really better off setting strong password policies about what passwords are set on accounts and when/where they are entered: secondary login isn't going to help a potential hacker much, they can get in with primary login just as easily, right..?
-
Doesn't always work
2004-03-18 13:21:12 Mitch Tulloch |
[View]
I think that may be the way to go. I tried changing the ACL on the Runas service under Computer Configuration\Windows Settings\Security Settings\System Services in Group Policy so that the Domain Users group has Deny Full Control permission, but this doesn't prevent an ordinary user from still using Runas...











Setting HideRunAsVerb to 1 in the registry disables the "Run As..." menu option that appears when you hold down Shift and right click an executable file; it doesn't stop users from running runas.exe. Similarly, if you disable runas.exe via Group Policy, it does nothing to prevent users from using the shift+right click method.
Additionally, you can set Software Restriction Policies on a standalone machine. Simply run mmc as administrator, add the Group Policy snap in and accept the default "Local Computer" group policy object.
Having said that, I don't think disabling "Run As" or runas.exe really achieves that much. Someone still needs to know the username and password of an admin account to be able to escalate their privileges, so your time would be better spent making sure that your password policies are sound.