Multiple principals from different realms via kinit?

[Nordgren, Bryce L -FS]

> -----Original Message-----
> From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On
> Behalf Of Greg Hudson
> Sent: Thursday, August 28, 2014 10:30 AM
> To: Cedric Blancher; <kerberos at mit.edu>
> Subject: Re: Multiple principals from different realms via kinit?
>
> NFS is a special case, as the program making the decision doesn't have access
> to the environment of the process which made the filesystem call.
>  I'm not sure what the state of the art is here; typically gssd needs some
> knowledge of where the login system puts credentials, and it might make a
> choice based on the username.

I think the golden rule is that each application must be self-consistent, repeatable and deterministic, but not necessarily the same. NFS is special not only for the reason mentioned above, but also because it supports three way mapping between GSS Auth Name (Kerberos principal), local system ID, and a "portable" NFS ID. It also supports a many-to-one mapping from gss auth names to local system ID/NFS ID. Many to one means that once you provide a Kerberos principal, there really is no choice about which Local ID or NFS ID are used. NFS doesn't perform initial authentication, so it doesn't have to worry about the reverse process.

Sssd allows for static configuration of domains, each of which has a one-to-one mapping between local ID and Kerberos principal. The mapping is performed by a configurable regexp. Connection information for the KDC in each domain may be overridden.

Apache's mod_auth_kerb provides the authenticated Kerberos principal (name at REALM) as the REMOTE_USER variable, which applications can remap to usernames as they please (http://www.mediawiki.org/wiki/Extension:LDAP_Authentication/Kerberos_Configuration_Examples).

So the short answer is: it's application dependent. The onus is on the application to translate a Kerberos principal into an identity locally meaningful. However, the application doesn't have access to your credential cache. If you (or the client you're using) supply an identity that the application doesn't (can't) recognize, then expect it to fail. The client side of the application protocol should make it a point to try all your cached identities and/or allow you to specify one you haven't "kinit"ed yet.

Bryce






This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.