If you use an Active Directory (AD) server and LDAP to authenticate users, you can specify the servers, parameters, and the search modes that Elastic Cloud Enterprise uses to locate user credentials. There are several sections to the profile:
- Specify the general AD settings.
- Optional: Prepare the trusted CA certificates.
- Supply the bind credentials.
- Select the search mode and group search settings.
- Create role mappings, either to all users that match the profile or assign roles to specific groups.
- Add any custom configuration advanced settings to the YAML file.
- Log into the Cloud UI.
- Go to Users and then Authentication providers.
- From the Add provider drop-down menu, select Active Directory.
Provide a unique profile name. This name becomes the realm ID, with any spaces replaced by hyphens.
The name can be changed, but the realm ID cannot. The realm ID becomes part of the certificate bundle.
Add one or more LDAP server URLs and the port. You can use LDAP or LDAPS, but you can’t use a mix of types.
Choose how you want your load balancing to work:
- If a LDAP server connection fails, the LDAP traffic is processed by the servers in the order they were entered. The first server that connects gets used for subsequent connections.
- DNS failover
- The request is sent to a DNS hostname and the associated server IP addresses are searched in the order they are listed by the load balancer. Each request starts at the beginning of the IP address list, regardless of previous failures.
- Round robin
- A server is chosen at random and the traffic connects to each server IP address until a connection is made.
- DNS round robin
- The request is sent to a DNS hostname that is configured to with multiple IP addresses, rotating through until a connection is made.
- Provide the top-level domain name.
Though optional, you can add one or more certificate authorities (CAs) to validate user certificates with SSL/TLS. Connecting via SSL/TLS ensures that the identity of the AD server is authenticated before Elastic Cloud Enterprise transmits the user credentials and that the contents of the connection are encrypted. If the AD server also requires a client certificate for authentication then you will need to additionally include the client private key in the bundle for proof of identity.
Provide the URL to the keystore ZIP file with the certificate(s) (optionally also containing the client private key if using client certificate authentication).
The bundle should be a ZIP file containing a single
keystore.ksfile in the directory
:idis the value of the Realm ID field created in the General settings.
- Select a truststore type.
- Add the password to access the truststore bundle.
You can either select Bind anonymously for user searches or you must specify the distinguished name (DN) of the user to bind and the bind password.
Bind settings are not used with search templates.
The profile can specify each of the details for a user search or use a template to perform AD queries.
To configure the user search:
- Provide the Base DN for the user or the group.
Set the Search scope:
- Searches everything under the base but not the base itself.
- One level
- Searches for objects within the base DN.
- Uses only the base DN as the user object.
- Optional: Specify any additional query filters.
Optional: You can specify an attribute such as
memberofto apply the profile to all members who are included in that group and match the query or you could use
uniquememberto limit the query further.
To search with a template:
- Select Template.
- Provide one or more User DN templates.
When a user match is found, the role mapping assigns them privileges.
To assign all matched users a single role, select one of the Default roles.
To assign roles according to the User DN or Group DN, use the Add role mapping rule fields.
You can add any additional settings to the Advanced configuration YAML file. For example, if you need to ignore the SSL check in a testing environment, you might add