Managing Access Rights and Roles

This chapter describes how to establish role-based access controls for the computers that have the Agent for Windows installed and identity and privilege management features enabled.

Basics of Authorization and Access Rights

You can use Access Manager to centrally manage what users can do on computers that have the Agent for Windows installed. For example, you can control who can log on or connect remotely for each computer in a zone through the assignment of roles. As discussed in Managing access rights and roles using zones, a right represents a specific operation that a user is allowed to perform.

System Rights Allow Users to Log On

For Windows computers, the most basic rights are the system rights that determine whether a user can log on locally, log on remotely, or both. The rights that grant users local and remote access are defined by default in the Windows Login role so that you can grant users access simply by assigning the Windows Login role and without defining any custom roles or any additional access rights. You can enable or disable these system rights in any custom role definition, but you cannot add, modify, or delete them.

In most cases, you can assign the Windows Login role to all local Windows users, all Active Directory users, or both, to allow users to log on locally or remotely. However, the system rights in the Windows Login role do not override any native Windows security policies. For example, most domain users are not allowed to log on locally on domain controllers. Depending on how your organization has configured native Windows security policies, users might need to be members of a specific Windows security group, such as Server Operators or Remote Desktop Users, to log on to specific computers locally or remotely.

If you would like to require multi-factor authentication for users or groups that use IBM Security-managed Windows computers, you must assign them the require MFA for login role in addition to the Windows Login role as there is no system right to enable multi-factor authentication within the Windows Login role.

If you enable multi-factor authentication, users will be required to type their password and provide a second form of authentication before being able to log on. For example, you can configure an authentication profile that requires users to answer a phone call, click a link in an email message, respond to a text message, provide a one-time password (OTP) token, or answer a security question. Before defining this system right, however, you should be aware that multi-factor authentication for IBM Security-managed Windows computers relies on the infrastructure provided by the Privileged Access Service.

For more information about preparing to use multi-factor authentication, see the Multi-factor Authentication Quick Start Guide.

In addition to the system rights that specify whether a user can log on locally or remotely, you can use the Rescue rights setting to specify that users in a particular role should always be allowed to log on to a computer. This option is intended as a “safety net” for “emergency” situations when users would normally be locked out. For example, if auditing is required for a role, but the agent is not running or has been removed, users are not allowed to log on. You can use the rescue rights option to allow selected administrative users access to computers when they would otherwise be locked out and prevented from logging on. Because this option allows unaudited activity, you should strictly limit its use.

If you do not explicitly set the Rescue rights option for any users, only the local administrator and the domain administrator accounts will have rescue rights. Those accounts are always allowed to log on by default.

Windows-specific Rights Can Grant Users Privileged Access

In general, you use the default Windows Login role for most users during the initial deployment to prevent disruptions in user access. You can then define custom roles to add specialized access rights to grant users additional privileges in a controlled manner.

For Windows computers, these specialized access rights are:

• Desktop access rights enable users to create additional working environments and run applications in that desktop with their own credentials but as a member of an Active Directory or built-in group. Users who are assigned to a role with desktop rights can switch from their default desktop to a desktop with administrator privileges without having to enter an Administrator password. With a desktop right, users can also run any application from their default desktop using a selected role and credentials without opening a new desktop.
• Application access rights enable users to run specific local applications as another user or as a member of an Active Directory or built-in group. Users who are assigned to a role with application rights can log on with their normal Active Directory credentials and run a specific application using a role with elevated privileges without having to enter the service account or Administrator password.
• Network access rights enable users to connect to a remote computer as another user or as a member of an Active Directory or built-in group to perform operations, such as start and stop services, that require administrative privileges on the remote computer. Users who are assigned to a role with network access rights can perform administrative operations on a remote server using a role with elevated privileges that only applies to the operations performed on the network computer without having to enter the service account or Administrator password. You can use zones to control who can connect and perform tasks on remote computers and what their elevated privileges allow them to do.

Combining Rights into Roles and Role Assignments

You can combine the system rights and specialized Windows rights into role definitions that reflect the needs of a specific job function, such as database administrator or web services administrator, or a particular task, such as troubleshooting application failures. You can then assign those roles to specific users and groups.

You can configure rights, role definitions, and role assignments in any parent or child zone. In most cases, you define rights and roles in a parent zone and make role assignments in a child zone.

Roles can be assigned to individual Active Directory users or to Active Directory groups. Therefore, you can manage how roles are applied to users completely through Active Directory group membership.

The rights from multiple role assignments accumulate, which provides great flexibility and granularity in how you define and assign rights and roles. For example, you can use the Windows Login role to control console and remote access, and define a second role with desktop access rights so that a user assigned to both roles could log in and create another desktop for accessing applications with administrative privileges. By separating login and desktop access rights into separate roles, not every user who is allowed to log on can create a desktop with administrative privileges.

Deciding Where to Define and Assign Roles

Because access rights are additive, it is important to consider where you define and assign roles to control who has administrative privileges on which computers. For example, it might seem reasonable to assign the predefined Windows Login role to all Active Directory users. Doing so, however, could grant broad permission to log on locally or remotely on computers to which you want to restrict access. If you assign that role in a parent zone, it is inherited along with any additional rights granted in child zones.

In most cases, it is appropriate to define roles in parent zones, but assign roles carefully in child zones to avoid granting access rights on computers that host administrative applications or sensitive information.

Adding Predefined Rights to a Zone

There are many predefined rights available that grant access to specific Windows applications. For example, there is a predefined Performance Monitor right that allows users to run Performance Monitor on a computer without being a local administrator or knowing an administrative password.

You can add any or all of these predefined rights to any zone so they are available to include in role definitions. Alternatively, you can add predefined rights to individual role definitions without adding them to zones. In either case, you create the predefined rights in the context of a role definition.

To create predefined rights in a zone:

1. Open the Access Manager console.

2. Expand Zones and the parent zone or child zones until you see the zone where you want to define a predefined right.

3. Expand Authorization > Role Definitions.

4. Select a role definition, right-click, then select Add Right.

5. Select a type of right if you want to filter the list of rights displayed.

   For example, select Any Windows Rights or Any Windows Applications to list only Windows-specific rights.

6. Click Create Predefined Rights.

7. Select the specific predefined rights you want created in the zone you selected in Step 2 from the list of available rights, then click OK.

   By default, all of the selected predefined rights are added to the role definition in the zone. You can deselect any of the rights you don’t want added to the role definition.

8. If you have selected at least one of the predefined rights as applicable for the role definition, click OK.

   If none of the predefined rights is applicable for the role definition, you can click Cancel to add the rights to the zone without adding them to the role definition.

You can click Refresh in Access Manager to see the predefined rights listed as Windows application rights.

Enabling Multi-factor Authentication for Windows Rights

In addition to the require MFA for login role, which requires users to provide both their password and a second form of authentication to log on to a IBM Security-managed Windows computer, you can enable multi-factor authentication for a predefined right. When you define a desktop, application, or network access right, you can choose to enable multi-factor authentication for that right. For example, if you want to require multi-factor authentication before a user can open a privileged desktop, you would issue that user a role with a predefined desktop right that has multi-factor authentication enabled.

To enable multi-factor authentication for a right definition:

1. Right-click the predefined right after adding it to a role definition.

2. Select Properties.

3. Click the Run As tab and select Re-authenticate current user and Require multifactor authentication.

   Before defining this right, you should be aware that multi-factor authentication for IBM Security-managed Windows computers relies on the infrastructure provided by the Privileged Access Service.

4. Click OK.

Using Multi-factor Authentication When There are Selective Cross-forest Trusts

If you have domains in different forests that have a two-way selective trust relationship, any computer or user accounts that are used to log on to the remote forest must be granted the “Allowed to authenticate” right on the domain controllers in both forests to get role information.

In addition to granting the “Allowed to authenticate” right to users and to computers with the Agent for Windows installed, the right must also be granted to computers that host your connectors.

After you grant these computers and users the “Allowed to authenticate” right for the domains in both forests, users that are assigned a role with a multi-factor authentication right for privilege elevation will be able to authenticate using any of the authentication mechanisms that you have assigned to them.

If a connector is not allowed to authenticate on the remote domain controller, some multi-factor authentication mechanisms may fail to authenticate users.

For more information about preparing to use multi-factor authentication, see the Multi-factor Authentication Quick Start Guide.

Defining Desktop Access Rights

When users log on with their normal Active Directory credentials, Windows brings up the default desktop for the user logging on. You can define desktop rights to enable users to create additional working environments—new desktops—that run using their own credentials but with the privileges of an Active Directory or built-in group.

Users who are assigned to a role with desktop rights can switch from their default desktop to a desktop with elevated privileges to perform administrative tasks. For example, if assigned to a role that has a desktop right, a user can create a new desktop and switch to it when he needs perform administrative tasks such as install new software or stop running services on the local computer account. The user can perform these tasks without having to enter the service account or Administrator password.

Users who are assigned a role with desktop rights can also select any application on the computer, right-click, and run the application using a selected role. The difference between the desktop right and an application right is that the desktop right allows the user to run any applications using the privileged account defined in the desktop right. An application right restricts access to a specific application using the privileged account explicitly defined for that application.

Desktop rights are useful for users who frequently perform tasks that require the privileges associated with the Administrator account.

To define a desktop right:

1. Open the Access Manager console.
2. Expand Zones and the parent zone or child zones until you see the zone where you want to define a desktop right.
3. Expand Authorization > Windows Right Definitions.
4. Select Desktops, right-click, then click New Windows Desktop.
5. On the General tab, type a name and a description for the desktop right.

   For this	Do this
   Name	Type the name you want to use for this desktop right. For example, if the desktop allows a user to create a desktop using the privileges associated with a service account, you might include the security group in the name.
   Description	Type a description for this desktop right. The description is optional. You can use it to provide a more detailed explanation of the privileges associated with the desktop.
   Priority	Set the priority for this desktop right.

