Initial Auth Realm Fall-back

[Shawn M Emery]

On 08/19/13 09:04 AM, Greg Hudson wrote:
> On 08/19/2013 02:39 AM, Shawn M Emery wrote:
>> Wanting to get feed-back on a proposal for initial authentication
>> through multiple realms when the user may not know which realm or domain
>> that they reside.  This is key, given that client referrals do not work
>> unless a UPN suffix is provided.
> Can you elaborate on this?  Are you talking about Active Directory
> behavior or client behavior, when you say that AS referrals without UPNs
> don't work?

Server side client referrals for AD requires that the client name 
contain a UPN suffix in order to trigger referrals.

>> [libdefaults]
>>           default_realm = DEV.EXAMPLE.COM
>>           fallback_realms = CORP.EXAMPLE.COM ACCT.EXAMPLE.COM
>>
>> where user foo resides in the ACCT realm and the system has service keys
>> in the DEV realm.  With this configuration when user foo authenticates
>> to the system the default realm DEV is tried.  When DEV returns
>> KDC_ERR_C_PRINCIPAL_UNKNOWN, the new algorithm tries and fails with the
>> CORP realm request, and succeeds on the third request to the ACCT realm.
> I can see a couple of concerns off the top of my head:
>
> 1. There probably wouldn't be any security guarantees regarding the
> shadowing of users between realms (possibly with FAST, but only if the
> implementation were very careful).  An attacker could pretty easily
> cause a fallback from DEV to ACCT, for a user who actually exists in
> DEV.  The worst attack I can imagine is getting a client to send an OTP
> PIN and value to ACCT for a user in DEV or CORP, which may not be a huge
> deal.

I believe that customers are aware that user name collisions are evil in 
this type of configuration whether they are using the realm option for 
pam_krb5 or the proposed Kerberos configuration. Inadvertent collisions 
will yield authentication errors where the user's actual realm is not 
first.  For collisions from a compromised realm, yes, there would be 
unintended access for the targeted user(s), but subsequent access to 
services would still require an auth to local mapping for principals 
outside of the service's default realm.

> 2. Getting this to work right with FAST seems tricky.  You would need an
> armor ticket for each potential realm.  The current command-line
> interface for FAST kinit (the -T option) wouldn't be adequate.

In addition, I don't think that this solution would scale very well in 
our customer's environment.

Shawn.
--