Hi!
We have a fairly standard OpenLDAP setup (on 2.4.49) running well, where our replica instances chain writes back to the master using the chain overlay. Relevant bits of configuration we're using below:
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: TRUE
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbIDAssertBind: mode=self flags=override,prescriptive tls_reqcert=never bindmethod=sasl saslmech=plain authcID=proxy credentials=XXXXX olcDbRebindAsUser: TRUE olcDbChaseReferrals: TRUE olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 8 olcDbSessionTrackingRequest: TRUE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbIdleTimeout: 5
. . .
dn: cn=proxy,ou=System,dc=example,dc=net cn: proxy objectClass: simpleSecurityObject objectClass: organizationalRole userPassword: XXXXX authzTo: {0}dn.regex:^uid=[^,],ou=People,dc=example,dc=net$
Above works great, with the client identity being authorized through the ProxyAuthz control.
However, we also have a service using SASL proxy authorization, in which case the authcid is used in the ProxyAuthz instead of the authorized authzid. Ldapwhoami works as expected and the username mentioned in the session tracking request (visible in the producer's logs) is actually the authzdn (being cn=enduser,ou=People,dc=example,dc=net in this example, whereas cn=service,ou=system,dc=internal,dc=machines is the authcdn):
ldapwhoami -H ldaps://$(cat /etc/service_hostname) -U service -X dn:cn=enduser,ou=People,dc=example,dc=net -Y PLAIN SASL/PLAIN authentication started Please enter your password: SASL username: dn:cn=enduser,ou=People,dc=example,dc=net SASL SSF: 0 dn:cn=enduser,ou=People,dc=example,dc=net
Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 PROXYAUTHZ dn="cn=service,ou=system,dc=internal,dc=machines" Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] MOD dn="uid=sys.cp.test,ou=People,dc=internal,dc=machines" Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] MOD attr=klarnaItNote Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] RESULT tag=103 err=0 text=
Am I misunderstanding how this is supposed to work, am I hitting a certain limitation or maybe a bug? Let me know if you need any more details!
Thanks! Dieter Bocklandt
--On Friday, February 28, 2020 11:11 PM +0100 Dieter Bocklandt dieterbocklandt@gmail.com wrote:
However, we also have a service using SASL proxy authorization, in which case the authcid is used in the ProxyAuthz instead of the authorized authzid.
Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 PROXYAUTHZ dn="cn=service,ou=system,dc=internal,dc=machines" Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] MOD dn="uid=sys.cp.test,ou=People,dc=internal,dc=machines"
Am I misunderstanding how this is supposed to work, am I hitting a certain limitation or maybe a bug? Let me know if you need any more details!
This looks to me like it:
a) Logs what the proxied identity is (PROXYAUTHZ dn="cn=service,ou=system,dc=internal,dc=machine")
b) Logs what the actual identity making the changes is (USERNAME=cn=enduser,ou=People,dc=example,dc=net) and what IP address it came from (IP=10.243.72.199) so that if questions arise about who made a change, those questions can be answered from the logs.
I.e., I see both bits of information provided in the connection operation.
What makes you think you are hitting a limitation or a bug?
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org