User Guide Release 5.0

(1)

User Guide

(2)

COPYRIGHT NOTICE

Copyright © 2005–2011 BeyondTrust Software, Inc. All rights reserved. Use of this software and/or document, as and when applicable, is also subject to the terms and conditions of the license between the licensee and BeyondTrust Software, Inc. (“BeyondTrust”) or BeyondTrust’s authorized remarketer, if and when applicable.

TRADE SECRET NOTICE

This software and/or documentation, as and when applicable, and the information and know-how they contain constitute the proprietary, confidential and valuable trade secret information of BeyondTrust and/or of the respective manufacturer or author, and may not be disclosed to others without the prior written permission of BeyondTrust. This software and/or documentation, as and when applicable, have been provided pursuant to an agreement that contains prohibitions against and/or restrictions on copying, modification and use.

DISCLAIMER

BeyondTrust makes no representations or warranties with respect to the contents hereof. Other than, any limited warranties expressly provided pursuant to a license agreement, NO OTHER WARRANTY IS EXPRESSED AND NONE SHALL BE IMPLIED, INCLUDING WITHOUT LIMITATION THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR USE OR FOR A PARTICULAR PURPOSE.

LIMITED RIGHTS FARS NOTICE (If Applicable)

If provided pursuant to FARS, this software and/or documentation, as and when applicable, are submitted with limited rights. This software and/or documentation, as and when applicable, may be reproduced and used by the Government with the express limitation that it will not, without the permission of BeyondTrust, be used outside the Government for the following purposes: manufacture, duplication, distribution or disclosure. (FAR 52.227.14(g)(2)(Alternate II))

LIMITED RIGHTS DFARS NOTICE (If Applicable)

If provided pursuant to DFARS, use, duplication, or disclosure of this software and/or documentation by the Government is subject to limited rights and other restrictions, as set forth in the Rights in Technical Data – Noncommercial Items clause at DFARS 252.227-7013. TRADEMARK NOTICES

PowerBroker, PowerPassword, and PowerKeeper are registered trademarks of BeyondTrust. PowerSeries, PowerADvantage, PowerBroker Password Safe, PowerBroker Directory Integrator, PowerBroker Management Console, PowerBroker for Desktops, PowerBroker for Virtualization, and PowerBroker Express are trademarks of BeyondTrust. SafeNet and SafeNet logo are registered trademarks of SafeNet, Inc. Copyright 2009, by SafeNet, Inc. All rights reserved. Product names of any third party remain the trademarks of such third party manufacturers and/or distributors, respectively.

FICTITIOUS USE OF NAMES

All names of persons mentioned in this document are used fictitiously. Any resemblance to actual persons, living or dead is entirely coincidental.

OTHER NOTICES

If and when applicable the following additional provisions are so noted:

BeyondTrust is a registered trademark of BeyondTrust Software, Inc. This document is for informational purposes only. BeyondTrust offers no warranties, express or implied, in this document. Microsoft, Microsoft Outlook, Microsoft Exchange, Microsoft Internet Explorer, Microsoft Windows, Microsoft Windows 2000, Microsoft Windows XP, Microsoft Windows Server 2003, Microsoft Windows Vista, Microsoft Windows Server 2008, Microsoft Windows Server 2008 R2, and Microsoft Windows 7 are trademarks of Microsoft Corporation. Other names mentioned herein may be trademarks of their respective owners.

LIBRARY NOTICES cryptolib.lib Library

Big Arithmetic routines coded by D. P. Mitchell and Jack Lacy December 1991. Copyright (c) 1991 AT&T Bell Laboratories. This is version 1.1 of CryptoLib.The authors of this software are Jack Lacy, Don Mitchell and Matt Blaze.

(3)

required licenses are obtained.

SOME PARTS OF CRYPTOLIB MAY BE RESTRICTED UNDER UNITED STATES EXPORT REGULATIONS.

THIS SOFTWARE IS BEING PROVIDED “AS IS”, WITHOUT ANY EXPRESS OR IMPLIED WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. detours.lib Library

Microsoft Research Detours Package, Professional Version 2.1 Build_216. DISCLAIMER AND LICENSE:

=======================

Portions may be covered by patents owned by Microsoft Corporation. libtomcrypt.lib Library

Tom St Denis, [email protected], http://libtomcrypt.org.

(4)

(5)

Introduction

This guide provides the instructions for using BeyondTrust PowerBroker for Desktops Windows Edition (PowerBroker Desktops), and contains

information about product features, benefits, functions, unique concepts, and basic procedures. If you have not yet installed the product, see the PowerBroker Desktops Installation Guide. If you are upgrading from one version to a higher version, see the PowerBroker Desktops Upgrade Guide.

The following sections include the document conventions, list of documentation for the product, and where to get additional product information and technical assistance.

Conventions Used in This Guide

Specific font and linespacing conventions are used in this book to ensure readability and to highlight important information such as commands, syntax, and examples.

Font Conventions

The font conventions used for this document are:

• Courier New Font is used for program names, commands, command arguments, directory paths, variable names, text input, text output, configuration file listings, and source code. For example:

C:\Documents and Settings\All Users

• Courier New Bold Font is used for information that should be entered

into the system exactly as shown. For example:

pbdeploy.exe

• Courier New Italics Font is used for input variables that need to be

replaced by actual values. In the following example, the variable

MyServer, must be replaced by an actual environment server name and

the variable MyFolder must be replaced by an actual folder name:

\\MyServer\MyFolder\pbwdcl32.msi

• Bold is used for Windows buttons. For example: Click OK.

Linespacing Conventions

The linespacing of commands, syntax, examples, and computer code in this manual may vary from actual Windows and Unix/Linux usage because of space limitations. For example, if the number of characters required for a single line does not fit within the text margins for this book, the text is

(10)

Where to Go Next?

For licensing information and installation instructions for PowerBroker Desktops, see the PowerBroker Desktops Installation Guide.

For detailed information and advanced procedures for PowerBroker Desktops, see the PowerBroker Desktops User Guide.

Documentation Set for PowerBroker Desktops

The complete PowerBroker Desktops documentation set includes the following:

• PowerBroker Desktops Getting Started Guide

• PowerBroker Desktops User Guide

• PowerBroker Desktops Installation Guide

• PowerBroker Desktops Upgrade Guide

• PowerBroker Desktops online help

Obtaining Support

BeyondTrust provides an online knowledge base, as well as telephone and web-based support. In addition, when working with any PowerBroker Desktops item, you can click the Help button to view detailed information about available options.

Available Resources

The PowerBroker Desktops Knowledge Base provides information and solutions to many known problems and issues. Registered users can access the Knowledge Base at: http://pm.beyondtrust.com/support/kb.

To read about the other BeyondTrust products, see our corporate Web site at: www.beyondtrust.com.

Before Contacting Technical Support

Be sure to read this section before contacting technical support.

Tip: Is the PowerBroker Desktops Client Running?

A computer must have the PowerBroker Desktops client installed and running to recognize rules.

If a computer does not respond to a rule or a policy, make sure that the client is installed and activated on the computer. Run the polmon.exe utility on the computer to check for client activation and functionality.

(11)

Obtain as much information about the problem as possible using PowerBroker Desktops troubleshooting tools, such as:

• Policy Monitor

• Trace options

• Event logging

• Resultant Set of Policy (RSoP) logging

To expedite support, collect the following information:

• Image or the full text of any error messages

• Context of the problem, including affected platforms

• How to reproduce the problem

• For client problems: A copy of the XML configuration data that produces the problem, trace output, event log messages, and RSoP reporting data if available

Contacting Support

If you encounter problems during your installation that are not covered in the documentation, contact BeyondTrust technical support using e-mail at

[email protected]or if you are located in the United States,

you can call 800-234-9072.

Telephone: +1 800-234-9072

Hours: Staffed 24 hours per day, seven days per week.

Web: Use the following instructions to contact technical support from the BeyondTrust Web site:

1. Browse to:

http://www.beyondtrust.com/Technical-Support.aspx?sectopm=Technical-Support

2. Log into the BeyondTrust Support Web site.

3. Scroll down the page to the section and click Create Ticket to file an incident report.

When contacting BeyondTrust technical support, provide the following information:

– Your company name

– Telephone and e-mail address where you can be contacted

(12)

Product Overview

In many organizations, higher levels of privileges are often given to common users so that they can run an application or perform mundane system tasks such as mounting a printer or setting the system clock. However, granting such privileges creates significant vulnerability to network security. When credentials are elevated, common users can perform a wide variety of tasks beyond the scope their responsibility and authority.

In a truly secure environment, users are given rights to only the resources they need, and only when they need the resource. Ideally, all users are assigned

Least Privileged User Accounts (LUA). This means that they have minimal rights in the overall network context.

Unfortunately, in the Windows® environment, many applications and processes require elevated rights in order to be launched and run.

How PowerBroker Desktops Works

PowerBroker Desktops allows you to create rules (group policy items) that define and govern how individual processes and applications are assigned rights. By creating a rule, you determine the specific permissions and privileges assigned to an application. When a user launches the application, the rule is communicated to the client computer as a matter of policy. The following illustration depicts the role of PowerBroker Desktops within the enterprise as it monitors launch events and adjusts privileges.

(13)

In addition to application rules, you can create rules that apply to system tasks and process, as well as to individual users. Using these rules, you might provide access to system clock functions for all users. You might also limit the ability to launch and run a spreadsheet application to users or computers in the Finance organizational unit (OU).

By customizing access in this way, you match security restrictions to the needs of your organization. At the same time, you provide protection to the network while maintaining user productivity.

PowerBroker Desktops communicates privilege configuration within the Windows Group Policy framework. When Group Policy is refreshed, PowerBroker Desktops rules take effect. They are enforced any time the related application or process launches.

The PowerBroker Desktops user interface, running within the Windows Group Policy Management Editor (GPME), displays as shown in the following example:

In this Windows GPME example, the PowerBroker Desktops node is selected under Computer Configuration, Policies, BeyondTrust. A second

PowerBroker Desktops node is displayed under User Configuration, Policies, BeyondTrust.

Because the Computer Configuration, Policies, BeyondTrust node is selected, the right pane lists various rules and policies that were created by the

(14)

PowerBroker Desktops Architecture

PowerBroker Desktops provides a kernel-mode security driver that resides on the client computer. This security driver is deployed and installed in a single installer package (.MSI) that also contains the Group Policy client-side extension (CSE) and the Windows Management Instrumentation (WMI) namespace for reporting the Resultant Set of Policy (RSoP), and machine state model data.

Most organizations deploy this MSI by using Group Policy or their preferred software distribution technology.

The security driver monitors process launches on the client machine and checks each launch against the rules communicated to the client through Group Policy. When a rule exists, the security driver intercepts the launch event and modifies the security token for that process according to the instructions contained in the rule.

The benefits of this approach include:

– No secondary accounts are required (unlike “Run As” style solutions). – Security exposure is not increased.

– Applications that need to write to HKEY_CURRENT_USER do not fail because the process still launches under the authenticated user. This enables a common user to perform specific tasks and operations that normally require administrator-level privileges.

For more information about PowerBroker Desktops rules, review the product FAQ in the Knowledge Database on the BeyondTrust web site.

After registering with the Web site, you can access the knowledge base at: http://pm.beyondtrust.com/support/CB

Licensing and Operating Modes

There are two types of PowerBroker Desktops licenses:

• Registered Product - You have purchased software licenses or obtained a license from BeyondTrust or an authorized reseller and have imported a registered license. The product is fully functional and can be used for multiple domains.

• Evaluation Product - You have installed PowerBroker Desktops with a temporary license. The product is fully functional, can be used across multiple domains, but has an expiration date encoded in the license. A fourteen (14) day grace period is implemented for license expiration. If the term of the license is exceeded, CSEs will report a warning to the event log while operating within 14 days of the last successful license check. If the grace period is exceeded, the CSEs will not process policy for the GPO and an error will be written to the event log.

