1. Forum
  2. Usenet
  3. COMP.PROTOCOLS.KERBEROS

  • Restoring DB to alternate LDAP suffix

    From Jake Scott@21:1/5 to All on Wed Jan 29 12:00:29 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Hudson@21:1/5 to Jake Scott on Wed Jan 29 15:25:04 2025
    To: kerberos@mit.edu

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Hudson@21:1/5 to Jake Scott on Thu Jan 30 00:33:29 2025
    Copy: kerberos@mit.edu

    On 1/29/25 21:57, Jake Scott wrote:
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jake Scott@21:1/5 to Greg Hudson on Wed Jan 29 21:57:40 2025
    Copy: kerberos@mit.edu

    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@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.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)