Access Control is the latest policy engine introduced in Privileged Account Manager, which enables administrators to configure privileged access permissions in a simpler, easier and meaningful manner. It also provides quick insights into Privilege Governance (Who has what access) details.
Access Control engine emphasizes on grouping the Resources based on similar access requirements of an organization and then granting the access to users by defining the criteria such as allowed time of access, privilege level, monitoring needs etc.
In an organization, consider there are several Resources such as, Windows Servers, UNIX Servers, and Network devices, and various Users with different access levels, who require access on these servers.
The first step of designing access permissions is to group all the Resources based on similar access requirements or attributes such as:
Operating system
Specific software installed in those Resources
Location of the Resources
Department to which these Resources belong
Users who need the access on those Resources, etc
The second step is to group the users based on their access requirements on the Resources or attributes such as:
Tasks assigned to users on the Resources
Privilege level allowed on the Resources
Location of the Users
Department of the users
The third step is to configure permissions to grant access on these Resource Groups to one or more User Groups, by defining the criteria such as:
Allowed time of access
Privilege level required on the Resources
Access restrictions on file system or executables
Activity monitoring
Remediation in case of risks found in users’ activities, etc
Access Control depends on four primary components to enable privileged access to users on various types of resources.
Resource Pools contain similar kind of resources with similar access requirements.
NOTE:A resource cannot be part of more than one Resource Pool.
Resource Pool types are categorized as below:
Agents
Windows Agents – Contains Windows Agents only
NOTE:Windows Agents are Windows systems where Privileged Account Manager - agent or manager is installed
UNIX Agents – Contains any Linux or UNIX Agents
Agent-less
SSH Servers – Resources configured in Credential Vault within Generic UNIX category
NOTE:SSH and Telnet servers can be any Linux, UNIX machines, Network devices, or Mainframe.
Telnet Servers – Resources configured in Credential Vault within Telnet category
Terminal SSH – Resources configured in Credential Vault within Terminal SSH category. To specify the starting directory for a SSH session invoked by Windows Terminal
Windows Systems – Resources configured in Credential Vault within Windows Hosts category
Database
Oracle
Microsoft SQL Server
My SQL
Sybase
PostgreSQL
MariaDB
IBM Db2
Applications
Applications
Application SSO
Keys
SSH Keys
Windows Keys
VMWare Keys
Custom Keys
User Roles contain users and groups, collectively called as members, from various sources who have similar access requirements. A User role can contain members from one or more sources. The supported sources are:
Local Users: Users created locally in Privileged Account Manager.
Agent Users: Users from any Agent registered to Privileged Account Manager.
LDAP Users and Groups: Users or Groups from LDAP Servers configured for Authentication. Administrators can configure Excluded Members from LDAP Users and Groups, if there is a Group already added in Included Members section of a role.
Database Users: Users created for authorizing access to database while co-ordination and monitoring it’s use. Administrators can configure Excluded Members from LDAP Users and Groups, if there is a Group already added in Included Members section of a role.
Assignment is a relationship between a single Resource Pool and a User Role, which enables to configure one or more permissions under it.
NOTE:An assignment created for a Resource Pool and a User Role is unique, hence the same assignment cannot be created again.
Under an assignment, one or more permissions define the access criteria such as Privilege Level, Allowed Access time, Monitoring options, File or Folder access control, Customization etc. Below is the list of permissions based on the Resource Types.
NOTE:Every time a new permission is added the user has to log out and log in for the new permission to take effect.
Default: Default Privileges selected for Resource in Resource Pool
Submit User: No Elevation of Privileges
Common Run User or Common Credential: A Common privilege for all the Resources authorized through this permission
Custom Run User or Custom Credential: Custom Credentials per Resource
All Days – 24 hours and 7 days access
Time Range – Selecting a specific start time and end time, recurring every week
Custom – A recurring time slot for each selected day
NOTE:If a Permission is defined for All Days which is 24 hours and 7 days, another permission of same type is not allowed under an assignment.
NOTE:The time specified is always treated as GMT.
Session Capture – Capture Key Strokes and Low level audits
X11 – Applicable for Terminal SSH only
Video Capture – Capture Videos
Video FPS – Frames Per Second to use while capturing Videos
Secondary Authentication – Move the slider to the left if you do not want this option to be enabled. By default, this option is set to enabled. To use this, ensure that Netiq Advanced Authentication is enabled. This setting ensures that the users are prompted for secondary authentication to log in to the Administration Console.
User Message – Display a message to the Users while accessing the session authorized by this permission. This is applicable for selected permissions only
Shell Options – Applicable for UNIX Agent permissions, to change the shell behavior
NOTE:Low Level Audits, also called as Command Audits are applicable only for Agents.
Administrators can enforce access restrictions on files, folders or executables in Agents, by defining the allowed operations such as read, write, delete and execute.
NOTE:Unless the user logs off and logs in again, the EAC Policy is not effective. Non-English characters are not supported with Enhanced Access Control on Windows.
Command Lists are useful to allow or deny access on specific commands or applications within privileged sessions.
On Agents, Privileged Applications or Privileged Commands permissions can be configured using Command Lists, to allow privileged access to specific applications or commands, rather than providing a complete privileged session.
On Agent-less scenarios, Command Lists are helpful to allow or deny specific commands within privileged sessions.
Administrators can add Perl scripts to permissions, to customize the behavior of the permission before authorizing the privileged access. For example, a script added in the permission can verify a user’s attribute such as location or department, before authorizing the access.
Figure 6-1 Overview of Privileged Access Permissions
Below is the list of permissions under Windows Agents Resource Pools.
Credential Provider
Users must use the Credential Provider provided by Privileged Account Manager Agent installation.
Users must use the Credential Provider provided by Privileged Account Manager Agent installation.
Direct RDP
Users can directly login into the Windows system using own accounts.
Privilege Elevation is not applicable.
Web Agent RDP
Users need to login into Privileged Account Manager's User Console.
Users' are authenticated by authentication sources configured in Privileged Account Manager.
Privileged Applications
Users can directly login into the Windows system using own accounts. Users need to request a specific application to run with privileges supplied by Privileged Account Manager, using the Run as privileged user option, that appears when you right click on any application.
The table highlights the differences of each permissions with respective options and user experience:
|
Permissions |
Authentication |
Secondary Authentication |
Privilege Elevation |
Mode of Access |
Mode of session |
Session Capture |
Video Capture |
Enhanced Access Control |
Application Command Lists |
|---|---|---|---|---|---|---|---|---|---|
|
Credential Provider |
Privileged Account Manager |
Yes |
Yes |
Thick Client |
RDP Session |
Yes |
Yes |
Yes |
NA |
|
Direct RDP |
Windows Authentication |
NA |
NA |
Thick Client |
RDP Session |
Yes |
Yes |
Yes |
NA |
|
Web Agent RDP |
Privileged Account Manager |
Yes |
Yes |
Web Browser |
RDP Session |
Yes |
Yes |
Yes |
NA |
|
Privileged Applications |
NA |
NA |
Yes |
Thick Client |
Requested Application |
Yes |
Yes |
NA |
Yes |
The List of permissions under Linux or UNIX Agents Resource Pools are:
Privileged Shell
Users can directly login into the Linux or UNIX systems using own accounts.
Users need to request for privileged shell using the command - usrun pcksh.
Login Shell
Users can directly login into the UNIX or Linux systems using own accounts.
Users' default shell should be set to /usr/bin/cpcksh.
Privileged Commands
Users can directly login into the UNIX or Linux systems using own accounts.
Users must request for privileged commands using the command - usrun.
The table highlights the differences of each permissions with respective options and user experience:
|
Permissions |
Authentication |
Secondary Authentication |
Privilege Elevation |
Mode of Access |
Mode of session |
Session Capture |
Enhanced Access Control |
Application Command Lists |
|---|---|---|---|---|---|---|---|---|
|
Privileged Shell |
Local Accounts on Agent |
NA |
Yes - On Demand |
Terminal |
PCKSH Shell |
Yes |
Yes |
NA |
|
Login Shell |
Windows Authentication |
NA |
Yes - On Login |
Terminal |
CPCKSH Shell |
Yes |
Yes |
NA |
|
Privileged Commands |
Privileged Account Manager |
NA |
Yes - On Execution |
Terminal |
Requested Command |
Yes |
NA |
Yes |
The List of permissions under SSH Resource Pools are:
Terminal SSH
Users can list or access SSH Sessions from any terminal, by connecting to the port of SSH Relay - ssh -t -p 2222 username@pamhost
Users' are authenticated by authentication sources configured in Privileged Account Manager.
Web SSH
Users must login into Privileged Account Manager's User Console.
Users' are authenticated by authentication sources configured in Privileged Account Manager.
The table highlights the differences of each permissions with respective options and user experience:
|
Permissions |
Authentication |
Secondary Authentication |
Privilege Elevation |
Mode of Access |
Mode of session |
Session Capture |
X11 |
Video Capture |
Application Command Lists |
|---|---|---|---|---|---|---|---|---|---|
|
Terminal SSH |
Privileged Account Manager |
Yes |
Yes |
Thick Client |
SSH Session |
Yes |
Yes |
Yes |
Yes |
|
Web SSH |
Privileged Account Manager |
Yes |
Yes |
Web Browser |
SSH Session |
Yes |
NA |
NA |
NA |
The List of permissions under Telnet Resource Pools are:
Terminal Telnet
Users can list or access SSH Sessions from any terminal, by connecting to the port of SSH Relay - ssh -t -p 2222 username@pamhost
Users' are authenticated by authentication sources configured in Privileged Account Manager.
Web Telnet
Users must login into Privileged Account Manager's User Console.
Users are authenticated by authentication sources configured in Privileged Account Manager.
The table highlights the differences of each permissions with respective options and user experience:
|
Permissions |
Authentication |
Secondary Authentication |
Privilege Elevation |
Mode of Access |
Mode of session |
Session Capture |
Application Command Lists |
|---|---|---|---|---|---|---|---|
|
Terminal Telnet |
Privileged Account Manager |
Yes |
Yes |
Thick Client |
Telnet Session |
Yes |
Yes |
|
Web Telnet |
Privileged Account Manager |
Yes |
Yes |
Web Browser |
Telnet Session |
Yes |
NA |
The List of permissions under Windows (Agent-less) Resource Pools are:
Web RDP
Users need to login into Privileged Account Manager's User Console.
Users' are authenticated by authentication sources configured in Privileged Account Manager.
The table highlights the differences of each permissions with respective options and user experience:
|
Permissions |
Authentication |
Secondary Authentication |
Privilege Elevation |
Mode of Access |
Mode of session |
Video Capture |
|---|---|---|---|---|---|---|
|
Web RDP |
Privileged Account Manager |
Yes |
Yes |
Thick Client |
RDP Session |
Yes |
Oracle Database Access
Oracle Database Credentials
Microsoft SQL Server Database Access
Microsoft SQL Server Database Credentials
MySQL Database Access
MySQL Database Credentials
Sybase Database Access
Sybase Database Credentials
PostgreSQL Database Access
PostgreSQL Database Credentials
MariaDB Database Access
MariaDB Database Credentials
IBM DB2 Database Access
IBM DB2 Database Credentials
The List of permissions under Database Resource Pools are:
Database Access
Users can access database from any thick client or command line tools, by connecting to the port of Database connector configured in the Resource.
Users are authenticated by the database.
Users from the below User Roles are authorized if specified in the respective Assignments to the Resources:
Local users or LDAP users, if the credentials are checked out.
Agent users, if the credentials are not checked out and an agent is present in the resource where the database client is invoked.
Database users, if the credentials are not checked out and agent is not present.
Database Credentials
Database Credentials
Users need to login into Privileged Account Manager's User Console.
Users are authenticated by authentication sources configured in Privileged Account Manager.
Users can check out the Credentials of authorized Resources from the User Console.
The table highlights the differences of each permissions with respective options and user experience:
|
Permissions |
Authentication |
Secondary Authentication |
Privilege Elevation |
Session Capture |
Mode of Access |
|---|---|---|---|---|---|
|
Database Access |
Database Server |
NA |
No |
Yes |
Thick Client/Command line |
|
Database Credentials |
Privileged Account Manager |
Yes |
NA |
NA |
Web Browser/ REST API |
In the Access Control > Assignments > Permissions > Checkout Options page, select the options as required.
Allow Password Change During Check-in: Move the radio button to the right to enable this option. By default this option is set to disabled and does not allow user to change the password while checking in. Enabling this option allows you to change the password while check in and provides the following options.
NOTE:For users upgrading from Privileged Account Manager 4.1 to 4.2 version, and want to continue using the same Check in and Check out behavior for credentials, do not enable the Allow Password Change During Check in option.
Whereas enabling the Allow Password Change During Check in is a new behavior of functionality from Privileged Account Manager 4.2 version onwards.
Credential Checkout Mode: Credential Checkout Mode: Selected by System option allows system to select the user for checkout.
Allow Selection by User option allows you to select the user for which you want to perform password check-in and check-out function.
Credentials Allowed for Checkout This option allows you to either allow All credentials to perform Check in and Check Out function.
The Restrict Credentials to a Privilege Type option is only applicable if you have already defined privilege type and want to select for which user you want to change the password while check out.
Applications
Application SSO
The list of permissions under Applications are:
Application Credentials
Users need to login into Privileged Account Manager's User Console.
Users are authenticated by authentication sources configured in Privileged Account Manager.
Users can check out the Credentials of authorized Resources from the User Console.
For more information, see Section 5.3.1, Configuring Credential Checkout for Application and Database Type Credentials.
The table highlights the differences of each permissions with respective options and user experience:
|
Permissions |
Authentication |
Secondary Authentication |
Mode of session |
|---|---|---|---|
|
Application Credentials |
Privileged Account Manager |
Yes |
Web Browser/REST API |
The list of permissions under Application SSO are:
Application SSO over Web
Users need to login into Privileged Account Manager's User Console.
Users are authenticated by authentication sources configured in Privileged Account Manager.
|
Permissions |
Authentication |
Secondary Authentication |
Privilege Elevation |
Mode of Access |
Mode of Session |
Session Capture |
Video Capture |
|---|---|---|---|---|---|---|---|
|
Application SSO over Web |
Privileged Account Manager |
Yes |
Yes |
Web Browser/REST API |
Requested Application |
Yes |
Yes |
In the Access Control > Assignments > Permissions > Checkout Options page, select the options as required.
Allow Password Change During Check-in: Move the radio button to the right to enable this option. By default this option is set to disabled and does not allow user to change the password while checking in. Enabling this option allows you to change the password while check in and provides the following options.
NOTE:For users upgrading from Privileged Account Manager 4.1 to 4.2 version, and want to continue using the same Check in and Check out behavior for credentials, do not enable the Allow Password Change During Check in option.
Whereas enabling the Allow Password Change During Check in is a new behavior of functionality from Privileged Account Manager 4.2 version onwards.
Credential Checkout Mode: Credential Checkout Mode: Selected by System option allows system to select the user for checkout.
Allow Selection by User option allows you to select the user for which you want to perform password check-in and check-out function.
Credentials Allowed for Checkout This option allows you to either allow All credentials to perform Check in and Check Out function.
The Restrict Credentials to a Privilege Type option is only applicable if you have already defined privilege type and want to select for which user you want to change the password while check out.
SSH Keys
Windows Keys
VMWare Keys
Custom Keys
The List of supported Keys are:
SSH Keys
Windows Keys
VMWare Keys
Custom Keys
The list of permissions for the above mentioned keys are:
Users need to login into Privileged Account Manager's User Console.
Users are authenticated by authentication sources configured in Privileged Account Manager.
Users can check out the Keys of the authorized Resources from the User Console.
|
Permissions |
Authentication |
Secondary Authentication |
Mode of Access |
|---|---|---|---|
|
All permissions under Keys |
Privileged Account Manager |
Yes |
Web Browser/REST API |
The following sections explain how you can manage resource pools, user roles, assignments, and permissions.
Resource Pools contain resources of similar type.
The following procedure explains how to manage resource pools:
On the home page of the console, click Access Control.
In the navigation pane, click Resource Pools.
In the details pane, click Create. A left pane with Create Resource pool is displayed with General and Resources settings.
In the Resources page, specify a name for the Resource Pool.
Add a Description.
Specify the Type of resource pool from the list.
Click Next. Resources page is displayed for configuration.
Click Add. Select the resources.
Click Add.
Select or enter the Default Credential. For more information, see Default Credential.
Click Create.
To modify a resource pool: In the details pane, select the resource pool you want to modify, then click the edit icon next to the resource pool name or click on the resource pool you want to modify and Edit Resource Pool page opens up on the right pane. Optionally, you can also modify the default credential at this point.
Configure the following fields:
Name: Specify a name for the resource pool.
Description: Describe the purpose of this resource pool.
Add, Remove or Delete resources.
NOTE:You cannot delete a Resource Pool if it is a part of an assignment.
NOTE:You cannot modify the type of the resource pool.
A credential with least privileges, should be selected as a Default Credential, for each resource added in a Resource Pool. This would help organizations in implementing the least privilege model as per the security recommendations and also minimizes the effort required to select a Credential while creating the access permissions.
To create permissions in Access Control, each Windows Agent must be linked with a Credential Vault, where the Credentials are stored for single sign-on purposes for respective Agents. To link a Windows Agent with a Credential Vault follow the procedure:
Go to Hosts select Windows Agent.
Click Modify Host and select a value for the Vault.
Click Finish.
You can link the following two types of Windows Agents:
Active Directory type Credential Vaults can be used for linking, if the Windows Agent is connected to an Active Directory Domain and to reference only Active Directory accounts in the Agent.
Windows Hosts type Credential Vaults can be used for linking, if the Windows Agent is a stand-alone Windows Host or a Windows Agent which is part of a Domain but also has Local Accounts. To reference both the Local Accounts and Active Directory accounts in the Agent, the Windows Host type vault in Credential Vault should be linked to an Active Directory domain.
These Resources can use a username as Default Credential, which should be typed-in. For example, root or administrators.
These Resources can use any Credential, which belongs to them in the Credential Vault.
These Resources can use any Credential, which belongs to them in the Credential Vault or the linked Active Directory domain.
NOTE:Default credentials are not required for the following resource pools:
Database
Applications
Keys
To add a new user role:
On the home page of the console, click Access Control.
In the navigation pane, click User Roles.
In the details pane, click Create. A Create User Role page with General, Included Members, and Excluded Members setting is displayed.
General: Specify the name and description of the user role. Click Next.
Included Members: Click Add to select users from the dropdown list which should be included in the user role. The drop down list consists of Local Users, LDAP Users and Groups, Database Users, and Agent Users.
Browse to users or groups and select a source.
Click Next.
Excluded Members: This field is only applicable for LDAP Users and groups. An LDAP user or group can be excluded, if that user or group is part of the LDAP groups selected Included Members in the previous section
Click Create.
To modify a user role: In the details pane, select the user role you want to modify and click the edit icon on that row or click on the user role you want to modify. Edit User Role page is displayed on the right pane.
Modify the following fields:
General: Modify the Name and Description of the user role and click Next.
Included Members: Click Add to select users from the dropdown list which should be included in the user role.
The drop down list shows Local Users, Agent Users, LDAP Users and Groups, and Database Users sources.
Browse to the users or groups and select a source. Click Add.
To remove, select existing users or groups from the table and click Remove.
Click Next.
Excluded Members: This field is applicable only for LDAP users and groups.
To delete a user role: In the details pane, select the user role that you want to delete and click the delete icon next to the user role name.
To select multiple user roles, click Delete multiple.
NOTE:You cannot delete a user role if it is a part of an assignment.
Assignment is a relationship between a single Resource Pool and a User Role, which enables to configure one or more permissions under it.
On the home page of the console, click Access Control.
In the access control pane, click Assignments.
In the details pane, click Create.
To create an assignment, you must select a User Role, Resource Pool, and provide a Description. This Description is shown to the users while listing their permissions.
Click Add and select a Permission. Configure the permission options using the wizard. For more information, see Configuring Permissions.
Click Create to add the new assignment.
NOTE:After creating the assignment or permissions, you cannot modify the User Role and Resource Pool.
To modify and assignment: In the details pane, select the assignment you want to modify and then click the Edit icon on that row or click on the assignment you want to modify and Edit Assignment page is displayed on the right pane. You can edit the Description and the Priority, click Save.
Priority is helpful to prioritize the assignments of the same Resource Pool and if one or more members are included in more than one User Role involved in these assignments.
For example: Consider that a Resource Pool (RP) is assigned to two User Roles UR1 and UR2, through the Assignments A1 (RP + UR1) and A2 (RP + UR2).
Members m1 and m2 are part of both User Roles.
A1 and A2 are configured to deliver the access with similar privileges on the target servers, but A2 has higher level of monitoring.
If A2 is expected to provide access to m1 and m2, with higher level of monitoring, A2 should have higher priority value over A1.
The assignment with highest priority value will authorize the access request.
The allowed values are - 1 to 99.
To delete an assignment: Select the assignment you want to delete and click Delete to delete the assignment and all child assignments.
For more information, see Configuring Assignments.
Under an assignment, one or more permissions define the access criteria such as Privilege Level, Allowed Access time, Monitoring options, File or Folder access control, Customization etc. Below is the list of permissions based on the Resource Types.
While configuring permissions, only the applicable options are available for configuration. The wizards on the console are helpful in navigating to a particular section of options for a permission and selecting, enabling or disabling the required options.
On the home page of the console, click Access Control.
In the access control pane, click Assignments.
In the details pane, click Create Assignment or modify an existing Assignment.
Click Add and select a Permission. Configure the permission options using the wizard. For more information, see Configuring Permissions.
Click Save.
To modify a permission: In the details pane, select the permission you want to modify and then click the Edit or Delete icon on that row to modify the permission.
Consider the following scenario:
An organization contains two user roles named consultants and contractors, need access on ten resources
Consultants role need access on four resources where software A installed
Contractors role need access on four resources where software B installed.
Both roles need access on two shared resources where both software A and B are installed.
Steps to provide privileged access in this scenario:
Create a Resource Pool (A) with four Resources where software A is installed.
Create a Resource Pool (B) with four Resources where software B is installed.
Create a Resource Pool (AB) with two Resources where both software A and B are installed.
Create a User Role – Consultants and include the required users
Create a User Role – Contractors and include the required users
Consider a scenario where you need access to shared resources. You can configure a resource pool which overlaps one or more resource pool. For example. It there is a development and an automation resource pool, wherein development servers/resources are accessed by the developers and automation servers/resources are accessed by quality analysts. The overlapping or shared permission scenario is where there is a possibility of both developers and quality analysts accessing a share resource pool which have a mix of both development and automation servers/resources.
Create an assignment between Resource Pool A and Consultants and define required permissions.
Create an assignment between Resource Pool B and Contractors and define required permissions.
Create an assignment between Resource Pool AB and Consultants and define required permissions.
Create an assignment between Resource Pool AB and Contractors and define required permissions.
Figure 6-2 Usage Scenario Permissions
Consider the following scenario:
A user role needs access to a set of Windows Agents over weekdays with Privilege elevation. Administrator wants to monitor the activity as well as controlling file access and blocking certain applications from execution.
The same user role needs access on those resources over weekends without elevation.
Steps to provide privileged access in this scenario:
Link the Agents to appropriate Credential Vaults, where all the required credentials are present.
Create a Resource Pool with all the required Windows Agents in it.
Create a User Role with all the required users.
Create an Assignment between the created Resource Pool and User Role.
Create a Credential Provider Permission with below options
Privilege Elevation as required (Example: Administrator).
Define Time Restrictions with Monday 00:00 to Saturday 00:00.
Enable Session Capture and Video Capture.
Configure Enhanced Access Control for Files. Directories and Executables and add it in this permission.
Create another Credential Provider Permission with below options:
Privilege Elevation with any other account which does not have any higher privileges.
Define Time Restrictions with Saturday 00:00 to Monday 00:00.
Disable Session Capture and Video Capture.
A sample procedure is listed below:
Click Settings on the Administration Console.
Click LDAP Servers on the left pane and click Add New.
Perform the following actions:
Specify Domain Name of the LDAP Server.
Type is set to Active Directory Services, by default.
Specify Host Name/IP Address of the LDAP Server.
NOTE:Port is set to 636, by default.
Select SSL and Verify Certificate to secure the connection via SSL by using the CA certificate.
Click GetBaseDN to fetch the appropriate details.
Set Scope to Subtree.
Specify User DN, User Name, and Password that are required for retrieving the user details and domain details for authentication.
Click Save.
A resource is a network device, application, repository, or data storage device to which users can get privileged access.
Click Credential Vault on the Administration Console.
Click +Add > Windows > Windows Host.
In Name, specify a name for Windows Server.
For this example, the resource name is set to winsrv16.intech.com.
Click Next.
Perform the following actions to configure the Connection details:
In Host Name/IP Address, specify the host name or IP address of Windows Server.
NOTE:Port is set to 3389, by default.
Select Active Directory Domain displays the list of domains if the specified host name is associated to a domain.
In this example, Windows Server is a standalone device and does not need to be associated to any Active Directory Domain.
Click Next.
Click Finish.
Click the resource that you have added and click Credentials tab.
Click Add.
Specify the User Name, Password, and Privilege Type required to access Windows Server.
Click Access Control > User Roles > Create.
Specify the role name in Name and additional information about the role in Description.
Click Next.
Click +Add > LDAP Users and Groups.
Select the domain and select the preferred user or group.
In this example, the user AlbertJ is selected.
Click Add > Create.
Click Access Control > Resource Pools > Create.
Specify Name and Description for this resource pool.
For this example, the resource pool name is set to Windows Server with AD Users.
Select Type as Windows Servers under Agentless.
Click Next.
Click Add.
Select Default Credentials that is required to allow users to access the resource.
Click Create.
Click Access Control > Assignments > Create.
Select the User Role that you defined in .
The Description gets generated with the name that you have provided for Resource Pool and User Role.
Click Add and select Web RDP permission in the Privilege Elevation window.
NOTE:By default, Credential is set to Default to allow users to access Windows Server with the default credentials that is configure for the resource.
Click Next.
Select Custom Days and set the days and time frame as follows:
Select Mon to Fri as the days.
Specify 9 to 6 as time frame for the selected days.
Click Next.
Disable Secondary Authentication.
In User Message, specify a message that is displayed to users on connecting to the resource.
Click Next > Finish > Create.
Click Settings on the Administration Console.
Click LDAP Servers on the left pane and click Add New.
Perform the following actions:
Specify Domain Name of the LDAP Server.
Specify Host Name/IP Address of the LDAP Server.
NOTE:By default, Type is set to Active Directory Services and Port is set to 636.
Select SSL and Verify Certificate to secure the connection via SSL by using the CA certificate.
Click GetBaseDN to fetch the appropriate details.
Set Scope to Subtree.
Specify User DN, User Name, and Password that are required for retrieving the user details and domain details for authentication.
Click Save.
Click Credential Vault on the Administration Console.
Click +Add > Linux/Unix/Network Device > SSH.
In Name, specify a name for the Linux system.
For this example, the resource name is set to lnx-mchs.intech.com.
Click Next.
Perform the following to configure the Connection details:
In Host Name/IP Address, specify the host name or IP address of the Linux system.
NOTE:Port is set to 22 by default.
Click Get Host Key to get the key of the specified machine.
Click Next.
Click Finish.
Click Count of the resource that you have added.
Click Add in the Credentials tab.
NOTE:Credential Type is set to Password by default, this grants elevated access to the resource using the specified Password.
Specify the User Name, Password, and Privilege Type required to access Linux system.
Click Add.
Click Access Control > User Roles > Create.
Specify the role name in Name and additional information about the role in Description.
Click Next.
Click +Add > LDAP Users and Groups.
Select the domain and select the preferred user or group.
In this example, the user Silvia is selected.
Click Add > Create.
Click Access Control > Resource Pools > Create.
Specify Name and Description for this resource pool.
For this example, the resource pool name is set to lnx-ssh-pool.
Select Type as SSH Servers under Agentless.
Click Next.
Click Add and select the resource that you added in Add Linux System as a Resource.
Click Add.
Select Default Credentials that is required to allow users to access the resource.
Click Create.
Click Access Control > Assignments > Create.
Select the Resource Pool that you created in Create a Resource Pool.
Select the User Role that you defined in Defining a User Role.
The Description gets generated with the name that you have provided for Resource Pool and User Role.
Click Add and select Web SSH permission.
NOTE:By default, the Credential is set to Default in the Privilege Elevation window.
Click Next.
NOTE:Time Restriction is set to All Days (24 hours) by default, allowing Linux system to be accessible for 24 hours without any restriction.
Click Next.
Disable Secondary Authentication.
In User Message, specify a message that is displayed to users on connecting to the resource.
Click Next > Finish > Create.
Access Control assigns permissions to users based on their role. It provides granular control and offers a simple, manageable approach to access management that is less prone to error than assigning permissions to users individually.
The user role and permissions concept simplifies user assignments because management of users is not done individually, but instead have privileges that conform to the permissions assigned to their role(s).
All the objects in the advanced configurations can be managed using folders.
Creating a Folder for Scripts, Enhanced Access Control, and Application Command List
NOTE:You have the option to create a folder and associate objects to the created folder.
On the home page of the console, click Access Control.
In the navigation pane, click Configurations > Scripts.
In the left side of the details pane, click on a specific script.
Click the folder icon.
Create New Folder dialog is displayed.
Enter a folder Name. Click Create.
You can move the existing scripts to this folder by selecting the script and clicking Move.
NOTE:You cannot delete a folder if the folder is associated with a Command list, EAC, or Scripts.
Click on the edit icon against a specific folder to edit the folder name and then click Save.
NOTE:You cannot modify the folder type, but you can enable or disable the script.
The following configuration options are provided to assist you with Access Control configuration and management:
Keeping Windows and Linux/Unix agents in perspective, rather than elevating the entire session for the user, we have option to elevate privileges for certain applications. This may be for a command prompt or database client <SQL client> which ever application which might required granular permissions to be granted.
For agentless sessions although they are elevated sessions using SSH and Telnet, we can restrict the user functions. These command lists are easy to configure because there are wizards to guide to users.
The following procedure helps you in adding commands which you want to allow or deny.
Create a command list.
Go to Access Control > Configuration > Application Command List.
Click New List > Create New List
Enter the Name, optionally add the Description.
Select the List Type. Either Windows or Linux.
Click Create.
Add commands which you want to allow or deny.
Set the Risk Score to any of the following levels:
Undefined
Low
Medium
High
Go to Credential Vault. Select either Linux/Unix Network Device or Windows. as applicable.
Select the resource for creating the vault for which you want to add allow/deny commands.
Create a Resource Pool.Access Control > Resource Pools. For more information, see Section 6.2.2, Configuring Access Control.
Create a User Role based on the user selection from Local User, Agent User, LDAP User. For more information see, Configuring a User Role.
Create an Assignment by delegating necessary permissions.
In the Command List page, add the command list you created in the configuration tab and specify if you want to allow or deny those set of commands.
Click Finish > Save.
If you log into the target machine and execute the commands, you will notice that the commands you set to deny will throw a “permission denied” error.
You can view the risk details in Reports > All Sessions Details > Keystrokes.
Enhanced Access Control (EAC) policy can be defined at Permission level and also at an individual at the Access Control EAC object level and these can be associated to the Permission.
The EAC capability defines granular risks scores. Earlier capability included defining risk for every path (file or folder). But with the present functionality one can define the same for every operation on a given path for read, write, delete, execute, separate risk can be defined. The order of EAC policy execution is sequential. In the event of conflict, the first one takes the priority.
The Enhanced Access Control functionality includes the following four categories:
File and Directory Level Access
Application Process Control
Registry Access
Services Start/Stop Control
The earlier functionality with Command Control was limited to Linux/Unix but the present one includes support for Windows.
This ability has control over files and directories permissions to users based on sessions. An administrator can specify a list of paths and each one has access control such as; Read, Write, Delete capabilities.
NOTE:Non-English characters are not supported with Enhanced Access Control on Windows.
Click Access Control > Configuration > Enhanced Access Control > New Policy.
Specify the Name
(Optional) Specify the Description
Select the List Type as Windows.
Click Create.
Click Add Path: Create a path in the target machine. Modify this path rule to create appropriate permissions for file and associate this with the necessary risk score if you want.
Click Save.
Create Resource Pool. For more information see, Section 6.2.2, Configuring Access Control.
Create User Role. For more information, see Configuring a User Role.
Associate the Resource Pool and User Role with an assignment by clicking permissions for the Enhanced Access Control.
Click Add > Add EAC Policy. The Windows policy is displayed.
Select the Policy and click Add.
Click Finish. The permission is created.
Log into a Windows machine and navigate to the created folder. You can verify that the permissions you had created are successfully configured.
You can view the risk details in Reports > All Sessions Details > Keystrokes.
For more information on Enhanced Access Control on Linux and Unix machine, see Enhanced Access Control.
Click Access Control > Configuration > Enhanced Access Control > New Policy.
Specify the Name
(Optional) Specify the Description
Select the List Type as Linux.
Click Create.
Click Add Path: Create a path in the target machine. Modify this path rule to create appropriate permissions for file and associate this with the necessary risk score if you want.
Click Save.
Create Resource Pool. For more information see, Section 6.2.2, Configuring Access Control.
Create User Role. For more information, see Configuring a User Role.
Associate the Resource Pool and User Role with an assignment by clicking permissions for the Enhanced Access Control.
Click Add > Add EAC Policy. The Windows policy is displayed.
Select the Policy and click Add.
Click Finish. The permission is created.
Log into a Windows machine and navigate to the created folder. You can verify that the permissions you had created are successfully configured.
You can view the risk details in Reports > All Sessions Details > Keystrokes.
You can use Perl scripts to provide additional, customized functionality using relevant permissions. The Perl scripts defined as conditional can be used in permission. The return codes are limited to 1 for true and 0 for false. These conditional Scripts are executed during the permission evaluation. You can organize these scripts into a single level folder structure. Follow the steps to create a script:
On the home page of the console, click Access Control.
In the navigation pane, click Configurations > Scripts.
In the details pane, click +Script. A Create New Script page with Name, Description, and Script is displayed.
Name: Specify the name for the script.
Description: Add a description for the script.
Script: Write the script. Click Create.
You can add this script to a folder.
Exceptions are used as access deny lists in Access Control. Exceptions are created automatically when you block the user during a manual or automatic disconnect session.
Exceptions are used as access deny lists in Access Control. Exceptions are created automatically when you block the user during a manual or automatic disconnect session.
Blocking user access in versions earlier than Privileged Account Manager 4.0: Till Privileged Account Manager 4.0, any privileged access request processed by Access Control, Command Control, or Emergency Access, was evaluated against Blocked Users group first. If a user was part of Blocked Users group, then all the access was denied.
Blocking user access from Privileged Account Manager 4.1 and later: Exceptions are applicable only to Access Control. They are not considered while evaluating Command Control policies or Emergency Access requests. Any privileged access request processed by Command Control or Emergency Access, is evaluated against Blocked Users group.
Navigate to Access Control > Exceptions and click the Configuration icon on the right pane to set properties or exceptions.
Status: You can retain the enabled status of this option if you want the exceptions to be evaluated while processing the privileged access requests by Access Control. This option is enabled by default. Move the slider to the left if you want to disable this option.
Deny Access On: You can select any combination of Resources or Permissions.
Selection All Resources implies that user access is denied on all resources.
Selecting Target Resource implies that user access is denied on the target resources only.
Selecting All Permissions implies that user access is denied for all permissions.
Selecting Target Permission implies that user access using the target permission is denied for the user with any permission.
Following are all the possible combinations:
All Resources + All Permissions: This combination implies that all access for the user is denied.
All Resources + Target Permission: This combination implies that user access for the target permission is denied on all resources. Example: If the target permission is Direct RDP, then user access to any resource using Direct RDP is denied.
Target Resource + All Permission: This combination implies that access to the target resource is denied for the user using any permission.
Target Resource + Target Permission: This combination implies that user access using target permission to the target resource is denied.
Expire After: You can set the validity for the exception in minutes, hours, days, week, or never. The default value Never, implies the exception will be applicable indefinitely.
Delete After: You can set the deletion time for the exception after expiry. The exceptions will be purged from the server after the configured days of expiry. Only the expired exceptions will be deleted.
You can mark exceptions as Mark Expired from the Active tab. Expired exceptions indicate that the validity for the exception has expired.
To mark an exception as expired:
On the home page of the console, click Access Control > Exceptions.
Select the exceptions that you want to mark as expired.
In the details pane, click Mark Expired.
Click Yes to confirm.