(15)

Demonstration Mode

When no license is present, PowerBroker Desktops runs in Demonstration mode. In this mode, all rules are fully functional within a Local GPO, but the product will process (enforce) only template rules from a network GPO. Template rules are preconfigured rules specific to an operating system. They are accessible from the ellipsis button on the Application tab of the

Properties dialog in the Path, Shell, and UAC rules.

The advantage of Demonstration mode is that it allows the configuration and deployment of template rules without the requirement of a license. In

addition, it supports the creation of most rule types so you can gain familiarity with rules and policy making. However, even though most types of rules can be created, non-template rules are not functional at the domain level.

When a license is eventually acquired, all rules (template and non-template) created in Demonstration mode become fully functional and can be deployed across the domain without modification. This leverages the time you invested and the experience you gained with PowerBroker Desktops.

Note: In Demonstration mode, the following template rules are not available: Add Printers, Add Plug and Play Devices, and configuration of network settings.

Obtaining an Updated License Key for V5.0

Version 5 of PowerBroker Desktops requires a unique license key. As a result, you cannot apply a license from a previous PowerBroker Desktops version to version 5.

To acquire a version 5 license key, contact BeyondTrust using one of the following methods:

– E-Mail - Send a key request to: [email protected]

– Phone - Contact your BeyondTrust sales representative directly by calling: 1-818-575-4000

Sales staff will authorize and create a license key for your PowerBroker Desktops installation.

(16)

Getting Started with PowerBroker Desktops

PowerBroker Desktops enables you to create rules in the Group Policy Management Editor (GPME). Each PowerBroker Desktops rule elevates or reduces the permissions and privileges of a Windows application or process at runtime. A rule can also elevate or reduce the permissions and privileges of an MSI package or an ActiveX control when they launch.

Rules can be created manually using the rule Wizard or the Rule Properties dialog. Rules can also be generated automatically using the automatic rule generator. Rule generation is a good way to assemble a basic rule set for your organization. This set of rules can then be refined to meet your specific needs. For increased targeting granularity, you can use item-level targeting to apply rules to selected computers or specific users.

Using the Management Dashboard

The PowerBroker Desktops Management Dashboard is your gateway to a more secure enterprise. From the dashboard you can access information, tools, and reports related to rule application and operation.

The dashboard contains three major sections:

– Getting Started - Provides links to online help and other useful information resources.

– Tools and Wizard - Provides access to rule creation and generation wizards, and the rule property sheet.

– Rule Summary- Provides access to summary-level information about the rules in use, including rule types, numbers of rules and more. It also provides access to individual rule settings reports and XML reports.

A rule’s settings report provides a quick picture of the rule’s attributes and permissions.

A rule’s XML report displays the XML coding that represents a rule in the client’s environment.

To view the dashboard, select a BeyondTrust node in the Group Policy Management Editor. The dashboard will open in the right pane of the editor. In the dashboard shown in the following example, the Overview and Tools and Wizard sections are expanded. Note the Disable Wizard button in the Tools and Wizard section. This button allows you to turn off the wizard and thereby gain access to the rule property sheet for the manual rule creation.

(17)

Interpreting Dashboard Reports

The Rule Summary section of the dashboard provides reports that document the all the rules in use and the configuration of each rule. Two types of reports are available:

– Settings Report - The Settings report is an easy-to-read, HTML based, report that documents all the configuration parameters of all rules. Rules are presented by type (Path, Hash, and so forth) and listed in the order in which they appear in the application security file. Use the Settings report to gain an overview of how a rule is configured and the effect the rule has on its target application.

(18)

– XML Report - The XML report provides the actual XML notation that represents the rule. This notation specifies all the configuration parameters of a rule. Rules are presented by type (Path, Hash, and so forth) and listed in the order in which they appear in the application security file. Use the XML report to view the internal operation of a rule and to understand how it interacts with its target application. A typical dashboard Report Summary screen looks similar to the following. Clicking on the Settings Report icon in the Path rules row displays the settings report for each Path rule in the system.

(19)

Rule Types and Tasks

PowerBroker Desktops enables you to create rules with targeting options appropriate to many different situations and tasks. Use the following tables as a guide to creating the types of rules you need, based on what you want to accomplish

In the following table, specific application limitations are listed in the left column and the rule types used to implement a limitation are suggested in the right column.

Table 1. Security Situations and the Rules to Control Them To modify permissions and privileges of… Select a…

A Windows process Path rule

A program in a specific location Path rule A specific program regardless of location Hash rule All applications published by a specific company Publisher rule All programs in a specific folder Folder rule A specific version of an application Publisher rule An MSI package in a specific location MSI Path rule All MSI packages in a specific folder MSI Folder rule All installations initiated by Internet Explorer ActiveX rule Specific installations initiated by Internet Explorer ActiveX rule Installation of all ActiveX controls ActiveX rule Installation of specific ActiveX controls ActiveX rule All applications on a certain CD or DVD CD/DVD rule Any application that a user specifies Shell rule An application that triggers a UAC prompt UAC rule

(20)

In the following table, various user management scenarios are listed in the left column. The right column lists the rule types that implement a solution.

Table 2. Management Scenarios and Rules to Control Them I want to… Select a…

Elevate the permission level for restricted users performing a common Windows task or running an application requiring higher privileges

Path rule or Hash rule

Elevate the permission level for restricted users running any applications in a specific folder

Folder rule

Reduce the permissions for administrators when using applications such as Internet Explorer and Outlook

Path rule or Hash rule

Elevate all applications from a specific company Publisher rule Elevate a specific version of an application Publisher rule Provide a self-service software installation point

for restricted users

Folder rule for executable and MSI Folder rule for MSI packages

Enable restricted users to use the Add Hardware wizard or prevent users from using the wizard

Path rule

Enable restricted users to add or remove plug and play hardware or prevent users from adding plug and play hardware

Path rule

Enable restricted users to shut down their computers

Path rule

Enable users to elevate applications on demand Shell rule Enable users to elevate all applications on a

