b.candler@pobox.com wrote:
> Full_Name: Brian Candler
> Version: 2.4.21
> OS: Ubuntu 10.04.1
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (87.114.104.19)
>
>
> DOcumentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI gives two
> example authorization DNs built from SASL/GSSAPI:
>
> "a user with the Kerberos principal kurt@EXAMPLE.COM would have the associated
> DN:
>          uid=kurt,cn=example.com,cn=gssapi,cn=auth
> and the principal ursula/admin@FOREIGN.REALM would have the associated DN:
>          uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth"
>
> Experimentation shows that the actual behaviour is different.
>
> You could treat this either as a behaviour error or a documentation error - if
> the latter, the olcSaslRealm is pretty useless, because if set it appears in all
> auth DNs (for both local and foreign realms)

Could be a bug, but we're using the parameters as documented by Cyrus. I 
suggest you file this bug report with them instead.

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

I get similar behaviour using Cyrus SASL's sample-client and sample-server:

...
Negotiation complete
Username: student@REALM3.WS.NSRC.ORG
Realm: (NULL)
SSF: 56
...

Now, in sample-server.c, the displayed realm comes from

  result = sasl_getprop(conn, SASL_DEFUSERREALM, (const void **)&data);

which suggests this is intended to be the default realm, not the realm of
the user connecting. And clearly the username does include the Kerberos
realm.

But I'm having difficulty finding the corresponding OpenLDAP code to extract
the realm.  Is it making use of session callbacks, and expects Cyrus to call
slap_sasl_canonicalize (SASL_CB_CANON_USER) with the user_realm parameter?

Regards,

Brian.

I've been doing some analysis of the Cyrus SASL code.

When you say "we're using the parameters as documented by Cyrus", I presume
the documentation you refer to is the comments within the source, in which
case this all hinges on one line in include/sasl.h:

 *  user_realm    -- the user realm (may be NULL in case of client)

(in the parameter list for the SASL_CB_CANON_USER callback). So what's meant
by "the user realm"?

When the callback is actually made (in lib/canonusr.c), the value passed is
sconn->user_realm.  This appears to be the value you get from sasl_getprop()
with SASL_DEFUSERREALM.

The user_realm value can be set in sasl_server_new (lib/server.c) and
sasl_setprop (lib/common.c).

There is a further description of realms in sasl/include.h:

 * IMPORTANT NOTE: server realms / username syntax
 * ... A single server may support multiple realms.  If the
 * server knows the realm at connection creation time (e.g., a server
 * with multiple IP addresses tightly binds one address to a specific
 * realm) then that realm must be passed in the user_realm field of
 * the sasl_server_new call.  If user_realm is non-empty and an
 * unqualified user name is supplied, then the canon_user facility is
 * expected to append "@" and user_realm to the user name.

That is: it seems to me fairly clear that the purpose of user_realm is to
provide a *default* realm which can be appended to the username when
canonicalizing it.

As a specific example, the code in _canonuser_internal() appends
@<user_realm> if the username doesn't contain '@'.

Furthermore, it's also clear from this that the username (SASL_USERNAME) is
intended to include '@' and a realm; Cyrus is not designed to split it into
a username part and a realm part.  This matches what I see when using Cyrus
SASL's standalone "sample-server" and "sample-client" programs, with GSSAPI
and a client with a kerberos ticket from a different realm to the server:

...
Negotiation complete
Username: student@REALM3.WS.NSRC.ORG    << sasl_getprop SASL_USERNAME
Realm: (NULL)                           << sasl_getprop SASL_DEFUSERREALM
SSF: 56
...

There's a full transcript of this example at
http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2010-December/002177.html

Next, looking at plugins/gssapi.c: AFAICS it doesn't make use of user_realm,
but does ask GSSAPI if the name without realm is the same as the name with
realm, and if so returns the name with the realm stripped off.

        /* If the id contains a realm get the identifier for the user
           without the realm and see if it's the same id (i.e. 
           tmartin == tmartin@ANDREW.CMU.EDU. If this is the case we just want
           to return the id (i.e. just "tmartin" */

So, there is code in the GSSAPI plugin to *strip* the realm if it's the same
as the default, but I don't think there's code to *separate* the username
from the realm if the realm is foreign.

Putting all this together: it seems to me that the "user_realm" you see is
really just the configured default realm for the session; and that when you
query SASL_USERNAME for a Kerberos client, you will see "username" if it's
in the default realm, and "username@foreign.realm" for other realms.  And
this matches what I observe when testing this in OpenLDAP.

