Initial Auth Realm Fall-back

Henry B. Hotz hotz at
Mon Aug 19 16:35:06 EDT 2013

Shouldn't the fallback option be in [appdefaults] instead?

I'm not sure I have a general problem, assuming the default behavior is no-fallback.  For actual deployment, it seems like a can of worms, and I'm not sure I can identify what they all are.

For the specific case of all the realms satisfying the NIST 800-63 constraints on cross-realm relationships I think it's OK.  (From memory: that's all realms under the same administrative control, and all usernames synchronized, but don't hold me to it.)

On Aug 19, 2013, at 9:19 AM, <krbdev-request at> wrote:

> Date: Mon, 19 Aug 2013 00:39:47 -0600
> From: Shawn M Emery <shawn.emery at>
> Subject: Initial Auth Realm Fall-back
> To: krbdev at
> Message-ID: <5211BDB3.8080006 at>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 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.  Currently this configuration is 
> augmented with the use of the realm option for pam_krb5, which is not 
> optimal given that pam_krb5 should not entail Kerberos configuration and 
> this solution does not support kinit/gic applications.
> The proposed solution would be a white-list set of the possible realms 
> used on the authenticating system.  For example:
> $ cat /etc/krb5/krb5.conf
> [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.
> Shawn.

The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at, or hbhotz at

More information about the krbdev mailing list