certain CD or DVD CD/DVD rule

Enable certain users to use credentials in UAC

(21)

About Permission Levels

In a given rule, you can make modifications to the permissions of an

application or a process when it is run. Permissions are defined by the security groups listed in the process token. With each rule, you can add security groups to or remove security groups from the application’s process token. The effect is the same as making changes to the end-user’s group

memberships but only for a specific application.

About Privileges

In a rule you can also make changes to the privileges of an application or a process. With each rule, you can grant or deny privileges to the application. The effect is the same as if the privileges were granted or denied to the end-user but only for the specific application.

This is especially useful because Windows grants as standard privileges the ability to Shut down the system and Take ownership of files or other objects. These are not tasks administrators want users capable of performing.

About Item-Level Targeting

Item-level targeting allows you to restrict to selected users and computers a rule’s application of permission and privilege modifications. Using item-level targets in conjunction with rules you can manage a wider variety of users and computers with a smaller number of GPOs.

For example within a single GPO, you can include similar rules customized for selected users and computers, with each targeted rule to apply its settings only to the relevant users or computers.

The item-level targeting editor, with the New Item menu open, looks similar to the following example. Note the various tool bar icons and menus.

(22)

PowerBroker Desktops provides more than 25 items that fine tune and enhance the application of security configurations to users and computers. When multiple items are specified, the Item Options menu provides access to boolean operators such as AND/OR and IS/NOT. Using these operators you can conjoin multiple items in a logical expression.

In addition, collections of items can be named and saved. This feature is helpful when frequently used constraints must be applied repeatedly.

Using item-level targeting you can accomplish selective rule application such as:

Elevate the security of application X, but only for members of the Domain Admins security group.

Item-level targeting can be much more complex as you construct

boolean-type expressions that determine how items are applied. For example: you might create the following item expression:

Modify the security of version 3.0.135 of application X, but only for members of the Domain Admins security group when they launch the application on a specific computer.

(23)

GPO Backup Files

The PowerBroker Desktops snap-in has the functionality to create up to three GPO backup files using standard GPO backup procedures. These files contain the rule XML code that defines each rule you have created. You might want to create a backup file to store in a source control system for version control or to import into a PowerBroker Desktops utility such as PBDeploy. Backup files are created in the Application Data directory. The directory path for the GPO backup files varies depending on the operating system, as shown in the following lists.

For Windows Server 2003 and Windows XP

C:\Documents and Settings\All Users\Application Data\ BeyondTrust\

PowerBroker Desktops\GPOBackupData For Windows 7 and Windows Vista

C:\ProgramData\BeyondTrust\PowerBroker Desktops\GPOBackupData

GPO Backup File Name Format

The following formats are used for the GPO backup file names: AppSecComp_<GPOName>.xml

AppSecUser_<GPOName>.xml Backup File Name Examples

The following list shows examples of the GPO backup file names: AppSecUser_<GPOName>.xml

AppSecUser_<GPOName>.xml.bk1 AppSecUser_<GPOName>.xml.bk2 AppSecUser_<GPOName>.xml.bk3

As a result of the Microsoft Application Data Folder Security rules when multiple non-administrator users create group policy rules on the same machine, only the snap-in user that created the GPO or the snap-in users with administrator permissions are allowed to update the backup files. To avoid permission problems, grant the user the appropriate permissions in the GPOBackupData folder.

(24)

Working with PowerBroker Desktops Rules

A PowerBroker Desktops rule can elevate or reduce the permissions and privileges of a Windows application or process at runtime. In addition, a rule can do the same to an MSI package or ActiveX control. Using Group Policy Objects and item-level targeting, you can apply these security changes to selected computers and individual users.

A rule can be created in the following three ways:

– Using the Rule Wizard - By providing information to a multi-page wizard that creates a rule.

– Automatic Generation - By running the Rule Generator which analyzes client machine application use and builds a set of rules based on that analysis.

– Manually - By using the rule property sheet to specify rule parameters and settings.

All three methods of rule creation are described in the following sections.

Using the Rule Wizard to Create a Rule

If you have a basic knowledge of rule types, the rule wizard provides an easy way to build a rule. The wizard guides you through all the steps required to configure and name a rule. Each wizard page corresponds to a tab in the rule property sheet. Helpful text prompts assist you in making configuration choices and selections.

The wizard can be enabled or disabled on the management dashboard using a button. When enabled, the wizard starts any time Create New Rule is selected. When the wizard is disabled, clicking Create New Rule opens a rule property sheet.

To create a rule using the rule wizard, do the following:

1. Open the management dashboard by selecting either of the BeyondTrust

nodes in the Group Policy Management Editor.

2. Expand the Tools and Wizards section of the dashboard and ensure that the wizard is not disabled.

(25)

3. Click Create a New Rule.

4. On the first page of the wizard, select the type of rule you want to create. 5. Follow the prompts in the subsequent wizard pages to configure the rule. 6. On the last page of the wizard, provide a name for the rule, a description

(optional), and click Create.

The new rule is added to the bottom of the rule list, and you are prompted to create another rule or to exit the wizard.

After you have created a rule, you can edit it by opening its property sheet and changing values on various pages of this tabbed dialog.

Automatically Generating a Set of Rules

Manually creating a set of rules to control application access in a large organization is a daunting task. The Automatic Rule Generator automates rule creation by gathering data from machines running the PowerBroker Desktops client. This data includes information about the applications being used, the privileges they require, how they are launched, and the frequency of their use. Based on the collected data, the generator creates a file containing a set of XML-based rules. The administrator can review the generated rules, delete any rules deemed unnecessary, and copy the remaining rules to a production instance of the snap-in.

(26)

How Automatic Generation Works

When application state modeling is enabled on a client by turning on a setting in the administrative template, the client stores information about the

application launch and application usage in the local registry in the form of a state model. By examining a client’s state model, the rule generator gathers information about the applications used on the client.

The following general steps illustrate the rule generation process: 1. Access one or more target machines and collect state model data. 2. Store data in SQLite database.