As you suggested, I did bring this up on the cyrus-sasl mailing list
(archive URL above), but no replies have been forthcoming so far.

Now, if my understanding of the user_realm parameter is correct, I think
there are two ways to make OpenLDAP's behaviour consistent with its
documentation.

(1) Stick more or less with the current behaviour, and change the
documentation to say that you'll get
    uid=ursula/admin@foreign.realm,cn=gssapi,cn=auth
for foreign realms.

However, the odd thing about the current behaviour is that setting
olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into
the auth DN, regardless of whether it's local or foreign.  That's not very
useful.

I think it would make more sense, if olcSaslRealm is present, to use it to
*qualify* usernames which don't have a realm.

     uid=kurt,cn=gssapi,cn=auth
---> uid=kurt@<olcsaslrealm>,cn=gssapi,cn=auth

i.e. change the canonicalize function to append @user_realm if the username
doesn't contain '@'.

This would be useful if you want to undo the Cyrus SASL GSSAPI behaviour of
stripping off the default realm.

(2) Change the OpenLDAP behaviour so that it matches the documentation at
http://www.openldap.org/doc/admin24/sasl.html#GSSAPI

To do this, the canonicalize function would have to parse the username,
splitting it on '@' to separate username from realm, so that you would get

    uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth

If the username doesn't contain '@', but olcSaslRealm is set, then I suggest
you insert that instead:

    uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth

And if there's no '@' and no olcSaslRealm, then just leave it alone:

    uid=kurt,cn=gssapi,cn=auth

Regards, Brian.

Brian Candler wrote:
> Now, if my understanding of the user_realm parameter is correct, I think
> there are two ways to make OpenLDAP's behaviour consistent with its
> documentation.
>
> (1) Stick more or less with the current behaviour, and change the
> documentation to say that you'll get
>      uid=ursula/admin@foreign.realm,cn=gssapi,cn=auth
> for foreign realms.
>
> However, the odd thing about the current behaviour is that setting
> olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into
> the auth DN, regardless of whether it's local or foreign.  That's not very
> useful.

Note that it's not the OpenLDAP code that's sticking this in there; it's the 
Cyrus code that's returning this realm in the callback. IMO our job is to 
faithfully return what the Cyrus library gave us.

> I think it would make more sense, if olcSaslRealm is present, to use it to
> *qualify* usernames which don't have a realm.

That decision is made by the Cyrus library, not us.

>       uid=kurt,cn=gssapi,cn=auth
> --->  uid=kurt@<olcsaslrealm>,cn=gssapi,cn=auth
>
> i.e. change the canonicalize function to append @user_realm if the username
> doesn't contain '@'.
>
> This would be useful if you want to undo the Cyrus SASL GSSAPI behaviour of
> stripping off the default realm.
>
> (2) Change the OpenLDAP behaviour so that it matches the documentation at
> http://www.openldap.org/doc/admin24/sasl.html#GSSAPI
>
> To do this, the canonicalize function would have to parse the username,
> splitting it on '@' to separate username from realm, so that you would get
>
>      uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth
>
> If the username doesn't contain '@', but olcSaslRealm is set, then I suggest
> you insert that instead:
>
>      uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth
>
> And if there's no '@' and no olcSaslRealm, then just leave it alone:
>
>      uid=kurt,cn=gssapi,cn=auth

This has been discussed at great length, read the -devel archives from 9 or 10 
years ago. The fact is that the SASL specification doesn't reserve '@' as a 
special character and there is no guarantee that this is actually a realm 
separator. There are plenty of authentication mechanisms where '@' is an 
integral part of the username. This suggestion simply won't fly.

I don't believe we have any freedom to make any code changes here; feel free 
to suggest verbiage changes for the documentation.

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

On Sun, Jan 02, 2011 at 07:40:25PM -0800, Howard Chu wrote:
> >(1) Stick more or less with the current behaviour, and change the
> >documentation to say that you'll get
> >     uid=ursula/admin@foreign.realm,cn=gssapi,cn=auth
> >for foreign realms.
> >
> >However, the odd thing about the current behaviour is that setting
> >olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into
> >the auth DN, regardless of whether it's local or foreign.  That's not very
> >useful.
> 
> Note that it's not the OpenLDAP code that's sticking this in there;
> it's the Cyrus code that's returning this realm in the callback. IMO
> our job is to faithfully return what the Cyrus library gave us.

The Cyrus library is faithfully passing on the *default* user_realm that
you originally passed to sasl_server_new() in servers/slapd/sasl.c

(which is global_realm, a.k.a. olcSaslRealm)

Then OpenLDAP is sticking it into the authDN, in slap_sasl_getdn()

