[36220] in Kerberos
Re: copy users from one realm to another
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Jun 24 22:46:54 2014
Message-ID: <53AA380C.1020900@mit.edu>
Date: Tue, 24 Jun 2014 22:46:36 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: "Paul B. Henson" <henson@acm.org>, kerberos@mit.edu
In-Reply-To: <023501cf9004$842d1650$8c8742f0$@acm.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On 06/24/2014 07:32 PM, Paul B. Henson wrote:
> I see the -e option global to kadmin, and then one specific to the create
> principal or change password function [...]
Sorry to be unclear; I was referring to the kadmin renprinc command. In
addition to renaming the principal, it adds an explicit salt.
>> 2. The master key stash file (since 1.7) is a keytab file with the key
>> filed under K/M@oldrealm. This has to be modified to have the key filed
>> under K/M@newrealm.
>
> That seems pretty simple.
I don't think we have a convenient way of renaming a principal entry in
a keytab (short of editing the binary file), but you can dump a new one
with ktadd -norandkey in the same kadmin.local session where you rename
the K/M principal.
> Do you think this is something that would either clearly work/not work,
> or potentially something that might appear to work but leave some latent
> problem that mysteriously pops up at some later time?
As it turns out, I know someone who had to rename a realm a few weeks
ago, and after resolving the above issues reported success.
In case it wasn't obvious, I should also have mentioned that any
references to principal names in ACL files (or the equivalent) must be
updated, and all server keytabs must be re-provisioned. This is
probably the hardest part in a large-scale deployment. (In some cases
server keytabs might continue to work, but I wouldn't count on it.)
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
