Skip to content

Commit 383856a

Browse files
authored
[DOCS] Adds LDAP realm configuration details (#30214)
1 parent 5064ff6 commit 383856a

File tree

5 files changed

+292
-231
lines changed

5 files changed

+292
-231
lines changed
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,214 @@
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

Comments
 (0)