Question related to keytab entries upgrade
matthieu.hautreux at gmail.com
Mon Jan 14 09:56:07 EST 2013
I would like to periodically refresh keytab entries, that is to say
modifying and increasing the kvno of the different principals on the KDC
and adding the new version to the keytabs on the different machines.
What I have is that :
- a client still owning an older version of a TGS will still be able to
contact the associated service as long as the services will have access to
both the older and the new version of the entries (different kvno)
- new clients will get the new version of the TGS key and will only contact
successfully a service that will be in possession of the new keytab entry.
To do that upgrade of keytab principal entries, I can either (1) do the
upgrade of principal keys on the KDC and push the additional entries to the
different machines for addition in current keytabs or (2) do that directly
on the machine using kadmin if kadmind is using a coherent ACL and a port
that is not filtered from the different machines.
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, thus this method is only limited to maintenance period where I
can guarantee that no one will try to access the servers in the update
If I use (2), I do not have to take that synchronization effect into
account, but I need to open the firewall and ACL. Moreover, I am used to
use configuration management tools like puppet or cfengine to manage
configuration files (including keytabs) on a central management node, this
method (2) does not really cope wit this requirement as every server will
update locally its keytab and the configuration management node will ask
him to go back to the previous version every time.
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. With such a workflow, I could guarantee that everything is
always working as expected and do a hot-"rolling upgrade" of all the
keytabs with a centralized management system and without having to add
every node to the ACL and alter the firewall rules. I have taken a quick
look at the KDC code, and it seems that the KDC is always looking for keys
of highest kvno number when performing a TGS_REQ, so it must not be
possible, but in case I am wrong and someone is knowing how to do that, or
an other alternative for my problem please let me know.
Thanks in advance.
More information about the krbdev