Set up Enterprise Search with Active Directory user authentication

edit

Set up Enterprise Search with Active Directory user authentication

edit

Active Directory for Enterprise Search is a gold feature.

The following documentation describes the process of configuring Elasticsearch and Kibana:

Active Directory user authentication

If you are using the standalone Enterprise Search UI, make sure that the realms configured in Enterprise Search mirror those configured in Elasticsearch. For example, if Elasticsearch has both native and active_directory enabled:

xpack:
  security:
    authc:
      realms:
        native:
          native1:
            order: 0
        active_directory:
          ad1:
            order: 1
            domain_name: example.org
            url: ldap://dc1.example.org:389
            bind_dn: "administrator@example.org"

Then Enterprise Search should have those as well:

ent_search.auth:
  native1:
    source: elasticsearch-native
    order: 1
  ad1:
    source: elasticsearch-active-directory
    order: 2

If you are using the Kibana UI, within your Enterprise Search configuration settings, make sure that:

any auth.source configurations are removed
kibana.host is set
kibana.external_url is set.

Instructions specific to Elastic Cloud users

edit

On Elastic Cloud:

it’s not possible to remove ent_search.auth section
kibana.external_url is applied automatically and is not part of user settings
elasticsearch-native auth source is always added automatically to the list of sources, and should not be included in user settings.

Elastic Cloud users should explicitly configure auth sources in the Enterprise Search config, whether they intend to use Kibana or Enterprise Search UI to log in.

Example:

ent_search.auth:
  ad1:
    source: elasticsearch-active-directory
    order: 1

Configure Enterprise Search role mappings for Active Directory users

edit

When a user is logged in to Enterprise Search in Kibana via Active Directory, the following metadata properties would be populated:

ldap_dn: user’s distinguished name
ldap_groups: the distinguished name of each of the groups that were resolved for the user.

Based on those metadata fields, it is possible to create role mappings that apply to groups of users. For example, members of the group called Administrators would get admin permissions to Workplace Search:

PUT _security/role_mapping/workplace_search_admin_ad
{
  "roles": ["enterprise-search-workplace-search-admin"],
  "rules" : {
    "field" : {
      "groups" : "CN=Administrators,CN=Builtin,DC=example,DC=org"
    }
  },
  "enabled": true
}

While members of the group called Users would get user permissions:

PUT _security/role_mapping/workplace_search_user_ad
{
  "roles": ["enterprise-search-workplace-search-user"],
  "rules" : {
    "field" : {
      "CN=Users,CN=Builtin,DC=example,DC=org"
    }
  },
  "enabled": true
}

Users can also be mapped in Users and Roles in Enterprise Search UI in Kibana:

Mapping can use common Elasticsearch user attributes, such as username and email, but also anything provided in metadata that is returned by the Active Directory provider. Here is an example of metadata:

{
    "ldap_dn" : "CN=adminuser,CN=Users,DC=dummy,DC=example,DC=org",
    "displayName" : "Admin User",
    "ldap_groups" : [
      "CN=Administrators,CN=Builtin,DC=dummy,DC=example,DC=org",
      "CN=Domain Users,CN=Users,DC=dummy,DC=example,DC=org",
      "CN=Users,CN=Builtin,DC=dummy,DC=example,DC=org"
    ],
    "name" : "adminuser",
    "cn" : "adminuser",
    "userPrincipalName" : "adminuser@dummy.example.org"
}

In Elasticsearch, the Active Directory realm that provided this metadata would be configured as follows:

xpack:
  security:
    authc:
      realms:
        active_directory:
          ad1:
            order: 1
            domain_name: dummy.example.org
            url: ldap://ad.dummy.example.org:389
            bind_dn: "administrator@dummy.example.org"
            metadata:
              - cn
              - name
              - displayName
              - userPrincipalName

For more information about configuring metadata returned by an Active Directory realm, see User metadata in Active Directory realms.

« Set up Enterprise Search with LDAP user authentication Subscriptions and features »