KDB and referrals/aliases
lukeh at padl.com
Tue Sep 1 13:42:11 EDT 2009
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
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.
More information about the krbdev