Skip to main content

Add Active Directory data store

In the SecureAuth® Identity Platform, you can add an Active Directory data store to assert or manage user identity information.

Prerequisites

  • Identity Platform release 24.04 or later, cloud or hybrid deployment

  • SecureAuth Connector installed and connected for Identity Platform cloud deploymentSecureAuth Connector installation

  • Active Directory data store

Process

There are two parts to adding a data store in the Identity Platform — (1) adding the data store and (2) mapping the data store properties.

Step 1 of 2: Add an Active Directory data store

The first part of adding an Active Directory data store is configuring the data store name, connections, credentials, and search attributes.

  1. On the left side of the Identity Platform page, click Data Stores.

  2. Select the Data Stores tab.

  3. Click Add a Data Store.

  4. On the Add a Data Store page, start with the following configurations, depending on your deployment type.

    ad_data_store_03.png

    Settings in hybrid deployments

    ad_data_store_03_cloud.png

    Settings in cloud deployments

    Data Store Name

    Set the name of the data store.

    Connection Type

    Set to Active Directory.

    Use this directory for user membership validation

    Appears only in hybrid deployments

    Use one of the following options:

    • On – Enable membership validation; use the directory to search for the user's membership in a user group.

      This means the directory is a Membership Store, containing the password to validate with the username.

      After the data store is saved, this field is the Membership Store label shown on the View Summary.

      60556399.png

      A common use case for a Membership Store would be to have a directory with username and password information (and maybe some profile information), and then have a second directory or database used to store and access data that the Identity Platform writes to the directory (such as device recognition, device enrollment, push notification tokens, and so on).

    • Off – Disable membership validation; use the directory to search only for the user profile information.

      This means the directory is only used to find the username and profile information (such as phone number, email address, device recognition profiles, OATH tokens, and so on).

    Group of connectors

    Appears only in cloud deployments

    Assign this data store to a SecureAuth Connector group.

    To learn more about Connector groups, see Manage SecureAuth Connector groups.

  5. In the Connection String section, set the connection string for the domain to the Active Directory.

    Note

    For information about how to identify the corporate connection string, see the external article How can I figure out my LDAP connection string?

     

    Source Domain

    The domain for your directory to build the connection string in the next field.

    For example: acme.com

    Connection String

    The value in this field is the connection string auto-populated by the Source Domain field and contains domain and generic values for DC=directory, DC=domain (unless a custom connection string is manually entered).

    For example, the result would be: LDAP://acme.com/DC=acme,DC=com

    advanced mode

    To manually enter the connection string, click the advanced mode link.

    ad_data_store_05.png

  6. In the Credentials section, provide the log in credentials to access the Active Directory data store.

    Enter Service Account Credentials

    With this option, enter the following fields:

    • Service Account Login – Email address for the service account login

    • Password – Password for the service account login

    Test the data store connection by clicking Test Credentials.

    ad_data_store_06_2202.png

    Use CyberArk Vault for Credentials

    With this option, enter at least one field for the service account login:

    • Username – User name of machine to be scanned by CyberArk Application Identity Manger (AIM). This information appears on the Account Details page of the CyberArk Password Vault Web Access (PVWA) Admin Console

    • Address – Address of machine to be scanned by AIM

    • Safe – Name of Access Control Safe where credentials are stored

    • Folder – Name of folder where account resides (by default, it its the root folder)

    • Object – Unique identifier Object name for the account

    Test the data store connection by clicking Test Credentials.

    ad_data_store_07_2202.png

  7. In the SecureAuth IWA Service Settings section, define the settings to use Windows SSO for your resources.

    Note

    This option is available only in cloud deployments.

    For more information about Windows SSO integration, see Windows SSO integration with Active Directory.

    Allow Windows SSO integration

    You can use Windows SSO to allow secure access to your resources. Move the slider:

    • On – Allow Windows SSO integration.

      The Identity Platform connects with the SecureAuth IWA service to validate user credentials and allow Windows SSO access to resources.

    • Off – Do not allow Windows SSO integration.

      The Identity Platform uses the authentication policy login workflow to allow access to resources.

    Active Directory Domain

    The AD data store domain for this AD service account.

    Service Account Password

    Password for the SPN-assigned AD service account.

    Note

    If the password changes in the Active Directory for this SPN-assigned AD service account, you must update the password in this field.

    The password must be in sync in both places to maintain a Windows SSO connection between the AD data store and SecureAuth IWA service.

    Service Account Name

    Name of the AD service account used to establish a connection between the AD data store and the SecureAuth IWA service.

    The AD service account must have an assigned Service Provider Name (SPN). For more information, see Configure Active Directory service account for SecureAuth IWA service.

    It is recommended to use a different AD service account with least privilege access for Windows SSO and SecureAuth IWA service.

    This optional field is not validated in the Identity Platform. Use this field to help you remember the name of the service account used for the Windows SSO integration with the Identity Platform.

    ad_data_store_004_2104b.png

  8. In the Search Filter section, define the search attribute to find a user account.

    Search Attribute

    Set the search attribute for the search filter.

    Available options are: sAMAccountName or userPrincipalName (UPN)

    Search Filter

    Value is auto-populated in this field.

    Example of search filter or sAMAccountName: (&(sAMAccountName=%v)(objectclass=*))

    Example of search filter for userPrincipalName (UPN): (&(userPrincipalName=%v)(objectclass=user)(objectcategory=person))

    advanced mode

    To enter a custom search filter, click the advanced mode link.

    ad_data_store_08.png

  9. In the Advanced Settings section, define the attribute to encrypt user profile data.

    Encryption Attribute

    The unique directory value inherits the default value from the Username attribute field to encrypt user profile data.

    For example: sAMAccountName

    Validate User Type

    Choose how to validate usernames and passwords in Active Directory:

    • Bind – Make a direct call to the directory to validate the username and password (faster search)

    • Search – Use the search function to find and validate a username and password (slower search)

    Connection Mode

    Select how the Identity Platform and the directory connect:

    • Secure – Use a secure LDAP connection on Port 389, using NTLMv2

    • SSL – Use a secure connection on Port 636, but uses Secure Socket Layer technology, which relies on certificates

    • Standard – Use a standard LDAP connection on Port 389 that uses basic authentication (plain text)

    Allow Anonymous Queries

    Move the slider to indicate whether non-authenticated users should also be granted access to browse the protected resource.

    In most cases, this setting should be off; unless using a generic LDAP directory.

    Allow Advanced User Checks

    Move the slider to indicate whether to allow the Identity Platform to search this directory for more user information. This is useful in a scenario in which a user account is locked.

    Disable Nested Groups

    Move this slider ON to indicate that the Identity Platform will only search main group memberships and ignore nested groups.

    This will improve performance.

    ad_data_store_09.png

  10. Click Continue.

    The Map Data Store Properties page opens.

Step 2 of 2: Map the Active Directory data store properties

The second part of adding an Active Directory data store is mapping the data store properties.

Each user is uniquely identified by profile data that is read from or stored in your directories and databases.

The Identity Platform does not store user profiles, so your organizational directory attributes must be mapped to Active Directory profile properties to be read and updated in the directory by the Identity Platform. The directory attribute mapped to the property is retrieved only when required for authentication or assertion purposes.

For more information about how data store profile properties are stored for on-premises, hybrid, or cloud Identity Platform deployments, see List of stored profile field properties.List of stored profile field properties

Note

Each mapped profile property should have its own directory attribute. It is not recommended to map the same directory attribute to more than one property.

For example, the mobile attribute is mapped to Phone 2, so you would use a different attribute for Phone 3.

Refer to the following table about attribute mapping and other information.

Column

Description

Name and Active Directory Field

Map the following required Active Directory field attributes:

  • First Name. For example, givenName

  • Last Name. For example, sn

  • Groups. For example, memberOf

  • Email 1 (Work). For example, mail

Map the following recommended Active Directory field attributes:

  • Phone 1 (Work). For example, telephoneNumber

  • Phone 2 (Mobile). For example, mobile

Data Format

For mapped profile properties (for example, Push Notification Tokens, Behavioral Biometrics, and Device Profiles), specify the Data Format to define how data is encrypted and stored in the directory.

For cloud deployments, certain profile properties (for example, Push Notification Tokens, Behavioral Biometrics, and Device Profiles) are generated and used by SecureAuth, and stored in the SecureAuth cloud database.

Selection options listed below may vary depending on your Identity Platform deployment:

  • plain text – store data as regular, readable text (default)

  • standard encryption – store and encrypt data using RSA encryption

  • advanced encryption – store and encrypt data using AES encryption

  • standard hash – store and encrypt data using SHA-256 hash

  • plain binary – store data as a binary representation of the data (uses a .NET library to make it binary – may not be readable by all applications)

  • json – store data in a universal format, readable by all applications (similar to plain text)

  • encrypted json – stored as JSON, with values inside encrypted using AES encryption

Writable

Define whether a profile property can be writable (select check box) or not writable (cleared check box) according to your Active Directory configuration.

For example, if you want to allow users to update their personal email address on the self-services page, select the Writable check box.

Some profile properties are disabled by default in the system; for example, biometric profile properties used by SecureAuth cloud services.

Use Cloud Storage

Available only in cloud deployments.

Store values in Aux IDs to the cloud profile database. When you select this check box, enter a description about the purpose of the Aux ID.

To learn more, see How to set up Aux ID for cloud storage.

In this section:
See also: