Depending on how the Security Policy Administrator configured the policy, a password release request will either require approval by one or more Safeguard for Privileged Passwords users, or be auto-approved. This process ensures the security of account passwords, provides accountability, and provides dual control over the system accounts.
|
Note: You can configure Safeguard for Privileged Passwords to notify you of a password release request that requires your approval. For more information, see Configuring alerts. |
To approve or deny a password release request
You can then select and drag the pane to any location on the console and re-size the window.
|
Note: You enable or disable the Home page widgets in the |
State | Description |
---|---|
All | Password release requests in all states. |
Pending | Requests that are waiting for approval. |
Approved | Requests that have been approved, but not yet available to the requester. |
|
Note: The number indicates how many requests are in that state. |
Take the following actions on password release requests:
State | Actions | ||
---|---|---|---|
Pending |
Select Optionally, enter a comment of up to 255 characters. | ||
Pending Additional Approvers |
Select Optionally, enter a comment of up to 255 characters. | ||
Approved |
Select
|
The Security Policy Administrator can configure an access request policy to require a review of completed password release requests for accounts in the scope of the policy.
You can configure Safeguard for Privileged Passwords to notify you of a password release request that requires your review. For more information, see Configuring alerts.
To review a completed password release request
You can then select and drag the pane to any location on the console and re-size the window.
|
Note: You enable or disable the Home page widgets in the |
Take the following action on password release requests:
Optionally, enter a comment of up to 255 characters.
Once the review is complete, it no longer appears on the Reviews pane.
|
TIP: If one requester checks in the request and another requester wants to use it, the second requester is unable to check out the password until the original request has been reviewed. However, the Security Policy administrator can Close a request that has not yet been reviewed. This will bypass the reviewer in the workflow and allow the account to be accessed by another requester. |
With the embedded sessions module, authorized users can authorize connections, view active connections, limit access to specific resources, be alerted if connections exceed pre-set time limits and even terminate connections.
Typically a session request follows this workflow.
The following topics explain the entire end-to-end session access process from request to approval to review (and play back if sessions recording is enabled).
One Identity Safeguard for Privileged Passwords proxies all sessions to target resources. Users do not have direct access to resources, therefore, the enterprise is protected against viruses, malware or other dangerous items on the user's system. One Identity Safeguard for Privileged Passwords for Privileged Sessions can proxy and record Unix/Linux, Windows, network devices, firewalls, routers and more.
Sessions requests are enabled by default. However, if authorized users cannot request sessions, check the Session Requests Enabled setting (Administrative Tools | Settings | Access Request | Enable or Disable Services).
|
NOTE: You must have Appliance Administrator permissions to manage the service settings. |
Both SSH and RDP session recordings use the Timestamping Certificate Authority. For more information, see Sessions Certificates.
Recordings are signed and timestamped every 30 seconds so that partial recordings may be verified as authentic.
During an RDP session, the embedded sessions module proxies the connection to the target asset.
When an RDP connection is established, the embedded sessions module will generate a certificate on the fly and sign it using the RDP Connection Signing Certificate. Therefore the RDP client trusts the RDP Connection Signing Certificate and the generated certificate that is signed by the RDP Connection Signing Certificate. This allows the client to verify that the connection is trusted.
During an SSH session, the Privileged Sessions module proxies the connection to the target asset. Therefore, Safeguard for Privileged Passwords's SSH host key (Settings | Sessions | SSH Host Key) must be trusted by the client. This SSH host key is unique and produced during manufacturing. This key can be trusted by the client or replaced with a different key if desired.
© 2021 One Identity LLC. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy