A problem with kadm5_setkey_principal() using an LDAP backend

[Lonigro, Frank A]

Greg,

This fixed the problem.  Thanks again for getting back to me.

-Frank

# diff -c /home/frank/rpmbuild/BUILD/krb5-1.10.3/src/lib/kadm5/srv/svr_principal.c.orig /home/frank/rpmbuild/BUILD/krb5-1.10.3/src/lib/kadm5/srv/svr_principal.c
*** /home/frank/rpmbuild/BUILD/krb5-1.10.3/src/lib/kadm5/srv/svr_principal.c.orig        2012-08-08 18:27:56.000000000 -0400
--- /home/frank/rpmbuild/BUILD/krb5-1.10.3/src/lib/kadm5/srv/svr_principal.c      2017-06-21 13:50:58.000000000 -0400
***************
*** 2058,2063 ****
--- 2058,2067 ----
      /* unlock principal on this KDC */
      kdb->fail_auth_count = 0;

+     /* key data changed, let the database provider know */
+     kdb->mask = KADM5_KEY_DATA | KADM5_FAIL_AUTH_COUNT; /* Fix for LDAP backend */
+     /* | KADM5_RANDKEY_USED */;
+
      if ((ret = kdb_put_entry(handle, kdb, &adb)))
          goto done;


-----Original Message-----
From: Greg Hudson [mailto:ghudson at mit.edu] 
Sent: Monday, June 19, 2017 11:49 AM
To: Lonigro, Frank A <franco at bu.edu>; kerberos at mit.edu
Subject: Re: A problem with kadm5_setkey_principal() using an LDAP backend

On 06/19/2017 10:13 AM, Lonigro, Frank A wrote:
> We have an application that uses kadm5_setkey_principal() to set the key for a Kerberos account.  This application works fine on a KDC with a BDB backend, but fails to set the key on a KDC with an LDAP backend.
[...]
> Is this a known issue?

This was not a known issue, but I believe I can see the problem in the code.  In kadm5_randkey_principal_3(), there is a statement:

    kdb->mask = KADM5_KEY_DATA | KADM5_FAIL_AUTH_COUNT;

which lets the KDB provider know what fields it should put into the database.  There is no corresponding statement in kadm5_setkey_principal_3().  The BDB KDB module doesn't care about the mask (it just serializes the whole principal entry no matter what), but the LDAP KDB module uses it to determine which attributes to change.

If you are prepared to rebuild the code, adding an identical kdb->mask assignment to kadm5_setkey_principal_3() just before the call to
kdb_put_entry() should fix your issue.  (In the master branch, the assignment would go in kadm5_setkey_principal_4().)

I will open a ticket for this bug.  Although I think the fix is trivial, testing it is not, so it may take me a bit to submit a PR.  As we only support releases for two years, we are only likely to backport the bugfix to 1.15 and 1.14 patch releases.