KDB and referrals/aliases

[Luke Howard]

So, we need to distinguish between aliases OK and referrals OK, when  
requesting an entry from the KDB. We also need to be conscious that an  
administrative interface might not want to see aliases.

This is how it works in 1.7. Apologies in advance for any confusion!

  * KRB5_KDB_FLAG_CANONICALIZE means both to look up aliases and  
return referrals (notwithstanding the exception below)
  * KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY means that referrals should be  
returned with naming information only (as skeletal principals), rather  
than as cross-realm TGS entries

There are three interesting cases in the KDC path (I'm leaving S4U out  
for now, that is similar to the AS-REQ client path):

  * AS-REQ client lookup
  * AS-REQ server lookup
  * TGS-REQ server lookup

In the AS-REQ client lookup case, we set  
KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY always, and optionally  
KRB5_KDB_FLAG_CANONICALIZE (depending on the setting of the  
canonicalize KDC option).

For both server lookup cases, we set KRB5_KDB_FLAG_CANONICALIZE  
depending on the setting of the canonicalize KDC option.

Novell's DSfW backend always returned aliases in the TGS-REQ server  
lookup path, and used KRB5_KDB_FLAG_CANONICALIZE to determine whether  
to return referrals or not. The MIT LDAP backend patch I proposed  
earlier matched this behaviour.

Another way of looking at this is: only if  
KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY is set should  
KRB5_KDB_FLAG_CANONICALIZE determine whether aliases are returned;  
otherwise, they should always be returned. If  
KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY is not set, then  
KRB5_KDB_FLAG_CANONICALIZE governs only whether referrals should be  
returned; aliases should always be.

The problem here (as Sam has noted) is that this behaviour leaves no  
opportunity for an administrative interface to disable aliases. So, if  
this is important, then we should potentially introduce another flag.

On the point of always setting KRB5_KDB_FLAG_CANONICALIZE in the TGS- 
REQ server lookup path, I suspect we don't want to that, because the  
backend should have the opportunity to not generate referrals.  
(Referral generation may be expensive: for example, in the AD  
information model, this requires running string2key on the cross-realm  
secret.)

Were I doing this again, it would be cleaner to have separate  
LOOKUP_ALIASES and LOOKUP_REFERRALS flags. AS-REQ client would set  
LOOKUP_ALIASES (if the canonicalize KDC option was set), and TGS-REQ  
server would always set LOOKUP_ALIASES. LOOKUP_REFERRALS would be set  
only in the TGS-REQ server path, and then only if the KDC canonicalize  
option was set. However, I'd prefer to not change the existing  
interface if at all possible, out of courtesy to Novell.

Finally, note that for ease of implementation, the backend can always  
return the canonical principal name: the KDC will determine which name  
to return to the client based on its own policy and the setting of the  
canonicalize KDC option.

-- Luke