3. Analyze stored data and eliminate duplicate application information. 4. Build an XML rules file based on the collected data.

5. Save the database and the rules file to the specified directory. Recommended Rule Generation Strategy

To use the rule generator most effectively, target machines that contain a typical collection of the applications used in your enterprise. During this initial data collection operation, be sure to enable the Detailed Rules check box. Using this option provides the most complete and comprehensive data set because multiple application instances are detected for each launch argument combination used to launch the application.

After this comprehensive data set is created, you can examine the resulting rules. In most cases, there will be redundant rules for a given application because of the variety of launch arguments used to start the application. The final step is pruning the rules to eliminate duplicates. To prune the rules, run the rule generator on the stored data in the database. Disable the

Detailed Rules check box during this operation. The resulting rule set will be significantly smaller and will not contain duplicate rules.

To further reduce the size of a rule set, include or eliminate applications from various companies. For example you can include only rules for all applications signed by Microsoft, or you can completely eliminate rules for all applications signed by Microsoft. To do this, enter Microsoft either in the Create Rules ONLY for Company field or Exclude Company from Rule Creation

field. Credential Issues

The rule generator must have administrative and remote access to any machine it inventories. As a result, when it is run on a large number of machines, it should be run with high-level administrative credentials to ensure that the generator can extract data from all the machines in the domain. Enter the credentials in the appropriate input fields.

(27)

In addition, the rule generator relies on Windows Management

Instrumentation (WMI) for data collection. Therefore, WMI must be enabled on all client machines, switches, and other devices on the network.

Generated Files

The rules generator creates several output files. By default, these files are placed in the C:/beyondtrust directory. However, you can specify an alternate location. Generated files include one or more of the following types of files, depending on the rule creation operations performed:

– [machine_name]-autorules.xml – XML rule file that can be

placed directly into the snap-in.

– PBDAutorules.db – SQLite database containing raw rule data.

– PBDautorules-Detailed.xml – Verbose version of generated rules

in which application arguments were included during rule generation. Rules can be pasted directly into the snap-in.

– PBDutorules-Consolidated.xml – Consolidated version of

generated rules in which application arguments were ignored during rule generation. Rules are based on the application location (path). Rules can be pasted directly into the snap-in.

Rule Generator User Interface

The rule generator provides an easy-to-use interface in which you can enter information and make selections. The following screen illustrates the rule generator dialog with numbers corresponding to the following selections: 1. Input area for targeting information.

2. Rule generation status panel.

3. Detailed or consolidated rule generation control. 4. Directory path for generated rule files.

5. Exclude and Include text entry fields. 6. Rule XML report directory.

7. Computer and database generate buttons. 8. Close dialog or Stop generation button.

(28)

Rule Generation Options

Several options are available in the rule generator user interface that can be used when generating rules. The options you enable determine the type of rule set that you create.

The following options can be used when generating rules:

– Auto Search Domain - When enabled, this check box directs the rule generator to detect all machines the native domain. Machine names are placed in the scrolling list to the right of the check box. You can select one or more machines directly from the list.

– Domain Name - Displays the name of the native domain of the snap-in machine.

– Login name - Name of valid admin-level account on target machine. – Password - Password associated with login name.

– Create Rules from Computer - Initiates data collection and rule generation using the data obtained directly from the application inventory of the specified computer.

– Create Rules from Database - Initiates rule generation from previously inventoried data that resides in the rule generator database. – Exclude Company from Rule - Allows you to ignore applications

from one or more companies. The rule generator examines the company name in an application’s certificate and skips the application if the name matches a name entered in the Exclude Company From Rule field. Use this feature to avoid creating rules for products from a specific company. Separate multiple names using a plus (+) sign.

(29)

– Create Rules ONLY for Company - Allows you to generate rules for applications from specific companies. The rules generator

examines the company name in an application’s certificate and builds a rule for the application only if the company name matches a name entered in the Create Rules ONLY for Company field. Use this feature to build a comprehensive rule set for a suite of applications from a single company, such as Microsoft. Separate names with a plus (+) sign.

– File Directory to Save Rules - By default, the rules generator saves its output to the location: C:\beyondtrust. However, you can direct the rules generator to save output to any location, including a mapped drive. When you click this field, a file explorer opens allowing you to navigate to an alternate location.

– View Reports - This field indicates the location of the rules generator output files. When you click this field, a file explorer opens enabling you to open and review the contents of XML rule files created by the rules generator. The resulting reports provide all the data necessary to understand how a rule is being applied.

– Detailed Rules -Enables verbose generation mode. By default, this feature is disabled. When enabled, the generator creates multiple rules for each launched instance of an application, based on the arguments used to launch the application. Detailed rules usually produce many more rules being created and also results in rule redundancy. However, it is useful because it allows you to detect every launch instance of a given application. and obtain an overview of how, where, and by whom an application is being used.

Generated Rule XML Files

The rule generator produces two types of XML files, depending on whether or not the Detailed Rules check box is enabled. These files are:

– Detailed Rule XML File - This file contains rules for every detected instance of an application. That means that multiple rules are often created for a single application because the application is started with different arguments.

– Consolidated Rule XML File - This file has been purged of duplicate rules and contains rules based ONLY on application location (path). The reduction in rules can be dramatic, often fifty percent or more. In most cases, these location-specific rules provide an acceptable level of security while simplifying rule tracking and management.

(30)

Viewing Rule Generation Reports

The rule generator provides two, easy to read, reports based on the XML rule file it has created. You can view these reports by placing the cursor on the

View Reports field and double-clicking an XML report file name. A report opens in Internet Explorer that details the following for each rule:

– Rule Name - Name assigned to the rule by the rule generator. You can change this name.

– Rule Type - Type of rule generated. For example, Path indicates a path rule.

– Program - Name of the application or executable the rule targets as defined by the full path to the executable. For example:

C:\Windows\system32\mmc.exe

– Args - Any launch arguments used to start the application or executable. For example: c:\windows\system32\gpedit.msc – Hash - Hash code of the application or executable.

