>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 reaut
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.
N
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 pre-popula
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
>> immedi
* 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 se
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.
> T
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 script ge
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)
>
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 understand
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'
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 any
11 matches
Mail list logo