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=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.org>) escribió:

--On Monday, November 4, 2024 8:29 PM -0300 tmp 2810 <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.com
> uri             "ldaps://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