|
| 1 | +[role="xpack"] |
| 2 | +[[configuring-ldap-realm]] |
| 3 | +=== Configuring an LDAP realm |
| 4 | + |
| 5 | +You can configure {security} to communicate with a Lightweight Directory Access |
| 6 | +Protocol (LDAP) server to authenticate users. To integrate with LDAP, you |
| 7 | +configure an `ldap` realm and map LDAP groups to user roles. |
| 8 | + |
| 9 | +For more information about LDAP realms, see |
| 10 | +{xpack-ref}/ldap-realm.html[LDAP User Authentication]. |
| 11 | + |
| 12 | +. Determine which mode you want to use. The `ldap` realm supports two modes of |
| 13 | +operation, a user search mode and a mode with specific templates for user DNs. |
| 14 | ++ |
| 15 | +-- |
| 16 | +LDAP user search is the most common mode of operation. In this mode, a specific |
| 17 | +user with permission to search the LDAP directory is used to search for the DN |
| 18 | +of the authenticating user based on the provided username and an LDAP attribute. |
| 19 | +Once found, the user is authenticated by attempting to bind to the LDAP server |
| 20 | +using the found DN and the provided password. |
| 21 | + |
| 22 | +If your LDAP environment uses a few specific standard naming conditions for |
| 23 | +users, you can use user DN templates to configure the realm. The advantage of |
| 24 | +this method is that a search does not have to be performed to find the user DN. |
| 25 | +However, multiple bind operations might be needed to find the correct user DN. |
| 26 | +-- |
| 27 | + |
| 28 | +. To configure an `ldap` realm with user search: |
| 29 | + |
| 30 | +.. Add a realm configuration of type `ldap` to `elasticsearch.yml` under the |
| 31 | +`xpack.security.authc.realms` namespace. At a minimum, you must set the realm |
| 32 | +`type` to `ldap`, specify the `url` of the LDAP server, and set |
| 33 | +`user_search.base_dn` to the container DN where the users are searched for. If |
| 34 | +you are configuring multiple realms, you should also explicitly set the `order` |
| 35 | +attribute to control the order in which the realms are consulted during |
| 36 | +authentication. See <<ref-ldap-settings>> for all of the options you can set for |
| 37 | +an `ldap` realm. |
| 38 | ++ |
| 39 | +-- |
| 40 | +For example, the following snippet shows an LDAP realm configured with a user search: |
| 41 | + |
| 42 | +[source, yaml] |
| 43 | +------------------------------------------------------------ |
| 44 | +xpack: |
| 45 | + security: |
| 46 | + authc: |
| 47 | + realms: |
| 48 | + ldap1: |
| 49 | + type: ldap |
| 50 | + order: 0 |
| 51 | + url: "ldaps://ldap.example.com:636" |
| 52 | + bind_dn: "cn=ldapuser, ou=users, o=services, dc=example, dc=com" |
| 53 | + user_search: |
| 54 | + base_dn: "dc=example,dc=com" |
| 55 | + attribute: cn |
| 56 | + group_search: |
| 57 | + base_dn: "dc=example,dc=com" |
| 58 | + files: |
| 59 | + role_mapping: "CONFIG_DIR/x-pack/role_mapping.yml" |
| 60 | + unmapped_groups_as_roles: false |
| 61 | +------------------------------------------------------------ |
| 62 | + |
| 63 | +The password for the `bind_dn` user should be configured by adding the appropriate |
| 64 | +`secure_bind_password` setting to the {es} keystore. |
| 65 | +For example, the following command adds the password for the example realm above: |
| 66 | + |
| 67 | +[source, shell] |
| 68 | +------------------------------------------------------------ |
| 69 | +bin/elasticsearch-keystore add \ |
| 70 | +xpack.security.authc.realms.ldap1.secure_bind_password |
| 71 | +------------------------------------------------------------ |
| 72 | + |
| 73 | +IMPORTANT: When you configure realms in `elasticsearch.yml`, only the |
| 74 | +realms you specify are used for authentication. If you also want to use the |
| 75 | +`native` or `file` realms, you must include them in the realm chain. |
| 76 | + |
| 77 | +-- |
| 78 | + |
| 79 | +. To configure an `ldap` realm with user DN templates: |
| 80 | + |
| 81 | +.. Add a realm configuration of type `ldap` to `elasticsearch.yml` in the |
| 82 | +`xpack.security.authc.realms` namespace. At a minimum, you must set the realm |
| 83 | +`type` to `ldap`, specify the `url` of the LDAP server, and specify at least one |
| 84 | +template with the `user_dn_templates` option. If you are configuring multiple |
| 85 | +realms, you should also explicitly set the `order` attribute to control the |
| 86 | +order in which the realms are consulted during authentication. See |
| 87 | +<<ref-ldap-settings>> for all of the options you can set for an `ldap` realm. |
| 88 | ++ |
| 89 | +-- |
| 90 | +For example, the following snippet shows an LDAP realm configured with user DN |
| 91 | +templates: |
| 92 | + |
| 93 | +[source, yaml] |
| 94 | +------------------------------------------------------------ |
| 95 | +xpack: |
| 96 | + security: |
| 97 | + authc: |
| 98 | + realms: |
| 99 | + ldap1: |
| 100 | + type: ldap |
| 101 | + order: 0 |
| 102 | + url: "ldaps://ldap.example.com:636" |
| 103 | + user_dn_templates: |
| 104 | + - "cn={0}, ou=users, o=marketing, dc=example, dc=com" |
| 105 | + - "cn={0}, ou=users, o=engineering, dc=example, dc=com" |
| 106 | + group_search: |
| 107 | + base_dn: "dc=example,dc=com" |
| 108 | + files: |
| 109 | + role_mapping: "/mnt/elasticsearch/group_to_role_mapping.yml" |
| 110 | + unmapped_groups_as_roles: false |
| 111 | +------------------------------------------------------------ |
| 112 | + |
| 113 | +IMPORTANT: The `bind_dn` setting is not used in template mode. |
| 114 | +All LDAP operations run as the authenticating user. |
| 115 | + |
| 116 | +-- |
| 117 | + |
| 118 | +. (Optional) Configure how {security} should interact with multiple LDAP servers. |
| 119 | ++ |
| 120 | +-- |
| 121 | +The `load_balance.type` setting can be used at the realm level. {security} |
| 122 | +supports both failover and load balancing modes of operation. See |
| 123 | +<<ref-ldap-settings>>. |
| 124 | +-- |
| 125 | + |
| 126 | +. (Optional) To protect passwords, |
| 127 | +<<tls-ldap,encrypt communications between {es} and the LDAP server>>. |
| 128 | + |
| 129 | +. Restart {es}. |
| 130 | + |
| 131 | +. Map LDAP groups to roles. |
| 132 | ++ |
| 133 | +-- |
| 134 | +The `ldap` realm enables you to map LDAP users to to roles via their LDAP |
| 135 | +groups, or other metadata. This role mapping can be configured via the |
| 136 | +{ref}/security-api-role-mapping.html[role-mapping API] or by using a file stored |
| 137 | +on each node. When a user authenticates with LDAP, the privileges |
| 138 | +for that user are the union of all privileges defined by the roles to which |
| 139 | +the user is mapped. |
| 140 | + |
| 141 | +Within a mapping definition, you specify groups using their distinguished |
| 142 | +names. For example, the following mapping configuration maps the LDAP |
| 143 | +`admins` group to both the `monitoring` and `user` roles, and maps the |
| 144 | +`users` group to the `user` role. |
| 145 | + |
| 146 | +Configured via the role-mapping API: |
| 147 | +[source,js] |
| 148 | +-------------------------------------------------- |
| 149 | +PUT _xpack/security/role_mapping/admins |
| 150 | +{ |
| 151 | + "roles" : [ "monitoring" , "user" ], |
| 152 | + "rules" : { "field" : { |
| 153 | + "groups" : "cn=admins,dc=example,dc=com" <1> |
| 154 | + } }, |
| 155 | + "enabled": true |
| 156 | +} |
| 157 | +-------------------------------------------------- |
| 158 | +// CONSOLE |
| 159 | +<1> The LDAP distinguished name (DN) of the `admins` group. |
| 160 | + |
| 161 | +[source,js] |
| 162 | +-------------------------------------------------- |
| 163 | +PUT _xpack/security/role_mapping/basic_users |
| 164 | +{ |
| 165 | + "roles" : [ "user" ], |
| 166 | + "rules" : { "field" : { |
| 167 | + "groups" : "cn=users,dc=example,dc=com" <1> |
| 168 | + } }, |
| 169 | + "enabled": true |
| 170 | +} |
| 171 | +-------------------------------------------------- |
| 172 | +// CONSOLE |
| 173 | +<1> The LDAP distinguished name (DN) of the `users` group. |
| 174 | + |
| 175 | +Or, alternatively, configured via the role-mapping file: |
| 176 | +[source, yaml] |
| 177 | +------------------------------------------------------------ |
| 178 | +monitoring: <1> |
| 179 | + - "cn=admins,dc=example,dc=com" <2> |
| 180 | +user: |
| 181 | + - "cn=users,dc=example,dc=com" <3> |
| 182 | + - "cn=admins,dc=example,dc=com" |
| 183 | +------------------------------------------------------------ |
| 184 | +<1> The name of the mapped role. |
| 185 | +<2> The LDAP distinguished name (DN) of the `admins` group. |
| 186 | +<3> The LDAP distinguished name (DN) of the `users` group. |
| 187 | + |
| 188 | +For more information, see |
| 189 | +{xpack-ref}/ldap-realm.html#mapping-roles-ldap[Mapping LDAP Groups to Roles] |
| 190 | +and |
| 191 | +{xpack-ref}/mapping-roles.html[Mapping Users and Groups to Roles]. |
| 192 | +-- |
| 193 | + |
| 194 | +. (Optional) Configure the `metadata` setting on the LDAP realm to include extra |
| 195 | +fields in the user's metadata. |
| 196 | ++ |
| 197 | +-- |
| 198 | +By default, `ldap_dn` and `ldap_groups` are populated in the user's metadata. |
| 199 | +For more information, see |
| 200 | +{xpack-ref}/ldap-realm.html#ldap-user-metadata[User Metadata in LDAP Realms]. |
| 201 | + |
| 202 | +The example below includes the user's common name (`cn`) as an additional |
| 203 | +field in their metadata. |
| 204 | +[source,yaml] |
| 205 | +-------------------------------------------------- |
| 206 | +xpack: |
| 207 | + security: |
| 208 | + authc: |
| 209 | + realms: |
| 210 | + ldap1: |
| 211 | + type: ldap |
| 212 | + metadata: cn |
| 213 | +-------------------------------------------------- |
| 214 | +-- |
0 commit comments