Hi!
If that’s the paths of the actual certificates, I could imagine that the user running slapd has no access to /root/ and below. Despite of that I think it’s a bad idea to place certificates for a server into a user’s home directory.
Regards, Ulrich
From: tmp 2810 t2810mp@gmail.com Sent: Tuesday, November 5, 2024 5:07 PM To: Quanah Gibson-Mount quanah@fast-mail.org Cc: openldap-technical@openldap.org Subject: [EXT] Re: Issue with slapd and Google LDAP Integration (lowercase user)
Thats my actual config and the message on the logs is : Unauhtenticated
================================================ uri "ldaps://ldap.google.com/dc=proxyhttp://ldap.google.com/dc=proxy" suffixmassage "dc=proxy" "dc=example,dc=com" lastmod off readonly on idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_reqcert=demand tls_reqsan=demand tls_cert=/root/ldapcerts/google_cert.crt tls_key=/root/ldapcerts/google_cert.key tls_cacert=/root/ldapcerts/ca/gtsr1.pem ================================================
I've actually been trying all kinds of configurations for the last 2 weeks. Is there a chance that this doesn't work with Google's LDAP? I can't find a single example on the entire internet of someone who has managed to do this whit the LDAP of google.
El mar, 5 nov 2024 a las 12:51, Quanah Gibson-Mount (<quanah@fast-mail.orgmailto:quanah@fast-mail.org>) escribió:
--On Monday, November 4, 2024 8:29 PM -0300 tmp 2810 <t2810mp@gmail.commailto:t2810mp@gmail.com> wrote:
Once again, I apologize; I ran so many tests that I accidentally copied one where the binddn was incorrect.
The target looks more like this:
## example.comhttp://example.com uri "ldaps://ldap.google.com/dc=proxyhttp://ldap.google.com/dc=proxy" suffixmassage "dc=proxy" "dc=example,dc=com" lastmod off readonly on idassert-bind bindmethod=simple binddn="cn=ChiwewDaw"
cn, is by definition, case insensitive. If Google LDAP is forcing case sensitivity in this attribute, it is gross violation of the LDAP RFCs. However, having had to interface with it in the past, I don't believe that is the case. I would generally suspect that this is not the full DN of the user.
idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_reqcert=demand tls_reqsan=demand starttls=critical
This is not sufficient, please read the man page:
idassert-bind bindmethod=none|simple|sasl [binddn=<simple DN>] [credentials=<simple password>] [saslmech=<SASL mech>] [secprops=<properties>] [realm=<realm>] [authcId=<authentication ID>] [authzId=<authorization ID>] [authz={native|proxyauthz}] [mode=<mode>] [flags=<flags>] [starttls=no|yes|critical] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_ecname=<names>] [tls_protocol_min=<version>] [tls_crlcheck=none|peer|all]
You *must* specify tls_cert, tls_key, and tls_cacert as a part of idassert-bind as it provides the TLS identity to bind as. In your configuration for simple bind, tls_cert and tls_key are unnecessary as you're not doing SASL/EXTERNAL binds.
--Quanah