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.
- 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.
-
OneLogin MFA: See OneLogin MFA settings.
-
SCIM: See SCIM settings.
Active Directory and LDAP settingsUse 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.
| Property | Description |
|---|---|
|
Product |
The product name. |
|
Forest Root Domain Name |
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. SPP 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 SPP to use to connect to the managed system over the network. |
| Service Account Name (for Active Directory) |
Enter an account for SPP to use for management tasks. If the Active Directory has previously been added as an asset, you can use the same service account, but you will need to know the current password of the account. Once added, you can have SPP manage the service account and periodically change the password without effecting the connectivity. For identity and authentication purposes, the service account only requires read access to the Active Directory domain(s). The service account does not require write access. Typically, any member of the default Domain Users group is sufficient. The service account must be able to read the following attributes on all users:
In addition, the service account requires read access to other domain level attributes:
Lastly, the service account must be able to enumerate the Active Directory User object class hierarchy to build the complete attribute schema. |
| Service Account Distinguished Name (for LDAP) |
Enter a fully qualified distinguished name (FQDN) for SPP to use for management tasks. For example: cn=dev-sa,ou=people,dc=example,dc=com |
| Service Account Password |
Enter the password SPP 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 server. You must have a valid SSL certificate and have the SSL's issuer certificate be trusted by SPP. For more information, see Trusted CA Certificates. |
|
Domain Controllers |
For Active Directory, instead of having SPP automatically find domain controllers from a DNS and CLDAP ping, you can specify domain controllers. |
| Sync additions every |
Enter or select how often you want SPP to synchronize directory additions (in minutes). This updates SPP with any additions, or modifications that have been made to the directory objects, including group membership and user account attributes mapped to SPP. Default: 15 minutes Range: Between 1 and 2147483647 |
| Sync deletions every |
Enter or select how often you want SPP to synchronize directory deletions (in minutes). This updates SPP with any deletions that have been made to the directory objects, including group membership and user account attributes mapped to SPP. Default: 15 minutes Range: Between 1 and 2147483647 |
Attributes tab
On the Attributes tab, synchronize the attributes in SPP to the directory schema attributes. The Attributes tab displays the default directory attributes that are mapped to the SPP 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 SPP 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. SPP' auto-complete feature immediately displays a list of attributes to choose. SPP 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.
| SPP 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 |
|
| |
| Description |
description |
|
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. | |
|
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. | |
|
The directory attribute used when automatically associating existing managed Accounts to users of a directory user group as linked accounts. Defaults:
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. | |
|
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 |
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 SPP user to be associated with the federated user. 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 SPP and logged in.
NOTE: Additional two-factor authentication can be assigned to the associated SPP user to have the user authenticate again after being redirected back from the external STS.
To use external federation, you must first download a copy of, or have the URL to the federation metadata XML of your STS. For example, in Microsoft AD FS, you can download the federation metadata XML from: https://<adfs server>/FederationMetadata/2007-06/FederationMetadata.xml. Or if the Safeguard for Privileged Passwords appliance can directly access that URL, it can be used as well when creating the provider.
To add external federation:
- In the External Federation dialog, supply the following information:
-
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.
-
Description: Enter any text. The text is seen only here and used for administrative purposes.
-
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.
-
Federation Metadata: Select one of the following options:
-
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.
-
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.
-
-
Application ID Override: If needed, override the Issuer name value that is sent in a SAML2 AuthnRequest to match the ID of the relying party application defined in the IdP.
For example, when creating an App registration in Microsoft's Azure AD, you would copy the Application ID URI value into this field.
-
Login Provider ID: A system generated identifier that can be used when integrating with third-party or other custom software or automation scripts. For information on accessing the SPP API, see Using the API.
NOTE: When integrating with Safeguard for Privileged Sessions, you can effectively enable Single Sign-On (SSO) between the two applications by creating and using the same SAML2 external federation login provider in both. This Login Provider ID value from SPP must then be entered into the Safeguard for Privileged Sessions Script Reference field when creating the matching SAML2 login method.
-
When the Require User to Always Authenticate check box is selected, the user will always be required to enter their credentials on the external provider, regardless of whether they are already logged in. This may be seen as negating one of the features of Single Sign-On, and therefore can be turned off. Or it may be considered a more secure option and turned on.
-
- Click Download SPP 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.
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:
-
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.
- Description: Enter any text. The text is seen only here and used for administrative purposes.
-
Type: Choose As Primary Authentication or As Secondary Authentication.
- Server Address: Enter a network DNS name or the IP address used to connect to the server over the network.
- Secondary Server Address: (Optional) Enter a network DNS name or the IP address for an additional or redundant server.
- Shared Secret: Enter the server's secret key. Click
to show the server's secret key.
- Port: Enter the port number that the Radius server uses to listen for authentication requests. The default is port 1812.
- Timeout: Specify how long to wait before a Radius authentication request times out. The default is 20 seconds.
-
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.
- 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 SPP 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.
Create and configure FIDO2 for use as a secondary authentication provider.
- In the FIDO2 dialog, provide the following settings:
- Name: The unique name assigned to the provider. The name is for administrative purposes only and will not be seen by the end users.
-
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.
- Description: Enter any text. The text is seen only here and used for administrative purposes.
- Click OK.
Create and configure OneLogin MFA as a secondary authentication provider.
IMPORTANT: Before configuring OneLogin as an authentication provider, you must first purchase a subscription with OneLogin.com and create an API credential to be used by SPP. For information on OneLogin, see OneLogin documentation.
NOTE: The OneLogin administrative site is used to configure the desired Authentication Factors, security policies, and users. SPP currently supports the following secondary authentication methods:
-
OneLogin Protect
-
Authenticator
-
SMS
-
Email
-
In the OneLogin MFA dialog, provide the following settings:
-
Name: The unique name assigned to the provider. The name is for administrative purposes only and will not be seen by the end users (up to 50 characters).
-
Description: Enter any text. The text is seen only here and used for administrative purposes (up to 255 characters).
-
DNS Host Name: Enter the complete OneLogin DNS host name of your subscription; for example, <subdomain>.onelogin.com.
-
Client ID: Enter the API Client ID created in OneLogin. SPP requires that the Manage All permission is used for the API credentials created in OneLogin. For more information, see Working with API Credentials.
-
Client Secret: Enter the API Client Secret created in OneLogin. SPP requires that the Manage All permission is used for the API credentials created in OneLogin. For more information, see Working with API Credentials.
-
-
Click OK.
NOTE: After you have configured OneLogin MFA as an authentication provider, when adding individual users to SPP you need to ensure the email address configured for that user is identical to what is in OneLogin. After initial configuration, the user information in OneLogin can be updated if needed without impacting the connection with SPP.
Create and configure System for Cross-Domain Identity Management (SCIM) provisioning via Azure Active Directory or OneLogin.
-
In the SCIM dialog, provide the following settings:
-
Name: The unique name assigned to the provider. The name is for administrative purposes only and will not be seen by the end users.
-
Description: Enter any text. The text is seen only here and used for administrative purposes.
-
-
Click OK to save the information.
-
On the Identity and Authentication pane, select the name of the newly created SCIM provider and click
.
-
Use the General tab to provide the following information:
Table 28: SCIM: General tab Setting
Description
Name
The unique name assigned to the provider. The name is for administrative purposes only and will not be seen by the end users.
Description
Enter any text. The text is seen only here and used for administrative purposes.
Tenant URL
This is the URL for the tenant that you specified in Azure Active Directory. Use the
button to copy the URL.
Application Token
This is the token required to connect with Azure Active Directory and will needed to be added to you SCIM provisioning configuration in Azure Active Directory. Use the Generate New Token button to populate this field and provide a
Application Token Set
This is the date (month, day, year) that the token was last generated.
Generate New Token
Click this button to generate a new token. Once generated, the token text will appear in the Application Token field.
-
Use the Authentication tab to provide the following information:
Table 29: SCIM: Authentication tab Setting
Description
Default Primary Authentication Provider
(Optional) Select a primary authentication provider.
Default Secondary Authentication Provider
(Optional) Select a secondary authentication provider.
-
On the Permissions tab, select any of the administrative permissions and/or the Personal Password Vault permission to be assigned to each member of the SCIM User Group. For each group member, the selected permissions of the group will be combined with any existing permissions that have already been granted explicitly or by some other Group to which they belong. For more information, see the Permissions tab (add user).
During synchronization of a SCIM User Group, a user may be identified as no longer being a member. In this case, the selected permissions of the SCIM User Group are removed from the user unless the user is also a member of another Group from which they inherit the permission. SPP does not keep track of nor distinguish between an explicitly assigned permission versus one that was assigned via a Group. -
IMPORTANT: The Personal Password Vault permission, like any other permission, can be set explicitly on a user or inherited from a Group. If a user with the Personal Password Vault permission stores one or more personal passwords and then later has the permission revoked, either explicitly or by having been removed from all Groups from which they inherited it, the user will no longer be able to access
Personal Password Vault features. But the user’s data within the vault will still be maintained. If at any point the user is granted the Personal Password Vault permission again, they regain access to all of their existing data.
-
Click OK.