need help with LDAP plug-in code and liblber dependency

[Vinayak Hegde]

>>> On Thu, May 25, 2006 at  6:42 AM, in message
<20060525011252.GI16281 at sun.com>,
Will Fiveash <William.Fiveash at sun.com> wrote: 
> On Tue, May 23, 2006 at 10:52:12PM - 0400, Ken Raeburn wrote:
>> On May 23, 2006, at 21:38, Will Fiveash wrote:
>> >  Should kdb5_util support the create command with a ldap
>> >plug- in?  If not, how does one prep the directory so that kadmind
and
>> >krb5kdc can use it as they do the db2 KDB?
>> 
>> It would be nice, someday, but no, currently you need to use  
>> kdb5_ldap_util to create it.  I have a few notes in my email on how 

>> to do this; we should be getting manual updates at some point.
> 
> A couple of points here:
> 
> -  I'm concerned about UI consistency in regards to the db utils.  I
was
>   thinking that once one loaded the krb schema into the directory
and
>   configured the k*.conf files to use the LDAP plug- in that they
could
>   then proceed to create the KDB as they did in the past using
>   kdb5_util.  In the case where the LDAP plug- in is used, the
> 
>   kdb5_util create - r ACME.COM - s
> 
>   would interact with the LDAP directory and create the default
>   principal records and local stash file.  If a krb container object
is
>   required then it would create this as well.
>

Following were the issues when we thought of supporting LDAP 
database configuration using kdb5_util:
i) For existing commands like create, LDAP database needs some
additional information, such as LDAP user DN and password. So we need
to pass these arguments down to LDAP plug-in, which will process it. 
This will not be modular and reporting parse-error will be
complicated.

ii) The documentation and command help can't be made generic for all 
the db back ends.

iii) For any new database specific command to be introduced, we need 
to extend the DAL API set to support this command.

iv) And kdb5_util will also be changed for any new command.

In addition to the above ones, UI experience is also bound to change.
So we thought that implemented a new utility for LDAP database is the
better one.
 
> -  Why is kdb5_ldap_util create required in order to access
princ/policy
>   records in the directory?  The man page states that kdb5_ldap_util
>   create creates a realm object which I assume is optional.  Am I
>   mistaken?
>

According to the design, realm object is a container object, which is
created
mandatorily, as part of "create" command. This object will have some of

the Realm specific information like, encryption types, salt types, etc.
The
default principals like kadmin/admin, krbtgt/REALM etc and any service
principal host/servername is created under this realm container.

 In addition to the Realm attributes mentioned above, "create" command

(and all of the LDAP specific commands) needs to bind to the LDAP
Server 
using user name and password. 

> -  How does one migrate an existing db2 KDB to a directory?  I was
>   assuming that kdb5_util dump & load would be used.
> 
> -  Regardless of the above kdb5_util should not core dump regardless
of
>   the backend being used.  There needs to be better NULL function
>   pointer checking in the kdb code.

As you pointed out, the user should get appropriate error message.

Cheers,
Vinayak