Initial Auth Realm Fall-back

[Greg Hudson]

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?

> [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.

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.