– Description - General information about how the application is used, including: first launch, last launch, number of launches, number of launches managed by, and the user security ID associated with the most recent launch.

By reviewing the reports, you gain an understanding of the logic and operation of a generated rule.

Using Generated Rules

After you have successfully generated a rule set and reviewed the rules, you can place the generated rule XML file directly into the snap-in. The rules are then distributed to clients and take effect after the next group policy update. Troubleshooting Generation Problems

The rule generator requires that several processes and programs are available on any machine it inventories. When an error occurs, the rule generator indicates the type of error in its status window. Some of the more common errors that may be encountered are discussed in the following sections. Invalid Name Space Errors

The rule generator uses the client as a data collection engine. This means that the client must be running on any machine that is inventoried by the

generator. If the client is not running, an error occurs when the generator attempts to connect to and survey the machine.

The error reported in this situation is similar to the following: Targeting: [machine_name].[domain_name]

Attempting to access and extract data from [machine_name] Failed to access WMI Application State data.

(31)

When you see a namespace error, use the Policy Monitor utility on the client machine to check the operational status of the client. The client should be running with rules and policies loaded successfully.

Access Denied Errors

The rule generator relies on Windows Management Instrumentation (WMI) for data collection. If WMI is not enabled on the client machine and

throughout the network, rule generation will fail.

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

Errors have been detected. RPC Server Errors

A Remote Procedure Call (RPC) error indicates that a machine is inaccessible. The cause of this error is usually one of the following:

• The machine is not powered on.

• The fire wall is blocking access to the machine.

• The network switch between the machine and the rule generator has WMI disabled. This issue can be verified by checking the status of TCP port 135. This port should not be blocking WMI.

The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

(32)

Manually Creating a Rule

You can use the rule property sheet to manually create a rule. The property sheet is a tabbed dialog that provides access to all rule settings and

parameters.

The general steps for creating a rule using the property sheet are: – Disable rule wizard.

– Open the rule property sheet. – Choose a rule type.

– Target an application or process for which to modify permissions and privileges.

– Modify the permissions for the targeted application or process. – Optional. Modify the privileges for the targeted application or

process.

– Optional. Specify the integrity levels for the targeted application or process.

– Optional. Apply item-level targeting the rule so that it is targeted at specific users and computers.

The following section provides instructions for creating and configuring a rule.

To manually create a rule, do the following:

1. Open the Group Policy Management Editor (GPME). For detailed instructions, see “Creating and Editing a GPO,” page 99.)

2. Access the management dashboard and disable the rule wizard by checking the Disable Wizard check box.

3. To create a rule that applies to a computer or user, use the appropriate instructions:

For a computer -Click Computer Configuration, Policies, Beyondtrust, PowerBroker Desktops.

For a user - Click User Configuration, Policies, BeyondTrust,

PowerBroker Desktops.

4. Right-click the PowerBroker Desktops node and select Create New Rule.

Note: When the wizard is disabled, clicking Create a new Rule on the dashboard opens the rule property sheet.

(33)

5. To modify an existing rule, right-click the rule and select Properties.

6. To continue, see “Targeting an Application or a Process with a Rule,”

page 34.

Tip: Duplicating a rule

You can copy and paste (or drag and drop) a rule in the Group Policy Management Editor to create a duplicate rule. You can then modify the duplicate rule.

(34)

Targeting an Application or a Process with a Rule

To modify the security for an application or a process, you must first create a rule based on information about the target application or process. This rule modifies the security token associated with the application.

Use the following rule types to define the targeted application: – Path - Target an application by its file path location – Publisher - Target an application by its digital signature – Folder - Target all applications by its folder

– Hash - Target an application version regardless of location – ActiveX - Target the installation of specific ActiveX control, all

ActiveX controls, or any installation initiated by Internet Explorer – CD/DVD - Target all applications on a CD or DVD

– MSI Path - Target an MSI package based by location – MSI Folder - Target all MSI packages in a folder

– Shell - Enable users to elevate any application on demand – UAC - Target all applications started by UAC

For additional help in determining the type of rule you need, see “Rule Types and Tasks,” page 19 to view reference tables of tasks and appropriate rules.

Using the Rule Properties Dialog

The Rule Properties dialog contains all of the settings that can be applied to a rule. This dialog is where you select a rule type and customize the rule. Each tab in the dialog presents different settings and options. In the following screen, the Application tab is selected.

Note: Context-sensitive help is available for each tab in the Properties dialog.

(35)

In the following screen, the Rule drop-down menu displays the various rule types available and the Publisher rule is selected.

.

Using Wild Cards in Rules

Two wild card characters are supported in various rule text input fields in the rule property sheet. Rules that support wild cards include:

– Publisher - In the Product name, File name, or Product version fields – Shell - In the Arguments field

– Path - In Path and Arguments fields – Hash - In Arguments field

– Folder - In Folder field – MSI Path - In Package field – MSI Folder - In Folder field – UAC - In Path field

Observe common conventions when using the following wild card characters: – * - Replaces one or more characters in a string

– ? - Replaces an individual character in a string

The net effect of a wild card in the rule text input fields is to make a rule or an argument more generic, which may not always be in the best interest of the rule.

(36)

For example, when using wild cards for path rules, you want to make the path as specific possible to keep the rule secure. Wild card placement in the following argument makes the rule very broad and can potentially allow abuse.

http://*printerandpcvendor.com/*

However, by placing the wild card argument and using the following text, it narrows the wild card’s reach:

http://printerandpcvendor.com/printers/downloads/*

In this example, specifying as much as possible of the actual URL prevents a standard user from downloading unapproved files from unforeseen locations. Another typical use for a wild card is in a setting in which a naming

convention is used to represent hardware. In this case, a wild card can be substituted for certain name elements.

For example: \\corporateserver_accounting1 \\corporateserver_accounting2 \\corporateserver_sales \\corporateserver_engineering \\corporateserver_marketing

can be addressed using the following wild card notation: \\corporateserver*

Wild Cards and Subfolders

