Restoring DB to alternate LDAP suffix

[Jake Scott]

Thank you for the detailed response, it is much appreciated.

We worked around the issue by using an LDAP level dump/restore with some
search/replace in between and that seemed to have done the job.  But it
would be nicer to use the kdb5_util interface for sure.  Now that I’m aware
that this data is in the dump and how it is encoded, thanks to you - I will
try to find time to create some dump manipulation tooling.

One thing — I did try restoring the dump to a file based database and then
dump/restoring again to LDAP and the same issue happened so I assume that
the LDAP data ends up in the file DB as well - is that also what you expect?


Many thanks — Jake



On Wed, Jan 29, 2025 at 15:25 Greg Hudson <ghudson at mit.edu> wrote:

> On 1/29/25 12:00, Jake Scott wrote:
> > We are currently migrating data from an LDAP backend (MIT v1.18) to a new
> > suffix. We've dumped the data using kdb5_util and are attempting to
> restore
> > it using a new configuration with the updated suffix.
> >
> > During the restore process, it appears that the principals are being
> added
> > back using their original DNs instead of under the new suffix. Is this
> > expected behavior? We were surprised to find the principal DNs included
> in
> > the dump file.
>
> That is expected behavior.  I would speculate that the design intent was
> that administrators can set explicit DNs when creating principals, and
> that dumping and loading should preserve that DN structure rather than
> creating a new one based on the container DN and principal names.
>
> I don't see an easier workaround for your use case than modifying the
> dump file.  Unfortunately, the principal DNs are hidden two layers deep:
>
> * Within each principal line are fields representing zero or more
> type-length-data records.  The placement and structure of these records
> is documented in https://github.com/krb5/krb5/pull/1408 .
>
> * Within the tl-data record of type 255 is an encoded series of LDAP
> type-length-data subrecords.  This encoding isn't documented anywhere as
> far as I know (I will hopefully add it to the PR), but it's one or more
> repetitions of a one-byte tag, a two-byte big-endian length, and then
> <length> bytes of data.  Tag 3 indicates a user DN.  You could change
> the tag of the subrecord to some nonsense value (like 255) to cause it
> to be ignored, or remove it and fix up the length of the containing field.
>