[37700] in Kerberos
Re: Using enterprise principal name in GSS-API
daemon@ATHENA.MIT.EDU (Isaac Boukris)
Fri Sep 23 03:52:43 2016
MIME-Version: 1.0
In-Reply-To: <CAC-fF8RM+XJborxV58Oh0Tr7Ku7pU4P7XSo+poX1p3yjTb_z7A@mail.gmail.com>
From: Isaac Boukris <iboukris@gmail.com>
Date: Fri, 23 Sep 2016 10:52:24 +0300
Message-ID: <CAC-fF8Q9p_5-u-rVf=qk7n4D0o2=GyHUJfYZuFw=7yed64BD9w@mail.gmail.com>
To: kerberos <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Hi again,
On Wed, Sep 21, 2016 at 12:07 AM, Isaac Boukris <iboukris@gmail.com> wrote:
> Hi all,
>
> Is there a way to support name canonicalization (like kinit -E) when
> acquiring creds via gss_acquire_cred_with_password() and
> gss_acquire_cred_impersonate_name() ?
>
> The use case is to use userPrincipalName for client name against AD.
I've found RFC 4768 already laments the lack of enterprise names in
GSS-API (and raises some concerns, mainly ACL related).
RFC 6860 on the other hand says nothing about GSS-API.
Technically, if I change krb5_gss_import_name() to pass
KRB5_PRINCIPAL_PARSE_ENTERPRISE flag when parsing the name, then both
aforementioned functions work fine with UPN (even when the UPN suffix
differs from realm name).
Maybe we need a new gss name type oid like GSS_NT_ENTERPRISE_NAME,
though I guess it's more complicated than it sounds :)
Thanks and regards.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
