[36761] in Kerberos
RE: Renaming principals causes them to disappear
daemon@ATHENA.MIT.EDU (Paul B. Henson)
Thu Feb 5 17:39:12 2015
From: "Paul B. Henson" <henson@acm.org>
To: "'Greg Hudson'" <ghudson@mit.edu>, <kerberos@mit.edu>
In-Reply-To: <54D276DD.50807@mit.edu>
Date: Thu, 5 Feb 2015 14:38:53 -0800
Message-ID: <0cdd01d04194$86d44d50$947ce7f0$@acm.org>
MIME-Version: 1.0
Content-Language: en-us
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
> From: Greg Hudson
> Sent: Wednesday, February 04, 2015 11:46 AM
>
> For a one-off, you could write a C program which gets a principal entry,
> fixes up the salt, and puts it back without changing the name. You
> could use the code for kadm5_rename_principal() in svr_principal.c as a
> template.
Thanks for the suggestion. It seemed like a lot of overhead to put together
a standalone C program that duplicated all of the initialization and other
basic tasks, so what I ended up doing was hack the kadm5_rename_principal
function in place to do what I needed. After compiling it, and temporarily
copying in the modified library, I could run kadmin -q 'renprinc -force user
user', and rather than actually renaming anything, it would simply update
the salt in place for that principal to hardcode it to the required value.
I think this is going to work out; I tested a process where I dump my
production LDAP data for realm A, load it into the new realm B server
temporarily configured to be realm A, use the modified renprinc command to
fix the salts, dump the data again, update the dump to replace A with B,
then load it into the new realm B server. It's a bit of processing, but in
the end I was successfully able to authenticate as a principal using the
existing realm A password to realm B :), so I think it's going to suffice
for my needs.
Thanks again.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
