kdc ldap referral handling broken

[Paul B. Henson]

On Tue, Mar 20, 2012 at 10:48:22AM -0700, Nico Williams wrote:

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

We run our actual enterprise directory in mirror-mode, with two masters
for redundancy and failover, but only one of which gets updates at a time,
to ensure LDAP semantics. However, for use as a kerberos backend, I
don't think you really need strict ldap semantics?

The issue that came to our minds for true multimaster ldap backends for
kerberos was that with object level replication you might have a failed
login update on one kdc overwrite a password change update on another
kdc 8-/, which isn't exactly desirable. However, we just noticed that
openldap now supports delta-syncrepl (attribute level replication) in
multimaster mode, which resolves that issue. We're now tentatively
planning to deploy openldap in multimaster mode, which works around the
referral issue, as each kdc is talking to a local ldap master that
allows writes. For clients, we're probably going to still have updates
just go to one master at a time, but that's a separate issue with our
load balancer (which we're running in one-arm mode with a non-symmetric
traffic pattern, requiring relatively short state timeouts, and causing
occasional tcp resets to an idle client that hasn't generated traffic
"recently").

> referral URL has changed, possibly check the referred-to server name
> against a pre-configured list.

That's what we were thinking about doing.

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

My colleague Kevan has looked at it in more detail, but my understanding
is that the openldap api does provide a callback mechanism for
referrals, allowing the client to just decide what should be done and
then let openldap take care of it.

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768