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?



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.


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.


  • Thx @true-demon. Since the LDAP server instance is managed and configured by someone else (Google) is there an easy way for me to verify that my user just doesn't have the proper access control rights? I'm not setting up an openldap server, I'm just trying to use ldap client tools to authenticate against their server. – bfallik Feb 11 at 22:53
  • @true-demon I have the same issue but in context of Jenkins. In my case ldapsearch works too and in both cases (Jenkins and ldapsearch) I use the same bind user. But Jenkins still doesn't work – ALex_hha Feb 12 at 10:12
  • @BrianF Hmm, I'm afraid that I wouldn't know enough in that instance to help you, since I've only ever had to manage my own OpenLDAP instances, so I'm not as familiar with GCDS, though I can't imagine it differs that much. Since I'm not there in front of the console, there's only so much I can suggest, but in this situation, my first instinct would be to compare authentication logs when using ldapsearch with the working binduser vs the one that fails authentication. The documentation doesn't get very detailed though. – True Demon Feb 15 at 19:49
  • @ALex_hha I don't know what kind of permissions Jenkins needs, but it still sounds like a permissions issue. I would think that Jenkins would require similar permissions to the rootdn manager, but handing out those kinds of permissions to an application as notoriously exploitable as Jenkins gives me goosebumps and night sweats. Once again, I'm only familiar with managing a standalone OpenLDAP server, where you have absolute control over ACLs. If you're using GCDS, you might not have that option. It could be that GCDS just won't permit the application to have those kinds of permissions. – True Demon Feb 15 at 19:55
  • @true-demon I already solved my issue with Jenkins - serverfault.com/questions/952988 The root of the issue is that ldap.google.com requires a certificate and a key for authentication. – ALex_hha Feb 17 at 9:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.