Tchater maintenant avec le support
Tchattez avec un ingénieur du support

One Identity Safeguard for Privileged Passwords 7.0 LTS - Administration Guide

Introduction System requirements and versions Using API and PowerShell tools Using the virtual appliance and web management console Cloud deployment considerations Setting up Safeguard for Privileged Passwords for the first time Using the web client Home Privileged access requests Appliance Management
Appliance Backup and Retention Certificates Cluster Enable or Disable Services External Integration Real-Time Reports Safeguard Access
Asset Management
Account Automation Accounts Assets Partitions Discovery Profiles Tags Registered Connectors Custom platforms
Security Policy Management
Access Request Activity Account Groups Application to Application Cloud Assistant Asset Groups Entitlements Linked Accounts User Groups Security Policy Settings Reasons
User Management Reports Disaster recovery and clusters Administrator permissions Preparing systems for management Troubleshooting Frequently asked questions Appendix A: Safeguard ports Appendix B: SPP and SPS join guidance Appendix C: Regular Expressions About us

How do I audit transaction activity

The appliance records all activities performed within Safeguard for Privileged Passwords. Any administrator has access to the audit log information; however, your administrator permission set determines what audit data you can access.For more information, see Administrator permissions.

Safeguard for Privileged Passwordsprovides several ways to audit transaction activity:

How do I configure external federation authentication

Safeguard for Privileged Passwords supports the SAML 2.0 Web Browser SSO Profile, allowing you to configure federated authentication with many different Identity Provider STS servers and services, such as Microsoft's AD FS. Through the exchange of the federation metadata, you can create a trust relationship between the two systems. Then, you will create a Safeguard for Privileged Passwords user account to be associated with the federated account.

Safeguard supports both Service Provider (SP) initiated and Identity Provider (IdP) initiated logins.

  • For SP initiated, the user will first browse to Safeguard and choose External Federation as the authentication provider. After entering just their email address, they will be redirected to the external STS to enter their credentials and perform any two-factor authentication that may be required by that STS. After successful authentication, they will be redirected back to Safeguard for Privileged Passwords and logged in.
  • For IdP initiated logins, a user will first go to their IdP STS and authenticate. Typically, the customer will have configured Safeguard as an application within their STS, allowing the user to just click on a link or icon and be redirected to Safeguard, automatically being logged in without having to enter any further credentials.

NOTE: Additional two-factor authentication can be assigned to the associated Safeguard for Privileged Passwords user account to have the user authenticate again after being redirected back from the external STS.

To use external federation, you must first download the federation metadata XML for your STS and save it to a file. For example, for Microsoft's AD FS, you can download the federation metadata XML from:

https://<adfs server>/FederationMetadata/2007-06/FederationMetadata.xml.

How do I add an external federation provider trust

It is the responsibility of the Appliance Administrator to configure the external federation service providers in Safeguard for Privileged Passwords.

To add an external federation service provider

  1. Go to Appliance Management | Safeguard Access | Identity and Authentication.
  2. Click Add then select External Federation.
  3. In the External Federation dialog, supply the following information:
    1. Name: Enter a unique display name for the external federation service provider. The name is used for administrative purposes only and will not be seen by end users.

      Limit: 100 characters

    2. Realm: Enter a unique realm value, typically a DNS suffix, like contoso.com, that matches the email addresses of users intended to use this STS for authentication. Values can be separated by a space, comma, or semi-colon. A case-insensitive comparison will be used on the value(s) when performing Home Realm Discovery.

      Wildcards are not allowed.

      Limit: 255 characters

    3. Federation Metadata File: Choose or enter the file path to the STS federation metadata file that you previously downloaded.
    4. Download Safeguard Federation Metadata: If you have not done so before, click the link to download a copy of Safeguard for Privileged Passwords's federation metadata XML. You will need this file when creating the corresponding trust relationship on your STS server.

      NOTE: The federation metadata XML files typically contain a digital signature and cannot be modified in any way, including white space. If you receive an error regarding a problem with the metadata, ensure that it has not been edited.

    5. Click OK.

How do I create a relying party trust for the STS

The process for creating the relying party trust in your STS (Security Token Service) will differ between applications and services. However, as stated earlier, you can download a copy of Safeguard for Privileged Passwords's federation metadata by clicking the link when you entered the STS information in Safeguard for Privileged Passwords. You can also download the Safeguard for Privileged Passwords federation metadata at any time using one of the following methods:

  1. Go to Appliance Management | Safeguard Access | Identity and Authentication.
  2. Click Download Safeguard Federation Metadata.
  3. Download the file from the following URL:
https://<Safeguard for Privileged Passwords server>/RSTS/Saml2FedMetadata

If the STS does not support importing federation metadata, but instead requires you to manually input values, you will typically need an App ID and Login or Redirect URL. Both of these values can be copied from the Safeguard for Privileged Passwords federation metadata XML file you downloaded.

  • The App ID for Safeguard for Privileged Passwords will come from the entityID attribute of the <EntityDescriptor> element in the XML file.
  • The Login or Redirect URL will come from the Location attribute of the <AssertionConsumerService> element within the <SPSSODescriptor> element.

    NOTE: Only the HTTP-POST binding is supported for this end point.

You must then configure or ensure that the STS returns the authenticated user's email address as a SAML attribute claim. The email address must appear in either the standard SAML email address claim or name claim:

  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

If the emailaddress and name attribute claims are not present in the SAML assertion, the SAML Subject NameID can be used.

NOTE: Any other attributes or claims will be ignored.

The SAML Response or Assertion must be signed, but not encrypted. When the signing certificate used by your STS expires, you must update the metadata in Safeguard for Privileged Passwords by uploading a new copy of your STS's metadata file. Safeguard for Privileged Passwords will not automatically attempt to refresh the metadata.

NOTE: Your STS's metadata can contain more than one signing certificate to allow for a grace period between an expiring certificate and a new one.

For further details regarding specific STS servers, see the following knowledge base articles on the One Identity support site:

  • Configuring Microsoft's AD FS Relying Party Trust for Safeguard for Privileged Passwords: KB Article 233669
  • Configuring Microsoft's Azure AD for Safeguard for Privileged Passwords: KB Article 233671
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation