Authenticating against google secure ldap

[aisangelos]

When trying to authenticate against google secure ldap, Vault first searches for the existence of the account which is a good thing. It retrieves the full user DN and tries a rebind with the user credentials and the full DN. This is all kosher but Google's BindDN for user authentication is the email .

can we get some kind of an override field for the user binddn ?

This will help me use google secure ldap as an SSO solution

[maxb]

Please provide more detail about this part:

This is all kosher but Google's BindDN for user authentication is the email .

An LDAP directory which rejects binding, when the bind DN is specified as the actual DN you want to bind as, would be a pretty significant deviation from LDAP standards.

[aisangelos]

This is the way it works

LDAPTLS_CERT=~/Google_2026_06_12_59791/Google_2026_06_12_59791.crt \ LDAPTLS_KEY=~/Google_2026_06_12_59791/Google_2026_06_12_59791.key \ ldapsearch -x \ -H ldaps://ldap.google.com:636 \ -D angelos.karageorgiou@myco.com -W \ -b ou=Users,dc=myco,dc=com,dc=myco,dc=com \ '(mail=angelos.karageorgiou@myco.com)'

[maxb]

If you run the command you posted, obtain the exact DN string representing your user's entry, and repeat the command using your DN (appropropriately quoted) as the value for the -D option, does this LDAP server not accept your login?

If that is the case, this LDAP server is acting incompatibly with the authentication method defined in RFC4513 and with commonly implemented practice.

As for what happens next, I should note that I am a community contributor not associated with HashiCorp in any official capacity, so the decision is not mine - however I imagine that a request to add an option to support a proprietary LDAP server's deviation from the specification may meet with limited interest.

[aisangelos]

We are talking about Google secure ldap here!

[maxb]

We are talking about Google secure ldap here!

It is unclear what you are aiming to imply by that statement.

[aisangelos]

I am saying it is a huge market segment.

[maxb]

I did a quick bit of searching just now, and based on the FAQ page at https://support.google.com/a/answer/9100761:

Only the certificate authenticates the LDAP client. The access credentials only exist if the client insists upon also sending a username and password.

It appears that the product does not support use in the way Vault (or any application seeking to use it to validate user passwords) needs.

By that, I mean that authentication to this LDAP product appears to only support explicitly provisioned service principals, and does not allow connections using end-user passwords - which is the operation needed to use an LDAP interface to verify if an end-user password is correct.

[heatherezell]

Hi @aisangelos - can you clarify for me what your specific request / enhancement would be? More details would help me understand the ask, and then we can see what our product and engineering teams think about it. Thanks!

[aisangelos]

@hsimon-hashicorp I am thinking for you to provide an override for the binddn instead of that being fixed in the code. Your code , I assume, rebinds with the full user DN which is fine in 99% of the cases, yet in systems like google's secure ldap it fails. Google expects the binddn to be the users email , if memory serves. So a configurable override would be nice

[heatherezell]

Can you provide any error messages you're receiving, both through Vault and Google? Thanks!

[aisangelos]

Sorry that project died and its logs with it.

[heatherezell]

Sorry that project died and its logs with it.

Unfortunately, without more data to go on, we won't be able to determine the cause of the issue and resolve it. As such, I'm going to go ahead and close this issue now, but please feel free to open a new one in the future as needed. Thanks!