MKE integration with LDAP

To control the integration of MKE with LDAP, you create user searches. For these user searches, you use the MKE web UI to specify multiple search configurations and specify multiple LDAP servers with which to integrate. Searches start with the Base DN, the Distinguished Name of the node in the LDAP directory tree in which the search looks for users.

MKE to LDAP synchronization workflow

The following occurs when MKE synchronizes with LDAP:

  1. MKE creates a set of search results by iterating over each of the user search configurations, in an order that you specify.

  2. MKE choses an LDAP server from the list of domain servers by considering the Base DN from the user search configuration and selecting the domain server with the longest domain suffix match.


    If no domain server has a domain suffix that matches the Base DN from the search configuration, MKE uses the default domain server.

  3. MKE creates a list of users from the search and creates MKE accounts for each one.


    If you select the Just-In-Time User Provisioning option, user accounts are created only when users first log in.

Example workflow:

Consider an example with three LDAP domain servers and three user search configurations.

The example LDAP domain servers:

LDAP domain server name








The example user search configurations:

User search configurations


baseDN=\ ou=people,dc=subsidiary1,dc=com

For this search configuration, dc=subsidiary1,dc=com is the only server with a domain that is a suffix, so MKE uses the server ldaps:// for the search request.

baseDN=\ ou=product,dc=subsidiary2,dc=subsidiary1,dc=com

For this search configuration, two of the domain servers have a domain that is a suffix of this Base DN. As dc=subsidiary2,dc=subsidiary1,dc=com is the longer of the two, however, MKE uses the server ldaps:// for the search request.

baseDN=\ ou=eng,dc=example,dc=com

For this search configuration, no server with a domain specified is a suffix of this Base DN, so MKE uses the default server, ldaps://, for the search request.

Whenever user search results contain username collisions between the domains, MKE uses only the first search result, and thus the ordering of the user search configurations can be important. For example, if both the first and third user search configurations result in a record with the username jane.doe, the first has higher precedence and the second is ignored. As such, it is important to implement a username attribute that is unique for your users across all domains. As a best practice, choose something that is specific to the subsidiary, such as the email address for each user.