# Okta LDAP Interface

Okta LDAP Interface is a built-in Okta integration that enables you to expose your Okta directory over standard LDAP wire. The Okta LDAP Interface exposes the entire Okta directory.

{% hint style="warning" %}
**LDAP interface is not an isolated application**

You cannot manage the assignment of users and groups to the LDAP Interface the same way you would in a web application. Instead, you should be able to leverage LDAP filters to moderate access to applications that call the LDAP Interface (i.e., filtering user attributes and groups.)
{% endhint %}

## 1 - Enable LDAP interface in your Okta account

1. Go to the **Admin Console** in your Okta account.
2. Select **Directory**, and then click **Directory Integrations**.
3. Select **Add Directory** and **Add LDAP Interface**. You will be presented with the details required to make a successful LDAP connection.

{% hint style="info" %}
Create a service account to use as your LDAP bind user; any Okta admin with the "view users" permission can serve the role. Choose the Read-Only Admin to grant the least privilege.
{% endhint %}

## 2 - Set up authentication with the LDAP interface in Immuta

For details about the configuration options below and additional configuration options, see the [LDAP protocol reference guide](https://documentation.immuta.com/saas/configuration/people/reference-guides/ldap-protocol#configuration-options).

1. Navigate to the **App settings page** and select **LDAP/Active Directory** from the **Identity Provider Type** dropdown menu.
2. Adjust **Default Permissions** granted to users by selecting from the list in this dropdown menu, and then complete the required fields in the **Credentials** and **Options** sections. *Note: Either **User Attribute** OR **User Search Filter** is required, not both. Completing one of these fields disables the other.*
3. Opt to have **Case-insensitive user names** by clicking the checkbox.
4. Opt to **Enable Debug Logging** or **Enable SSL** by clicking the checkboxes.
5. In the **Profile Schema** section, map attributes in LDAP/Active Directory to automatically fill in a user's Immuta profile. *Fields that you specify in this schema will not be editable by users within Immuta.*\
   If usernames in your data platform align with usernames in an external IAM and those accounts align with an IAM attribute, enter the IAM attribute in the field that corresponds to your data platform:
   1. **User's Databricks Username**
   2. **User's Snowflake Username**
   3. **User's Trino Username**
   4. **User's Azure Synapse Analytics Username**
   5. **User's Redshift Username**
   6. **User's BigQuery Username**
   7. **User's AWS User**. After entering the IAM attribute in the User's AWS User field, click the **Select AWS User Type** from the dropdown and select one of the types below**.** This is used by the Amazon S3 Integration to map users in Immuta to the corresponding user type in AWS.
      * **None** (fallback to Immuta username): When selecting this option, the AWS username is assumed to be the same as the Immuta username.
      * [**AWS IAM role**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-roles): Only a single Immuta user can be mapped to an IAM role. This restriction prohibits enforcing policies on AWS users who could assume that role. Therefore, if using role principals, create a new user in Immuta that represents the role so that the role then has the permissions applied specifically to it.
      * [**AWS IAM user**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-users)
      * **AWS Identity Center user IDs**: You must use the numeric `User ID` value found in AWS IAM Identity Center, not the user's email address.
   8. **User's PostgreSQL Username**
   9. **User's Teradata Username**
6. Opt to **Link SQL Account**.
7. Opt to **Enable scheduled LDAP Sync support for LDAP/Active Directory** and **Enable pagination for LDAP Sync**. Once enabled, confirm the sync schedule written in [Cron rule](https://crontab.guru/#0_*/1_*_*_*); the default is every hour. Confirm the LDAP page size for pagination; the default is 1,000.
8. Opt to [**Sync groups from LDAP/Active Directory to Immuta**](https://documentation.immuta.com/saas/configuration/people/reference-guides/ldap-protocol#group-mapping). Once enabled, map attributes in LDAP/Active Directory to automatically pull information about the groups into Immuta.
9. Opt to [**Sync attributes from LDAP/Active Directory to Immuta**](https://documentation.immuta.com/saas/configuration/people/reference-guides/ldap-protocol#attribute-mapping). Once enabled, add attribute mappings in the attribute schema. The desired attribute prefix should be mapped to the relevant schema URN.
10. Opt to enable **External Groups and Attributes Endpoint**, **Make Default IAM**, or **Migrate Users** from another IAM by selecting the checkbox.
11. Then click the **Test Connection** button.
12. Once the connection is successful, click the **Test User Login** button. *Because this test button attempts to log in, a user or group must be assigned to the application in Okta that you have login access for.*
13. Click the **Test LDAP Sync** button if scheduled sync has been enabled.

{% hint style="warning" %}
**Multiple user accounts cannot have the same email address**

If you register user accounts that have the same email address as an existing Immuta user account, the email field for the subsequent user accounts will be left empty. For more details, see the [Identity managers reference guide](https://documentation.immuta.com/saas/configuration/people/reference-guides/index#limitations).
{% endhint %}

## 3 - Configure MFA in Okta

To enforce directory-wide MFA, create an authentication policy in Okta (if you do not yet have MFA policies in place).

1. Navigate to **Security** in the Okta Admin console.
2. Select **Authentication**, and then click **Sign On**.

   *Note: If you enforce MFA on the user that’s configured as your LDAP bind user, the integration won’t work. You will therefore need to make that user exempt in your MFA policies.*