FAQ on LDAP
With Aerospike 4.1, the ability to use external authentication systems is supported. That release supports LDAP authentication. An updated client will send not only the hashed version of the password (in case the user is internal), but also the actual password, which will be sent to the external system. The external auth capabilities can be disabled on the client login call, which will not send the password but only the hashed password.
What is the LDAP Authentication Flow in Aerospike?
An Aerospike client API allows the specification of a username and password from the application.
If the client detects a server with external authentication enabled, it will first determine whether it has a stored access token. If it has no access token, it sends the username, the bcrypt() version of the password, and the password. The inclusion of both systems allows transparent hybrid access.
The server will then check the local database, and if the user exists and has a bcrypt() version of the password set, the bcrypt() version of the password is checked. If the password check succeeds, an access token is generated by the server. If the bcrypt() password does not match, the authentication fails. If there is no bcrypt() version of the password, then authentication passes to the external phase.
The configured LDAP server is contacted, and a BIND login request is initiated. If configured, the username may be remapped or translated. Both a standard password and an SASL authentication will be supported, using OpenLDAP libraries.
If the LDAP login succeeds, the server generates an access token and passes it to the client.
The cluster then makes a request to the LDAP server using the appropriate wildcard query to determine the list of groups available for this user. Once this is done, the result is stored locally and distributed to other members of the cluster.
The client then opens each successive TCP connection using the access token, which is validated by verifying the timestamp and the HMAC. This is done on every TCP connection.
If the client needs a new TCP connection and the access token is no longer valid, the server will reject the access token and the client will request a new access token from the server through the same interaction as specified above.
How do I do an in-place upgrade from a local authenticated enabled cluster to an external authenticated enabled cluster?
When upgrading from Aerospike local authentication to external authentication, each server is separately authenticated, but maintenance of groups is done by one elected server within the cluster.
An in-place upgrade can be supported as long as the following operational procedure is followed:
- Update all clients to a version which supports external authentication (and thus the sensing of whether a server supports the old or new authentication mechanisms),
- Update the server configuration to include LDAP external auth information and restart.
Note - If you have TLS enabled you must add your certs on the client machine and either an
ldap.conf file must be created or environment variables must be set.
Note - A TCP connection attempt with an expired token will fail, and the client must log in again to get a fresh token.
Does turning on security for user access (local or LDAP) present any noticeable overhead in latency?
We would recommend benchmarking this based on your traffic pattern.
In general, we do not expect a noticeable performance degradation with simple access control (TLS or LDAP would likely have a more noticeable impact on performance). The client(s) would authenticate (would need credentials) for each new connection being created.
I enabled LDAP but it is not working as expected and I see the following warning getting printed in the server logs. I confirmed that LDAPSEARCH works as expected.
WARNING (security): (ldap_ee.c:548) couldn't start tls: ldaps://ldap.dev.aerospike err 1 (Operations error)
LDAP support of the current Aerospike server uses StartTLS rather than ldaps:// which is deprecated. Support for ldaps has nevertheless been included in Aerospike EE server versions 4.6 and above.