Question related to keytab entries upgrade

Greg Hudson ghudson at MIT.EDU
Mon Jan 14 12:03:32 EST 2013


On 01/14/2013 09:56 AM, Matthieu Hautreux wrote:
> If I use (1), I need to be sure that no clients will request for a TGS for
> updated principals as long as the new entries are not added on the server
> machines

> If I use (2), I do not have to take that synchronization effect into
> account, but I need to open the firewall and ACL.

Principals have implicit permission to update their own keys (subject to
minimum lifetime restrictions), so you shouldn't have to open the ACL.
You do have to open the firewall, of course.

The race window you refer to exists even when using kadmin from the
server.  The window is short, but it's there--some amount of time passes
between the KDC generating the new keys, sending them to the kadmin
client, and the kadmin client adding them to the keytab.  You might be
able to make the window similarly short for a KDC-push-to-server approach.

> I am wondering if I am missing an other approach that would let me create
> new versions of principal keys on the KDC, generate the associated keytab
> entries (increased kvno), push+add them to the targeted servers keytabs
> (when I want) and then inform the KDC to use the new version in consecutive
> TGS_REQ calls.

I believe Heimdal has a feature like this (an active kvno attribute),
but we do not at this time.  I would like us to have something like it,
assuming we can come up with clean RPC interfaces and UIs for it.

The other way around this problem is to generate the keys outside of the
KDB (either on the KDC or the servers), store them into the keytabs they
need to be in, and then push them into the KDB.  We have a server-side
"setkey" RPC in kadmind which allows keys to be pushed to the KDB, but
no client tools for it at this time.  Using the setkey RPC requires
explicit "setkey" access in the kadmind ACL, because kadmind has no
assurance that the generated key is random (and not based on a password
which wouldn't meet kadmind's password policy).

You might want to take a look at https://github.com/elric1/krb5_admin
and see if it can meet any of your needs.  I haven't learned about it in
detail myself.



More information about the krbdev mailing list