Skip to main content

Add LDAP data store

In the SecureAuth® Identity Platform, you can add an LDAP data store to assert or manage user identity information. You can use the Generic LDAP data store option to integrate an LDAP type of data store that is not listed as an out-of-the-box option.

Prerequisites

  • Identity Platform version 20.06 or later

  • SecureAuth Connector installed and connected for Identity Platform cloud deployments

  • LDAP data store (this can be for any type of LDAP directory)

  • Service account for an LDAP data store with read access (and optional write access) for the Identity Platform

Data store limitations

Note the following issues with LDAP data stores:

  • SSL connection – Depending on the type of LDAP directory and the directory setup, the SSL connection might or might not work.

  • Data store support – Take note that all data format types might not work for all property and attribute mappings. Make sure to test the storage and usage before releasing to users.

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 LDAP data store

  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. Set the Data Store Name and select the Connection Type as Generic LDAP.

    60563905.png

  5. For the Use this directory for user membership validation slider, 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.

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

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

    60563907.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).

  6. In the Connection String section, set the connection string for the domain to the LDAP 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: initech.local

    For an IP address in the connection string, use the advanced mode link.

    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 you manually enter a custom connection string).

    For example, the result would be: LDAP://initech.local/DC=initech,DC=local

    Note

    This field does not auto-populate correctly for IP addresses. Use the advanced mode link.

    advanced mode

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

    For example, for an IP address the result would be: LDAP://198.51.100.02/dc=initech,dc=local

    60563906.png

  7. In the Credentials section, provide the log in credentials to access the LDAP 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

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

    60568839.png

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

    Search Attribute

    Set the search attribute. For example, uid, sAMAccountName or userPrincipalName (UPN).

    Search Filter

    Value is auto-populated in this field.

    Example search filter for uid: (&(uid=%v)(objectclass=*))

    advanced mode

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

    60563909.png

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

    Validate User Type

    Choose how to validate usernames and passwords in the LDAP 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:

    • 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 an 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.

    60563910.png

  10. Click Continue.

    The Map Data Store Properties page opens.

    60563911.png

Step 2 of 2: Map LDAP attributes to profile properties

The second part of adding an LDAP data store is mapping the directory 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 LDAP directory attributes must be mapped to the Identity Platform profile properties to be read and updated in the directory by the Identity Platform. The LDAP directory attribute mapped to the profile 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.

Note

Each mapped profile property must have its own directory attribute. You cannot 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.

  1. On the Map Data Stores Properties page, define the required attributes in the LDAP directory field that corresponds to each profile property required by your environment and the Identity Platform. The required attributes are:

    • First Name

    • Last Name

    • Groups

      Note

      The Identity Platform supports POSIX groups. Map the LDAP Groups field attribute as posixGroups.

      To use a different groups search filter, edit the GroupsearchFilter in the web.config file. For Identity Platform cloud deployments, contact SecureAuth Support.

    • Email 1 (Work)

  2. Define the recommended attributes in the LDAP directory field that corresponds to each profile property. The recommended attributes are:

    • Phone 1 (Work)

    • Phone 2 (Mobile)

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

    The selection options are listed below (options vary depending on your Identity Platform deployment):

    • 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

    • 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

  4. Click Save Data Store.

    The LDAP data store you just added appears in the User Data Stores list.

In this section:
See also: