I have a consumer server (2.4.57) that successfully forwards pwdFailureTime modifications to the master server using GSSAPI authentication. I want to replace GSSAPI with certificate-based (SASL EXTERNAL) authentication along with proxy authorization. Basically, I want to configure the equivalent of the following command line:
LDAPTLS_KEY=server.key LDAPTLS_CERT=server.crt \ ldapmodify -Z -Y EXTERNAL \ -e '!authzid=dn:cn=proxydn,dc=example,dc=com' -e relax \ -h ldap-master.example.com -f update_pwdfailuretime.ldif
The command line works as expected -- it authenticates successfully using the server certificate, and then does PROXYAUTHZ to cn=proxydn,dc=example,dc=com to perform the modify operation. The issue is when I try to configure this behavior with chain on the consumer server. I've tried various incantations along these lines:
chain-idassert-bind bindmethod=SASL saslmech=EXTERNAL tls_cert=server.crt tls_key=tls.key authzId=dn:cn=proxydn,dc=example,dc=com
The SASL EXTERNAL authentication works fine -- It binds to the master with the DN mapped from the certificate's subject. But it doesn't do the proxyauthz to cn=proxydn,dc=example,dc=com. I've read through the docs in detail and tried various modes, flags and other settings, but I can't get it to do the proxy authz.
Does anyone have a known working config for this kind of setup that they can share? Otherwise, any suggestions on the best way to troubleshoot this further would be great.
Thanks,
-Kartik
On Apr 14, 2022, at 4:56 PM, Kartik Subbarao subbarao@computer.org wrote:
I have a consumer server (2.4.57) that successfully forwards pwdFailureTime modifications to the master server using GSSAPI authentication. I want to replace GSSAPI with certificate-based (SASL EXTERNAL) authentication along with proxy authorization. Basically, I want to configure the equivalent of the following command line:
LDAPTLS_KEY=server.key LDAPTLS_CERT=server.crt \ ldapmodify -Z -Y EXTERNAL \ -e '!authzid=dn:cn=proxydn,dc=example,dc=com' -e relax \ -h ldap-master.example.com -f update_pwdfailuretime.ldif
The command line works as expected -- it authenticates successfully using the server certificate, and then does PROXYAUTHZ to cn=proxydn,dc=example,dc=com to perform the modify operation. The issue is when I try to configure this behavior with chain on the consumer server. I've tried various incantations along these lines:
chain-idassert-bind bindmethod=SASL saslmech=EXTERNAL tls_cert=server.crt tls_key=tls.key authzId=dn:cn=proxydn,dc=example,dc=com
The SASL EXTERNAL authentication works fine -- It binds to the master with the DN mapped from the certificate's subject. But it doesn't do the proxyauthz to cn=proxydn,dc=example,dc=com. I've read through the docs in detail and tried various modes, flags and other settings, but I can't get it to do the proxy authz.
What's error in the logs?
Does anyone have a known working config for this kind of setup that they can share? Otherwise, any suggestions on the best way to troubleshoot this further would be great.
Here’s a snippet from an ansible template we use for one of our tests:
```conf overlay chain
chain-uri "{{ hostvars[providers | first].ldap_url }}" chain-tls start tls_cacert="{{ cacert_path }}" tls_cert="{{ config_path }}/{{ inventory_hostname }}.crt" tls_key="{{ config_path }}/{{ inventory_hostname }}.pem" tls_reqcert=demand chain-idassert-bind mode=legacy bindmethod=sasl saslmech=external binddn=cn=notused starttls=yes tls_cacert="{{ cacert_path }}" tls_cert="{{ config_path }}/{{ inventory_hostname }}.crt" tls_key="{{ config_path }}/{{ inventory_hostname }}.pem" tls_reqcert=demand ```
Other important items is the service account used as proxy must have:
```ldif … sn: service account authzTo: ldap:///ou=People,dc=example,dc=com??subtree?(objectclass=someperson) ```
Also, on the consumer:
```conf authz-regexp "cn=([^,]*),ou=Symas,o=Symas corp,l=Grand Junction,st=Colorado,c=us" "cn=$1,ou=clients,dc=example,dc=com"
```
And on the target:
```conf authz-policy to authz-regexp "cn=([^,]*),ou=Symas,o=Symas corp,l=Grand Junction,st=Colorado,c=us" "cn=$1,ou=servers,dc=example,dc=com" ```
HTH
— Shawn
Shawn McKinney wrote:
Here’s a snippet from an ansible template we use for one of our tests:
[...]
Hi Shawn, I'm looking to do something slightly different than your example. I can set up certificate-based authentication with the authz-regexp and authzTo stuff, no problems there. But I also want to do *proxyauth* to a different dn on the master. I don't see the authzId parameter in your chain configuration -- that's the part I can't get working.
Let me provide some more context. Let's say we have two consumer servers, consumer1.example.com and consumer2.example.com. Both of them have the same certificate installed. This certificate has a subject name of CN=ldap.example.com and a subject Alternate Name of DNS:*.example.com (wildcard certificate), so it can be used on all the consumer servers. When these servers update pwdFailureTime on the master server (via chain), I want the modifiersName to show the actual server name, not ldap.example.com.
On consumer1, I want to set up chain like this: chain-idassert-bind bindmethod=SASL saslmech=EXTERNAL tls_cert=server.crt tls_key=tls.key authzId=dn:cn=consumer1,dc=example,dc=com
On consumer2, I want to set up chain like this: chain-idassert-bind bindmethod=SASL saslmech=EXTERNAL tls_cert=server.crt tls_key=tls.key authzId=dn:cn=consumer2,dc=example,dc=com
I have set up authzFrom/authzTo on the master to allow CN=ldap.example.com to proxyauth as both of these names.
As I indicated in my original message, the idea is to do the equivalent of this (on consumer1):
LDAPTLS_KEY=server.key LDAPTLS_CERT=server.crt \ ldapmodify -Z -Y EXTERNAL \ -e '!authzid=dn:cn=consumer1,dc=example,dc=com' -e relax \ -h ldap-master.example.com -f update_pwdfailuretime.ldif
Hope this helps clarify what I'm looking for.
Thanks,
-Kartik
--On Monday, April 18, 2022 6:49 PM +0000 subbarao@computer.org wrote:
Hope this helps clarify what I'm looking for.
Hi Kartik,
We do something similar at Klarna. Our olcDbIDAssertBind configuration is:
olcDbIDAssertBind: mode=self flags=override,prescriptive,proxy-authz-critical bindmethod=sasl saslmech=external tls_cert=... tls_key=... tls_cacert=...
Then our olcSyncrepl config has:
olcSyncrepl rid=001 provider=... bindmethod=sasl saslmech=external authzid="dn:cn=replicator,..." searchbase=... type=... keepalive=... retry=... tls_cert=... tls_key=... tls_cacert=... timeout=..
I would note that we also have a custom patch applied to the OpenLDAP 2.4 series to fix an issue with proxy authorization (It does not fully apply to 2.5+) and ACL evaluation using the wrong identity.
--Quanah
--On Monday, April 18, 2022 12:03 PM -0700 Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Monday, April 18, 2022 6:49 PM +0000 subbarao@computer.org wrote:
Hope this helps clarify what I'm looking for.
Hi Kartik,
We do something similar at Klarna. Our olcDbIDAssertBind configuration is:
olcDbIDAssertBind: mode=self flags=override,prescriptive,proxy-authz-critical bindmethod=sasl saslmech=external tls_cert=... tls_key=... tls_cacert=...
Then our olcSyncrepl config has:
olcSyncrepl rid=001 provider=... bindmethod=sasl saslmech=external authzid="dn:cn=replicator,..." searchbase=... type=... keepalive=... retry=... tls_cert=... tls_key=... tls_cacert=... timeout=..
I would note that we also have a custom patch applied to the OpenLDAP 2.4 series to fix an issue with proxy authorization (It does not fully apply to 2.5+) and ACL evaluation using the wrong identity.
Ok, this was ITS#9179, fixed in OpenLDAP 2.5.1+
--Quanah
Quanah Gibson-Mount wrote:
We do something similar at Klarna. Our olcDbIDAssertBind configuration is:
[...]
I would note that we also have a custom patch applied to the OpenLDAP 2.4 series to fix an issue with proxy authorization (It does not fully apply to 2.5+) and ACL evaluation using the wrong identity.
Ok, this was ITS#9179, fixed in OpenLDAP 2.5.1+
Thanks Quanah, will check out this info.
Regards,
-Kartik
openldap-technical@openldap.org