Password Access Control Workflow35 minutes to read
Access Control - DefinitionAccess control is a strategy that verifies the authenticity of users and ensures that they have suitable privileges to perform a task or access data. To put it simply, access control is a way of selectively restricting access to sensitive data. An effective access control strategy comprises of two major components: authentication and authorization. Through authentication, one can verify if a person is who they claim to be. However, authentication alone is not sufficient to protect data, and an additional layer called authorization, which determines whether a user is permitted to access the data or perform an action they are attempting, is mandatory. Authentication and authorization are the two key components that are essential to strengthen data security in an organization. Glossary of Terminologies
Password Access Control in PAM360PAM360 provides an access control mechanism that allows administrators to grant password access to users for a specific period. Admins can start granting exclusive privileges once a password is ready to share, and only one user is allowed to use a particular password at a single point of time. Additionally, administrators can provide just-in-time (JIT) privilege elevation to local user accounts in a Windows resource. For example, assume, "dbuser" is a local account in a Windows resource added to PAM360, and this account does not have any admin privileges. Using the JIT privilege elevation feature, admin can elevate dbuser's privileges equal to that of an admin or any other privileged user. You will learn the following topics concerning Password Access Control workflow in this document:
1. The Password Access Control WorkflowOnce the password access control is enforced for a resource or an account, the following workflow is invoked for password access attempt by the users:
2. Precedence in Password Access ControlAccount level access control configuration takes higher precedence over Resource level access control configuration as explained below in detail:
3. Executing the Password Access Control WorkflowFollow the below steps to implement password access control for a resource or an account:
3.1 Access Control at Resource Level
![]() 3.2 Access Control at Account LevelWith Access Control at account level, it is possible to set password access control independently for each account under a resource, without affecting the access control configurations of other accounts in the resource. This ability to set unique configurations for each account helps users maintain unparalleled security levels for each account, based on requirements. Follow the below steps to implement access control for accounts:
![]() ![]()
3.2.i Approval AdministratorsDesignate the administrator(s) as the approvers of password release requests. The list of all administrators, password administrators, and privileged administrators in the system are listed in the left pane. You can designate as many administrators as you wish for a particular resource or an account. Anyone from the list of Authorized Administrators could approve the requests raised by users. ![]() 3.2.ii Excluded UsersExclude a set of users from the access control workflow using this option. The excluded users will be able to access passwords directly without raising requests ![]() 3.2.iii Miscellaneous Settings
![]() Note: You can also designate user group(s) as approvers for password release requests. When a user group is designated as an approver, all the users with admin rights within that group (the administrators, password administrators, privileged administrators and admin users with the custom role) are given access rights. If you have enforced approval by a particular number of administrators, say 5, then the authorized user group must have at least 5 valid administrators. 3.2.iv Auto Approval
![]() 3.2.v JIT Privilege ElevationThe Just-in-Time (JIT) privilege elevation mechanism in PAM360 allows administrators to temporarily elevate access for Windows local accounts and domain accounts. This functionality enables users to perform privileged tasks within a specified timeframe, ensuring that elevated access is only granted when necessary. With JIT privilege elevation, a Windows local account can be granted privileged access by adding it to the local group on the corresponding machine. Similarly, a domain account can be elevated by adding it to the appropriate domain security groups in the domain controller. By leveraging JIT privilege elevation, organizations can implement granular control over access permissions, reducing the need to provide blanket access with elevated privileges across multiple user accounts. This temporary elevation approach significantly mitigates security risks associated with permanent administrative access, ensuring that elevated privileges are only granted when required. Explore this link for detailed steps on configuring JIT privilege elevation. Notes:
3.3 Viewing Access Control DetailsOnce Access Control is activated for an account or a resource, the Access Control Details option consolidates all the settings applied and provides it in a single window for easy perusal. Please note that the Access Control Details window can be accessed from the Account Actions menu only. Follow the below steps to view the access control details:
4. Use Case ScenariosThe following are some of the use case scenarios in which access control workflow will be useful in an organization. Case 1: User Requesting Access to View a PasswordTo access a password protected by the access control workflow, a user will have to request the administrator to grant permission to view the password. Steps To Make a Request:
![]() ![]()
Case 2: Administrator Approving a Password RequestIf you're an administrator and a user has requested your approval to view a password, you will receive an email notification about the request. You can view all the requests pending your approval from the Admin tab. To Approve a Request,
![]() ![]() ![]() ![]()
Case 3: User Requesting Access and Administrator Approving a Password Request for Windows Domain AccountSteps to request a password:
![]() To Approve a Request:
Case 4: User Completes their Password UsageThe crux of the access control mechanism is that the user will be allowed only temporary access to passwords. So, once the user finishes their work, they can give up the password. To Give Up Access to the Password:
Case 5: Administrator Forcefully Checks In the PasswordAccess control mechanism allows exclusive access privilege to a user for a specified time period. During this period, no one else will be allowed to view the password, including the owner. In case an emergency arises to revoke the exclusive permission to the user, administrator can forcefully check in the password at any point of time. To Forcefully Check In a Password:
Case 6: What Happens if the Automatic Scheduled Password Reset Fails During Password Check InOnce a password is checked out by a user, it will be checked in due to any of the following three reasons:
When password is checked in, if the admin settings require automatic password reset, PAM360 will try to reset the password. In case PAM360 is not able to reset the password in the actual resource, PAM360 will immediately trigger email notifications to the administrators who approved the password access request of the use so that they can troubleshoot and set things right. The password reset failure will also reflect on the audit trails. Case 7: What Happens if a Scheduled Password Reset Scheduled Task Runs When a Password is Checked Out?PAM360 provides an option to create scheduled tasks for automatic and periodic password resets. It is possible that a scheduled task starts executing the reset of a password that is currently checked out by a user. If that reset task is allowed to execute successfully, the user will be working with an outdated password. To avoid such password mismatch issues, PAM360 will prevent the reset of that password alone while all other passwords of other resources that are part of the scheduled task will be reset. The failure to reset the exempted password during the password reset schedule will reflect on the audit trails. Case 8: Disabling Access ControlAs an administrator, if you want to disable access control for any resource or an account, you may do so at any time as explained below. i. Deactivating Access Control for Resources
ii. Deactivating Access Control for Accounts
Now, the Access Control for the selected resources or accounts is deactivated. So, any user who has permission to view a password (owned/shared) can directly view the password without going through the access control process.
Case 9: Transferring Approver Privileges to Other AdministratorsWhen an administrator leaves the organization or moves to a different department, resources/ accounts owned by that administrator are transferred to some other administrator. If the departing administrator had acted as the approver for password release requests, the approval privileges should also be transferred. All the resources and accounts that were earlier controlled by one admin can be easily transferred in bulk to another admin. Follow the below steps to learn how to transfer approver privileges from one administrator to another. To Transfer Approver Privileges:
![]() 5. Message TemplatesBy default, PAM360 has predefined templates for access control dialog boxes such as Password Request, Password Check In, Password Check Out. Using message templates, the administrators will be able to alter the messages in access control workflow dialog. To customize the messages in access control dialog:
![]() ![]() 6. Limitation in Access Control WorkflowThe password access control workflow in PAM360 currently presents a compatibility issue when it comes to High Availability secondary servers. If the primary server becomes unavailable, PAM360 users won't be able to utilize the password access control workflow. To solve this, administrators can use a workaround solution, though it needs careful tracking of approved requests in that timeframe. Here's how to use the password access control workflow when the primary server is down:
Upon the primary server's restoration, the automated check-in will not work efficiently for the resources checked out from the secondary server during the interim time. So, it becomes the administrator's responsibility to review manually and check-in the resources that were checked out during the interim period. | ||||||||||||||||