Restoring DB to alternate LDAP suffix

[Greg Hudson]

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.