* Harald Barth [2012-12-11 23:07:07 +0100]: > > Thanks. My next question is: if I do this, will it break existing > > sessions using tokens obtained via afs@? > > If you merge a new secret into the AFS key file on the server with a > new (high, say 10001) kvno, it should not. I have not tested this > though.
I haven't tested kvno's that high, but with more mundane values it does work. When I did this some years ago, the afs@ principal had kvno=3 or 4 so I simply gave the new afs/cell.name@ principal kvno=1. The only requirement is that all kvno's in the keyfile be unique at any given time. > Methinks between 1. and 3. tokens with the new key may fail. There are two schools of thought about this. One is "just keep that window short and at a time of low usage, and hope no one will notice". The other involves suggestions like yours. Here is what my AFS rekeying procedure says (assumes Heimdal): 1. Generate a new DES key on the master AFS server, store it in a temporary keytab. The command is: ktutil -k afs.keytab add -p afs/cell.name -V kvno -e des-cbc-crc -r The key version number should be one more than the current value for this principal. 2. Add the key to the AFS keyfile: asetkey add kvno afs.keytab afs/cell.name (again, with the appropriate key version number). 3. Wait for the AFS keyfile to propagate to all servers. One can use bos listkeys server -localauth to verify that the named server has been updated. 4. Use asetkey list to get the 16-byte hexadecimal string representation of the new key. This can also be extracted from the keytab using ktutil -k afs.keytab list --keys 5. Add the new key to the KDC database: kadmin cpw --key=hexvalue afs/cell.name If the afs/cell.name principal doesn't exist yet, kvno must be 1 and one should use add instead of cpw. [I'm not sure that last sentence is still relevant; it was written years ago. If Heimdal now supports creating principals with kvno>1, feel free to do that. If not, and if a...@math.cornell.edu still has kvno=1, I'd suggest rekeying it and removing the old kvno=1 key before creating afs/math.cornell.edu@...] Then there are a couple of cleanup steps: 6. When migrating from afs@ to afs/cell.name@ only: remove the afs@ principal from the KDC database (once you've verified that the new afs/cell.name@ principal works for all clients). 7. Wait one maximum token lifetime. 8. Remove the old key from the AFS keyfile. > What do the experts think about this: > > 1. Start empty heimdal KDC for MATH.CORNELL.EDU on laptop. > 2. Create afs/math.cornell....@math.cornell.edu on laptop with known > (long, random) password and high kvno. > 3. Extract AFSKEY with ktutil from KDC on laptop. > 4. Merge AFSKEY for afs/math.cornell.edu into testserver's KeyFile. > 5. Try to access something on testserver from laptop with key > material created with kimpersonate. > 6. Merge AFSKEY into all production servers. > 7. Create identical afs/math.cornell....@math.cornell.edu on real KDC. > > Warning: I have not tried this in practice, but I think in this manner > you can back out each step without problem. It looks similar to my (well-tested: I've rekeyed in this way many times now) procedure above, except I don't need a laptop (and I skip your test step 5). _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info