[37707] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Using enterprise principal name in GSS-API

daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Sep 26 12:09:21 2016

To: Isaac Boukris <iboukris@gmail.com>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <22a014d8-2a7b-0aca-44eb-8cc2f5fac875@mit.edu>
Date: Mon, 26 Sep 2016 12:09:00 -0400
MIME-Version: 1.0
In-Reply-To: <CAC-fF8T=LCrTiNWJci0abT=aZqUHtJMcE83PHPZHPLPKpPMHRA@mail.gmail.com>
Cc: kerberos <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

On 09/25/2016 04:32 PM, Isaac Boukris wrote:
> The more a look at the code and on wire traffic, I think
> enterprise-name and canonicalization are different things (although
> related).
> Here is what my tests against AD (w2k3) seem to show so far.
> 
> First, the 'kinit' man page says -E implies -C but it doesn't seem to
> be correct (according to observations).

I see that we don't set the canonicalize KDC option when -E is given.
Our KDC implementation treats AS requests as having the canonicalize
flag if the client principal name type is KRB5-NT-ENTERPRISE-PRINCIPAL,
with the comment "Note that according to the referrals draft we should
always canonicalize enterprise principal names".  My reading of RFC 6806
is more ambiguous; in section 5 (defining the enterprise name type) it
says "The KDC will recognize this name type and then transform the
requested name into the true principal name if the client account
resides in the local realm."  But in section 6 (defining the
canonicalize flag) it doesn't say that the canonicalize flag should be
inferred from the principal type, and its example AS-REQ scenario
includes both an enterprise client principal name and the canonicalize flag.

> In such a case (no canonicalization), if the user is found, the KDC
> returns AS reply with the exact name and name-type (enterprise) as
> requested.

Interesting.  That's probably not a behavior we want; enterprise names
should ideally only exist on the edge of the krb5 protocol.  I also
don't think that's the behavior we would see with an MIT krb5 KDC
(combined with a third-party KDB module that implements enterprise
principal name lookup).

> Note that if canonicalization is requested in GSS-API (via conf), then
> my trick above (changing krb5_gss_import_name) doesn't work, I get:
> gss_acquire_cred_with_password(): Invalid credential was supplied
> Principal in credential cache does not match desired name

We would probably need to adjust gss_acquire_cred_with_password().

> We probably want to support both enterprise-name and canonicalization
> in GSS-API (the latter could be set via conf).

I think perhaps we should be setting the canonicalize option whenever we
make an AS-REQ with an enterprise client principal name, although I'm
not entirely confident about this because Heimdal doesn't seem to do it.
 (Heimdal's kinit actually seems to do the reverse; its kinit
--canonicalize parses the client principal as enterprise even if
--enterprise isn't given.)

I'm not sure how gss_acquire_cred_with_password() with its current
signature could express a desire for the canonicalize flag, other than
by importing an enterprise name.
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post