Some characters cannot be used in SASL ids processed by the SASL mechanism that olcAuthzRegexp configures. It is undocumented which characters are allowed and which are not. See also ITS bug number 9495.
(In reply to Karl O. Pinc from comment #0) > Some characters cannot be used in SASL ids processed by the SASL mechanism > that olcAuthzRegexp configures. It is undocumented which characters are > allowed and which are not. > > See also ITS bug number 9495. As already noted in the RFC you referenced in #9495, the character encodings are mechanism-specific. So look in the SASL documentation.
On Fri, 25 Jun 2021 22:18:58 +0000 openldap-its@openldap.org wrote: knowing one it's not obvious > https://bugs.openldap.org/show_bug.cgi?id=9594 > > Howard Chu <hyc@openldap.org> changed: > As already noted in the RFC you referenced in #9495, the character > encodings are mechanism-specific. So look in the SASL documentation. I believe that the SASL mechanism in question is contained entirely within OpenLDAP and is not fully documented. I appreciate your attention. It would be helpful to know of any errors in the following: OpenLDAP can use olcAuthzRegexp to convert a SASL id directly to a DN. The supplied credentials can then validate against the password of the DN's entry in the LDAP database. This seems contained entirely within OpenLDAP. I don't know the name of the mechanism or any way to invoke it other than by default. And I can't find an LDAP RFC that seems relevant. If there is such an RFC it would be helpful to mention it somewhere in the OpenLDAP documentation related to SASL and/or olcAuthzRegexp. After further thought, there seem to be 2 things that are undocumented about olcAuthzRegexp. Each (might) imply the other but neither is obvious. It's hard to say but I think both need to be documented because, to the ordinary LDAP admin for whom administering LDAP is only a part of their job, knowing one fact it's not obvious that the other is also the case. In uses of olcAuthzRegexp, when direct DN mapping with a string like "dn:..." as the 2nd argument, it seems that some characters substituted in replacement placeholders ($1, etc) are escaped. Seemingly per RFC4514 section 2.4. I can't say whether values substituted into URIs have some characters URI/XML escaped. In any case, the user's input is transformed and the transformation should be documented so that it's clear what happens in corner cases with atypical SASL id input. The second is that the replacement regexp placeholders ($1, etc) cannot appear in arbitrary locations in "..." part of configurations doing direct DN mapping, like: olcAuthzRegexp "UID=([^,]*),CN=.*" "dn:..." You're clearly allowed to substitute into "data values", like: olcAuthzRegexp "UID=([^,]*),CN=.*""dn:UID=$1,OU=Accounts,DC=example,DC=com" You cannot make arbitrary mappings to DNs. As a trivial example, you can't write an identity transformation: olcAuthzRegexp "UID=([^,]*),CN=.*" "dn:$1" The escaping prevents the generation of a valid DN. And you can't generate one or more "attr=value" components of a DN: olcAuthzRegexp "UID=([^,]*),CN=.*" "dn:$1,OU=Accounts,DC=example,DC=com" When generating test cases I found a use for generating arbitrary "attr0=value0,attr1=value1" DN components. I can't say if this is really useful in production settings but it seems like it could be. It's unclear whether you're allowed to substitute into "attribute names": olcAuthzRegexp "UID=([^,]*),CN=.*" "dn:$1=Key,OU=Accounts,DC=example,DC=com" I can't say if injecting attribute names, without values, into a DN is useful. ITS#9594 is a complaint that olcAuthzRegexp is limited in the transformations it supports when doing direct DN mapping. If you don't want to remove the limits, an entirely reasonable choice given the utility of automatic character escaping in what may be common use cases, backwards compatibility, etc., the limits should be documented. (Assuming there is utility, it seems reasonable to be able to specify a "no escape" flag as an additional olcAuthzRegexp argument so as to remove limits. That would be an enhancement request, out of scope of this ITS report, and something I am not now interested in requesting.) Regards, Karl <kop@karlpinc.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
(In reply to Karl O. Pinc from comment #2) > You cannot make arbitrary mappings to DNs. As a trivial > example, you can't write an identity transformation: > > olcAuthzRegexp "UID=([^,]*),CN=.*" "dn:$1" > > The escaping prevents the generation of a valid DN. The UID value must be a valid SASL userID. So again, "what is valid" is specific to the SASL mechanism in use, but there are no SASL mechanisms that use DNs as userIDs. So the above example is never valid. > And you can't generate one or more "attr=value" components of a DN: > > olcAuthzRegexp "UID=([^,]*),CN=.*" "dn:$1,OU=Accounts,DC=example,DC=com" Same applies here.