Integration with LDAP¶

DataRobot can optionally be integrated with an external LDAP server.

The following LDAP servers are supported:

• Microsoft Active Directory
• OpenLDAP
• FreeIPA

To configure these options, refer to the Tuning DataRobot Environment Variables section of this guide.

LDAP authentication types¶

DataRobot supports two authentication types: ldap and ldapsearch.

Authentication Type ldap¶

To use ldap, all DataRobot users must belong to one level of an LDAP node. This is less flexible than ldapsearch, but there is no need to store LDAP credentials in the configuration.

The authentication flow is as follows:

1. User enters a username in the UI.
2. ldap backend interpolates dist name template (replaces $username with an actual username) and gets DN (distinguished name) of the user.
3. ldap backend tries to bind to LDAP server using the DN above and the password entered by the user.
4. If DataRobot fails to bind, it assumes the username or password is incorrect.
5. If the bind process was successful, DataRobot optionally retrieves LDAP attrs (using the bound LDAP session) for impersonation.

Limitations:

1. Limited by dist name template and can't authenticate users from different organization units.
2. Attribute that's not a part of DN can't be used as a DataRobot username (e.g., if corporate DN is uid=john.smith,cn=users,cn=accounts,dc=datarobot,dc=com, DataRobot can only use john.smith as a username).

Authentication Type ldapsearch¶

Backend ldapsearch does not make any assumptions on LDAP structure and is more flexible than ldap authentication type, but requires more configuration options to be set. This requires LDAP credentials to be stored in the configuration.

The authentication flow is as follows:

1. User enters a username in the UI.
2. ldapsearch backend performs an LDAP query using a predefined query pattern (e.g. (uid=$username), (sAMAccount=$username), (email=$username) or ((cn=$username)|(foo=bar))) - DataRobot takes BIND_DN / BIND_PASSWORD from the configuration for making this query.
3. If exactly one user is found, ldapsearch takes the appropriate DN from the search results and tries to bind using the password entered by the user to check if the password is correct.
4. If USER_AUTH_LDAP_ORGANIZATION_NAME_ACCOUNT_ATTRIBUTE is configured, the backend tries to find an organization the user belongs to using the config value as an attribute name. If the attribute is set in the LDAP user profile, the user is mapped to the organization on the DataRobot side.
5. If the USER_AUTH_LDAP_GROUP_SEARCH_BASE_DN config value is specified, the backend tries to map the user group on AD with a DataRobot group by making another request. The query for the group search looks like (&(objectClass=groupOfNames)( | (member=cn={username},{base_dn})(member=uid={username},{base_dn}))).

If the backend found a group with the same name as a group in the DR database, the logged-in user is automatically assigned to this group. Also, it's important to mention when the user is part of an organization, this is also considered during group mapping, i.e., the group on the DR side must also be within the organization.

LDAP configuration options¶

Common options¶

• USER_AUTH_TYPE - ldap or ldapsearch
• USER_AUTH_LDAP_URI - protocol, host, and port, e.g., ldap://1.2.3.4:389 (protocol can be ldap, ldaps or ldapi)
• USER_AUTH_LDAP_REQUIRED_GROUP (optional) - users outside of this group won't have access to DataRobot, e.g., CN=datarobot-group,OU=Groups,DC=example,DC=org
• USER_AUTH_LDAP_MAPPING (optional) - account attribute mapping rules for LDAP integration. USER_AUTH_LDAP_MAPPING={"<DR_USER_PROFILE_ATTRIBUTE>": "<LDAP_USER_PROFILE_ATTRIBUTE>"}
• USER_AUTH_LDAP_GLOBAL_OPTIONS (optional) - JSON-encoded dict (usually used for advanced TLS configuration)
• USER_AUTH_LDAP_CONNECTION_OPTIONS (optional) - JSON-encoded dict (usually used for advanced TLS configuration)

Options for ldap authentication type¶

• USER_AUTH_LDAP_DIST_NAME_TEMPLATE - template for converting DataRobot usernames into LDAP DN, e.g., CN=$username,OU=Users,DC=example,DC=org

Options for ldapsearch authentication type¶

