If a user has not logged onto Safeguard for Privileged Passwords for a set number of days, Safeguard for Privileged Passwords disables the user account.
|
NOTE: This is set using the Disable After setting in Administrative Tools | Settings | Password Settings | Login Control. For more information, see Login Control. |
If a user did not receive an email notification, first check to see if you have set everything up in Safeguard for Privileged Passwords correctly for the email notifications to work properly. For more information, see Enabling email notifications.
Safeguard for Privileged Passwords does not dynamically maintain the email addresses for an escalation notification contact list.
If you change a Safeguard for Privileged Passwords user's email address or delete a Safeguard for Privileged Passwords user after creating a policy, you must update the email addresses in escalation notification contact lists manually. For example, when you create a policy you can indicate who to contact when emergency access has been used. If a user has changed his or her email address, the notification will not be received by that individual. Furthermore, if a user has been deleted from Safeguard for Privileged Passwords, he or she will still receive the notification.
The following topics will help you find answers to some of your questions about managing Safeguard for Privileged Passwords:
How do I customize the response using API query parameters
How do I audit transaction activity
How do I configure external federation authentication
How do I add an external federation provider trust
How do I create a relying party trust for the STS
How do I add an external federation user account
How do I manage accounts on unsupported platforms
How do I modify the appliance configuration settings
How do I prevent Safeguard for Privileged Passwords messages when making RDP connections
How do I set up telnet and TN3270/TN5250 session access requests
How do I set the appliance system time
How do Safeguard for Privileged Passwords database servers use SSL
What are the access request states
What do I do when an appliance goes into quarantine
What is required for One Identity Safeguard for Privileged Passwords, embedded sessions module
What role-based email notifications are generated by default
Verifying syslog server configuration
When does the rules engine run for dynamic grouping and tagging
You can use the API to automate Safeguard for Privileged Passwords tasks and access functionality not currently available in the Windows desktop client. Safeguard for Privileged Passwords has the following API categories:
Appliance: Resources used to manage the appliance itself (like setting the time, network configuration, syslog, etc.)
https://<Appliance IP>/service/appliance/swagger/
Core: Resources used to govern policy and manage accounts, etc.
https://<Appliance IP>/service/core/swagger/
Notification: Resources used to query the Safeguard for Privileged Passwords Appliance status
https://<Appliance IP>/service/notification/swagger/
You must use a bearer token to access most resources in the API. When using the Swagger web UI (as referenced in the URLs above), click the Authorize button at the top of each page and log in using the web UI. The Swagger web UI adds the bearer token to each API request automatically. However, if you are manually making the API request or writing your own application/script, perform the following two steps to obtain a bearer token.
You must first authenticate using the OAuth 2.0 Resource Owner Password Credentials or Client Credentials grant types. An example of the former is:
POST https://<ApplianceIP>/RSTS/oauth2/token
Host: <ApplianceIP>
Content-Type: application/json
Accept: application/json
"grant_type": "password",
"username": "<Username>",
"password": "<Password>",
"scope": "rsts:sts:primaryproviderid:local"
Where:
scope is required and set to one of the available identity provider's scope ID. The value shown in the example request, "rsts:sts:primaryproviderid:local", is the default value available on all Safeguard for Privileged Passwords Appliances. User accounts that you create in Safeguard for Privileged Passwords directly (that is, not an Active Directory or LDAP account) will most likely have this scope value.
|
NOTE: The list of identity providers is dynamic and their associated scope ID can only be obtained by making a request to: https://<ApplianceIP>/service/core/v2/AuthenticationProviders and parsing the returned JSON for the RstsProviderScope property. |
If you wish to authenticate using a client certificate, you must use the OAuth 2.0 Client Credentials grant type in which your certificate is included as part of the SSL connection handshake and the Authorization HTTP header is ignored. Set the scope to rsts:sts:primaryproviderid:certificate or any other identity provider that supports client certificate authentication.
POST https://<ApplianceIP>/RSTS/oauth2/token
Host: <ApplianceIP>
Content-Type: application/json
Accept: application/json
"grant_type": "client_credentials",
"scope": "rsts:sts:primaryproviderid:certificate"
After successfully authenticating, your response will contain an access_token that must be exchanged for a user token to access the API.
POST https://<ApplianceIP>/service/core/v2/Token/LoginResponse
Host: <ApplianceIP>
Content-Type: application/json
Accept: application/json
"StsAccessToken": "<access_token from previous response>"
You should now have an authorization token to be used for all future API requests. The token is to be included in the HTTP Authorization header as a Bearer token like this:
For example:
GET https://<ApplianceIP>/service/core/v2/Users/-2
Host: <ApplianceIP>
Accept: application/json
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1Ni...
|
NOTE: The token will expire in accordance to the Token Lifetime setting that is configured in Safeguard for Privileged Passwords (Settings | Safeguard Access | Login Control) at the time the token was issued. |
© 2021 One Identity LLC. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy