Microsoft Elevated Privileges Application Launcher

On This Page

Background Implications Download EPAL Configuration Known issues

Background

To reach some of the benefits of deploying a Windows 2000 infrastructure it is important to limit the end-user's ability to make changes to the core components of the operating system. Windows 2000 system administrators now have the option of giving users local User or Power User privileges. Under these privileges it is possible to perform the majority of the tasks that an end-user needs to complete to get their job done. However, some non-Windows 2000 logo compliant applications may not properly run. While there are a number of issues related to application not running under a user context, it is important to distinguished between security related requirements and other issues related to application compatibility.

The Elevated Privileges Application Launcher, EPAL, tool is designed to assist a fairly narrow spectrum of the application compatibility issues. It only deals with the ability of letting an application launch under some other user privilege, so that it has access to certain components of the local registry or the file system. With EPAL the network administrator now has the ability of only giving the user local user privileges on their systems and have the application execute and some higher privilege level on the local system that they are currently logged on with.

EPAL leverages the Windows 2000 Active Directory functionality to minimize the amount of effort on the part of network administrators to manage an environment in which a user has the privilege to execute an application under some other context. It does this by creating a Windows 2000 security principal and a Windows 2000 Group. The security principal, account, is the context that EPAL will use to launch a particular application. This account will need to be a member of the appropriate elevated group of the local Windows 2000 workstation. The Windows 2000 Group is used to maintain a membership list of those users that have been authorized to run a particular application using the elevated access.

Implications

Because EPAL has the ability to execute an application on the user's behalf at an elevated privilege level and while we have taken many precautions to make it as secure as possible, there are some chances for abuse. A couple of things to keep in mind when using this tool:

  • Do not deploy this tool to a domain that has a public presence, like the Internet, as it is likely that some hacker can exploit one of the application accounts defined in the system.

  • The application being executed at a higher privilege level will have the ability to replace a critical system file. It is not recommended that you use EPAL to install applications.

Download EPAL

Download the Elevated Privileges Application Launcher.

Configuration

It is recommended that you look at the various shims available from the Windows 2000 application compatibility group before looking at EPAL. If after all other options have been exhausted, then EPAL can provide the relief needed to execute a particular application.

EPAL has a number of command line switches:

/? – Display all of the switches available for EPAL to use.

/S – This switch will properly setup EPAL to properly record information in the application section of the event viewer. In order to execute EPAL using this switch you must have administrative rights on the local system.

/R – It is used to register new applications with the Active Directory. Prior to using this command line you will need to have access to the executable file being registered and permissions to create a user and group in the appropriate OU within the Active Directory.

/C – Allows you to specify the OU in which the user and group accounts will be created. By default they are created in the Users container.

/P – Some applications need to write to the "Current User" key in the registry. In this cases the /P will load a profile for this purpose.

/V – Generates a verbose log of the steps taken by EPAL.

The following steps will help you demonstrate how to best configure EPAL for use in your environment.

Step 1

Once the application is identified it is necessary to register the application with the Active Directory using the EPAL tool. You will need administrative rights on the appropriate OU in order to create the Windows 2000 account and global groups. In addition, you will need to locate the source executable.

Once these requirements are met execute EPAL with the /R switch. For example:

EPAL /C:ou=Atlanta,ou=Applications /R RedApp.exe

EPAL will automatically create a user account and group based on the application name in the designated container. The account that is created will be the name of the executable. EPAL uses a sophisticated technique to create a digital signature for every executable; therefore, every time there is a new version of the executable it is necessary to register it with EPAL. In this case it is necessary to use the /C command line to identify where the existing user and group exists. If a container is not specified with the /C switch then they will be placed in the default User container.

When the application is register EPAL will assign a strong password to the user account created. The accounts created by EPAL are basically service accounts, hence it is necessary to make sure to set the password expiration policy so that they do not expire.

Step 2

It is recommended that you create the application account in a pre-determined container as it will give you the option to apply group policies to them. Some of the User Configuration group policies you should consider to maintain a certain level of security on your system include:

  • Hide all icons from the desktop

  • Disable control panel

  • Disable command prompt

  • Disable registry editing tools

Step 3

Now that the user account is secured it is necessary to make it a member of a local privilege group. You can accomplish this by manually adding the EPAL user account to the local system Administrator or Power Users group. Or for simplicity you can use the Group Policy snap-in and in the Computer Configuration group policy and use the restricted group functionality to make the application user account a member of the appropriate local group (Power User or Administrator). This will allow the account to run under another context on the local system.

In order to use the local system Power User or Administrators group it is necessary to edit the restricted group policy from a Windows 2000 member server or Windows 2000 workstation with the Group Policy MMC.

Step 4

To facilitate auditing for the use of EPAL, EPAL records all successful and failed attempts when launching an application. The entries are written to the Windows 2000 event viewer of the system where EPAL is being used. In order for this function to work properly it is necessary to register the application with the operating system. This registration will require administrative privileges because it is necessary to write to the registry local machine key. To register EPAL, simply execute EPAL /S.

Step 5

To run the application it is suggested that the EPAL.EXE tool be part of the standard image. To execute the application make sure the application is launched using the EPAL.EXE. For example,

EPAL /C:ou=Atlanta,ou=Applications RedApp.exe.

It is recommended that you configure the application shortcut to start in a minimized state. This is done by editing the properties of the shortcut and selecting it to run in a minimized window. This will just keep the EPAL command prompt window from showing up while the application is launched.

Known issues

  • When the application is registered you must have a copy of the exe available because the application needs it to generate the account, group names, and a digital signature.

  • The account names are truncated at 20 characters because the SAMAccountName can not be longer. When registering an application with a directory name with spaces, make sure that the path is enclosed in quotes.

  • The EPAL tool launches the application without loading a new profile and this can create a problem for some applications that are looking to write to the CURRENT_USER key in the registry as that key is not available. In addition, if the application will not be able to write to the default My Documents folder.

  • The user account and group created for a particular application must always reside in the same container. If they are moved by the administrator, it is necessary to edit the shortcut on the user's desktop to notify EPAL of the appropriate container to search for.

  • As described earlier every time there is a new version of an application you will need to register that executable with EPAL. This will generate an executable signature that is stored within the user object for that application. The signature is stored in a multi-valued property, so if you would like to remove a particular version from the list of "approved" version, then you would have to remove that particular signature. To do this you will get the signature for the application via the /h switch. For example, EPAL /h c:\winnt\notepad.exe. Then use a tool like ADSI edit and remove that value from the wbemPath attribute.

  • The User account and Group used to launch the applications must be registered in the same domain as the user accounts for the users using EPAL to launch an application.

  • On occasion an application may call some other executable either using VBA or some other programming interface. If this is the case with your application, your results may vary.

  • Some applications like Adobe Acrobat expect to print to a default printer which will not exist for the EPAL account. In this cases, your functionality will be limited as there is no good way to add a default printer to the EPAL accounts.