• USER_AUTH_LDAP_BIND_DN - DN of the service LDAP account
• USER_AUTH_LDAP_BIND_PASSWORD - password for the service LDAP account
• USER_AUTH_LDAP_SEARCH_BASE_DN - LDAP node that contains all the DR users, (e.g., OU=Users,DC=example,DC=org)
• USER_AUTH_LDAP_SEARCH_SCOPE - LDAP search scope (ONELEVEL or SUBTREE, default is SUBTREE)
• USER_AUTH_LDAP_SEARCH_FILTER - LDAP search query (default: (cn=$username), LDAP = (&(objectClass=user)(uid=$username)), AD = (&(objectClass=user)(sAMAccountName=$username)))
• USER_AUTH_LDAP_ORGANIZATION_NAME_ACCOUNT_ATTRIBUTE - the organization name attribute in the LDAP user profile. If not configured, user organization mapping isn't performed.

Options for S3 impersonation¶

See User-Specific IAM Role Usage for more details on S3 Impersonation

• ENABLE_S3_ROLE_ASSUMPTION - Bool value to enable S3 role assumption (default: False)
• USER_AUTH_LDAP_ATTR["s3_role_arns"] - The name of the LDAP attribute containing zero or more Amazon Resource Name(s) (ARN) that should be utilized when ingesting data for the DataRobot user. When multiple ARNs are specified for a user, they're tried iteratively until DataRobot locates one with access to the object.
• S3_ROLE_ASSUMPTION_DEFAULT - An optional ARN to add to the user-specific list of ARNs supplied via ldap
• S3_ROLE_ASSUMPTION_SESSION_PREFIX - String prefix to add to AWS session names when assuming roles for ingest; see Assumed Session Names for more details (default: DataRobot-APP)

Email notifications for LDAP users¶

Use the USER_AUTH_LDAP_MAPPING["email_address"] configuration option to configure DataRobot to send email notifications to users with LDAP accounts. DataRobot uses this mapping to find the email address of the user in the corresponding LDAP record.

For example, users in the FreeIPA directory have a mail attribute, so in order to configure DataRobot to use that, configure the app in the following way:

# helm chart values snippet
core:
  config_env_vars:
        USER_AUTH_LDAP_MAPPING: '{"email_address":"mail"}' 

With this configuration, DataRobot reads the email address found in the mail attribute in the directory and uses it for sending notifications, such as the email about autopilot completion.

Note: Emails in DataRobot with LDAP authentication are read-only, meaning users aren't able to edit their email address from the DataRobot Application. Email is synchronized with the directory each time the user signs into the application and the only way to change a user's email address is to change it in the LDAP directory and re-log in.

Initial users for LDAP deployments¶

DataRobot Helm charts automatically create an initial user (admin@datarobot.com) when installing the chart. When the Generative AI service is enabled, additional service users are created. For LDAP integration, it may be necessary to define a list of users to allow the setup to proceed. This can be done by setting the following variable:

USER_AUTH_SERVICE_USERNAMES: localadmin@datarobot.com,admin@datarobot.com,genai@datarobot.com,genai-admin@datarobot.com 

Helm chart values example¶

To enable DataRobot LDAP integration, one needs to:

• Update core.config_env_vars:

# helm chart values snippet
core:
  config_env_vars:
        USER_AUTH_TYPE: ldapsearch
        USER_AUTH_LDAP_URI: ldap://1.2.3.4:389
        USER_AUTH_LDAP_BIND_DN: CN=datarobot-bot,OU=Users,DC=example,DC=org
        USER_AUTH_LDAP_BIND_PASSWORD: **********
        USER_AUTH_LDAP_SEARCH_BASE_DN: OU=Users,DC=example,DC=org 

Nested group membership¶

By default, when USER_AUTH_LDAP_REQUIRED_GROUP is set, only direct membership in that group is checked. You can enable nested group evaluation so that users who belong to child groups (subgroups) of the required group can authenticate as well.

This is useful when LDAP groups are organized hierarchically—for example, a top-level DR_Access_Allowed group contains department-level subgroups and users are assigned to those subgroups rather than to the top-level group directly.

Nested group evaluation is used only to verify whether a user can access DataRobot through USER_AUTH_LDAP_REQUIRED_GROUP. It does not create DataRobot groups, sync LDAP group membership into DataRobot, or assign users to DataRobot Application groups. DataRobot group mapping is handled separately by USER_AUTH_LDAP_GROUP_SEARCH_BASE_DN.

Prerequisites for nested groups¶

