On a test cell, I've been able to change the encryption key as
follows: I change the afs password using kadmin and export it
to the KeyFile. I then have to kill the bos process and all
server processes on all servers, since my old admin tokens
don't work any more, nor do new ones when I
* Russ Allbery [2007-03-16 15:11:20 -0700]:
Jeff is talking about additional functionality that several of us would
like to add to the Kerberos KDC that lets you create a new key (and hence
a keytab and hence pre-populate the KeyFile) without having the KDC
immediately start using it for
Sergio Gelato wrote:
* Russ Allbery [2007-03-16 15:11:20 -0700]:
Jeff is talking about additional functionality that several of us would
like to add to the Kerberos KDC that lets you create a new key (and hence
a keytab and hence pre-populate the KeyFile) without having the KDC
immediately
On Mar 17, 2007, at 08:48, Jeffrey Altman wrote:
Sergio Gelato wrote:
* Russ Allbery [2007-03-16 15:11:20 -0700]:
Jeff is talking about additional functionality that several of us
would
like to add to the Kerberos KDC that lets you create a new key
(and hence
a keytab and hence
Sergio Gelato [EMAIL PROTECTED] writes:
Out of curiosity, is AFS the only intended application for this?
It seems to me that the day AFS will finally use standard Kerberos 5
keytabs and per-server principals the problem will be much milder.
Granted, one may not want to wait that long.
No, it
The old Transarc documents recommend changing your server encryption
key every month. We've done it about 9 times in 16 years, and did
it last before we migrated to Kerberos V. The explanation of how
to change the encryption key assumes that you are using kaserver
and kas, so it's out of date
A V Le Blanc [EMAIL PROTECTED] writes:
On a test cell, I've been able to change the encryption key as follows:
I change the afs password using kadmin and export it to the KeyFile. I
then have to kill the bos process and all server processes on all
servers, since my old admin tokens don't
Wouldn't a better key-update-transition plan be:
* create a new key
* stash it in the KeyFile in the next kvno slot
* wait until the servers pick it up
* update the afs key on the kdc to match the new value (make sure it
matches the kvno that you used before)
* profit.
From what I
Robert Banz wrote:
Wouldn't a better key-update-transition plan be:
* create a new key
* stash it in the KeyFile in the next kvno slot
* wait until the servers pick it up
* update the afs key on the kdc to match the new value (make sure it
matches the kvno that you used before)
*
What is required is functionality in the KDC that says generate a new
key for service X but don't use it yet.
Then you could distribute the key to your servers and after they were
all updated, you could activate the use of the new key.
That functionality could be simulated with a blah script
Robert Banz [EMAIL PROTECTED] writes:
What is required is functionality in the KDC that says generate a new
key for service X but don't use it yet.
Then you could distribute the key to your servers and after they were
all updated, you could activate the use of the new key.
That
11 matches
Mail list logo