A check box setting available in many rule types can change rule behavior when a wild card is used. The following setting allows a rule to traverse a directory structure:

Apply rule to all programs in all subfolders of the specified folder.

When this setting is enabled and a wild card is used, the rule behaves as described in Table 3. For this example, the rule path statement or argument uses the following statement: C\Folder1\*\my.exe where the wild card represents a folder..

Table 3. Rule Behavior for C:\Folder1\*\my.exe Subfolder

Setting

Is Enabled Executable Path

Exe File Is Elevated No c:\Folder1\my.exe No Yes C:\Folder1\my.exe No No C:\Folder1\Folder2\my.exe Yes

(37)

As shown in the previous table, when the subfolder setting is enabled, the rule searches through the subdirectory structure looking for a match until it finds one.

In addition, if the * wild card is substituted for the executable name (*.exe), all executable files in the directory structure then have the rule applied. This technique is often used to apply a rule to multiple applications stored in a hierarchical directory structure.

Path Rule - Target by Location

To target an application or process based on its location so that you can modify its permissions or privileges when it is run, do the following:

1. Using the rule wizard or, on the Application tab in the Properties dialog box, select Path rule to target an application by its program file path

2. Enter a path or click to select a process or application. Based on your operating system software, you can choose from a variety of template rules.

Yes C:\Folder1\Folder2\my.exe Yes

No C:\Folder1\Folder2\Folder3\my.exe No

Yes C:\Folder1\Folder2\Folder3\my.exe Yes

Table 3. Rule Behavior for C:\Folder1\*\my.exe Subfolder Setting Is Enabled Executable Path Exe File Is Elevated

(38)

3. Select one of the following:

– A process running on your computer.

– A standard Windows process, such as Add or Remove Programs or

Display. Select the specific Windows version (and in some cases the service pack) and whether to target the Control Panel, Desktop, or

Task bar process. – An application.

– An executable file. Click Select a File to navigate to an executable file, which can be either a local file or a file on a network share path. It is recommended that you create rules based on network share paths using the fully qualified UNC (universal naming convention) paths, such as \\MyServer\MyFolder\MyApp.exe. If necessary, mapped drives may be used. When you create a rule based on a mapped drive, check Allow use of mapped drive letter in path on the Options

tab.

Note: Because a limited user has the ability to change a mapped drive, checking this option presents a security risk because it can enable the user to elevate an unintended application. If the following Default Security Settings dialog displays, you can click Yes

to automatically populate the permissions and privileges needed for this task:

(39)

Selecting Yes is recommended to simplify identification of these

permissions and privileges even if your intention is to restrict them. You can modify these security settings when you configure options on the

Permissions and Privileges tabs.

4. Optional. Select additional targeting options:

– To target this application only if specific command line arguments are used when the application is launched, enter the Arguments. This field is not case-sensitive. Depending on your Path selection, the field may be automatically populated.

– To target this application regardless of any command line arguments specified when the application is launched, leave this field blank. – To apply the rule only if the users type in their password, select Apply

rule only if user can authenticate (must provide credentials). – To require the users to type a justification for the elevation, select

Require user to enter text justification. If this check box is enabled, the users are prompted to enter an explanation each time they elevate an application.

– To target all applications in subfolders of this folder, select Apply rule to all programs in all subfolders of the specified folder. – To target this application only if it is a local file owned by the

Administrators group, select Apply rule only if program is owned by the Administrators group. (To target a specific file regardless of location, use a Hash rule instead.)

– To cause processes launched by this application to inherit these permission or privilege changes, select Apply rule to all processes

(40)

5. To continue, see “Modifying Permissions,” page 66 or “Modifying Privileges,” page 68.

Path Rule Examples

The path rule can be used in creative ways to target a variety of objects other than major applications. The following examples demonstrate how the Path rule can be applied to scripts, batch files, registry operations, and more. Elevate IE for a Specific Web Site

A unique application of a Path rule is to elevate Internet Explorer when the users access a specified Web site. This functionality is available only for IE versions 7, 8, and 9.

To elevate IE 7, 8, or 9 for a specific Web site, do the following: 1. Create a Path rule with the following settings:

– Path - Full path to the iexplore.exe file – Arguments - URL of Web site to be elevated – Permissions - Add BUILTIN\Administrators – Integrity Level - Medium recommended

When the user browses to the specified Web site, a second instance of IE will launch in a new window with elevated permissions. The title bar in the new window will reflect the fact that IE is running in an elevated state, and Rule Applied will display in the lower-left corner of the new window.

If the users browses from one specified site to another, the rule is not reapplied. Another rule that includes the second URL is required for any additional Web sites.

When multiple IE elevation rules are required, make sure that permissions, privileges and integrity levels are consistent for all rules.

Tip: Using variables and partial command lines

You can use variables in the Path and Arguments fields. For a list of variables, click the field and press F3, then double-click to select.

You can also use wild card characters in the Path and Arguments fields. Two wild cards are supported:

* - Can replace one or more characters

? - Can replace any individual character

You can use a partial command line in the Arguments field. A partial command line is considered a match as long as each character from left to right matches the beginning of the actual process command line.

(41)

The following figure shows a typical IE elevation Path rule Properties dialog:

Note: Elevation of Internet Explorer 9 - IE 9 elevation is not as obvious as elevation in other IE versions. In a default IE 9 installation, the only elevation indicator is BT on the page tab. Title bar & status bar elevation information is not displayed.

You can set IE 9 preference to enable the status bar. Toggle the ALT key and the menu bar appears or disappears. To view the Status bar, right-click in a blank area and then enable Status Bar in the menu. Elevate a Visual Basic Script

To elevate a script, create a rule to point to the scripting host. In the

arguments field, target the rule to the specific script you would like to elevate to prevent the user from elevating any script.

(42)

The following figure shows a Path rule that elevates a script:

Taking another approach, you can enter WindowsServer\Netlogon in the

Path field without a file specified. This approach elevates all scripts in the Netlogon folder. For another alternate, you can use a Folder rule.

Elevate a Registry Merge