• DataRobot is configured to use ldapsearch authentication type (USER_AUTH_TYPE=ldapsearch).
• A required group is configured via USER_AUTH_LDAP_REQUIRED_GROUP.
• The LDAP Nested Groups feature flag is enabled for your deployment. The USER_AUTH_LDAP_REQUIRED_GROUP_NESTING_MODE setting only appears in the System Configuration UI when the feature flag is active.

Nesting mode setting¶

Nesting mode: NONE (default)¶

Only direct membership in the required group is checked. The system verifies that the user's DN (or the configured account attribute) is listed in the group's member (or configured member attribute) list. This is the legacy behavior.

Use when: Users are added directly to the required group.

Nesting mode: TWO_NESTED_LEVELS¶

Checks whether the user belongs to one of the direct child groups of the required group:

1. The system reads the required group's member list from LDAP.
2. It reads the user's memberOf attribute from LDAP.
3. If any of the required group's members overlap with the user's memberOf memberships (case-insensitive comparison), access is granted.
4. If no nested match is found, the system falls back to the standard direct membership check.

Use when: Your group hierarchy has at most two levels (a parent group containing child groups, and users are members of those child groups). This mode does not require Active Directory and works with any LDAP server that populates the memberOf attribute.

Example structure:

DR_Access_Allowed (required group)
├── DataScientists (child group)   ← user "alice" is a member
├── Engineers (child group)        ← user "bob" is a member
└── user "charlie" (direct member) 

In this setup, alice, bob, and charlie would all pass the group membership check.

Nesting mode: FULL_RECURSIVE¶

Evaluates transitive (recursive) group membership using the LDAP matching rule 1.2.840.113556.1.4.1941 (LDAP_MATCHING_RULE_IN_CHAIN). The system issues a search on the user's own entry with a filter like:

(memberOf:1.2.840.113556.1.4.1941:=<required_group_dn>) 

This delegates the entire recursive traversal to the LDAP server.

Use when: Your group hierarchy has more than two levels, or you want the LDAP server to handle full recursive resolution. This mode is designed for Active Directory environments that support the LDAP_MATCHING_RULE_IN_CHAIN OID. Some other directory servers (e.g., 389 Directory Server) also support this OID via inChainMatch.

Related settings for nested groups¶

The USER_AUTH_LDAP_REQUIRED_GROUP_NESTING_MODE setting interacts with several other LDAP settings. The table below summarizes how each setting is used per nesting mode.

USER_AUTH_LDAP_REQUIRED_GROUP_MEMBER_ATTR¶

Defaults to member. Used to check whether the user's DN (or account attribute) is listed in the group's member list. In TWO_NESTED_LEVELS mode, this attribute is also used to read the list of child groups from the required group record—if this attribute name is wrong, the system cannot discover child groups and nested membership will always fail.

Change this if your directory uses a different attribute for group membership (e.g., uniqueMember for groupOfUniqueNames object classes). For Active Directory with group object class, the default member is correct.

USER_AUTH_LDAP_REQUIRED_GROUP_ACCOUNT_ATTR¶

Defaults to empty (the user's full DN is used). When set, the system compares the value of this user attribute against the group's member list instead of comparing the user's DN. This affects the direct membership check used by NONE mode and as a fallback in TWO_NESTED_LEVELS. It does not affect the FULL_RECURSIVE matching rule check.

In most Active Directory deployments, leave this empty.

USER_AUTH_LDAP_GROUP_OBJECT_CLASS¶

Defaults to groupOfNames. Defines the object class used for LDAP group searches. For Active Directory, set this to group. For OpenLDAP or 389 DS, use groupOfNames or groupOfUniqueNames depending on your schema.

Service account permissions¶

The service account (USER_AUTH_LDAP_BIND_DN / USER_AUTH_LDAP_BIND_PASSWORD) must have read access to:

• The required group's member attribute (needed for TWO_NESTED_LEVELS to discover child groups).
• User entries' memberOf attribute (needed for both TWO_NESTED_LEVELS and FULL_RECURSIVE).

If the service account lacks read permissions on these attributes, nested group checks will silently return empty results and users will be denied access. Verify permissions with an ldapsearch using the service account credentials.

Nested groups example configuration¶

Below is an example of a working configuration for an Active Directory environment with nested groups:

All other LDAP settings use their default values: