Safeguard for Privileged Passwords On Demand Hosted

Safeguard for Privileged Passwords allows you to create various types of identity and authentication providers to integrate with existing directory services. This helps you to effectively manage users and how they will log in to Safeguard. You can create providers for Active Directory, LDAP 2.4, any SAML 2.0 federated service, or Radius.

To be managed, a directory asset must be added as both an asset and as an identity provider. When adding the identity provider, if the account name matches an account name already linked to an identity provider, the provider is automatically assigned.For more information, see Accounts.

Go to Identity and Authentication:

web client: Navigate to Appliance Management | Safeguard Access | Identity and Authentication.
desktop client: Navigate to Administrative Tools | Settings | External Integration | Identity and Authentication.

The Identity and Authentication pane displays the following details about the identity and authentication providers defined.

Table 234: Identity and Authentication: Properties
Property	Description
Name	The name assigned to the identity or authentication provider. Names are assigned by the administrator that creates the identity or authentication provider. Depending on the provider type, the name may be displayed in a drop-down list on the login page, with exception of Active Directory, External Federation, and any 2FA provider. NOTE: The Starling 2FA service provider is automatically added to Safeguard for Privileged Passwords when you join Safeguard for Privileged Passwords to One Identity Starling. You cannot manually add, edit, or delete the Starling 2FA secondary authentication provider. For more information, see Starling.
Type	Types of identity and authentication providers follow. There are valid primary and secondary authentication combinations. For more information, see Authentication provider combinations. Active Directory LDAP External Federation Radius (use as a secondary authentication provider) Radius as Primary (use as a primary authentication provider) FIDO2
Description	Enter any descriptive information to use for administrative purposes.

Use these toolbar buttons to manage identity and authentication provider configurations.

Table 235: Identity and Authentication: Toolbar
Option	Description
Add	Add a identity or authentication provider configuration. For more information, see Adding identity and authentication providers.
Remove	Remove the selected identity or authentication provider. The provider can be deleted if there are no associated users.
Edit	Modify the selected identity or authentication provider.
Syncronize Now	Run the directory addition (incremental) synchronization process for directory users (identity providers) and directory user groups. All changes except for deletions are synced. The sync is queued by asset by provider and runs one directory sync on that asset at a time. You can run multiple syncs in parallel on different assets. This is the faster type of sync because deletions are not synced. A Tasks window displays the progress and outcome of the task. You can click Details to see more information or click Stop to cancel the task. In addition, this process runs through the discovery, if there are discovery rules and configurations set up. The directory deletion and addition (full) synchronization process must be run from the API (IdentityProviders/Synchronize).
Download Safeguard Federation Metadata	Download a copy of Safeguard for Privileged Passwords's Federation Metadata XML file. You will need this file to create the corresponding trust relationship on your STS server. The federation metadata XML file typically contains 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 the file has not been edited.
Refresh	Update the list of identity and authentication providers.

Authentication provider combinations

Some authentication providers can only be used for primary authentication and others can only support secondary authentication. See the table that follows for details on allowable authentication provider combinations.

The Starling 2FA service provider is automatically added to Safeguard for Privileged Passwords when you join Safeguard for Privileged Passwords to One Identity Starling. You cannot manually add, edit, or delete the Starling 2FA secondary authentication provider. For more information, see Starling.

It is the responsibility of either the Authorizer Administrator or the User Administrator to configure a user account to use two-factor authentication when logging into Safeguard for Privileged Passwords. For more information, see Requiring secondary authentication log in.

Using Local as the identity provider

Table 236: Allowable local identity provider combinations
Primary authentication	Secondary authentication
Local: The specified login name and password or SSH key will be used for authentication.	None Starling Radius Active Directory LDAP FIDO2
Certificate: The specified certificate thumbprint will be used for authentication.	None Starling Radius Active Directory LDAP FIDO2
External Federation: The specified email address or name claim will be used for authentication.	None Starling Radius Active Directory LDAP FIDO2
Radius: The specified login name will be used for authentication. NOTE: The Radius server may be configured to integrate with your company's existing identity and authentication solution and may provide its own means of two-factor authentication.	None Starling Active Directory LDAP FIDO2

Using Active Directory as the identity provider

Table 237: Allowable Active Directory identity provider combinations
Primary authentication	Secondary authentication
Active Directory: The samAccountName or X509 certificate will be used for authentication. NOTE: The user must authenticate against the domain from which their account exists.	None Starling Radius LDAP FIDO2
External Federation: The specified email address or name claim will be used for authentication.	None Starling Radius Active Directory LDAP FIDO2
Radius: The specified login name will be used for authentication. NOTE: The Radius server may be configured to integrate with your company's existing identity and authentication solution and may provide its own means of two-factor authentication.	None Starling Active Directory LDAP FIDO2

Using LDAP as the identity provider

Table 238: Allowable LDAP identity provider combinations
Primary authentication	Secondary authentication
LDAP: The specified username attribute will be used for authentication.	None Starling Radius Active Directory FIDO2
External Federation: The specified email address or name claim will be used for authentication.	None Starling Radius Active Directory LDAP FIDO2
Radius : The specified login name will be used for authentication. NOTE: The Radius server may be configured to integrate with your company's existing identity and authentication solution and may provide its own means of two-factor authentication.	None Starling Active Directory LDAP FIDO2

Using Starling as the identity provider

Table 239: Allowable Starling identity provider combinations
Primary authentication	Secondary authentication
Starling	None

Adding identity and authentication providers

It is the responsibility of the Appliance Administrator to add directories to Safeguard for use as identity and authentication providers.

If Active Directory forests have more than one domain, select the domain to use for identity and authentication and to display on the logon screen. It is the responsibility of an Appliance Administrator to create an External Federation or Radius provider to use for authentication.

To add identity and authentication providers

Go to Identity and Authentication:
- web client: Navigate to Safeguard Access | Identity and Authentication.
- desktop client: Navigate to Administrative Tools | Settings | External Integration | Identity and Authentication.
Click Add.
Click the provider:
- Active Directory: See Active Directory and LDAP settings.
- LDAP: See Active Directory and LDAP settings.
- External Federation: See External Federation settings.
- Radius: See Radius settings.
- FIDO2: See FIDO2 settings.
NOTE: Instead of being added via the Identity and Authentication page, a Starling Identity and Authentication provider is automatically added to Safeguard for Privileged Passwords when it is joined to Starling. For more information, see After joining Starling.

Active Directory and LDAP settings

Use the General tab to add the required service account information. The following table lists the properties and designates the properties for Active Directory and LDAP.

Table 240: Active Directory and LDAP: General tab properties
Property	Description
Product web client	The product name.
Forest Root Domain Name web client	Forest Root Domain Name.
Name	Unique name.
Service Account Domain Name (for Active Directory)	Enter the fully qualified Active Directory domain name, such as example.com. Do not enter the domain controller hostname, such as server.example.com; the domain controller's IP address, such as 10.10.10.10; or the NETBIOS domain name, such as EXAMPLE. The service account domain name is the name of the domain where the service account resides. Safeguard for Privileged Passwords uses DNS-SRV to resolve domain names to actual domain controllers.
Network Address (for LDAP)	Enter a network DNS name or the IP address of the LDAP server for Safeguard for Privileged Passwords to use to connect to the managed system over the network.
Service Account Name (for Active Directory)	Enter an account for Safeguard for Privileged Passwords to use for management tasks. If the account name matches an account name already linked to an identity provider, the provider is automatically assigned. If you want the password to be available for release, click Access Requests and select Enable Password Request from the details toolbar. To enable session access, select Enable Session Request. Add an account that has permission to read all of the domains and accounts that you want to manage with Safeguard for Privileged Passwords. Safeguard for Privileged Passwords is forest-aware. Using the service account you specify, Safeguard for Privileged Passwords automatically locates all of the domains in the forest and creates a directory object that represents the entire forest. The directory object will have the same name as the forest-root domain regardless of which account you specify. For more information, see About service accounts.
Service Account Distinguished Name (for LDAP)	Enter a fully qualified distinguished name (FQDN) for Safeguard for Privileged Passwords to use for management tasks. For example: cn=dev-sa,ou=people,dc=example,dc=com
Service Account Password	Enter the password Safeguard for Privileged Passwords uses to authenticate to this directory.
Description	Enter information about this external identity provider.
Connect	Click Connect to verify the credentials. If adding an Active Directory provider, all domains in the forest will be displayed. Choose which ones can be used for identity and authentication.
Available Domains for Identity and Authentication (for Active Directory)	All newly created Safeguard users that are imported from the directory user group will have their primary authentication provider set to use the directory domain from which their user originates. For an Active Directory forest with multiple domains, the domains must be marked as Available Domains for Identity and Authentication. Clearing the forest root domain will have undesired results when managing directory users and groups. For more information, see Adding a directory user group.
Advanced	Open to reveal the following synchronization settings:
Port (for LDAP)	Enter port 389 used for communication with the LDAP directory.
Use SSL Encryption	Select whether or not to use SSL when connecting to the LDAP server. You must have a valid SSL certificate and have the SSL's issuer certificate be trusted by Safeguard for Privileged Passwords. For more information, see Trusted CA Certificates.
Domain Controllers	For Active Directory, instead of having Safeguard for Privileged Passwords automatically find domain controllers from a DNS and CLDAP ping, you can specify domain controllers. In the desktop client, select Specify domain controllers. In the text box, enter the network addresses, which may be DNS names or IP addresses, separated by spaces, commas, or semicolons. For Active Directory, if you have multi-domains, you must provide a domain controller for every domain. Do not enter the domain itself. The domain controllers are used in the order entered. During the test connection from the Connection tab, if SPP does not find a domain controller in the list, the test connection fails and an error is returned. During a process, if one domain controller does not respond, the processes continue with the next domain controller. The non-responsive domain controller is blocked for about 5 minutes.
Sync additions every	Enter or select how often you want Safeguard for Privileged Passwords to synchronize directory additions (in minutes). This updates Safeguard for Privileged Passwords with any additions, or modifications that have been made to the directory objects, including group membership and user account attributes mapped to Safeguard for Privileged Passwords. Default: 15 minutes Range: Between 1 and 2147483647
Sync deletions every	Enter or select how often you want Safeguard for Privileged Passwords to synchronize directory deletions (in minutes). This updates Safeguard for Privileged Passwords with any deletions that have been made to the directory objects, including group membership and user account attributes mapped to Safeguard for Privileged Passwords. Default: 15 minutes Range: Between 1 and 2147483647

Attributes tab

On the Attributes tab, synchronize the attributes in Safeguard for Privileged Passwords to the directory schema attributes. The Attributes tab displays the default directory attributes that are mapped to the Safeguard for Privileged Passwords properties, such as the user's first name.

There are multiple valid schema mappings supported and you can modify its configuration, as needed. For example, the LDAP dialog, Attributes tab may display the Username as the cn <Display Name> or the uid <Username> based on your directory configuration.

To map the Safeguard for Privileged Passwords properties to different directory attributes

Browse to select one or more object classes for the users, computers, and groups categories, as applicable.

NOTE: You can use or remove the default object class.
If you do not want to use the default property, begin typing in the property box. Safeguard for Privileged Passwords' auto-complete feature immediately displays a list of attributes to choose. Safeguard for Privileged Passwords only allows you to select attributes that are valid for the object classes you have selected for users, groups, and computers.
Once you have set all the properties, click Apply.

The following table list the default directory attributes.

Table 241: Active Directory and LDAP: Attributes tab (defaults)
Safeguard for Privileged Passwords attribute	Directory attribute
Users
Object Class	Browse to select a class definition that defines the valid attributes for the user object class. Default: user for Active Directory, inetOrgPerson for LDAP
User Name	sAMAccountName for Active Directory, cn for LDAP
Password	userPassword for LDAP
First Name	givenName
Last Name	sn
Work Phone	telephoneNumber
Mobile Phone	mobile
Email	mail
Description	description
External Federation Authentication	The directory attribute used to match the email address claim or name claim value from the SAML Response of an external federation authentication request. Typically, this will be an attribute containing the user’s email address or other unique identifier used by the external Secure Token Service (STS). For both Active Directory and LDAP 2.4, this will default to the "mail" attribute. This is only used when processing members of a directory user group in which the group has been configured to use an External Federation provider as the primary authentication. For more information, see Adding a directory user group.
Radius Authentication	The directory attributed used to match the username value in an external Radius server that has been configured for either primary or secondary authentication. For Active Directory, this will default to using the samAccountName attribute. For LDAP 2.4, this will default to using the cn attribute. NOTE: This is only used when processing members of a directory user group in which the group has been configured to use Radius as either the primary or secondary authentication provider. For more information, see Adding a directory user group.
Managed Objects	The directory attribute used when automatically associating existing managed Accounts to users of a directory user group as linked accounts. Defaults: For Active Directory, this defaults to managedObjects. However, you may want to use the directReports attribute based on where you have the information stored in Active Directory. For LDAP 2.4, this defaults to the seeAlso attribute. When choosing an attribute, it must exist on the user itself and contain one or more Distinguished Name values of other directory user objects. For example, you would not want to use the owner attribute in LDAP 2.4, as the direction of the relationship is going the wrong way. You would instead want an owns attribute to exist on the user such as the default seeAlso attribute. For more information, see Adding a directory user group.
Groups
Object Class	Browse to select a class definition that defines the valid attributes for the group object class. Default: group for Active Directory, groupOfNames for LDAP
Name	sAMAccountName for Active Directory, cn for LDAP
Member	member
Description	description

