kdc ldap referral handling strangeness

[Kevan Carstensen]

Hi,

We have a kerberos (version 1.9.2) environment with three hosts; one
that runs both kadmin and a kdc, and two others that run only a kdc. All
three hosts use the LDAP backend. Each host runs its own openldap slapd,
and each slapd is configured to conceptually mirror the kerberos
environment on the same host; specifically, the slapd on the host with
kadmin is configured as a master, and the slapds on the kdc hosts are
configured as read-only replicas that use syncrepl to consume changes
from the master. Kerberos processes on a given host are configured to
connect to the slapd running on the same host.

It is expected behavior in certain situations for a kdc to change
attributes of a principal in response to an authentication attempt
(e.g., updating last failed login time, number of failed authentication
attempts, etc when preauth is used). To allow for this, we have the
following access control entry on all of our slapds:

  access to dn.subtree="cn=container,dc=kerberos,dc=csupomona,dc=edu"
      by dn="cn=kdc,ou=service,dc=kerberos,dc=csupomona,dc=edu" write
      by dn="cn=kadmin,ou=service,dc=kerberos,dc=csupomona,dc=edu" write
      by * none break
								  
This differs from the example access control entry given in the docs [1]
in that it gives both the kdc and kadmin processes write access to the
kerberos data (it is also overly broad; the kdc's access requirements
could be more precisely specified). In any case, I expected that this
would be sufficient to allow the kdcs to update principals as necessary.
On the master (the host with kadmin and the master slapd), it is; failed
login counts, login times, and so on are maintained correctly when
preauth is required/used. Replicas (kdcs on systems with a read-only
slapd) aren't able to update these attributes, so failed authentications
against a replica kdc don't result in any changes to the failed login
count, last failure time, etc.

Intuitively, I'd expect the kdc process on a replica to first try to
perform a principal modification on the local slapd. Since the local
slapd is read-only, it should reject the modification and send the
client a referral to the master slapd. The client should then follow
this referral, bind to the master slapd using the dn configured in
kdc.conf and stashed credentials as appropriate, and perform the
modification there. The kdc follows the first two steps of this process,
but binds anonymously to the master slapd. Since anonymous updates
aren't allowed by the ACL on the master slapd, the kdc's modification
fails.

Has anyone else run into this issue?  Am I missing something obvious?

[1] http://web.mit.edu/Kerberos/krb5-latest/krb5-1.10/doc/krb5-admin.html#Configuring-Kerberos-with-OpenLDAP-back_002dend

Thanks,
-- 
Kevan Carstensen                        <kacarstensen at csupomona.edu>
Operating Systems Analyst, I&IT Systems, Cal Poly Pomona