concerns with ldap plugin and 1.5

[Praveenkumar Sahukar]

>>> On Fri, Jun 2, 2006 at  1:52 AM, in message
<20060601202236.GA4031 at sun.com>,
Will Fiveash <William.Fiveash at sun.com> wrote: 
> On Thu, Jun 01, 2006 at 05:25:35AM - 0600, Praveenkumar Sahukar
wrote:
>> >>> On Thu, Jun 1, 2006 at  6:23 AM, in message
>> <20060601005356.GA27225 at sun.com>,
>> Will Fiveash <William.Fiveash at sun.com> wrote: 
>> > I have a number of concerns regarding the ldap plugin and schema
in
>> > the
>> > upcoming MIT 1.5 release:
>> > 
>> > 
>> > -   How is an existing db2 KDB migrated to a LDAP/Directory based
>> KDB?
>> 
>> We are designing a migration tool for migrating the MIT db2 KDB to
LDAP
>> database.
> 
> Why can't one do a kdb5_util dump with the db2 KDB then reconfigure
to
> use the ldap plugin, initialize the directory for KDB use, then use
> kdb5_util load to populate the ldap KDB?
> 
> Without this support, many customers are not going to be happy.

The existing 'load' functionality in kdb5_util accepts the following
options

1. Dump format related options: -old, -b6, -b7, -ov
2. Other options: -verbose, -hash, -update

This is sufficient only if both the source and destination of the
migration are
flat databases. When you move principals from a flat database to a tree
like
database (directory), there are many more options that need to be
configured.
In this case, the flat database is being 'merged' with a directory. The
following 
are few of the parameters.

1. Mapping principals in a flat database to existing users in the tree.

The Kerberos attributes of every user principal must be moved to the
proper
user in the tree. 
The rules for this mapping may be complex.
   1. Based on (possibly many) regular expressions 
      - for matching principals and
      - for matching directory objects (based on FDN or some attribute
like 
        'uid')
   2. Explicit mapping provided in a file

2. Creation of new objects in the directory corresponding to principals
which
can't be mapped to existing directory objects.
   1. Distinguishing between user principals and service principals -
this may
      be based on the principal flags and/or regular expressions.
Objects of
      different classes have to be created for these two types of
principals.
   2. In which container a newly created service / user is to be placed
- rules
      to select the container.

Most of these parameters are relevant only to a directory backend.
Instead of 
making the kdb5_util's 'load' functionality generic enough to accept
all these
parameters we decided to implement an independant migration tool.

-Praveen