> >I think it would make more sense, if olcSaslRealm is present, to use it to
> >*qualify* usernames which don't have a realm.
> 
> That decision is made by the Cyrus library, not us.

It does not mandate what you do with the user_realm. You are free to ignore
it, use it to qualify usernames which have no realm, or whatever.

The documentation for canon_user (in include/sasl.h) says:

 * If user_realm is non-empty and an
 * unqualified user name is supplied, then the canon_user facility is
 * expected to append "@" and user_realm to the user name.  The canon_user
 * facility may treat other characters such as "%" as equivalent to "@".

Here is _canonuser_internal from lib/canonusr.c in Cyrus SASL:

static int _canonuser_internal(const sasl_utils_t *utils,
                               const char *user, unsigned ulen,
                               unsigned flags __attribute__((unused)),
                               char *out_user,
                               unsigned out_umax, unsigned *out_ulen) 
...
    /* Need to append realm if necessary (see sasl.h) */
    if(sconn && sconn->user_realm && !strchr(user, '@')) {
        u_apprealm = (unsigned) strlen(sconn->user_realm) + 1;
    }
    
    /* Now Copy */
    memcpy(out_user, begin_u, MIN(ulen, out_umax));
    if(sconn && u_apprealm) {
        if(ulen >= out_umax) return SASL_BUFOVER;
        out_user[ulen] = '@';
        memcpy(&(out_user[ulen+1]), sconn->user_realm,
               MIN(u_apprealm-1, out_umax-ulen-1));
    }
    out_user[MIN(ulen + u_apprealm,out_umax)] = '\0';

> >(2) Change the OpenLDAP behaviour so that it matches the documentation at
> >http://www.openldap.org/doc/admin24/sasl.html#GSSAPI
> >
> >To do this, the canonicalize function would have to parse the username,
> >splitting it on '@' to separate username from realm, so that you would get
> >
> >     uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth
> >
> >If the username doesn't contain '@', but olcSaslRealm is set, then I suggest
> >you insert that instead:
> >
> >     uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth
> >
> >And if there's no '@' and no olcSaslRealm, then just leave it alone:
> >
> >     uid=kurt,cn=gssapi,cn=auth
> 
> This has been discussed at great length, read the -devel archives
> from 9 or 10 years ago. The fact is that the SASL specification
> doesn't reserve '@' as a special character and there is no guarantee
> that this is actually a realm separator. There are plenty of
> authentication mechanisms where '@' is an integral part of the
> username. This suggestion simply won't fly.

I suspect that's why canon_user was made pluggable in the first place; if
you have your own idea of what constitutes a username with or without a
realm then you code for it there.

In Cyrus-SASL, plugins/gssapi.c has it hard-coded:

        if (strchr((char *) name_token.value, (int) '@') != NULL) {
...
            /* cut off string at '@' */
            (strchr(name_without_realm.value,'@'))[0] = '\0';

I agree that non-Kerberos SASL mechanisms might have different username
formats; and hence, without additional configuration, OpenLDAP cannot split
arbitrary SASL usernames into uid=user,cn=realm.

However the current behaviour of olcSaslRealm isn't useful either, since it
just gives you uid=user[@realm],cn=olcSaslRealm.

I think the most appropriate behaviour for olcSaslRealm would be for it to
qualify usernames that don't contain '@' - and if your app doesn't use
usernames with '@', then don't set olcSaslRealm.

> 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.

--- 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
 

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/

On Mon, Jan 10, 2011 at 11:48:37AM -0800, Howard Chu wrote:
> >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.

True, although this text is under the GSSAPI subheading so I would read it
as specific to the GSSAPI mechanism.

> For GSSAPI it should probably just say
> not to specify olcSaslRealm at all since the mechanism has its own
> notion of realms already.

If they are using a mixture of SASL mechanisms then they might need to set
olcSaslRealm for the benefit of another one.

How about this:

-------------------------------------------------------------------
If you are using only GSSAPI authentication then you should not configure
olcSaslRealm. If you do, 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
-------------------------------------------------------------------

moved from Incoming to Documentation

We also did some commits for SASL_CANON not sure if that's relevant:

 Fixed libldap with SASL_NOCANON=on and ldapi connections (ITS#7585)
                Fixed ldap.conf(5) missing information on SASL_NOCANON option (ITS#7177)
        Fixed tools to not clobber SASL_NOCANON (ITS#7271)

fixed in master

Commits: 
  • 549d6a2b 
by Howard Chu at 2021-02-15T14:11:44+00:00 
ITS#6757 fix GSSAPI realm examples