立即与支持人员聊天
与支持团队交流

One Identity Safeguard for Privileged Passwords 7.5 - 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 page Privileged access requests Appliance Management
Appliance Backup and Retention Certificates Cluster Global Services External Integration Real-Time Reports Safeguard Access Appliance Management Settings
Asset Management
Account Automation Accounts Assets Partitions Discovery Profiles Tags Registered Connectors Custom platforms Importing objects
Security Policy Management
Access Request Activity Account Groups Application to Application Cloud Assistant Asset Groups Entitlements Linked Accounts User Groups Security Policy Settings
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

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 SPP.

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.

    3. Federation Metadata: Select one of the following options:

      1. From File: When using this option, SPP stores a static copy of the metadata. It is the responsibility of the administrators to update the metadata, when necessary, by repeating this process. For example, when the signing certificate used by the STS changes.

        You must first download the federation metadata XML for your STS and save it to a file locally. For example, for Microsoft's AD FS, you can download the federation metadata XML from: https://<adfs server>/FederationMetadata/2007-06/FederationMetadata.xml.

        Click Browse to select the STS federation metadata xml file.

      2. From URL: When using this option, SPP will automatically download the STS metadata and refresh it on a periodic basis, so it should always have the current signing certificates and other information used by the STS.

        Specify the complete HTTPS URL to the STS metadata. The SSL/TLS certificate used by the HTTPS URL must be trusted on every node of the SPP cluster, and each node of the cluster will need network/internet access to be able to download from the specified HTTPS URL. It is strongly recommended to verify that you can successfully log in on each node of the cluster after initially creating the Identity Provider.

        After the external federation provider is created, you can manually trigger SPP to update the metadata from the configured URL by clicking the Update Metadata button. This may be useful to help minimize any downtime when you know that the STS metadata has changed.

        NOTE: A proxy server may be configured. For more information, see Networking.

    4. Download Safeguard Federation Metadata: If you have not done so before, click the link to download a copy of SPP'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 SPP's federation metadata by clicking the link when you entered the STS information in SPP. You can also download the SPP 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://<SPP 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 SPP federation metadata XML file you downloaded.

  • The App ID for SPP 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.

    NOTE: If using SPP in a clustered environment and you do not use a load balanced DNS name to access SPP, or you wish to be able to log in to a specific node of the cluster, you will have to add additional login redirect URLs to your STS configuration.

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 may need to update the metadata for the associated external federation provider in SPP depending on how it and your STS are configured:

  • If the external federation provider in SPP was configured by uploading a copy of the STS metadata file, then that needs to be repeated with the new copy of the STS metadata file containing the new signing certificate.

  • If the external federation provider in SPP was configured to use the URL that points to the STS metadata (and the STS supports having multiple active signing certificates for seamless rollover), then you shouldn't have to do anything. SPP periodically attempts to download the metadata and will use the new certificate when it becomes active. Otherwise, you can manually trigger SPP to download and refresh the STS metadata from the configured URL by selecting the external federation provider and clicking the Update Signing Certificates and Metadata toolbar button.

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:

How do I add an external federation user

It is the responsibility of either the Authorizer Administrator or the User Administrator to add an associated external federation SPP user.

Preparation

You must add external federation service providers to SPP before you can add external federation users.

No user information, such as first name, last name, phone number, email address, is ever imported from the STS claims token. You must enter that information manually when creating the user in SPP if you need it.

To add a user

  1. Navigate to User Management > Users.
  2. In Users, click New User from the toolbar.

  3. In the User dialog, provide information in each of the tabs:

How do I manage accounts on unsupported platforms

SPP makes it possible for you to manage passwords and SSH keys for accounts on unsupported platforms and not addressed by a Custom platforms.

You will use a profile with a manual change password or an SSH key setting.

For example, you may have an asset that is not on the network. The manual change password or SSH key setting allows you to comply with your company policies to change account passwords on a regular schedule without using the SPP automatic change password or SSH key settings. SPP notifies you by email, toast notification, or both on a set schedule to change account passwords manually. You can then reset the password or SSH key yourself, or allow SPP to generate a random password or SSH key according to the password rule selected in the profile.

IMPORTANT: After you change the password or SSH key in SPP you must remember to change the password or SSH key on the account; SPP does not do that automatically for you.

The following summarizes the general workflow for managing accounts on unsupported platforms.

To manage account passwords or SSH key manually

  1. Configure a profile with a manual change password or SSH key setting and assign asset accounts to it. See: Adding change password settings and Adding SSH key change settings.
  2. Ensure toast notifications or email notifications are properly configured. For more information, see Enabling email notifications.
  3. When notified to change an account password or SSH key, choose:
相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级