https://bugs.openldap.org/show_bug.cgi?id=9495
Howard Chu <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|SUSPENDED |INVALID --- Comment #5 from Howard Chu <[email protected]> --- (In reply to Karl O. Pinc from comment #3) > On Mon, 14 Jun 2021 16:39:43 +0000 > [email protected] wrote: > > > https://bugs.openldap.org/show_bug.cgi?id=9495 > > > > Quanah Gibson-Mount <[email protected]> changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > Resolution|--- |WONTFIX > > Status|UNCONFIRMED |RESOLVED > > > > --- Comment #2 from Quanah Gibson-Mount <[email protected]> --- > > 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. -- You are receiving this mail because: You are on the CC list for the issue.