6. Click the Run As tab.

   You can browse for and select a specific group that will allow you to log on with your own credentials but with the elevated privileges of the specified group.

   Click Add AD Groups or Add Built-in Groups to search for and select a previously-defined or built-in group with the privileges you want to add to the logged in user’s account.

   Select No re-authentication required to allow users to use the desktop right without any additional authentication.

   Select Re-authenticate current user if you want to prevent the desktop right and its privileges from being used by anyone not authorized to do so. Selecting this option also allows you to enable multi-factor authentication for the right. For more information, see Enabling multi-factor authentication for Windows rights.

   If you select the Re-authenticate current user option, users are prompted to re-enter their password to verify their identity before they are allowed to create a new desktop or switch between desktops. Forcing users to re-authenticate ensures the privileges associated with the desktop are only granted to users who have been assigned those privileges.

   If you select this Re-authenticate current user option for users who are authenticated using a smart card, users must enter a personal identification number (PIN) or a password to resume working with the desktop.

7. Click OK to save the desktop right.

Where Desktop Rights Apply

Desktop rights can be used on Windows servers and workstations that have a traditional Windows desktop. If the computer you are using is running Windows 8 or 8.1, or Windows Server 2012 or 2012 R2, Windows does not provide access to applications natively when you switch from the default desktop to a privileged desktop due to changes to the underlying interfaces and supported features within the operating system. To enable access to applications on computers running these versions of Windows, the Agent for Windows provides a custom start menu. The start menu allows you to open and run applications as you would on Windows 7 or Windows Server 2008 R2. The start menu is installed on the left side of the taskbar and displays the IBM Security logo. This start menu is only available if you are using a role with IBM Security desktop rights and cannot be modified.

Defining Application Rights

Application rights allow users to run specific applications using either another user account or using their own credentials but with the privileges of an Active Directory or built-in group.

When you create an application right, you specify one or more application executable files to which you want to control access. The capability to specify more than one executable file in a single application right takes into account situations in which one application might reside in different locations on different computers. For example, the executable file for SQL Server Management Studio resides in different locations in Windows 2005, Windows 2008, and Windows 2012. By specifying all instances of the executable file in one application right, you can use that application right to control access to SQL Server Management Studio on computers running any of those operating systems.

You can also use IBM Security application utilities to allow access to common administrative tasks such as software installation, network, and Windows feature management. For more information on using these utilities, see Using IBM Security application utility rights

Although it is possible to define different applications (for example, SQL Server Management Studio and Internet Explorer) in one application right, this is not a recommended practice. Instead, it is recommended that you create separate application rights for different applications.

How to Specify Which Applications are in an Application Right

You can specify which application executable files are in an application right in these ways:

• You can specify the path and file name of an application executable file. You can perform this operation in two ways:
  • Manually, by typing or pasting the path and file name into an application right definition form. Specifying files manually is recommended only if you need to include a small number of files in the definition—typically just one or two. See Defining an application right manually for more information.
  • By navigating to the executable file or a running process that was launched by the executable file. After locating the executable file, you can import the path and file name into the application right definition form. See Using an installed application or running process to create application rights for more information.
• You can specify search criteria for application executable files, and then include all application executable files that match those criteria in the application right. You can perform this operation in two ways:
  • Manually, by typing or pasting values into search criteria fields. See Defining an application right manually for more information.
  • By importing values into search criteria fields from an executable file or from a running process that was launched by the executable file. See Using an installed application or running process to create application rights for more information.

See Examples of application right definitions for examples of defining application rights in all of these ways.

Defining an Application Right Manually

This section describes how to create an application right by manually typing or pasting information into several application right definition forms.

Alternatively, you can import information into application right definition forms from an executable file or from a running process that was launched by the executable file. See Using an installed application or running process to create application rights for more information.

To define an application right manually:

1. Open the Access Manager console.
2. Expand Zones and the parent zone or child zones until you see the zone where you want to define an application right.
3. Expand Authorization > Windows Right Definitions.
4. Select Applications, right-click, then click New Windows Application.
5. On the General tab, type a name and a description for the application right, and specify a priority for the application right.

   For this	Do this
   Name	Type the name you want to use for this application right. For example, if the right allows a user to run SQL Server Configuration Manager using the privileges associated with a security group, you might include the service account in the name. For example, you might use a name like SQL Config Manager.
   Description	Type a description for this application right. The description is optional. You can use it to provide a more detailed explanation of the privileges associated with running the application.
   	Set the priority for this application right. If more than one application right is added to the same role definition, the priority value determines the application right to use when users assigned to that role open that application. The lower the value, the higher the priority. For example, a right with the priority of 1 takes precedence over a priority value of 2. If the application rights have the same priority value, the application right listed first under the role definition is used.

6. Click the Match Criteria tab and use it to create or edit application definitions. Each application definition specifies one application or a group of applications. The set of application definitions displayed in the Match Criteria tab defines the set of applications that can be run by this application right.

   In the Match Criteria tab, click Add to create a new application definition.

   The Definition Settings dialog appears.

7. In the upper portion of the Definition Settings dialog, provide this information about the application definition.

   For this	Do this
   Description	Type a description for this application definition. For example, if the definition specifies one executable file (such as SQL Server Management Studio for Windows 2005), you might type Windows 2005 SQL Server Management Studio here. Or, if the definition specifies more general criteria so that multiple executable files (such as SQL Server Management Studio for all versions of Window) can run, you might type a more general description such as SQL Server Management Studio.
   File Type	Select the type of executable file for this definition. If you are constructing the definition so that it specifies multiple executable files, all files must all be of the type that you specify here. Supported file types are: .bat .cmd .com .cpl .exe .msc .msi .msp .ps1 .vbs .wsf

8. To specify executable files in this definition by typing or pasting the file name and location, select the Path option. Go to Step 9 and continue from there.

   Specifying files in this way is recommended only if you need to include a small number of files in the definition—typically just one or two.

   To specify a larger number of executable files in this definition, it is recommended that you select file parameters that are common to the set of files. Files that match the parameters are then included in the definition. To do this, go to Step 10 and continue from there.

9. Perform this step to specify a small number of executable files in this definition. In this step, you type or paste information about the executable file name, location(s), and arguments. When you are done with this step, go to Step 11 and continue from there.

   For this	Do this
   Name	Type the name of the application executable file. If this field is defined, you must also select a path option (standard system path or a specified path). For example, to specify the SQL Server Management Studio executable, type Ssms.exe.
   Standard system path	Select Standard system path to use the directories where the user would normally find the application specified. For example, to use the application executable in its default directory, select Standard system path.
   Specify path	Select Specify path if you want to define the location of the application specified. If you select this option, you can specify one or more paths, separated by a semicolon (;). Supported path variables are %systemroot%, %system32%, %syswow64%, %program files%, %winagentinstall%, and %program files(x86)% (note that a space between “program” and “files” is required). For example, to specify the location of the SQL Server Management Studio executable file in Windows 2008, type C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE.
   Arguments	If you selected a file type of .msc in Step 7, the Arguments option is required. The Arguments option is optional for all other file types. Select the Arguments option and leave the argument field blank to specify that the application cannot accept any arguments. To specify that the application can run using any argument, leave the Arguments option deselected. For example, if you specified the SQL Server Management Studio executable and left the Arguments option deselected, users can run SQL Server Management Studio with any option on a local computer with elevated privileges. If you want to restrict the arguments allowed, in the argument field type the list of arguments to allow. Valid arguments be must enclosed by quotation marks and separated by a space. For example, to allow users to run the specified application using argument1, argument2, or argument3, you would specify the list of arguments like this: “argument1” “argument2” “argument3” By default, arguments that you specify do not need to be a case-sensitive match, but do need to be an exact match (that is, a match is returned if the actual argument is a partial match of the argument string that you specify). If arguments must be a case-sensitive match for a particular application, select the Keep arguments case sensitive option. If arguments can be a partial match for a particular application, deselect the Match whole string only option.

10. Perform this step to specify a larger number of executable files in this definition. In this step, you use the File details area to specify characteristics that are used to search for applications to include in this definition. All of the characteristics that you specify must be met in order for an application to be a match. For example, if you specify a product name of Microsoft SQL Server and a company name of Microsoft Corporation, all executable files that meet both of those criteria are included in this definition.

    This step describes how to manually fill in each field in the File details area. You can select any combination of these fields to specify the file characteristics for which to search. Alternatively, you can populate fields in the Definition Settings dialog by importing values from an installed executable file or from a running process. Filling in fields by importing is faster and more accurate than filling in fields manually one at a time. For details about filling in fields by importing, see Using an installed application or running process to create application rights.

    For this	Do this
    Product Name	Select an operator (is or contains) from the drop-down list and in the provided field type the product name for which to search. If you select is, matches are returned for product names that exactly match the string that you type here. If you select contains, matches are returned for product names that contain the string that you type here anywhere in the product name.
    Company	Select an operator (is or contains) from the drop-down list and in the provided field type a company name for which to search.
    File Description	Select an operator (is or contains) from the drop-down list and in the provided field type a file description for which to search.
    Volume Serial #	Select an operator (is, contains, starts with, or ends with) from the drop-down list and in the provided field type a serial number for which to search. The supported format is 8-character hex string (FFFFFFFF). This criterion is matched only if the executable file was from CD/DVD media.
    Publisher	Select an operator (is, contains, starts with, or ends with) from the drop-down list and in the provided field type publisher information for which to search. For example, publisher information could look similar to: CN=Acme Corporation, OU=Digital ID Class 3 - Microsoft Software Validation v2, O=Acme Corporation, L=Sunnyvale
    Product Version	Select an operator (equal, earlier or equal, or later or equal) from the drop-down list and in the provided field type product version information for which to search. For example, the product version could look similar to: 3.1
    File Version	Select an operator (equal, earlier or equal, or later or equal) from the drop-down list and in the provided field type file version information for which to search. For example, the file version could look similar to: 3.1.2
    File Hash	Select this option to match applications using the encrypted file hash for the application. The file hash for the application is generated using the SHA-1 encryption algorithm, which is FIPS compliant. You can click Import Process or Import File and select an application to populate the File Hash field for which to search. Only applications with a hash string that is exactly the same as the string generated by the MD5 algorithm are matched. You can only use file hash matching to identify an application for files that are less than 500MB to limit the CPU and memory used to calculate the file hash. If the file with matching hash information is larger than 500MB, an empty value is returned for the file hash field.
    Owner	In the provided field, type owner information for which to search. Matches are returned for owner information that exactly matches the string that you type here. Owner information can be: AD user/group/builtin (SID) local user (user name) local group (group name) For example, the owner could look similar to: NT AUTHORITY\SYSTEM DEMO\Ed.Admin (this is an AD user account) Amy Adams (this is a local user account)

11. Optionally select the Application requires administrative user option to specify that applications in this definition run only if RequestedExecutionLevel is set to requireAdministrator in the application manifest. If you select this option, the applications in this definition run only for administrators and require that the applications be launched with the full access token of an administrator. This option applies only to .exe files.

12. Click OK to save the definition. You are returned to the Match Criteria tab, and the new or modified definition appears in the Match Criteria list of definitions.

13. Click the Run As tab and select the account that has the privileges you want to enable for this application right.

    You can browse for and select a specific user account or have the application run using the logged in user’s account credentials but with the elevated privileges of a specified group. Click Add AD Groups or Add Built-in Groups to search for and select a previously-defined or Built-in group with the privileges you want to add to the logged in user’s account.

    In most cases, you select a specific user account only if the application should run as a service account. However, some applications require a specific privileged user account to be used. For example, Microsoft System Center Operations Manager (SCOM) and Exchange require a user account. If you are defining an application right for an application that requires a privileged user account rather than membership in a privileged group, you should create a service account and use that account for the run-as account.

    Select Re-authenticate current user if you want to prevent the application right and its privileges from being used by anyone not authorized to do so. Selecting this option also allows you to enable multi-factor authentication for the right. For more information see Enabling multi-factor authentication for Windows rights.

    If you select this option, users are prompted to re-enter their password to verify their identity before they are allowed to select a role for running a local application. Forcing users to reauthenticate ensures the privileges associated with the application right are only granted to users who have been assigned those privileges.

    If you select this option for users who are authenticated using a smart card, users must enter a personal identification number (PIN) or a password to resume working with the application.

14. Click OK to save the application right.

Using Application Utility Rights

This section describes how you can manage user access to Windows programs and features using application utility rights.

There are many common administrative tasks such as managing software installations, changing network settings, and adding or removing Windows features that require access to the explorer.exe application on Windows systems. Because granting users privileged access to explorer.exe can allow the user to perform many other tasks that you may want to remain restricted, you can use the IBM Security application utilities, Application Manager, Network Manager and Windows Feature Manager, to grant access to these tasks using the corresponding predefined rights.

When you create a new zone, the IBM Security utility rights are automatically added to the list of Windows Right Definitions. However, in zones that existed before the addition of these utility rights, you may need to add them by following the procedure below.

To add the IBM Security Utilities to the list of Windows Right Definitions

1. Right click Windows Right Definitions and select Add predefined rights.

   Windows Right Definitions can be found in the following location:

   The application rights can be found in the following location:

   Access Manager > Zones > Zone Name > Authorization > Windows Right Definitions

2. Select the rights you would like to add and click OK.

   The rights will now appear under Applications.

It is important to note that if you do not install the Agent for Windows in the default location during the installation or upgrade process, users who are assigned these rights may not be able to access the corresponding applications. If you have installed the agent in a location other than the default location, you can specify a variable in the application right settings to allow them to be used by assigned users by doing the following:

To specify the application right path

1. Right click on the application right and select Properties.

   The application rights can be found in the following location:

   Access Manager > Zones > Zone Name > Authorization > Windows Right Definitions > Applications.

2. Click the Match Criteria tab, and then click Edit.

3. Check the Path box in the Commands components section, and select Specific path.

4. In the Specific path field, enter the following variable: %winagentinstall%

Do this for each of the Utility application rights.

Application Manager

Application Manager is a utility that allows a user to manage installed software. Application Manager is similar to the Windows utility Programs and Features. It can allow users who are assigned a role with the Utility - Application Manager right to Refresh, Uninstall, Change, or Repair installed software.

Windows Feature Manager

When you assign workstation users a role with the predefined right Utility - Windows Feature Manager, they will be able to access the normal Windows Feature Manager, where they can choose what Windows features to add or remove.

When you assign server users a role with this right, the Windows Feature Manager will launch. This utility is similar to the normal Windows utility, with a few notable differences.

Opening the utility will launch a wizard. When you select whether to add or remove roles and features on the first screen of the wizard, you can only perform one action at a time. For example, if you choose Add roles and features, you will not be able remove any installed features until you go back to the initial screen and choose Remove roles and features.

Additionally, when you attempt to install features that require the installation of dependent components, you will be prompted to add those features. All features with one or more components installed will appear with a check mark next to the name.

Network Manager

When you assign users a role with the predefined right Utility - Network Manager, they will be able to access the IBM Security version of Network Manager that is similar to the Windows version.

Users assigned a role with this right can view a list of network adapters for Ethernet and wireless connections and configure their IP and DNS settings.

Using an Installed Application or Running Process to Create Application Rights

This section describes how to create an application right by importing values from an installed executable file or from a running process. After values are imported into the application right definition form, you can select which fields to use as search criteria for matching applications. Applications that match the search criteria are included in the application definition.

For more information about filling in fields by importing, see Examples of application right definitions.

To define an application right based on an installed application:

1. Follow the procedure for creating a new application right manually to the point where the Definition Settings dialog opens (see Defining an application right manually).

2. In the Definition Settings dialog, click Import File.

3. Navigate to an application executable file, highlight the file, and click Open.

   Fields in the Definition Settings dialog fill in with all of the information that is available for the file that you selected. For example, if you navigated to C:\Program Files\Centrify\Access Manage and selected the Mmc_config.exe file, the Definition Settings dialog would look similar to this:

   

   Notice that:

   • The File Type field is set to .exe.

   • The Path option is selected, and the file name and path name are filled in.

   • Most fields in the File details section are filled in, but none are selected.

     The settings shown in this example specify that only the Mmc_config.exe <!---TODO update path ---> file located in C:\Program Files\Centrify\Access Manage is included in the application right. The information in the File details section is not used because no options in that section have been selected.

4. Choose whether to expand the definition to include other executable files, or to save the definition as it is currently defined (so that it specifies only the Mmc_config.exe file shown here).

   To expand the definition to include other executable files, go to Step 5 and continue from there.

   To save the definition as it is currently defined:

   • In the Description field, type a description for this application definition. This is the string that displays in the list of application definitions on the Match Criteria tab.
   • Click OK.
   • Continue to define the application right as described in Defining an application right manually.

5. To expand the definition to include other executable files, use the File details area to specify characteristics that are used to search for executable files. All of the characteristics that you specify must be met in order for an executable file to be a match. See Defining an application right manually for details about operators and syntax for each option in the File details area.

   • Deselect the Path option.

     This step is necessary because all of the search options that you select use the AND operator when the search executes. If you leave the Path option selected, the search is constrained to this location and the definition will include only the file that is specified in the Name field.

   • In the File details area, select options to define search criteria for executable files.

     Selecting criteria that are more general will usually result in a greater number of executable files being included in the definition. In the example shown in Step 3, you would select only the Company option if you wanted to allow this definition to run all .exe files having a company name tag of Acme Corporation. Select additional options to limit the scope of the search so that fewer executable files are included in the definition.

   • In the Description field, type a description for this application definition. This is the string that displays in the list of application definitions on the Match Criteria tab.

   • Click OK.

   • Continue to define the application right as described in Defining an application right manually. When you are done, the application right is available to use.

To define an application right based on a running process:

1. Follow the procedure for creating a new application right manually to the point where the Definition Settings dialog opens (see Defining an application right manually).

2. In the Definition Settings dialog, click Import Process.

   A list of running processes displays. By default, the list does not include these processes:

   Processes having an owner of SYSTEM, Local Service, or Network Service

   • conhost.exe

   • dllhost.exe

   • dwm.exe

   • explorer.exe

   • svchost.exe

   • taskhost.exe

     To display these processes, select the Show all processes option.

     System Idle Process and processes having unsupported file extensions (for example, .scr) are never shown.

3. Highlight a process and click OK.

   Fields in the Definition Settings dialog fill in with information from the executable file that launched the process that you selected.

4. Select executable files to include in this definition as described in Step 4 on page 149 through Step 5 on page 150. When you are done, the application right is available to use.

Examples of Application Right Definitions

This section contains these examples of how to use the Definition Settings dialog to specify an application right definition:

• Example 1: Manually specify one application path and file name—Describes how to define an application right to run the Access Manager console by manually entering the path name and application name.
• Example 2: Manually specify one application residing in two locations—Describes how to define an application right to run SQL Server Management Studio on Windows 2008 and Windows 2012 systems by manually entering the application name and the path names to the application on both systems.
• Example 3: Specify one application by importing its location—Describes how to define an application right to run the Access Manager console by <!---TODO update filename---> navigating to the centrifydc.msc file and importing its information.
• Example 4: Specify several applications by importing and specifying search criteria—Describes how to define an application right to run SQL Server Management Studio on several versions of the Windows operating system by navigating to the Ssms.exe file on Windows 2008, importing its information, and constructing application search criteria based on that information.

Example 1: Manually specify one application path and file name

In this example, it is assumed that you want to create an application right to run the Access Manager console application, and you know the path and file name of the application executable file.

1. Open the Definition Settings dialog and fill it in as follows:

   Description—Type a name of your choice (for example, Default Access Manager Console Application).

   Path—Select this check box.

   Name—Type the application name; in this case <!---TODO update filename---> centrifydc.msc.

   Arguments—Select this check box and specify which arguments can be executed through this application right.

   Specific path—Select this option and type the full path name to the <!---TODO update filename---> centrifydc.msc executable file: <!---TODO update path--->

   C:\Program Files\Centrify\Access Manager

2. Click OK to save the application right definition setting.

Example 2: Manually specify one application residing in two locations

In this example, it is assumed that you want to create an application right to run SQL Server Management Studio on Windows 2008 and Windows 2012 systems. The SQL Server Management Studio executable file resides in different locations in those operating systems, and you know the paths those locations.

1. Open the Definition Settings dialog and fill it in as follows:

   Description—Type a name of your choice (for example, SQL Server Management Studio 2008/2012).

   Path—Select this check box.

   Name—Type the application name; in this case Ssms.exe.

   Arguments—Optionally select this check box and specify which arguments can be executed through this application right.

   Specific path—Select this option and type the full path names to the Ssms.exe executable file in Windows 2008 and Windows 2012. Separate the path names with a semicolon(;)

   C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\ManagementStudio

2. Click OK to save the application right definition setting.

Example 3: Specify one application by importing its location

This example is similar to Example 1; it is assumed that you want to create an application right to run the Access Manager console application. Unlike in Example 1, you are not sure of the path name to the application executable file and you will navigate to it rather than type it in the form.

1. Open the Definition Settings dialog.
2. Click Import File.
3. Navigate to the <!---TODO update filename---> centrifydc.msc executable file, highlight it, and click Open.
4. Verify that the Definition Settings dialog fills in with application information.
5. In the Description field, type a name of your choice (for example, Default Access Manager Console Application).
6. Click OK to save the application right definition setting.

Example 4: Specify several applications by importing and specifying search criteria

This example is similar to Example 2; it is assumed that you want to create an application right to run SQL Server Management Studio on more than one version of the Windows operating system, starting with Windows 2008. Unlike in Example 2, you do not want to constrain the latest version of Windows to Windows 2012. Instead, you want to account for future versions of Windows and provide the capability to run SQL Server Management Studio on future Windows releases.

1. Open the Definition Settings dialog on a Windows 2008 system.

2. Click Import File.

3. Navigate to the Ssms.exe executable file, highlight it, and click Open.

   The Definition Settings dialog fills in with information from the Windows 2008 version of Ssms.exe.

4. Deselect the Path option so that the definition is not constrained just to that location.

5. Select the File Description option and keep the default operator and string.

6. Select the Product Version option and change the operator from equal to later or equal.

   The definition is now configured to include all .exe files having a file description tag of SSMS - SQL Server Management Studio and a product version later than or equal to the version that is installed on this Windows 2008 system.

7. In the Description field, either keep the string that was imported with the Ssms.exe file or type a description of your choice.

8. Click OK to save the application right definition setting.

Defining Network Access Rights

Network access rights allow users to access services on remote computers using another user account on the remote computer. Users who are assigned to a role with network access rights are only granted the elevated privileges when accessing the remote computer.

To define a network access right:

1. Open the Access Manager console.
2. Expand Zones and the parent zone or child zones until you see the zone where you want to define an application right.
3. Expand Authorization > Windows Right Definitions.
4. Select Network Access, right-click, then click New Network Access.
5. On the General tab, type a name and a description for the network access right.

   For this	Do this
   Name	Type the name you want to use for this network access right. For example, if the right allows a user to connect remotely to a Microsoft SQL Server instance using the privileges associated with a database system administrator account, you might include the SQL login name. For example, you might use a name like sysadmin.
   Description	Type a description for this network access right. The description is optional. You can use it to provide a more detailed explanation of the privileges associated with this right.
   Priority	Set the priority for this application right. If more than one network access right is included in the roles selected, the priority value determines which network access right to use. The lower the value, the higher the priority. For example, a right with the priority of 1 takes precedence over a priority value of 2. If users have multiple roles selected, the priority value of the network access right determines which network access right takes precedence over the access rights in other roles. For more information about selecting multiple roles for connecting to remote servers, see Scenario: Using multiple roles for network resources.

6. Click the Access tab to select the account that has the privileges you want to enable for accessing the remote computer.

   You can browse for and select a specific user account, create a new account, or access the remote computer using the logged-in user’s account credentials but with the elevated privileges of a specified group account. Click Add AD Groups or Add Built-in Groups to search for and select a previously-defined or Built-in group with the privileges you want to add to the logged in user’s account.

   In most cases, you select a specific user account only if accessing the remote computer using a service account.

   Select Re-authenticate current user if you want to prevent the network access right and its privileges from being used by anyone not authorized to do so. Selecting this option also allows you to enable multi-factor authentication for the right. For more information see Enabling multi-factor authentication for Windows rights.

   If you select this option, users are prompted to re-enter their password to verify their identity before they are allowed to select a role for accessing applications on a remote computer. Forcing users to reauthenticate ensures the privileges associated with the network access right are only granted to users who have been assigned those privileges.

   If you select this option for users who are authenticated using a smart card, users must enter a personal identification number (PIN) or a password to resume working with the remote server.

7. Click OK to save the network access right.

Using Network Access Rights When There are Two-way Selective Cross-forest Trusts

If you have domains in different forests that have a selective two-way trust relationship, any computer or user accounts that are used to log on to the remote forest must be granted the “Allowed to authenticate” right on the domain controllers in both forests to get role information. After you grant the computer used to access the remote server the “Allowed to authenticate” right for the domains in both forests, you can select roles that grant network access rights from either forest.

If an account is not allowed to authenticate on the remote domain controller, you cannot view or select roles that would otherwise allow you to perform tasks on the remote server.

Defining Custom Roles with Specific Rights

Rights can be combined or used independently of each other to create role definitions. Role definitions describe job functions that require a specific set of rights, including the specific days and times the role should be available for performing the operations allowed. If you have created desktop, application, or network access rights, you must create at least one role definition to use these rights.

To create a new role definition for a job function, you need to do the following:

• Create a new role and specify when the role is available.
• Specify how users in the role are allowed to log on.
• Add specialized Windows access rights to the role, as applicable.
• Specify whether the role requires multi-factor authentication before it can be selected.

In most cases, creating a separate role definition for each access right gives you the most granular control over what users assigned to a role can do. For example, if you create separate role definitions for desktop, application, and network access rights, you can choose which apply to specific users and groups through role assignments.

Creating a Role Definition with Desktop Rights

Before you can make the desktop rights you have defined available to users or groups, you must create one or more role definitions that include those rights. Desktop rights are especially useful to include in roles for users who frequently perform tasks that require the privileges associated with the Administrator group.

To create a new role definition with desktop rights:

1. Open the Access Manager console.

2. Expand Zones and the parent zone or child zones until you see the zone where you want to define a new role that includes a desktop right.

3. Expand the Authorization node.

4. Select Role Definitions, right-click, then click Add Role.

5. Type a role name and optional description for the role.

   The description can include details about time restrictions for the role and whether the role is audited or not.

6. Select Allow local accounts to be assigned to this role if you want to be able to assign local users or groups to the role you are creating.

   If you do not select this option, only Active Directory domain users can be assigned to the role.

7. Click Available Times and use the grid to specify when to allow or deny access for this role definition if you want to restrict when this role is available.

8. Click the System Rights tab and select Console login is allowed to allow users in the role to log on locally.

   To use the desktop right, the user must be able to log on locally on the computer. If you want to allow users to log on using a remote desktop connection, you can also select Remote login is allowed.

   Remote computers must be configured to allow remote desktop connections for the “Remote login is allowed” right to be valid. You can configure a computer to allow remote desktop connections by right-clicking Computer and selecting Properties or from the System Control Panel, then clicking Remote settings.

   Users must be assigned to at least one role with either console login or remote login rights to access any computers where the Agent for Windows is installed. You can grant access using the Windows Login role definition or the system rights in any custom role definition.

   The Windows right PowerShell remote access is allowed allows you to log on remotely to PowerShell.

   If you want to allow users to log on even when the Windows agent isn’t running or when audit and monitoring service is required but not available, you can select the rescue right. Because this right allows users to log on without having their activity audited, you should only assign roles with this right to trusted administrators or under controlled conditions. For example, assume you have a computer with sensitive information that normally requires all user activity to be audited. If that computer has application or operating system issues that require you to disable auditing temporarily, you can use a role with the rescue right to log on to that computer to diagnosis and fix the issue.

9. In the Authentication tab, you can add multi-factor authentication. If you want to require multi-factor authentication for users to access the role, select Require multi-factor authentication for login. You can also require multi-factor authentication for access to individual rights when you define the rights to add to roles. For more information see Enabling multi-factor authentication for Windows rights.

10. Click the Audit tab and select an option.

    If you select Audit not requested/required, users can log on to audited computers without having their session activity recorded. An audit trail event is recorded in the Windows event log when users open a desktop with this role, but the detailed record of what took place during the session is not captured.

    If you select Audit if possible, session activity is recorded when users open a desktop with elevated privileges on audited computers and not recorded when they log on to computers where audit and monitoring service is not enabled or audited computers when auditing is not currently running.

    If you select Audit required, users can only open a desktop with elevated privileges when auditing is running. If audit and monitoring service is not available or not currently running, the role is not available and users cannot use the elevated privileges.

11. Click OK to save the role definition.

12. Select the role definition, right-click, then click Add Right to add a desktop right to the role definition.

13. Select the desktop right from the list of rights from the current zone and from any parent zones, then click OK to add the right to the role definition.

Creating a Role Definition with Application Rights

Before you can make the application rights you have defined available to users or groups, you must create one or more role definitions that include those rights. Application rights are especially useful to include in roles for users who infrequently require access to specific applications with the privileges associated with the Administrator account or a service account on a local computer.

To create a new role definition with application rights:

1. Open the Access Manager console.

2. Expand Zones and the parent zone or child zones until you see the zone where you want to define a new role that includes an application right.

3. Expand the Authorization node.

4. Select Role Definitions, right-click, then click Add Role.

5. Type a role name and optional description for the role.

   The description can include details about time restrictions for the role and whether the role is audited or not.

6. Click Available Times and use the grid to specify when to allow or deny access for this role definition if you want to restrict when this role is available.

7. Click the System Rights tab and select Console login is allowed to allow users in the role to log on locally.

   To use the Run as selected role utility and an application right, the user must be able to log on locally on the computer where the application runs. If you want to allow users to log on using a remote desktop connection, you can also select Remote login is allowed.

   Users must be assigned to at least one role with either console login or remote login rights to access any computers where the Agent for Windows is installed. You can grant access using the Windows Login role definition or the system rights in any custom role definition.

   If you want to require multi-factor authentication for users to access the role, select Require multi-factor authentication. You can also require multi-factor authentication for access to individual rights when you define the rights to add to roles. For more information see Enabling multi-factor authentication for Windows rights.

8. Click the Audit tab and select an audit and monitoring service option.

   • If you select Audit not requested/required, users can log on to audited computers without having their session activity recorded. An audit trail event is recorded in the Windows event log when users select this role to run the application, but the detailed record of what took place during the session is not captured.
   • If you select Audit if possible, session activity is recorded when users select this role to run the application and not recorded when they use the application on computers where audit and monitoring service is not enabled or audited computers when audit and monitoring service is not currently running.
   • If you select Audit required, users can only select this role to run the application when audit and monitoring service is running. If audit and monitoring service is not available or not currently running, the role is not available and users cannot use their elevated privileges.

9. Click OK to save the role definition.

10. Select the role definition, right-click, then click Add Right to add the application right to the role definition.

11. Select the application right from the list of rights from the current zone and from any parent zones, then click OK to add the right to the role definition.

Creating a Role Definition for Network Access Rights

Before you can make the network access rights you have defined available to users or groups, you must create one or more role definitions that include those rights. Network access rights are especially useful to include in roles for users who require remote access to network services with the privileges associated with the domain Administrator account or a service account on the remote computer.

1. Open the Access Manager console.

2. Expand Zones and the parent zone or child zones until you see the zone where you want to define a new role that includes a network access right.

3. Expand the Authorization node.

4. Select Role Definitions, right-click, then click Add Role.

5. Type a role name and optional description for the role.

   The description can include details about time restrictions for the role and whether the role is audited or not.

6. Click Available Times and use the grid to specify when to allow or deny access for this role definition if you want to restrict when this role is available.

7. Click the System Rights tab and select Remote login is allowed to allow users in the role to connect to services on the remote computer.

   The user must be able to connect to the computer remotely to perform administrative tasks on that computer. If you want to allow users to log on locally, you can also select Console login is allowed.

   Users must be assigned to at least one role with either console login or remote login rights to access any computers where the Agent for Windows is installed. You can grant access using the Windows Login role definition or the system rights in any custom role definition.

   If you want to require multi-factor authentication for users to access the role, select Require multi-factor authentication. You can also require multi-factor authentication for access to individual rights when you define the rights to add to roles. For more information see Enabling multi-factor authentication for Windows rights.

8. Click the Audit tab and select an auditing option.

   If you select Audit not requested/required, users can connect to remote audited computers without having their session activity recorded. An audit trail event is recorded in the Windows event log when users select this role to connect to remote servers, but the detailed record of what took place during the session is not captured.

   If you select Audit if possible, session activity recorded when users log on to audited computers and not recorded when they log on to computers where audit and monitoring service is not enabled or audited computers when audit and monitoring service is not currently running.

   If you select Audit required, users can only log on to audited computers when audit and monitoring service is running. If audit and monitoring service is not available or not currently running, the role is not available and users cannot use their elevated privileges.

9. Click OK to save the role definition.

10. Select the role definition, right-click, then click Add Right to add a network access right to the role definition.

11. Select the network access right from the list of rights from the current zone and from any parent zones, then click OK to add the right to the role definition.

Combining Rights in the Same Role Definition

The previous sections illustrate how to create custom role definitions specifically for desktop, application, or network access rights. You can also combine multiple rights in the same role definition. For example, you can create a role definition that allows a user to open a specific application on the local computer using a service account with elevated privileges. The same role definition can also include a network access right that enables the user to modify information on a remote server.

Assigning Users and Groups to a Role

You can assign a role to an Active Directory user or to an Active Directory group. You can assign a role that is defined in the current zone or in a parent zone. You can also specify optional start and end times for the role assignment.

To assign users and groups to a role in a zone:

1. Open the Access Manager console.

2. Expand Zones and the parent zone or child zones until you see the zone where you want to make role assignments.

3. Expand Authorization.

4. Select Role Assignments, right-click, then click Assign Role.

5. Select the role definition from the list of roles, then click OK.

   By default, the role is set to start immediately and never expire. You can set a Start time, End time, or both start and end times for the role assignment. For example, if the role applies to a contractor who will be hired for a specific amount of time and you want to automatically disable the role after they finish the job and leave the organization, you can specify the start and end times when you assign the role.

6. Select whether the role assignment applies to all Active Directory accounts, all local accounts, or specific Active Directory and local accounts.

   To assign the role to specific accounts, click Add AD Account to search for and select the Active Directory groups or users to assign to the role, then click OK.

Rights and Role Assignments for Local Users

The rights you assign to users and group in a particular role apply to Active Directory users and groups. They can also apply to locally-defined users and groups if you configure the role definition to allow local accounts to be assigned to the role. All Windows users, including local users, must be assigned at least one role that allows them log on locally, remotely, or both.

Restricting Roles that Include Network Access Rights

Because role definitions can include a combination of rights and you can assign roles to local users, Active Directory users, or both, it is possible for you to assign roles that include network access rights to local accounts. Access Manager does not prevent you from configuring role definitions or role assignments in this way. However, users who log on with a local account will not be allowed to select the Advanced View or those network access rights for the remote computer. Therefore, you should avoid configuring role definitions that include network access rights and allow local accounts. Instead, you should keep role definitions that include network access rights separate from role definitions that allow local accounts to be assigned.

Making Rights and Roles Available in Other Zones

The access rights and role definitions that you create are specific to the zone where you configure them, and to any child zones of that zone. Once configured, though, you can copy and paste or drag and drop the definitions from one zone to another. After you import the information into a new zone, you can modify any of the details you have previously defined. For example, you can choose to export all the rights you have defined in one zone but create a completely new set of role definitions for those rights in the import zone.

Rights, roles, and role assignments are all inherited from parent to child zones, so generally there is no need to import or export roles within a zone hierarchy, but you may want to do so across zones. For example, if you have set up separate parent zones for different lines of business or different functional groups in your organization, you might want to import rights and roles from one business unit or functional group to another.

Exporting a Zone’s Rights and Role Definitions

You can export right and role definitions to an xml file that you can then use to import these definitions into another zone.

To export rights and role definitions:

1. Open the Access Manager console.
2. Expand Zones and the parent zone or child zones until you see the zone that has the rights and roles you want to export.
3. Expand Select the Authorization node, right-click, then click Export Roles and Rights.
4. Select the information you want to export, then click Next.
5. Click Browse to specify a location and file name for the export file, then click Next.
6. Review the information to be exported, then click Finish.

Importing Rights and Role Definitions into a New Zone

You can import rights and role definitions that you have previously saved from a different zone. You can also copy a paste or drag and drop rights and roles to a different zone.

To import rights, role definitions, and role assignments:

Before you begin, be certain you have saved rights and role definitions from a different zone and know the location of the xml file in which they are saved.

1. Open Access Manager.
2. Expand Zones and the parent zone or child zones until you see the zone into which you want to import rights and roles.
3. Select the Authorization node, right-click, then click Import Roles and Rights.
4. Click Browse to navigate to the file that contains the authorization information you want to import, then click Next.
5. Select the information you want to import, then click Next.
6. Review the information to be imported, then click Finish.

Copying Rights and Role Definitions into a New Zone

Exporting and importing information from one zone to another is the best solution if you want to include most or all information about rights and roles in a new zone. If you want to limit the information copied from one zone to another, you can copy and paste or drag and drop the information instead. With copy and paste, you can select specific right definitions, role definitions, or role assignments that you want to include in a new zone.

To copy role assignments from one zone to another, however, you should verify that the role definition associated with the role assignment exists in the new zone or is included in the information you are copying to the new zone.

To copy rights, role definitions, or role assignments:

1. Open the Access Manager.
2. Expand Zones and the parent zone or child zones until you see the zone that has the rights, role definitions, or role assignments you want to copy.
3. Expand the Authorization node.
4. Expand Window Right Definitions, Role Definitions, or Role Assignments until you see the specific right, role, or role assignment you want to copy.
5. Select the specific right, role definition, or role assignment to copy, right-click, then click Copy.
6. Open a different zone and expand Authorization > Windows Right Definitions, Role Definitions, or Role Assignments, right-click, then click Paste.

Alternatively, you can select a specific right, role definition, or role assignment and drag it to the appropriate node in a new zone.

Viewing Rights and Roles

You can view the status and effective rights for any user in a zone, whether they have been assigned a role or not. You can view detailed information about the rights and role assignments for users by selecting Show Effective Windows User Rights in the Access Manager console.

Displaying Rights for an Individual User in the Console

To view role assignments and Windows access rights for a user in the Access Manager console:

1. Open Access Manager.
2. Expand Zones and the parent zone or child zones until you see the zone that has the user of interest.
3. Right-click, then click Show Effective Windows User Rights.
4. Select a user to see information for the user in the selected zone or click Browse to select a specific computer in the zone if you only want to view user rights for a particular computer in the selected zone.
5. Click a tab to see the user’s role assignments, desktop rights, application rights, or network access rights.
   • Role Assignments lists the user’s role assignments, including where the assignment was made. For example, the Object Assigned column indicates whether the assignment for a user is explicit (user@domain), from a group (group@domain), or inherited from another setting (All AD Accounts). The Start Time and End Time are only displayed for roles that have time constraints.
   • Windows Desktops lists the user’s desktop rights granted by the roles to which the user is assigned. The tab identifies the account that can be used to open a new desktop or run an application, the zone where the desktop right is defined, and the role definition that includes the right.
   • Windows Applications lists the user’s application rights granted by the roles to which the user is assigned. The tab identifies the specific application and the account that can be used to run the application, the zone where the application right is defined, and the role definition that includes the right.
   • Network Access lists the user’s network access rights granted by the roles to which the user is assigned. The tab identifies the account that can be used to connect to services on a remote computer, the zone where the network access right is defined, and the role definition that includes the right.
6. Click Close when you are finished reviewing user rights in a zone or on particular computers.

Scenario: Using a Network Access Role to Edit Group Policies

The steps in this section illustrate a specific scenario of how to configure and use a desktop right and a network access right that allows the user Josh.Adams to log on with his normal Active Directory credentials, open an application that enables him to edit group policies, then connect to a domain controller with administrative privileges so that he can edit a Group Policy Object.

1. Install the Agent for Windows on the domain controller.

2. Install the Agent for Windows on a Windows computer that hosts the Group Policy Management console that the Josh.Adams uses to access the domain controller remotely.

3. Assign Josh.Adams the predefined Windows Login role and the custom role definition gpedit that includes a desktop right and a network access right.

4. Josh Adams logs on to his Windows computer using his Active Directory user name and password.

   To use a role with network access rights, you cannot log on using a local user account. You must use a domain user account authenticated using Active Directory.

5. On his local computer, Josh right-clicks the IBM Security icon in the system tray section of the task bar, then selects New Desktop.

6. In his list of available roles, Josh selects his gpedit role, then clicks OK.

7. Josh opens the Group Policy Management console on his local computer, connects to the domain controller in the console, then selects the default domain policy Group Policy Object.

8. Josh right-clicks the default domain policy, then selects Edit to modify the group policy.

9. When he is done working with the group policies, he switches back to his default desktop.

Scenario: Using Multiple Roles for Network Resources

For the local computer, users can select only one role at a time for their desktop or running an application. However, users can select more than one role to access network resources. By selecting multiple roles on the client, users can run applications that connect to multiple remote servers to perform administrative tasks.

In this scenario, Maya.Santiago uses a privileged account to open SQL Server Management Studio on her local computer. From this application, she wants to add accounts that require domain administrator privileges on a remote domain controller and modify database settings on a remote SQL Server instance. To do her work, she needs elevated privileges to run SQL Server Management Studio on her local computer and network access rights to contact the domain controller and the database server.

As the administrator, you have prepared the environment:

• You have put computers in appropriate zones and configured appropriate rights.
• You have configured a role definition, SideBet-DC-Admin, that grants network access to the domain controller using elevated privileges.
• You have also configured a role definition, SQL-DB-Default, that grants network access to SQL Server instances using elevated privileges.
• You have assigned Maya.Santiago to the roles.

To use an application that connects to multiple remote servers:

1. Install the Agent for Windows on the domain controller, the computer that hosts the SQL Server instance, and the computer Maya.Santiago uses to manage the SQL Server instance.

2. Assign Maya.Santiago the custom roles definition SideBet-DC-Admin that includes a desktop right and a network access right.

3. Maya.Santiago logs on to her Windows computer using her Active Directory user name and password.

4. On her local computer, Maya right-clicks SQL Server Management Studio, selects Run with Privilege.

5. Maya clicks Advanced View to see the list of available roles and selects SideBetDCAdmin as the local role that enables her to run local applications with administrator privileges.

6. Maya then clicks the Select one or more network roles option and selects the SideBetDC-Admin role for remote access to the domain controller and the SQLDBDefault role for remote access to the database server, then clicks OK.

   After she clicks OK, SQL Server Management Studio starts and she connects to the remote SQL Server instance using Windows authentication. The change to a role with privileges is recorded in the local Windows Application event log.

7. Maya uses SQL Server Management Studio to add and modify information on the domain controller and the SQL Server database.

8. When she is done working, she closes the application and returns to her default desktop and her login account privileges.

Defining Rights for Windows Applications that Encrypt Passwords

Microsoft provides a data protection application-programming interface (DPAPI) to enable applications to secure sensitive information, such as passwords, using encryption. The Data Protection API is the most common way to secure personal information on Windows computers because the information that is encrypted for one user cannot be decrypted by another user. Many applications and system services, including Microsoft Encrypting File System (EFS), Microsoft Internet Explorer, and Google Chrome for example, use the Data Protection API to encrypt passwords.

To use a desktop or application right with an application that uses the Data Protection API, you should select the Self with added group privileges option for the Run-as account. If you select this option when defining a right, you can install the Agent for Windows on the computer where the application using the Data Protection API is installed to allow users to run the application with administrative privileges.

If you want to use a specific user account for an application that uses the Data Protection API, you must install the Agent for Windows on both the domain controller and the computer where the application using DPAPI is installed. You must also make sure the domain controller is in a zone where users who are going to use the application are granted network access rights. In this scenario, the domain controller must be able to confirm the identity of the specific user account to allow protected information to be decrypted.

For example, assume you define an application right for running Access Manager using the Windows AM-Owner account and assign the user Steve to a role that has this application right. When Steve logs on to the computer where Access Manager is installed and opens the application using the role he is assigned, the Agent for Windows on the domain controller identifies him as the user AM-Owner and provides Jess with the master key for encryption and decryption, enabling him to use Access Manager to add computers, deploy agents, and perform other tasks.

Enabling Access Across Multi-tiered Application Layers

The traditional client/server scenario involves using a Windows client computer to connect to a Windows server to perform some operation. However, it is increasingly common that privileged access must cross multiple application layers. For example, you might have users who log on with their normal credentials who perform administrative tasks on a remote Sharepoint server and those tasks further require access to a SQL Server instance on yet another computer.

One way to ensure access across multiple applications tiers is to have all of the remote computers involved be in the same zone. At a minimum, the client computer and the computer in the first tier must have the Agent for Windows installed. If the client computer and the computer in the first tier are in different zones, which is the most common scenario, you should place computers in any additional tiers in the same zone as the computer in the first tier.

Requiring Users to Justify Privilege Elevation

You can assign some group policies that force your users to provide a reason when they choose to run an application with privilege. There are two group policies that you can use:

You can use just one of these policies or both. With either of these policies, when a user goes to run an application with privilege, they're prompted with an additional dialog box where they can enter a ticket number, a reason category, and any comments.

The above dialog box prompts users to enter the following information:

• Ticket number: If you have enabled the privilege elevation validator policy and subsequent script, you can validate the ticket number that a user enters against a ticketing system such as ServiceNow. If you haven't enabled the privilege elevation validator policy, users can enter any text string here.
• Reason: The user selects the reason category that best fits their situation. Their choices are:
  • Software Installation
  • Remote System Administration
  • Local System Administration
  • Windows Feature Management
  • System Networking Change
  • Maintenance (Shutdown, Reboot, Power Off)
  • PowerShell or Other CLI
  • Operation (Services, Zone Operations, etc.)
  • Other
• Comment: The user enters any comments about their need to run with privilege. You can view these comments in the audit trail event.

For more details about these policies, see the Group Policy Guide and the group policies' explain text.

Working with Computer Roles

A computer role associates a group of computers in a zone with a set of role assignments to users or groups. For example, you might have a set of computers dedicated to a specific function, such as hosting Oracle databases or payroll processing application. Users who are database administrators for those computers require different privileges than users who update payroll records on those computers.

Using a computer role, you can associate the group of computers that host an Oracle database with a specific role assignment, for example, users who are assigned the oracle dba role. The oracle-dba role definition might include desktop and network access rights because the users assigned to the oracle-dba role require administrative privileges.

You could also create a second computer role that associates the group of computers that host the payroll processing application with a group of users who are allowed to log on and update payroll records without granting any other administrative privileges. For example, if some of the computers that host an Oracle database are used for payroll processing, you can define another computer role—payroll-west—that associates just those computers with the role assignment payroll_mgmt. The payroll_mgmt role definition might have the console login right and an application right specifically for the payroll application. When users are assigned the payroll_mgmt role, they can log on locally and run the payroll application with elevated privileges only on the group of computers defined in the computer role payroll-west.

To use computer roles, you must do the following:

• Decide on the attribute the computers in a particular group share. For example, you can use a computer role to identify computers in the web farm, that host specific applications, or serve a specific department.
• Identify the sets of users that share common access rights and create Active Directory groups for them. For example, if you are creating a computer role for Oracle database servers, you might have different access rights for application users, database administrators, and backup operators.
• Identify the role definitions each set of users should be assigned. For example, application users role might use the default Windows Login role, while administrators might require a custom role definition with desktop and network access rights, and backup operators might require a custom role definition with an application right.

Using Computer Roles to Simplify the Management of Access Rights

Deciding how best to use computer roles requires some planning and configuration that may not be part of your initial deployment plan. To make effective use of computer roles, you also prepare appropriate role definitions for different sets of users. However, computer roles provide a powerful and flexible option for managing access to computers using your existing processes and procedures for managing Active Directory group membership.

After you create a computer role, it is easy to manage even as your organization changes and grows. For example, if another Oracle database server comes online, you add it to the computer group you created for Oracle database servers in Active Directory. If other DBAs join your organization, you add them to the Active Directory group you created for Oracle administrators. The computer role links the computer group to the role assignment and no additional updates are needed to accommodate these kinds of organizational changes. If you need to modify the access rights, you can change the role definition and have the changes apply to all members of the group.

Create an Active Directory Group for a Set of Computers

Computer roles create links between objects in Active Directory and access rights defined in Access Manager. After you have identified a group of computers that share a common attribute, you should create an Active Directory group for those computers if one does not already exist.

You can also create the computer group and add its members directly from Access Manager when you create the computer role. If you are not preparing the Active Directory group before creating the computer role, you can skip this section and go directly to Create a new computer role.

To create an Active Directory group for computers in a computer role:

1. Open Active Directory Users and Computers to create a new Active Directory group.
2. For example, create a new Active Directory group for Oracle Database Servers.
3. Select the new computer group, right-click, then click Properties.
4. Click the Members tab, then click Add.
5. Click Object Types, select Computers, then click OK.
6. Search for and select the computers that you have identified as Oracle database servers as members of the new group, then click OK.
7. Click OK to save the group.

Create an Active Directory Group for Each Set of Access Rights

In addition to the Active Directory group for the computers in a computer role, you should have an Active Directory group for each set of users that should have different access rights. By mapping Active Directory groups to role definitions, you can manage group membership and access rights at the same time using your current procedures.

To create an Active Directory group for each set of users linked to a computer role:

1. Open Active Directory Users and Computers to create a new Active Directory group for each set of users to link to the computer role.

   For example, create separate Active Directory groups for application users, database administrators, and backup operators using a naming convention similar to ComputerAttribute_Role_UserSet. For example, create the following Active Directory groups:

   • OracleServers_Role_AppUsers
   • OracleServers_Role_DBAs
   • OracleServers_Role_Backup

2. Select each new group, right-click, then click Properties.

3. Click the Members tab, then click Add.

4. Search for and select the users that you have identified as members of the each group, then click OK.

5. Click OK to save the group membership.

Create a Role Definition for Each Set of Users with Different Access Rights

Before you create a new role definition, identify the specific rights associated with each role and define those rights if they do not already exist. For this sample scenario, you might create role definitions similar to the following:

• Oracle_AppUsers with Windows Login access and an application right for a specific database application.
• Oracle_DBAs with Windows Login access and desktop and network access rights on computers in a specific zone.
• Oracle_Backup with console login allowed right and an application right that allow members of the group to run backup utilities with the privileges of the built-in Backup Operators group.

Create a New Computer Role

After you have prepared the appropriate Active Directory groups and role definitions for different sets of users, you can create one or more computer roles.

To create a new computer role:

1. Open Access Manager.

2. Expand Zones and the parent zone or child zones until you see the zone that has the computer for which you want to define a computer role.

3. Expand the Authorization node.

