kdc ldap referral handling broken

[Nico Williams]

On Tue, Mar 20, 2012 at 11:23 AM, Greg Hudson <ghudson at mit.edu> wrote:
> On 03/18/2012 09:11 PM, Paul B. Henson wrote:
>> So if any dev had a minute to take a look at the proposed design and
>> comment on whether they'd be likely to accept a patch implementing it
>> we'd appreciate it.
>
> I've had a chance to discuss this in a team meeting, and the best answer
> I can give is that we have some reservations about how useful and how
> risky this would be.
>
> 1. Slave KDCs would be attempting to write to the master with some
> frequency (every successful preauthenticated AS request if
> disable_last_success isn't turned on, and every failed preauthenticated
> AS request if disable_lockout isn't set).  If the master KDC host goes
> down, the slave KDCs would probably become useless due to timeouts
> attempting to contact the master.
>
> 2. Given the relatively high frequency of referrals to the master, there
> would be a strong temptation to keep the referred connections open to
> avoid constantly reconnecting and rebinding.  This would raise the risk
> of coding error causing those cached connections to be used for the
> wrong operations.

But... you need to do that for searches anyways, no?  (It suppose not
with CLDAP.)

> Architecturally, it seems superior to arrange for the attributes written
> to by a KDC to be non-replicated.  Unfortunately, I can't find any
> evidence that OpenLDAP supports this.

Architecturally it seems best to let the LDAP DS take care of
multi-mastering.  Some can, evidently.  But it seems to me that LDAP
servers are free to rely on referrals to achieve this, in which case
the KDC kinda has to follow referrals then...

LDAP semantics (atomic, one-object transactions) basically require
that a multi-master DSes engage in distributed locking, proxy to a
single master, or refer clients to a single master.

If you don't follow the referral then the user loses with any LDAP
implementation that relies on referrals for write operations.

To follow the referral is somewhat painful, sadly, because
ldap_open/init() is synchronous.  To get around this you'd have to
have a worker thread to open LDAP connections, but then, you already
need that anyways.

Given all this I think it'd be better for KDCs to follow referrals on
write operations.  It may also be desirable to chase referrals in
search results (e.g., to support partial/in-progress replicas).

The hard part is evaluating the propriety of a given referral.  The
KDC can do very little to decide whether to follow a given referral or
not, but the simplest thing is to check that only the server in the
referral URL has changed, possibly check the referred-to server name
against a pre-configured list.

Ideally the LDAP client library would hide all the complexity and
leave the app only to decide which referrals to chase...  This project
is hardly the first to run into these issues.

Nico
--