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 <ghud...@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. > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
