Google Cloud Identity (LDAP auth)

[andrew....@mark43.com]

We're looking at using the LDAP auth method against Google Cloud Identity, and have noticed that we're able to authenticate using the identity client's credentials but not able to retrieve any groups. Through my debugging/troubleshooting, it seems like we're not getting a proper LDAP search reference point due to the identity client not technically being an entry in the DIT. Looking for some clarity on whether this is a known limitation on the way that Vault issues the groups search / an incompatibility with Google identity. The following is our configuration setup of our LDAP setup against Google:

We use stunnel to handle the TLS connection between our Vault server and the Google LDAP endpoint:

stunnel.conf

[ldap]

client = yes

accept = 127.0.0.1:1636

connect = ldap.google.com:636

cert = /path/to/cert

key = /path/to/key

Enable and configure ldap auth method:

vault auth enable ldap

vault write auth/ldap/config url="ldap://127.0.0.1:1636" binddn="ClientUsername" userdn="ou=Users,dc=example,dc=com" userattr=uid groupdn="ou=Groups,dc=example,dc=com" groupfilter="(memberUid={{.Username}})" groupattr=cn

vault login -method=ldap username=first.last

The above "ClientUsername" set setup per the Configure access permissions documentation and in our testing given access to read the entire organization (i.e. all OUs and all entries within). We've verified that we can both authenticate and are authorized to see all aspects of the Google directory and entry details via ldapsearch.

Again, as much as I can tell the search being issued by Vault is indeed valid and gives back matching groups in an external tool (e.g. ldapsearch, JXplorer), but via Vault doesn't obtain any matching groups. My current theory is that this has something to do with the context that the Vault search for groups is happening under and the binddn (e.g. ClientUsername) is referencing a user that's not technically in the directory tree.

It's worth noting that I've tried several forms of groups resolution, including setting the groupdn to base off of the Users OU (i.e. ou=Users,dc=example,dc=com) and matching based on memberOf, and still don't get any matching groups.

Any insights or thoughts would be much appreciated!

Andrew

[andrew....@mark43.com]

I failed to mention that we're using Vault version 1.0.1.

[Alexander Holyoake]

I think this is a bug in the underlying go-ldap library. I am using exactly the same setup and have been pulling my hair out fro the last couple of days trying to get this to work.

We have vault 0.9.5 deployed which has the same issue as the latest vault.

I managed to get it to work by closing and reopening the connection before rebinding using the binddn and bindpassword (after the user authentication has happened). On the current master this is done in vault/builtin/credential/ldap/backend.go line 117 

c.Close()
c, err = ldapClient.DialLDAP(cfg)
defer c.Close()

and everything works.

[Alexander Holyoake]

I have raised an issue here: https://github.com/hashicorp/vault/issues/6111

[Igor Cicimov]

This is spot on, can't believe this has been opened since January and no one has had a look and fixed it. It is such a simple bug.

I left a comment in the #6111 issue, same problem that I'm seeing with OpenLDAP.