https://bugs.openldap.org/show_bug.cgi?id=9594
--- Comment #2 from Karl O. Pinc <[email protected]> --- On Fri, 25 Jun 2021 22:18:58 +0000 [email protected] wrote: knowing one it's not obvious > https://bugs.openldap.org/show_bug.cgi?id=9594 > > Howard Chu <[email protected]> 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 <[email protected]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein -- You are receiving this mail because: You are on the CC list for the issue.
