Re: (ITS#6757) SASL canonicalize doesn't work as documented

[hyc@symas.com]

Brian Candler wrote:
> On Sun, Jan 02, 2011 at 07:40:25PM -0800, Howard Chu wrote:
>> I don't believe we have any freedom to make any code changes here;
>> feel free to suggest verbiage changes for the documentation.
>
> No problem. I propose the following to bring the docs in line with
> behaviour.

This looks a bit too specific, the olcSaslRealm setting affects other SASL 
mechanisms too. For GSSAPI it should probably just say not to specify 
olcSaslRealm at all since the mechanism has its own notion of realms already. 
Most likely you would only set this for something like DIGEST-MD5 which uses 
realms but doesn't inherently know its own realm name.

> --- sasl.sdf.orig	2011-01-03 09:45:55.754879001 +0000
> +++ sasl.sdf	2011-01-03 10:07:34.808208000 +0000
> @@ -135,25 +135,35 @@
>   For the purposes of authentication and authorization, {{slapd}}(8)
>   associates an authentication request DN of the form:
>
> ->	uid=<primary[/instance]>,cn=<realm>,cn=gssapi,cn=auth
> +>	uid=<primary[/instance][@realm]>,cn=gssapi,cn=auth
> +
> +The realm is omitted by Cyrus SASL if it's equal to the default realm of the
> +server in {{FILE:/etc/krb5.conf}}.
>
>   Continuing our example, a user with the Kerberos principal
>   {{EX:kurt@EXAMPLE.COM}} would have the associated DN:
>
> ->	uid=kurt,cn=example.com,cn=gssapi,cn=auth
> +>	uid=kurt,cn=gssapi,cn=auth
>
>   and the principal {{EX:ursula/admin@FOREIGN.REALM}} would have the
>   associated DN:
>
> ->	uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth
> +>	uid=ursula/admin@foreign.realm,cn=gssapi,cn=auth
>
>
> -The authentication request DN can be used directly ACLs and
> +The authentication request DN can be used directly in ACLs and
>   {{EX:groupOfNames}} "member" attributes, since it is of legitimate
>   LDAP DN format.  Or alternatively, the authentication DN could be
>   mapped before use.  See the section {{SECT:Mapping Authentication
>   Identities}} for details.
>
> +If you configure olcSaslRealm then it is always inserted as an extra
> +component in the authorization DN, regardless of the realm of the client.
> +For example, if you set olcSaslRealm to {{EX:example.com}} then you will
> +get:
> +
> +>	uid=kurt,cn=example.com,cn=gssapi,cn=auth
> +>	uid=ursula/admin@foreign.realm,cn=example.com,cn=gssapi,cn=auth
>
>   H3: KERBEROS_V4
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/