External Federation settings

One Identity Safeguard for Privileged Passwords supports the SAML 2.0 Web Browser SSO Profile, allowing you to configure federated authentication with many different 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. When an end user logs in, 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.

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.

To add external federation:

In the External Federation dialog, supply the following information:
1. Name: The unique name assigned to the external federation service provider. The name is for administrative purposes only and will not be seen by the end users.
2. Description: Enter any text. The text is seen only here and used for administrative purposes.
3. 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
4. Federation Metadata File: Click Browse to select the STS federation metadata xml file.
Click Download Safeguard for Privileged Passwords Metadata File: You will need this file to create the corresponding trust relationship on your STS server. The federation metadata XML file typically contains 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 the file has not been edited.Also see: How do I create a relying party trust for the STS.

Radius settings

Create and configure a Radius server for use as either a primary authentication provider or secondary authentication provider. To use a Radius server for both primary and secondary authentication, you will need to create two authentication providers. The steps to create Radius as a primary provider or secondary provider follow:

In the Radius dialog, supply the following information:
1. Name: The unique display name. When creating the Radius provider for primary authentication, this name value will be displayed in the drop-down list on the login page.
2. Description: Enter any text. The text is seen only here and used for administrative purposes.
3. Type: Choose As Primary Authentication or As Secondary Authentication.
4. Server Address: Enter a network DNS name or the IP address used to connect to the server over the network.
5. Secondary Server Address: (Optional) Enter a network DNS name or the IP address for an additional or redundant server.
6. Shared Secret: Enter the server's secret key. Click to show the server's secret key.
7. Port: Enter the port number that the Radius server uses to listen for authentication requests. The default is port 1812.
8. Timeout: Specify how long to wait before a Radius authentication request times out. The default is 20 seconds.
9. PreAuthenticate for Challenge/Response: If selected, an Access-Request call containing only the User-Name is sent to the Radius server prior to the user's authentication attempt. This is done to inform the Radius server of the user's identity so it can possibly begin the authentication process by starting a challenge/response cycle. This may be required to seed the user's state data. In addition, the Radius server's response may include a login message that is to be displayed, which is specific to that user.
  
  If the Radius server is not configured to respond with an Access-Challenge, then this will cause the log in to fail and the user will be unable to proceed. This setting is only applicable when using Radius as a secondary authentication provider. The setting has no effect if enabled on a primary authentication provider.
10. Always Mask User Input: If selected, the text box that the user enters their one-time password, or other challenge required by the Radius server, will always be a password style text box in which the user's input is masked and appears as a series of dots, not as clear text. This may be desired when the challenge is not only a one-time password, but also contains the user's PIN. This will prevent any passer-by from seeing the private information. Note, however, that when this setting is enabled, it will also override the Prompt attribute of the Radius server's Access-Challenge response, such that the user's input will always be masked.
Click OK.

NOTE: When Safeguard for Privileged Passwords attempts to authenticate a user against the Radius server, it will always include the NAS-Identifier Radius attribute with a value set to the appliance ID. There is no setting to turn this on or off, nor specify a custom value.

FIDO2 settings

Create and configure FIDO2 for use as a secondary authentication provider.

