OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/6757
Full headers

From: b.candler@pobox.com
Subject: SASL canonicalize doesn't work as documented
Compose comment
Download message
State:
0 replies:
7 followups: 1 2 3 4 5 6 7

Major security issue: yes  no

Notes:

Notification:


Date: Thu, 30 Dec 2010 21:36:34 +0000
From: b.candler@pobox.com
To: openldap-its@OpenLDAP.org
Subject: SASL canonicalize doesn't work as documented
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.

(1) If the realm of the client is the same as the default_realm on the server,
then the auth DN is
  uid=kurt,cn=<olcSaslRealm>,cn=gssapi,cn=auth

(2) If the realm of the client is different to the default_realm on the server,
then the auth DN is
  uid=ursula/admin@foreign.realm,cn=<olcSaslRealm>,cn=gssapi,cn=auth

(If olcSaslRealm is unset in the config then cn=<olcSaslRealm> is omitted
entirely)

Some real examples are shown below. I reproduced this in a cross-realm auth
setup with two MIT Kerberos 1.8.1 KDCs. The realms are WS.NSRC.ORG and
REALM3.WS.NSRC.ORG. The server is host noc.ws.nsrc.org and is in realm
WS.NSRC.ORG. It has a keytab for ldap/noc.ws.nsrc.org@WS.NSRC.ORG, and has
olcSaslRealm: EXAMPLE.COM (which is just a junk realm, but it makes it clear
that this isn't used for authentication)

When a client presents a ticket for inst@WS.NSRC.ORG:

do_bind: dn () SASL mech GSSAPI
==> sasl_bind: dn="" mech=<continuing> datalen=32
SASL Canonicalize [conn=1000]: authcid="inst"
slap_sasl_getdn: conn 1000 id=inst [len=4]
=> ldap_dn2bv(16)
<= ldap_dn2bv(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0
slap_sasl_getdn: u:id converted to uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth
>>> dnNormalize: <uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth>
=> ldap_bv2dn(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth,0)
<= ldap_bv2dn(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=inst,cn=example.com,cn=gssapi,cn=auth)=0
<<< dnNormalize: <uid=inst,cn=example.com,cn=gssapi,cn=auth>
==>slap_sasl2dn: converting SASL name
uid=inst,cn=example.com,cn=gssapi,cn=auth
to a DN
<==slap_sasl2dn: Converted SASL name to <nothing>
SASL Canonicalize [conn=1000]:
slapAuthcDN="uid=inst,cn=example.com,cn=gssapi,cn=auth"
SASL proxy authorize [conn=1000]: authcid="inst@EXAMPLE.COM"
authzid="inst@EXAMPLE.COM"
SASL Authorize [conn=1000]:  proxy authorization allowed authzDN=""
send_ldap_sasl: err=0 len=-1
do_bind: SASL/GSSAPI bind: dn="uid=inst,cn=example.com,cn=gssapi,cn=auth"
sasl_ssf=56

When a client presents a ticket for student@REALM3.WS.NSRC.ORG:

do_bind: dn () SASL mech GSSAPI
==> sasl_bind: dn="" mech=<continuing> datalen=32
SASL Canonicalize [conn=1000]: authcid="student@REALM3.WS.NSRC.ORG"
slap_sasl_getdn: conn 1000 id=student@REALM3.WS.NSRC.ORG [len=26]
=> ldap_dn2bv(16)
<= ldap_dn2bv(uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0
slap_sasl_getdn: u:id converted to
uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth
>>> dnNormalize:
<uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth>
=> ldap_bv2dn(uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth,0)
<= ldap_bv2dn(uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth)=0
<<< dnNormalize:
<uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth>
==>slap_sasl2dn: converting SASL name
uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth to a DN
<==slap_sasl2dn: Converted SASL name to <nothing>
SASL Canonicalize [conn=1000]:
slapAuthcDN="uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth"
SASL proxy authorize [conn=1000]: authcid="student@REALM3.WS.NSRC.ORG"
authzid="student@REALM3.WS.NSRC.ORG"
SASL Authorize [conn=1000]:  proxy authorization allowed authzDN=""
send_ldap_sasl: err=0 len=-1
do_bind: SASL/GSSAPI bind:
dn="uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth"
sasl_ssf=56

You can see that the authcid from libsasl omits the realm when it's the same as
the server's, and includes the realm when it's different. However openldap does
not split out into "uid=ursula/admin,cn=foreign.realm" as the documentation
says.

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)

Followup 1

Download message
Date: Thu, 30 Dec 2010 17:27:08 -0800
From: Howard Chu <hyc@symas.com>
To: b.candler@pobox.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6757) SASL canonicalize doesn't work as documented
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/



Followup 2

Download message
Date: Fri, 31 Dec 2010 13:52:46 +0000
From: Brian Candler <B.Candler@pobox.com>
To: Howard Chu <hyc@symas.com>
Cc: openldap-its@openldap.org
Subject: Re: (ITS#6757) SASL canonicalize doesn't work as documented
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.



Followup 3

Download message
Date: Sun, 2 Jan 2011 20:51:01 +0000
From: Brian Candler <B.Candler@pobox.com>
To: Howard Chu <hyc@symas.com>
Cc: openldap-its@openldap.org
Subject: Re: (ITS#6757) SASL canonicalize doesn't work as documented
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=gssap

Message of length 5028 truncated


Followup 4

Download message
Date: Sun, 02 Jan 2011 19:40:25 -0800
From: Howard Chu <hyc@symas.com>
To: Brian Candler <B.Candler@pobox.com>
CC: openldap-its@openldap.org
Subject: Re: (ITS#6757) SASL canonicalize doesn't work as documented
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/



Followup 5

Download message
Date: Mon, 3 Jan 2011 10:15:04 +0000
From: Brian Candler <B.Candler@pobox.com>
To: Howard Chu <hyc@symas.com>
Cc: openldap-its@openldap.org
Subject: Re: (ITS#6757) SASL canonicalize doesn't work as documented
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

Message of length 6566 truncated


Followup 6

Download message
Date: Mon, 10 Jan 2011 11:48:37 -0800
From: Howard Chu <hyc@symas.com>
To: Brian Candler <B.Candler@pobox.com>
CC: openldap-its@openldap.org
Subject: Re: (ITS#6757) SASL canonicalize doesn't work as documented
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/



Followup 7

Download message
Date: Tue, 11 Jan 2011 09:07:21 +0530
From: Brian Candler <B.Candler@pobox.com>
To: Howard Chu <hyc@symas.com>
Cc: openldap-its@openldap.org
Subject: Re: (ITS#6757) SASL canonicalize doesn't work as documented
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
-------------------------------------------------------------------


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org