[37721] 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 (Isaac Boukris)
Mon Oct 3 11:04:29 2016

MIME-Version: 1.0
In-Reply-To: <22a014d8-2a7b-0aca-44eb-8cc2f5fac875@mit.edu>
From: Isaac Boukris <iboukris@gmail.com>
Date: Mon, 3 Oct 2016 18:04:12 +0300
Message-ID: <CAC-fF8SgNdMA042XegpKiPVrfpKCpxqKKWS9jKH4EBx+ZiB3dQ@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: kerberos <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

On Mon, Sep 26, 2016 at 7:09 PM, Greg Hudson <ghudson@mit.edu> wrote:
> On 09/25/2016 04:32 PM, Isaac Boukris wrote:
>> 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).


I've now looked further into the constrained delegation case.
Using enterprise name works fine with upn, but I see no
canonicalization happening (even with the flag on, enterprise
name-type is returned in TGS-REP).
This can be seen when using the 'kvno' tool to do constrained
delegation, as it always parses the 'for_user' as an enterprise name.
>From MS-SFU doc it sounds like the KDC copies back the username and
realm from the request (PA-FOR-USER).
________________________________________________
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