kdc ldap referral handling strangeness

[Kevan Carstensen]

Excerpts from Kevan Carstensen's message of 2012-02-29 11:12:32 -0800:
> 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.

I've worked a little bit on investigating this issue. As mentioned, the
kdc process is returned a referral to the master slapd when it attempts
to perform a modification on its local replica slapd. The kdc process
follows this referral, but doesn't try anything other than an anonymous
bind against the master slapd, so its attempt to perform a modification
fails. This is consistent with the default behavior of the openldap
library. ldap_set_rebind_proc(3) allows an application to specify a
rebind handler for when stronger authentication is necessary to follow a
referral. The ldap backend plugin doesn't specify a rebind handler, so
the behavior I ran into is expected.

Ideally, I'd like for the kdc to catch the referral, verify that it
points to the master slapd or some permissible slapd (to avoid malicious
referrals that could cause the kdc to disclose the credentials for the
service principal or some other bad thing), then bind to the master
slapd and attempt to perform the modification there. Catching the
referral, rebinding, and attempting to perform the modification again
can be done by using ldap_set_rebind_proc(3) in the ldap plugin code. A
whitelist of acceptable servers, specified in kdc.conf, seems like a
reasonable way to implement verification (assuming that one uses ldaps
and/or trusts one's local DNS). If no acceptable servers are specified,
the plugin could revert to the current behavior.

Does this seem like reasonable behavior? Would there be any interest in
modifying the ldap backend plugin to do this?

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