Skip to main content

​
Setting up Ldap Authentication

Security requirements for your production environment:
  • DELETE the admin default account shipped by OM in case you had Basic Authentication enabled before configuring the authentication with Auth0 SSO.
  • UPDATE the Private / Public keys used for the JWT Tokens. The keys we provide by default are aimed only for quickstart and testing purposes. They should NEVER be used in a production installation.
OpenMetadata allows using LDAP for validating email and password authentication. Once setup successfully, the user should be able to sign in to OpenMetadata using the Ldap credentials. Below are the configuration types to set up the LDAP Authentication:

Docker

Configure LDAP Authentication for Docker deployment.

Kubernetes

Configure LDAP Authentication for Kubernetes deployment.

Bare Metal

Configure LDAP Authentication for Bare Metal deployment.

​
Configure Ingestion

Once your server security is set, it’s time to review the ingestion configuration. Our bots support JWT tokens to authenticate to the server when sending requests. Find more information on Enabling JWT Tokens and JWT Troubleshooting to ensure seamless authentication.

​
Troubleshooting

This section covers common LDAP authentication problems and how to fix them.

​
Some Users Can’t Log In With Error data 52e

Some users log in normally, but others with correct passwords get “You have entered an invalid username or password.” The server log shows:
data 52e means the directory (for example, Active Directory) rejected the credentials in the bind. If the stack trace includes validatePassword or performLdapBind, the failing bind is the user’s own login, not the lookup (admin) account. Known issue in 2.0.x: Passwords that contain non-ASCII characters (for example ü, ç, or €) are corrupted before they reach the LDAP server, so the directory rejects them (#28694). The fix is included in 2.1.0. To work around it on 2.0.x:
  • Don’t change the LDAP admin (lookup) password. It isn’t the cause.
  • Check whether the affected users have non-ASCII characters in their passwords. Until you upgrade to 2.1.0, they can use a password with only ASCII characters.
  • Compare the LDAP attributes (for example mail and userPrincipalName) of affected users who use only ASCII characters with those of a user who can log in.
  • Confirm those users are under the configured userBaseDN.