A problem with kadm5_setkey_principal() using an LDAP backend

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

A problem with kadm5_setkey_principal() using an LDAP backend

Frank Lonigro
Hello,

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.  Both Kerberos KDC's have the "s" flag set in the ACL file.  The interesting thing is that if we have our application set a random key using kadm5_randkey_principal(), it works perfectly no matter the backend.  But obviously, randkey is not what we want.

In the LDAP messages log, the only attribute that is modified when doing the setkey is, MOD attr=krbExtraData

But when doing the randkey, the usual set of attributes are modified, MOD attr=krbLoginFailedCount krbprincipalkey krbpasswordexpiration krbLastPwdChange krbExtraData


Is this a known issue?

We are using krb5-1.10.3 currently on Linux.

Thanks,
Frank
Boston University
Senior Systems Engineer

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: A problem with kadm5_setkey_principal() using an LDAP backend

Greg Hudson
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.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: A problem with kadm5_setkey_principal() using an LDAP backend

Frank Lonigro
Greg,

Thanks for this quick response.  I will give your suggestion a try.

Thanks so much,
Frank

-----Original Message-----
From: Greg Hudson [mailto:[hidden email]]
Sent: Monday, June 19, 2017 11:49 AM
To: Lonigro, Frank A <[hidden email]>; [hidden email]
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.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: A problem with kadm5_setkey_principal() using an LDAP backend

Frank Lonigro
In reply to this post by Greg Hudson
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:[hidden email]]
Sent: Monday, June 19, 2017 11:49 AM
To: Lonigro, Frank A <[hidden email]>; [hidden email]
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.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos