Trying to use an authz-regexp that maps directly to dn-s by using "dn:..." instead of a URI results in the authz id having some characters "html escaped". As a result the authorized entity cannot be found. E.g. a "-U cn=Barbara Jensen,ou=Information Technology Division" with olcAuthzRegexp: "^uid=([^,]+),.*" "dn:$1,ou=people,dc=example,dc=com" fails. Debug logs show that the equal and the comma character return from ldap_bv2dn() in escaped forms, that are then substituted into the target dn and result in a dn that does not exist in the DIT. 6046d7cd SASL Canonicalize [conn=1113]: authcid="cn=Barbara Jensen,ou=Informatio n Technology Division" 6046d7cd slap_sasl_getdn: conn 1113 id=cn=Barbara Jensen,ou=Information Technolo gy Division [len=52] => ldap_dn2bv(16) <= ldap_dn2bv(uid=cn\3DBarbara Jensen\2Cou\3DInformation Technology Division,cn=PLAIN,cn=auth)=0 6046d7cd slap_sasl_getdn: u:id converted to uid=cn\3DBarbara Jensen\2Cou\3DInformation Technology Division,cn=PLAIN,cn=auth ... 6046d7cd send_ldap_result: err=49 matched="" text="SASL(-13): user not found: Password verification failed" I suspect that when the "dn:..." form is used with authz-regexp the supplied authzid should _not_ have it's characters canonicalized because they will not be substituted into a URI. If so, this would be a bug. If not, there should be documentation on the restrictions on what characters can be used in authzid when the "dn:..." form is used. Tested against HEAD of master, although the version in the bug report is 2.5. See also Bug# 6912.
It occurs to me that the regexp I used only "works" because the comma in the authzid is altered. A better olcAuthzRegexp regexp for testing with my example might be: "^uid=([^,]+,[^,]+),.*" Regards, Karl <kop@karlpinc.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Invalid usage. SASL works with usernames, not DNs. I.e., -U "cn=..." is invalid.
On Mon, 14 Jun 2021 16:39:43 +0000 openldap-its@openldap.org wrote: > https://bugs.openldap.org/show_bug.cgi?id=9495 > > Quanah Gibson-Mount <quanah@openldap.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |WONTFIX > Status|UNCONFIRMED |RESOLVED > > --- Comment #2 from Quanah Gibson-Mount <quanah@openldap.org> --- > Invalid usage. > > SASL works with usernames, not DNs. I.e., -U "cn=..." is invalid. RFC4422 Simple Authentication and Security Layer (SASL) states: 3.4.1. Authorization Identity String The authorization identity string is a sequence of zero or more Unicode [Unicode] characters, excluding the NUL (U+0000) character, representing the identity to act as. So, the literal "cn=..." is a perfectly valid SASL username. Regards, Karl <kop@karlpinc.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Based on rfc4422 (above) I've changed the status from "INVALID" to "SUSPENDED". This is probably not correct so you will probably want to change it.
(In reply to Karl O. Pinc from comment #3) > On Mon, 14 Jun 2021 16:39:43 +0000 > openldap-its@openldap.org wrote: > > > https://bugs.openldap.org/show_bug.cgi?id=9495 > > > > Quanah Gibson-Mount <quanah@openldap.org> changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > Resolution|--- |WONTFIX > > Status|UNCONFIRMED |RESOLVED > > > > --- Comment #2 from Quanah Gibson-Mount <quanah@openldap.org> --- > > Invalid usage. > > > > SASL works with usernames, not DNs. I.e., -U "cn=..." is invalid. > > RFC4422 Simple Authentication and Security Layer (SASL) > states: > > 3.4.1. Authorization Identity String > > The authorization identity string is a sequence of zero or more > Unicode [Unicode] characters, excluding the NUL (U+0000) character, > representing the identity to act as. > > So, the literal "cn=..." is a perfectly valid SASL username. You should read the entire text of that section. A non-empty authorization identity string indicates that the client wishes to act as the identity represented by the string. In this case, the form of identity represented by the string, as well as the precise syntax and semantics of the string, is protocol specific. While the character encoding schema used to transfer the authorization identity string in the authentication exchange is mechanism specific, mechanisms are expected to be capable of carrying the entire Unicode repertoire (with the exception of the NUL character). A literal of the form "cn=..." is only valid if the protocol defines it to be valid. The particular SASL mechanism must support it for it to be valid.