copy users from one realm to another

Paul B. Henson henson at acm.org
Tue Jun 24 19:32:05 EDT 2014


> From: Greg Hudson
> Sent: Monday, June 23, 2014 1:54 PM
>
> It's possible in theory, but we don't currently provide tooling for it.

We are not adverse to potentially putting some code together to do it, even
better if it would be code that could be submitted upstream to make it
easier for somebody else.

> 1. As you noted, the default salt of a principal includes the realm
> name.  To rename a principal entry with a password-based key, you have
> to modify the key data of that principal to include an explicit salt.
> We provide a kadmin operation which does that for a single principal,
> but not for a whole realm.

I see the -e option global to kadmin, and then one specific to the create
principal or change password function, allowing you to specify a particular
salt to use when a principal is created or password changed, but I don't see
anything that looks like it would allow you to override the salt for an
existing password and make it use something else? Did you mean an actual
kadmin CLI interface, or did you mean something in the kadmin C API that
could be called from code? I took a quick trawl through the code base and
nothing jumped out at me but I might have missed it.

> 2. The master key stash file (since 1.7) is a keytab file with the key
> filed under K/M at oldrealm.  This has to be modified to have the key filed
> under K/M at newrealm.

That seems pretty simple.

> 3. krbtgt principal entries (local and cross-realm) need to have their
> second components renamed as well as their realm names.  Cross-realm
> krbtgt principal entries need to be renamed in the foreign database as
> well as the local one.

We don't have any cross realm trusts, so this should be pretty simple as
well

>  The problems I'm aware of include:

Of course, I'm assuming there might be problems you're not aware of as well
:)? 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? Ideally we'd like to
make this change without requiring forced password updates, but on the other
hand I don't want to trade off long-term stability for short-term
convenience.

Thanks.



More information about the Kerberos mailing list