[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: [JunkMail] Re: Bug in LDAP_CONTROL_PROXY_AUTHZ (ITS#2871)

On Thu, 18 Dec 2003, Howard Chu wrote:

> > -----Original Message-----
> > From: owner-openldap-bugs@OpenLDAP.org
> > [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of igor@ipass.net
> > Thanks.
> >
> > Is this patch going to be backported to 2.1.x?
> I think the <absent mech> patch should be backported. I don't think we've
> resolved the realm handling satisfactorily yet.
> The client "-R" option can only ever affect the DIGEST-MD5 mech, it's not
> used anywhere else. It can only have any effect if the server supplies more
> than one realm in the DIGEST-MD5 challenge. The Cyrus DIGEST-MD5 mech never
> supplies more than one realm. I don't know if anyone else's SASL
> implementation behaves differently, but my tendency is to completely ignore
> this realm in any further thinking, as the Cyrus code already ignores it.
> The realm-embedded-in-the-authID trick that Cyrus uses is not documented by
> any of the SASL mechanism RFCs. I think we should ignore this as well, and
> never do any parsing of the provided authIDs. Even for Kerberos, which has
> explicit realms, Cyrus leaves the realm part in the username when it's a
> non-default realm.
> So, our SASL DNs should only ever be of the form:
> 	uid=<username>,cn=<mech>,cn=auth
> Any objections?

This sounds reasonable to me.

This will potentially break slapd.conf for some folks, so I suggest that
the new SASL DNs be noted in the release notes for the new version.