How to authenticate against ldap.google.com

g-suitegoogle-cloud-identityopenldapsssd

I've set up SSSD and openldap to successfully query ldaps://ldap.google.com. I can use ldapsearch to perform queries and can interact with the directory using both sssctl and getent. Unfortunately all my attempts to authenticate as a user in the directory are met with the INVALID_CREDENTIALS (ldap error code 49). I've reproduce this behavior using a number of clients. I can observe these failures in the LDAP audit log within the GSuite admin console as
LDAP bind with uid=brian,ou=Users,dc=XXX,dc=com failed with INVALID_CREDENTIALS.

My account does have 2 factor enabled but I'm using an application specific password to try and authenticate myself. I've quadruple-checked the password and even created a new one just to test this out. The Google ldap server is behaving as though it can't authenticate.

Any ideas how I can set up secure external authentication against ldap.google.com?

Thx

Best Answer

This is a bit misleading because "INVALID_CREDENTIALS" is actually a much more generic error than it implies. In reality, this usually is the result of a permissions error rather than invalid credentials. I ran into this while configuring a local OpenLDAP server of my own. The problem is likely that your user does not have the permission to bind/authenticate to the LDAPS server in the first place.

The reason that ldapsearch works for getent & sss daemon is because they are probably using either your LDAP administrator credentials, or if you've configured it correctly, your bind proxyuser account. (You should never do bind auth via manager directly).

The issue is caused by your ACLs (access control lists) for LDAP. What you essentially want to do is allow all users to read the full directory (with the exception of sensitive objects like password fields and such.

I don't know what your ACLs look like currently, but what you want to do is begin with the following ACL.

DISCLAIMER: THIS IS NOT SECURE BY DEFAULT

access to *
        by self write
        by users auth
        by users read

Effectively, this allows users to authenticate, and read all objects, as well as overwrite their own user objects so they can do things like change their passwords and such.

Bear in mind that this configuration is only slightly more secure than the default which allows anonymous binds, something no administrator worth his salt should ever allow. You should be VERY strict about what users have access to by setting access controls on specific attributes. This ACL is very open-ended, so you should make sure you go the extra mile to lock it down further.

Properly configured LDAP servers with good schemas already have some built-in security for guarding passwords and other sensitive objects, but you should always verify this.

Go to the documentation and read it thoroughly. LDAP is a huge monster, and it's unfortunately all too easy to mess it up.

https://www.openldap.org/doc/admin24/access-control.html

Related Topic