Using enterprise principal name in GSS-API

[Isaac Boukris]

Hi Greg,

On Fri, Sep 23, 2016 at 5:50 PM, Greg Hudson <ghudson at mit.edu> wrote:
> On 09/23/2016 03:52 AM, Isaac Boukris wrote:
>> Maybe we need a new gss name type oid like GSS_NT_ENTERPRISE_NAME,
>> though I guess it's more complicated than it sounds :)
>
> I think that might be reasonable for this use case.  I've seen requests
> to be able to import enterprise principal names before, although (IIRC)
> sometimes for use cases where it might not have made as much sense.
>
> The concerns I can immediately think of are:
>
> * Is there any prior art we should try to be compatible with?  I don't
> see any in Heimdal, and MS doesn't directly implement GSS-API, so I
> don't think there is.

Indeed.

> * If someone uses one of these GSS names in a different scenario (e.g.
> for an acceptor credential), will it fail gracefully?  I believe that's
> generally the case.

Perhaps we'll need to fail gss_canonicalize_name() since we cannot
know what MN it would produce on acceptor side.

> * Does canonicalization at cred acquisition time pose any issues for the
> GSS-API model, because the name you get creds for won't be the same as
> the name you asked for?  gss_acquire_cred_with_password() is an
> extension, not a standardized part of the API, so I think it shouldn't
> be a problem.

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).
When using enterprise name with -E, the client library allows for
embedded '@' sign in the client-name and sends it in AS request with
KRB5-NT-ENTERPRISE-PRINCIPAL name-type, but it does not request
canonicalization (flag off, unless -C was given or canonicalization is
set to true in krb5.conf).

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.
This still has the advantage of letting the KDC to lookup the user by
UPN in local realm (especially when different UPN suffixes are used in
local realm).

If however, the user is not found on local realm, the KDC returns an
error but also sets the 'crealm' field in the AS reply to a better
realm and the client tries to get credentials from this realm's KDC.
So the only canonicalization implied so far is perhaps for the realm name.

If canonicalization flag is on (-C or conf), then the (last) KDC
replies with a KRB5-NT-PRINCIPAL name-type containing the
sAMAccountName.
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

Also note, that I found one case where canonicalization occurs (when
requested) even using regular KRB5-NT-PRINCIPAL name (the name
changes, not the type).

We probably want to support both enterprise-name and canonicalization
in GSS-API (the latter could be set via conf).
So far I couldn't see find in GSS-API doc any problem with, let's say
returning a canonicalized name (e.g. in inquire_cred) different from
what was imported at acquire.

Thanks,
Isaac B.