In the FIDO2 dialog, provide the following settings:
1. Name: The unique name assigned to the provider. The name is for administrative purposes only and will not be seen by the end users.
2. Domain Suffix: This must be a DNS name that identifies the appliance. Typically, this will be the DNS name used to access Safeguard. It cannot be an IP address. The value is a a domain string identifying the WebAuthn Relying Party for which the registration or authentication ceremony is performed.
  
  A public key credential can only be used for authentication with the same entity (identified by this value) it was registered with. However, this value can be a registerable domain suffix of what appears in the user’s browser when registering. For example, you could enter contoso.com to register against a server at https://www.contoso.com or https://node1.contoso.com. Later, you can use the same authenticator security key to authenticate at either of the locations.
3. Description: Enter any text. The text is seen only here and used for administrative purposes.
Click OK.

SSH Key Management settings

desktop client only

SSH authorization keys are managed to maximize security over automated processes as well as sign-on by system administrators, power users, and others who use SSH keys for access. Safeguard for Privileged Passwords (SPP) performs the following.

NOTE:Safeguard for Privileged Passwords does not currently manage the options for an authorized key. If an imported key has any options configured in the authorized keys file on the asset, these options will not be preserved when the key is rotated by Safeguard for Privileged Passwords.

SPP provisions keys by creating a new key pair associated with a managed account. Any of the following methods can be used.
- An authorized key is added in the target account on the target host. A managed account can have more than one authorized key, however only one key can be managed by SPP at a time.
- An SSH key sync group is created for an SSH key pair. The new key is generated for the sync group and configured for each of the synced accounts on the target host. All accounts in the SSH key sync group synchronize the SSH Key so the same key can be used to log into all systems.
- A legacy SSH identity key is uploaded. The legacy SSH key is entrusted to SPP. When legacy SSH keys are exposed, SPP rotates them after they are checked in. SPP may rotate the keys after they are checked in if the Entitlement Policy | Access Configuration option specifies Change SSH Key after check-in.
SPP requests and rotates SSH keys based on the access request policy (key and session) as well as via A2A when A2A is configured to request and retrieve SSH keys. Rotation is profile-based. Each managed account can have a single SSH key.

Supported implementations

SSH implementations supported include:

Access requests provide SSH identity keys include OpenSSH, SSH2, and PuTTY format.
For management, SPP supports OpenSSH file formats and Tectia

Supported key types and key lengths

SPP supports RSA, Ed25519, ECDSA, and DSA algorithms for SSH identity keys. Supported key lengths follow:

RSA: 1024, 2048, 4096, and 8192-bit

Larger key sizes take longer to generate. In particular, a key size of 8192-bits may take several minutes.
DSA: fixed to 1024-bits
Ed25519: fixed to 32 bits
ECDSA: 256, 384, and 521 bits

Unsupported algorithms and key strings

SPP reads each line when parsing an authorized_keys file and attempts to extract the data. If a line is properly formatted according to the specification, SPP will report it as a discovered identity key. SPP recognizes keys with either the RSA or DSA algorithm. Other valid key types are still discovered by SPP and are identified as the Key Type of Unknown on the Discovered SSH Keys properties grid.

If a line is not properly formatted, the data will be skipped and a warning with the number of invalid lines will be included on the Toolbox | Task pane. Further details, including a copy of each invalid line, displays on the Operations tab. For more information, see Viewing task status.

Management

It is the responsibility of the Appliance Administrator to manage the access request and SSH key passphrase management services.

SSH key change, check, and discovery can be toggled on or off. For more information, see Enable or disable access request and services.

Navigate to Administrative Tools | Settings | SSH Key Management.

Table 242: SSH Key Management settings
Setting	Description
Change SSH Key settings	You can add, update, schedule, or remove SSH Key Change settings.
Check SSH Key settings	You can add, update, schedule, or remove SSH Key Check settings.
Discover SSH Key settings	You can add, update, schedule, or remove SSH Key Discovery jobs.
SSH Key Sync Groups settings	You can add, update, schedule, or remove SSH Key Sync Group settings. The Asset Administrator or a partition's delegated administrator defines the SSH key sync group for an SSH key pair. The new key is generated for the sync group and configured for each of the synced accounts on the target host. All accounts in the SSH key sync group synchronize so the same key can be used to log into all systems.

Seleccione su producto:

Con el fin de ofrecerle un mejor servicio, complete el campo Motivo del chat:

Soluciones recomendadas para su problema

Safeguard for Privileged Passwords On Demand Hosted - Administration Guide

Identity and Authentication