Restoring DB to alternate LDAP suffix

[Jake Scott]

Hi there..

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.

Any insight or advice would be much appreciated!


Thanks..

Jake

[Greg Hudson]

Post by Jake Scott
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.

[Greg Hudson]

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?

That's also expected. The LDAP KDB module synthesizes and interprets
the type-255 tl-data; other modules don't know anything about it, so
they just store it and replay it.

[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

Post by Jake Scott

Post by Jake Scott
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

Post by Jake Scott
it using a new configuration with the updated suffix.
During the restore process, it appears that the principals are being

added

Post by Jake Scott
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

Post by Jake Scott
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
* 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.