Options for dealing with LDAP policy refcounts

[ghudson@MIT.EDU]

Password policy records include a reference count, in order to prevent
password policies from being deleted if they are still referenced by
principals.  The refcount is maintained and checked by libkadm5srv,
not by the database module itself.

The LDAP back end does not store the policy refcount, probably because
they anticipated that principal data might be maintained through LDAP
instead of through kadmin.  Instead, whenever a policy is fetched, the
back end scans the entire subtree (or multiple subtrees if so
configured) for principals referencing the policy.  In almost all
cases, this work is wasted; unless we are deleting the policy object,
we have no interest in the refcount field.

This problem gets worse in 1.8 with account lockout support, because
the KDC is now looking up policy entries on every preauth-required
password principal.

My immediate reaction was that the refcount should be treated as an
implementation detail of the DB module.  Unfortunately, that doesn't
pan out as easily as I thought; it would require DB2's put_principal
method to become much more complicated.

I can see two options:

1. The LDAP back end sets the policy refcount to 0, so
kadm5_delete_policy() never fails the refcount check.  LDAP's
delete_policy operation performs the subtree scan and returns a new
KDB error (which libkadm5srv would translate to KADM5_POLICY_REF) if
any principals reference the policy.

2. Stop using the refcount field entirely.  If you delete a policy
with principals referencing it, those principals become policy orphans
and behave as if they had no policy.

I like the second option because it lets us remove a bunch of code,
and because deleting password policies strikes me as a rare operation
which doesn't need a strong safety guarantee.  The first option is a
more conservative response, though.