4. Select Computer Roles, right-click and click Create Computer Role.

5. Type a name and description for the computer role.

   For example, type OracleServers, and an optional description, such as Oracle database servers in the San Francisco data center.

6. In Computers group list, select <...> to search for the Active Directory group of computers you created in Create an Active Directory group for a set of computers.

   Select <Create group > if you want to create a new Active Directory group of computers and add members now. If you are creating a new group, click Browse to select a container to use, type a group name, and select the scope of the group, then click OK.

7. Click OK to save the computer role.

8. If you selected an existing computer group, expand Computer Roles > Members to see the computers that are members of this computer role.

   If you created a new computer group at Step 6, select the new computer role, right-click Members, then select Add Computer to search for and select one or more computers to add to the group.

Add Role Assignments to the Computer Role

If you have created the appropriate Active Directory groups and role definitions that you want to assign, you can now assign the roles to set of users as required.

To add role assignments to users in Active Directory groups:

1. Expand the computer role you just created, for example, expand OracleServers.

2. Select Role Assignments, right-click, then click Assign Role.

3. Select the role definition from the list of roles, then click OK.

   For example, select the Oracle_DBAs role definition. By default, the role is set to start immediately and never expire. You can set a Start time, End time, or both start and end times for the role assignment. For example, if the role applies to a contractor who will be hired for a specific amount of time and you want to automatically disable the role after they finish the job and leave the organization, you can specify the start and end times when you assign the role.

4. Select whether the role assignment applies to all Active Directory accounts, all local accounts, or specific Active Directory and local accounts, then click OK to complete the role assignment.

   For example, to assign the Oracle_DBAs role to the Active Directory OracleServers_Role_DBAs security group, click Add AD Account. You can then select Group to search for the group, select it from the results, then click OK.

5. Repeat Step 1 through Step 4 for each group that you want to add to this computer role. For example, repeat the steps to assign the Oracle_AppUsers role to the OracleServers_Role_AppUsers security group and the Oracle_Backup role to the OracleServers_Role_Backup security group.

6. Select the Role Assignments node to see all of the role assignments you have defined for groups associated with the computer role.

7. Select the Members node to see the computers or groups of computers to which the role assignments apply.

Assigning Roles on Multiple Computers at Once

To simplify the process of assigning Active Directory users or groups to a role, you can perform a bulk role assignment. With a bulk role assignment, you can assign a role to multiple Active Directory users and groups on multiple computers at the same time. For example, if you have two groups of SQL Server administrators and three computers where the members of those groups need access to their SQLServerAdmin role, you can select those two groups and those three computers to be assigned the SQLServerAdmin role in the same process. You can also specify optional start and end times for the role assignment and have those settings apply for all of the users, groups, and computers you have selected for bulk assignment.

To assign users and groups to a role in a zone:

1. Open the Access Manager console.

2. Expand Zones and the parent zone or child zones until you see the zone where you want to make role assignments.

3. Right-click, then select Assign Roles to Computers.

4. Type the user and group names you want to be included in the role assignment, then click OK.

   You can specify multiple names separated by a semi-colon (;). You can also search for user and group names by typing part of the name and clicking Check Names or by clicking Advanced and entering search criteria.

5. Type the computer names you want to be included in the role assignment, then click OK.

   You can specify multiple names separated by a semi-colon (;). You can also search for the computer names by typing part of the name and clicking Check Names or by clicking Advanced and entering search criteria.

6. Select a role for the list of roles available, then click OK.

7. Review the role assignment start and end time and the user and group accounts that are being assigned the role, then click OK.

   You can make changes to the start and end times if you want those changes applied for all of the users, groups, and computers that are part of this bulk role assignment.

After you click OK, the selected users and groups are then automatically assigned the selected role on the selected computers.

Using the Authorization Center Directly on Managed Computers

The Authorization Center is available on managed computers where you have deployed the Agent for Windows and enabled the privilege elevation service. From the Authorization Center, you can view details about the rights, role definitions, role assignments, and auditing status for any users. Individual users can see details about their own login rights, effective roles, role assignments, role definitions, and auditing status. Administrators can select any user of interest to view the details for that user.

To use the Authorization Center on a local computer:

1. Log on to a computer where the Agent for Windows and privilege elevation features are deployed.

2. Click the arrow next to the notifications area in the taskbar.

3. Right-click the IBM Security icon, then select Open Authorization Center.

4. Click a tab to see details about the current user’s roles.

   • Effective Login Rights displays the current user’s local, remote, and PowerShell login rights and whether auditing is requested, required, or not applicable.
   • Effective Roles lists the roles that have been assigned to the current user and the status of each role names to which the user is assigned. You can right-click a role, then select Role Properties to view additional details, such as any time constraints defined for the role and the specific rights granted by the role.
   • Role Assignments lists details about the user’s role assignments, including where the assignment was made. For example, the Object Assigned column indicates whether the assignment for a user is explicit, from a group, or inherited from another setting, for example, from the selection of All Active Directory Accounts. You can right-click a role, then select Assignment Properties or Role Properties to view additional details, such as any time constraints defined for the role and the specific rights granted by the role.
   • Role Definitions lists detailed information about the selected user’s login rights and the audit requirements that have been defined for the roles the user has been assigned. You can right-click a role definition, then select Properties to view additional details.
   • Auditing lists the desktops used and auditing status for each desktop started in a session.

5. Click Browse to view information for another user.

6. Type all or part of the user name, then click OK.

   If more than one user name is found, select the appropriate user from the results, then click OK.

7. Click Close when you are finished viewing detailed authorization information for the selected user.

Working with the Authorization Cache on Managed Computers

Authorization information—such as your rights, role definitions, and assignments—is cached locally on each computer where you have deployed the Agent for Windows. The cache saves access privilege information to improve performance and also to persist elevated privilege capabilities for users and groups when the computer is not connected to Active Directory.

The following sections describe:

• Which Verify Privilege Server Suite capabilities are and are not persisted by the cache when a computer is disconnected from a domain controller.
• Where the cache resides.
• How and when to perform cache operations such as refreshing, flushing, and dumping.

Persisted and Non-persisted Capabilities

The Verify Privilege Server Suite cache persists several role-based capabilities when a computer is not connected to Active Directory. A computer is considered to be not connected when the Windows agent is unable to reach one or more of the following entities:

• The domain to which the computer is joined.
• The domain of any zone in the zone hierarchy. The zone hierarchy is the domain of the zone that the machine is joined to, or any parent zones of that joined zone.
• An Active Directory global catalog (GC) associated with any of these domains.

If the Windows agent can reach all of these entities, it is considered to be connected.

Persisted Capabilities

These capabilities are supported when a computer is not connected:

• Users can log in based on role.
• Users can run applications based on role.
• Users can create desktops based on role.
• Computers can be removed from zones.
• IBM Security software can be installed (but the computer cannot be joined to a zone).
• IBM Security software can be upgraded, but this practice is not recommended because there will be no authorization data in the cache after the upgrade.

Non-persisted capabilities

These limitations exist when a computer is not connected:

• You cannot join a zone or change a computer’s zone.
• The use of Network rights is not supported.

Cache Location

The cache resides in SYSTEMDRIVE\ProgramData\Centrify\DirectAuthorize\Cache.

Performing Cache Operations

You must have administrator privileges to perform the cache operations described here. Available cache operations include:

• Refreshing the cache (perform this operation from the user interface or the command line)
• Flushing the cache (performed from the command line)
• Dumping the cache (performed from the command line)

Refreshing the Cache

As administrator, you can refresh the cache from the user interface or from the command line. Refreshing the cache updates the cache with fresh information from Active Directory, ensuring that the agent has the most up-to-date information about users’ current rights and roles.

Refreshing the cache is useful if you change authorization information with the management console, and you want to see the updated information on the Windows agent right away.

In domains containing multiple domain controllers, you might not see the updated information even after you refresh the cache. In cases such as this, wait for Active Directory replication (typically a few minutes), and then refresh the cache again. Alternatively, wait another 10 minutes and the agent will refresh the data on its own.

You can refresh and flush the cache only on computers that are connected to a domain controller.

To refresh the cache from the user interface:

1. Open the agent configuration panel by clicking Agent Configuration in the list of applications on the Windows Start menu.

2. Click Privilege Elevation Service.

3. Click Settings.

4. Click the Troubleshooting tab.

5. Click Refresh, then click OK to acknowledge the successful operation.

   Alternatively, you can execute the dzrefresh command line utility to refresh the cache as described in the next section.

To refresh the cache from the command line:

Execute the dzrefresh command line utility to refresh the cache. Executing dzrefresh performs the same operation as clicking the Refresh button in the agent configuration panel Troubleshooting tab.

The syntax for running the dzrefresh utility is:

dzrefresh

Flushing the Cache

Execute the dzflush command line utility to flush (clear) the cache. Flushing the cache removes all cache data and reloads it from Active Directory. You should flush the cache only when directed to do so by Support. Under most circumstances, you should refresh the cache rather than flush the cache.

The syntax for running the dzflush utility is:

dzflush

Dumping the Cache

Execute the dzdump command line utility to dump the cache to standard output or to a redirect file that you specify on the command line. You can also use the options shown here to display only specific types of cache data, such as zone hierarchy, role definitions, right definitions, and other data.

You should execute the dzdump utility only when directed to do so by Support.

The syntax for running the dzdump utility is:

dzdump [/d [directory-path]] [/w=screen-width] [/s] [/n] [/g] [/l] [/a] [/r] [/i] [/t] [/z] [/u] [/h]

If you execute dzdump with no options, all dzagent in-memory cache is dumped.

Setting valid options

You can use the following options with dzdump:

Use this option	To do this
/d	Dump cache files from the default location.
/d=directory-path	Dump cache files from the specified location.
/w=screen-width	Use the specified width rather than the default of 80 for word-wrap. Set /w=0 to disable word-wrap.
/s	Display SID mappings.
/n	Display name mappings.
/g	Display assignee mappings.
/l	Display assignments in the joined zone hierarchy.
/a	Display assignments for SIDs.
/r	Display role definitions.
/i	Display right definitions.
/t	Display access token information.
/z	Display zone hierarchy.
/u	Display recent user log-ins.
/h	Display help information.

Configuring PowerShell Remote Access

You can run PowerShell commands on remote computers and have the agent handle the authentication and privilege elevation for you. In order to run remote PowerShell commands, the following requirements apply:

• The target computer needs to have the Agent for Windows installed with the Privilege Elevation Service enabled.
• Assign the user to a role with the "PowerShell remote access is allowed" system right granted.

If you're using the Audit & Monitoring Service, when a user attempts to run PowerShell remotely on a computer, the system triggers an audit trail event. Audit & Monitoring Service is an optional service.

To assign PowerShell remote access to a user:

1. In the Access Manager console, open the zone that the Windows system to be managed belongs to (Access Manager is not necessary installed on the machine with the Windows agent).
2. Under Role Definitions, right-click a role that you'd like to assign PowerShell remote access permission to and select Properties.
3. Under System Rights > Windows rights, select PowerShell remote access is allowed.
4. Right-click Role >Assignment and select Assign Role.
5. Select the role as defined above and assign the Windows account to it.

What Gets Audited for Remote PowerShell Commands and Scripts

For cases where someone runs individual PowerShell cmdlets, the audit trail event captures the following details:

• Specific cmdlets that were run
• Arguments
• Return codes
• User who ran the cmdlets
• The timestamp when the user ran the cmdlets

For cases where someone runs a PowerShell script, the audit trail event captures the name of the script as well, and if the script was run remotely the audit trail event captures the contents of the script. If the script is very long, the audit trail will truncate it and add an ellipsis (...).

If the user runs a PowerShell script on the target system from that same system, the audit trail event does NOT capture the contents of the script. This is due to a limitation in Windows Remote Management. Basically, the thing to remember is that if you send over script text to a remote system, the audit trail captures the script text; if you send over just a script filename, that's what the audit trail captures.

Examples of Remote PowerShell Commands

For example, if a user runs individual PowerShell commands on a remote system, they would start the session with a command similar to the following:

Enter-PSSession -ComputerName targetcomputername

The audit trail event captures details about any commands that the user enters during the above PowerShell session.

As another example, if a user runs a script without first creating the remote session and runs the script against a remote, target system from another system, the user might run a command similar to the following:

Invoke-Command -ComputerName targetcomputername -FilePath {c:\script.ps1}

In this second example, you'll know that the user ran a script because there'll be a isscript=true parameter in the audit trail.

As a final example, if a user runs a script without first creating the remote session and runs the script from the target system, the user might run a command similar to the following:

Invoke-Command -ComputerName targetcomputername -Command{c:\script.ps1}

Hiding the Remote PowerShell Script Text

There may be situations where your users have scripts to run on remote systems but you don't want or need the script text to appear in the audit log. To hide the script text from the audit log, change the following registry to 1 (the default value is 0):

SOFTWARE\Policies\Centrify\DirectAuthorize\Agent\HideRemotePsScript (REG_DWORD)

You can set the HideRemotePsScript option by group policy.

Authentication Service Enforcement

Any time you open the Access Manager console, a background process determines the availability of licenses.

As you increase the number of licenses in use, license enforcement is progressive. If the number of computers is less than 90% of the number of licenses you have purchased, there’s no affect on any auditing features. If the number of computers is more than 90% of the licenses purchased, enforcement depends on the number of licenses in use:

• 90-100% of the licensing limit displays a warning message that you are close to over deployment, but you can continue to use all authentication and privilege elevation features.
• 100-120% of the licensing limit displays a warning message that you must acknowledge by clicking OK when you open the console, after which you can resume using the console.
• Over 120% of the licensing limit displays a warning message for 60 seconds when you open the console. If you see the 60 second warning message, use the License dialog box to add license keys to continue using features.

You can contact IBM Security to purchase additional licenses or remove some computers to bring the number of licenses used into compliance.

Configuring MFA with RADIUS for Privilege Elevation Service for Windows Checklist

This document provides a configuration checklist for 3rd party multi-factor authentication providers such as Duo, Okta, SecurID (or any other vendor that provides a RADIUS service) to provide identity validation with the Privilege Elevation Service in the Microsoft Windows platform.

If you have an identity service provider (such as Duo, Okta, SecureID, and so forth) that you use for MFA logins, you can integrate authentication and privilege elevation with your identity provider and the RADIUS protocol to require MFA for privilege elevation tasks, such as Run with Privilege and New Desktop.

Make sure that you work with your RADIUS expert along with your network and directory services lead administrators during the design and configuration tasks.

The checklist below includes links to documented procedures.

If you use Privileged Access Service, although you can enable MFA with RADIUS, the recommended practice is that you use the native integration.

Step#	RADIUS Configuration Step	Notes
	RADIUS requirements
1	Gather the following settings for your RADIUS service: IP address or fully qualified domain name Port Timeout settings Pre-shared secret
2	Verify that you can generate a RADIUS one-time password successfully.
3	Verify that identity authentication is working correctly with your RADIUS system.
4	Have access to someone who is knowledgeable about your RADIUS system and can answer questions or help troubleshoot issues, if needed.
	Windows and Active Directory requirements for RADIUS configuration
5	A Windows computer to use as a RADIUS client for initial testing, including: Client name Client IP address
6	Make sure that client systems can reach the RADIUS server over the network (check your firewall settings). You may need help also from your network team if your RADIUS cluster has a load-balancer in the front end.
7	You have administrative access to the designated Windows computer so that you can install software and do configurations.
8	You have Active Directory account access so that you can modify group policies that apply to the target computer.
9	You have access to the Group Policy Management Console.
10	Your Active Directory expert must decide how the group policy layout and scope will be designed so that the group policies are applied to the clients based on their RADIUS service availability.
	Authentication and Privilege Elevation Services Requirements for RADIUS configuration
11	Access Manager console is installed on the client computer.	For details, see Running the setup program on a Windows computer.
12	The Agent for Windows is installed on the client system, you've configured the system to work with Privilege Elevation Service, including joining the computer to a zone.	For details, see Installing the Agent for Windows.
13	You have administrative access to Access Manager so that you can manage roles and rights.
14	The group policy templates from release 19.6 or later are installed. For RADIUS configuration, you need at least the IBM Security Windows settings group policies.	For details, see Installing group policy extensions separately from Access Manager.
15	If you want to capture the RADIUS events in your SIEM system, make sure the Audit trail is configured to go to the local log file.	In GPME, go to computer Configuration > Policies > Audit Trail Settings > Global Settings > Send audit trail to log file (this is not configured by default). For details, see "Send audit trail to log file" in the Group Policy Guide.
16	You have a role and user to test with. Make sure the role has rights for privilege elevation, such as New Desktop rights or Run as Role.	Make sure that you can elevate privileges successfully for that user and role before you try to configure RADIUS authentication.
	Configure a system to use RADIUS for privilege elevation (using group policies)
17	Enable and configure the RADIUS group policies.	Configure the following group policies: Windows > MFA Settings > Specify the authentication source for privilege elevation : set this policy to RADIUS Authentication. Windows > MFA Settings > Remote Authentication Dial-In User Service (RADIUS) Settings > Enable Remote Authentication Dial-In User Service (RADIUS): enable this policy. Specify the RADIUS connection timeout: Configure to match your RADIUS timeout setting. Specify the RADIUS server IP address: enter your RADIUS IP address. Specify the RADIUS server port number: enter your RADIUS port number (the default is 1812). For details, see "Remote Authentication Dial-In User Service (RADIUS) Service Settings" in the Group Policy Guide. After you update the policies, do a group policy update on the Windows client computer.
18	Configure the role to require re-authentication using multi-factor authentication.	For example: Right-click your test role and choose Properties. The Role Properties dialog box opens. Click the Run As tab. Select Re-authenticate current user and then select Require multi-factor authentication. Click OK to apply the changes.
19	Run dzflush to make sure that the agent has the changes from Access Manager.	For details, see Using dzflush.
20	Set the RADIUS shared secret.	The RADIUS secret is unique to each system and will match the secret that the RADIUS server has. You can set the pre-shared secret by either of the following methods on the client computer: Run the Set-CdmRadiusSecret cmdlet to set the RADIUS shared client secret. For details, see the DirectAuthorize PowerShell cmdlet help. Use the Agent Configuration settings dialog box to configure the RADIUS server, including the pre-shared secret. For details, see Configuring agent settings for the Identity Platform.
	TEST AND VERIFY
21	Verify that a user can elevate privileges by entering the RADIUS one-time password.	For example, if your role has New Desktop rights: Right-click the System Tray and select New Desktop. In the dialog box that appears, select your test role and click OK. If the RADIUS authentication has been configured successfully, you are prompted to enter a password for RADIUS authentication. Enter the password and click Next to continue. You can also view the audit trails for the successful authentication in the system's event log.
22	Verify that a user cannot elevate privileges after entering an incorrect RADIUS one-time password.

Adding Remote Users Automatically

If desired, you can configure your deployment so that members of the Windows Login group or the Windows Remote Login group are also automatically added to the Remote Desktop Users group and the ConsoleLogonUser group.

To make this change, add the following registry entry on each computer where you have installed the Agent for Windows:

HKEY_LOCAL_MACHINE\SOFTWARE\Centrify\DirectAuthorize\Agent\EnableAddUsersToRdpAndConsoleLogOn = 1

If you later uninstall the agent, the uninstall process removes the affected user accounts from the Remote Desktop Users group and the ConsoleLogonUser group. Only the user accounts that the agent added to those groups are affected.

Enabling Users to Run Applications with Alternate Accounts

Alternate accounts are typically a privileged or administrator account in Active Directory that's associated with an owner account. You can log in to the alternate account using your main account.

For example, system administrators typically have several accounts, a user account for general log-ins and an administrative account to access specific systems and services.

Here are the things you need to do in order to enable the ability to run with alternate accounts:

1. Set up alternate accounts for users in Privileged Access Service
2. Install a cloud connector in your domain and the Web Server (IWA) service is enabled.
3. Enable the policy entitled "Enable run with alternate account."
4. (Optional but recommended) Configure the following policies to set up a grace period after which time users running applications with alternate accounts must re-authenticate:
   • "Require re-authentication to run application with alternate account"
   • "Configure Windows authentication grace period for run with alternate account"
5. Install the Agent for Windows and enable the Identity Platform service on each computer where you want users to be able to run with alternate accounts.

If you don't enable the run with alternate account feature, your users can still run applications with these alternate accounts by logging in to Privileged Access Service and checking out the password.