[ Send this article ]
Your message has been sent.
How would you like to send this article:
[ Save this article ]
Save this article to your account for easy access.
This article has been saved to your account.
Go to my account
This article has been emailed to your Kindle.
Send this article
Complete the form below to send this article, Solving LUA Problems with Avecto Privilege Guard, to a friend (or to yourself). We will never share your details (or your friend's) with anyone. For more information, read our Privacy Policy.
by
Russell Smith | July 2010 |
Enterprise Articles Microsoft
This article by Russell Smith, author of Least Privilege Security for Windows 7, Vista and XP, includes information about tools and techniques that can be used to solve Least Privilege Security problems. Specifically, we will use third-party solution to configure administrative privileges for applications and Windows processes on-the-fly. Privilege Guard is a third-party solution, from Microsoft Gold Partner Avecto, that allows system administrators to dynamically add or remove privileges by modifying the logged in user's access token as it's assigned to new processes.
(For more resources on Microsoft products, see here.)
Configuring applications to run with elevated privileges on-the-fly
Despite all the possible workarounds to launch an application or set of commands with elevated privileges from a standard user account, Windows doesn't provide any built-in means of allowing system administrators to configure a particular application to launch as the currently logged in standard user, but with an administrative token. Consider a situation where you don't have time to fix an application that won't run as a standard user, but don't want to grant administrative privileges just for the sake of one application. While it may be possible to start the application using a secondary logon, this is impractical in most cases.
Solving LUA problems with Avecto Privilege Guard
Privilege Guard is a third-party solution, from Microsoft Gold Partner Avecto, that allows system administrators to dynamically add or remove privileges by modifying the logged in user's access token as it's assigned to new processes. The client-side component, provided as an .exe or .msi file for GPSI deployment, is implemented as a user-mode service and supports Windows XP (or Windows Server 2003) and later. Privilege Guard is licensed on a trust model, so it doesn't adhere to a strict object count in Active Directory.
Client settings are deployed with User or Computer Group Policy using a flexible architecture that separates policies, applications, messaging and access tokens. Programs can also be grouped together to minimize the number of policies applied.
Defining application groups
For each Application Group, you can define one or more programs using the following categories:
- Executables
- Control Panel Applets
- Management Console snap-ins
- Windows Installer Packages
- Windows Scripting Host (WSH), PowerShell scripts and batch files
- Registry Editor files
- ActiveX controls (matched by URL or CLSID)
Application Templates can also be used to quickly locate built-in Windows tools such as Performance Monitor or System Restore. In the screenshot that follows, I used an Application Template to locate the Disk Management console (diskmgmt.msc) in Windows 7. The default setting is to match processes by file or folder name, but processes can also be matched by command line switch, file hash, publisher or any combination thereof. Privilege Guard supports matching by publisher certificate when Windows binaries are indirectly signed using Windows Security Catalogs.
Additional options include:
- The ability to match processes if Privilege Guard detects that an application will trigger UAC.
- To determine whether child processes spawned by the matched parent process inherit the privileges of the user's modified access token.
- To suppress elevated privileges on File Open/Save common dialogs to prevent users from modifying protected files.
Defining access tokens
We can define the rights allotted to access tokens in Privilege Guard based on the privileges assigned to Windows built-in groups. Rights can also be added or removed on an individual basis. The access token below uses the built-in Administrators group as the basis for assigning privileges.
An access token's integrity level can also be overridden.
Any combination of groups, privileges or integrity levels can be added or removed in an access token.
Configuring messages
While it may be preferable in many situations to silently elevate privileges when a user starts a legacy application, organizations can use Privilege Guard to generate fully customizable messages, in multiple languages if necessary, that are displayed when applications are blocked, or if users are required to confirm their credentials or provide a reason for launching a process with elevated privileges.
The drop-down menu under Message Type can be set to Allow or Block Execution, and determines not only the type of message that's displayed, but enforces the corresponding block/allow action.
Defining policies
The final task is to define a policy to bring the entire configuration together and determine how it is applied. Here we can choose to apply our policy to all users (using the built-in Everyone group), or select individual users and groups; set the application group, access token and optionally message included in the policy. We can configure multiple sets of actions for application groups, access tokens, messages and auditing (Application Group Actions and Auditing).
Optional settings include the ability to configure Privilege Guard shell integration for specified application groups so that a process can be launched from Explorer's context menu with a modified access token, allowing advanced users to elevate applications on demand. System administrators can also enable logging options for the purposes of software metering or monitoring privilege use.
Solving LUA problems with Privilege Manager
BeyondTrust's Privilege Manager provides system administrators with a solution that allows them to define applications or processes that launch as the logged in user, but with an administrative-level access token. Privilege Manager is divided into client and server software. The server software, or snap-in software as it's referred to, installs on a server in your organization and updates Group Policy Object Editor for policy configuration and provides Group Policy Management Console integration. The client software installs on each device to which Privilege Manager policies will apply.
Let's take a simple example of how Privilege Manager might be used. We'll configure a policy that allows standard users to start Notepad with administrative rights.
Defining Privilege Manager rules
We start by deciding what kind of rule we want to apply, in a similar vein to Software Restriction Policy (or AppLocker in Windows 7), but the options for targeting applications are slightly expanded:
Privilege Manager Rules:
| Rule name | Function |
| Path rule | Target an application by its program file path |
| Hash rule | Target an application by a hash of its file |
| Folder rule | Target all applications in a folder |
| MSI Path rule | Target installations by MSI file path |
| MSI Folder rule | Target installations by MSI file folder |
| ActiveX rule | Target an IE ActiveX control installation |
| Certificate rule | Target an application by its certificate |
| Shell rule | Target any application started from Explorer |
| CD\DVD rule | Target a CD-ROM or DVD |
Once we've chosen the rule type, we can enter the path to our application manually or use the browse button to choose from a list of predefined Windows applications, control panel applets, and wizards.
Per-Computer or Per-User Policies
Policy Maker policy settings can be applied to the computer or to specific users. Additionally, Policy Maker can be used with local policy settings or Group Policy.
Two additional options require users to enter their credentials again before the process or application is launched (apply rule only if user can authenticate) or require users to provide an explanation for launching the application, which is logged by Privilege Manager (require user to enter text justification).
Assigning permissions
Here we get to choose the permission level with which the process or application will launch. You can choose to add or remove a group from the logged in user's access token.
Adding or removing individual privileges
The Privileges tab gives us more granular control to add or remove individual rights.
Specifying integrity levels
We have the opportunity to specify the integrity level with which the process should launch under Vista and Windows 7.
Summary
In this article, we have examined Avecto Privilege Guard, one of the third-party tools available for solving Least Privilege Security problems.
Further resources on this subject:
- Solving Least Privilege Problems with the Application Compatibility Toolkit
- Tools and Techniques for Solving Least Privilege Security Problems
About the Author :
Russell Smith
Russell Smith is an independent IT consultant who specializes in management and security of Microsoft-based IT systems. An MCSE with more than ten years experience, his recent projects include Active Directory Security Consultant for the UK Health Service National Programme for Information Technology (NPfIT) and Exchange Architect for Wipro Technologies. Russell is a regular contributor to industry journals Windows IT Professional, Security Professional VIP, CDW's Biztech Magazine and a contributing author to Supporting and Troubleshooting Applications on a Microsoft Windows Vista Client for Enterprise Support Technicians from Microsoft's Official Academic Course (MOAC) series of books published by Wiley and Sons. Russell also has extensive experience as an IT trainer.
Books From Packt
|
|
|
Post new comment