To elevate a registry merge, add the path to regedit.exe. In the arguments field, scroll down to the registry file you wish to elevate as shown in the following example:

Note: The elevation of the *.reg and script files are targeted to the item in the arguments field, the user cannot self elevate any script or *.reg file on their own when an argument is present.

(43)

Elevate a Batch File

A batch file is actually an application and can be treated as one with regard to elevation. As a result, you can elevate a batch file by specifying the path to (or hash of) the batch file as shown in the following example:

(44)

Publisher Rule - Target by Digital Signature

Use the Publisher rule to target a digitally signed file by any element of its digital signature.

Note: As of V5.0, the Publisher rule replaced the Certificate rule. Existing Certificate rules are brought forward during an upgrade. However, to update these Certificate rules to the more advanced Publisher rules, you must open a Certificate rule in version 5 and then save it. After you do this, any additional version 4.x Certificate rules are updated to Publisher rules.

Signed files can include executable files, MSI files, DLL files, and so forth. Signature elements can include the name of publisher (company), the application name, the file version number, the date of release, and more. After you have selected a signed file to target, the Publisher rule configuration dialog looks similar to the following:

(45)

Use the slider control to add items to the rule or enable Use custom values

and enter items directly in the input fields. Target by Publisher Only

Targeting the Publisher element of a signed file has several advantages: The file can move to any location and the rule will still apply. In addition, the file can be updated to a newer version and still be managed by the same rule. To target a file by the Publisher element of its digital signature, do the following:

1. Using the rule wizard or, on the Application tab in the Properties dialog, select Publisher rule.

2. Select a signed file to target. You can select either of the following: – Process running on your computer (providing it is signed) – File. Click Select a file and navigate to the file.

3. Select the file. The name of the publisher displays in the Publisher field. 4. Optional. Select additional targeting options from the following:

– To apply the rule only if the users authenticate using their Windows credentials, select Apply rule only if user can authenticate. – To apply the rule only if the user enters in a justification for the

elevation, select Require user to enter text justification.

– To target an application in this folder only if it is a local file owned by the Administrators group, select Apply rule only if program is owned by the Administrators group.

(46)

Target by Any Digital Signature Element

You can make a rule that targets a very specific instance of a signed file. This enables you to build granular Publisher rules that are based on individual characteristics of a file signature.

To target a file by an element of its digital signature, do the following:

1. Using the rule wizard or, on the Application tab in the Properties dialog, select the Publisher rule.

2. Select a signed file to target.

3. In the Signature dialog, use the slider control to select one or more of the following signature elements:

– Publisher - Name of the specific software publisher – Product name - Name of the software product

– File name - Name of signed file (EXE, DLL, MSI, and so forth) – Product version - Version number of the specific product release

4. Optional. Enable the Use Custom Values check box to change or refine displayed signature information. For example, you may choose to do the following:

– Use the version widget to specify an earlier or later product version than the version displayed in the File version box.

– Change any value in the text input fields. 5. Click OK to return to the Property dialog.

6. Optional. Select any of the following targeting options:

– To apply the rule only if the user authenticates using their Windows credentials, select Apply rule only if user can authenticate. – To apply the rule only if the user enters in a justification for the

elevation, select Require user to enter text justification.

– To target an application in this folder only if it is a local file owned by the Administrators group, select Apply rule only if program is owned by the Administrators group.

– To cause processes launched by this application to inherit these permission or privilege changes, select Apply rule to all processes launched by the targeted application.

Tip: Broaden a Publisher rule’s scope by using a wild card.

You can broaden the scope of a Publisher rule by using the (*) wildcard character. This character can be used in the following Publisher rule input fields: Product name, File name, and

Product version. The * must be used to replace an entire string. Partial strings (str*) incorporating the * are not supported.

(47)

Hash Rule - Target Regardless of Location

To target a specific application regardless of its location so that you can modify its permissions or privileges when it is run, do the following:

1. Using the rule wizard or, on the Application tab in the Properties dialog, select Hash rule to target an application by hash code.

2. Click to select an application. You can select any of the following: – A process running on your computer.

– An executable file. Click Select a File to navigate to an executable file, which can be either a local file or a file on a network share path. It is recommended that you create rules based on network share paths using the fully qualified UNC paths, such as

\\MyServer\MyFolder\MyApp.exe.

If necessary, mapped drives may be used. When you create a rule based on a mapped drive, check Allow use of mapped drive letter in path on the Options tab.

(48)

Note: Because a limited user has the ability to change a mapped drive, checking this option presents a security risk because it can allow the user to elevate an unintended application. An SHA1 hash code is calculated from the selected executable or process. 3. Optional. Select additional targeting options:

– To target this application only if specific command line arguments are used when the application is launched, enter the Arguments. This field is not case-sensitive.

– To target this application regardless of any command line arguments specified when the application is launched, leave this field blank. – To apply the rule only if the user types in their password, select Apply

rule only if user can authenticate (must provide credentials). – To require the user to type a justification for the elevation, select

Require user to enter text justification. If this check box is enabled, users are prompted to enter an explanation each time they elevate an application.

– To cause processes launched by this application to inherit these permission or privilege changes, select Apply rule to all processes launched by the targeted application.

4. To continue, see “Modifying Permissions,” page 66 or, “Modifying Privileges,” page 68.

(49)

Folder Rule - Target Contents of a Folder

To target all applications in a specific folder so that you can modify their permissions or privileges when they are run, do the following:

1. Using the rule wizard or, on the Application tab in the Properties dialog box, select Folder rule- Target all applications in a folder.

2. Enter a path or click to select a folder, which can be either a local folder or a folder on a network share path. Wild cards are supported in this field.

Tip: Using variables and partial command lines

You can modify the Arguments field to include variables. For a list of variables, click the field and press F3, then double-click to select a variable.

You can also use wild card characters in the Path and

Arguments fields. Two wild cards are supported:

* - Can replace one or more characters

? - Can replace any individual character

You can use a partial command line in the Arguments field. A partial command line is considered a match as long as each character from left to right matches the beginning of the actual process command line.