LDAP bind authentication with Jetty

Question

I am trying to secure Confluent Control Center 7.2.2 with the jetty LdapLoginModule. I have the following jaas configuration working.

c3 {
  org.eclipse.jetty.jaas.spi.LdapLoginModule required
  useLdaps="true"
  contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
  hostname="ldaps.xxxx.xxxxx"
  port="xxx"
  bindDn=<user principal name>
  bindPassword=<user password>
  authenticationMethod="simple"
  forceBindingLogin="true"
  userBaseDn="DC=xxxx,DC=xxxx,DC=xxx,DC=xx"
  userRdnAttribute="userPrincipalName"
  userIdAttribute="userPrincipalName"
  userObjectClass="user"
  roleBaseDn="OU=xxxxxx,OU=xxx,OU=xxxxx,DC=xxxx,DC=xxxx,DC=xxx,DC=xx"
  roleNameAttribute="cn"
  roleMemberAttribute="member"
  roleObjectClass="group";
};

I would like to avoid passing a bindDn and bindPassword and use the authenticating user credentials to bind instead. My understanding is that forceBindingLogin set to true should make that possible.

forceBindingLogin Indicate whether to bind as the user that is authenticating (true), otherwise bind as the manager and perform a search to verify user password (false).

Although when I remove bindDn and bindPassword from my config I get the following error:

DAP: error code 1 - 000004DC: LdapErr: DSID-0C090A71, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v3839

It looks like bindDn is still used when forceBindingLogin is set to true.

I noticed that in the Confluence documentation, the bindDn config went from optional to required between 6.1.9 and 6.2.0. Jetty was upgraded to 9.4.39, but there is no mention as to why bindDn would now be required.

Answer 1

I don't have experience with Confluent Control Center, but have been dealing with a lot of Java applications and OAuth that uses LDAP authentication during the years. As a DevOps I had to also manage a few LDAP instances myself so I will be rather speaking from that background.

The authentication process with OpenLDAP requires one of the following to be true:

1. Allows anonymous (connection) binding This configuration allows you to connect to the LDAP server as an anonymous user and lookup any object in the tree and therefore find any groups, users, etc.

2. Manager/User dn (connection) binding This configuration mandates you to connect to the LDAP server as a pre-configured user that has access to lookup objects in the tree and find the requested groups,users,etc. You can have many Manager DNs configured to access different parts of the LDAP tree.

Notice I mentioned CONNECTION binding - think of this as how you would connect to Postgres or MySQL. You need to have some credentials in order to lookup tables or if anonymous is enabled you can do pretty much anything.

The same thing applies to LDAP servers -- anonymous binding will allow you to establish a connection and lookup anything and manager / user dn requires authentication before the connection can be established.

People are not always deeply aware of LDAP's architecture and the documentation doesn't really help there. As such, the terminology makes you jump to the rational conclusion you jumped to:

@alex: I would like to avoid passing a bindDn and bindPassword and use the authenticating user credentials to bind instead

This would work only when the LDAP server is configured to allow Anonymous connections. If it is configured to require Manager/User DN connection:

1. When you bind as the user the authentication will likely pass (unless LDAP is configured not to allow that at all).
2. Once it succeeds it you would attempt to lookup the authorization objects (roles / groups / etc). At this point it will fail due to the inability to do the needed lookups and finally the result will be failed login.

To validate if this is the case you are ending in you should:

1. Use some tool to the LDAP server (you can try Apache Directory Studio
2. Setup a connection with binds as the bespoken user (i.e. my-username; not the manager dn, not a read-only dn)
3. Once you are connected try to lookup the userBaseDn and roleBaseDn DN's -- you are most likely not going to see any of the roles.

If the above is true then what you want is not possible with the current LDAP server setup.

If not -- then the LDAP server truly allows you to bind as the user and to lookup the directory tree. In this case you should open up a bug report with Confluent.