concerns with ldap plugin and 1.5

[Will Fiveash]

On Wed, Jun 07, 2006 at 03:55:14PM +0530, Rahul Srinivas wrote:
> I think there is a misunderstanding here. I am not favouring
> 'kdb5_ldap_util' over 'kdb5_util' for having the 'load' command. As you
> said, principals can be 'load'ed from a db2 dump into the directory through
> DAL. I mentioned 'kdb5_ldap_util' because currently all commands for realm
> management in a LDAP backend are in 'kdb5_ldap_util'. All I am saying is
> that such a basic 'load' funtionality will not be very useful. But, we
> could provide a 'load' command if required.

I can do:

kadmin.local -q 'addprinc william'

which creates a principal object.  One can make the case that if one
wants to integrate the principal auxiliary attributes with an existing
user object entry then having the addprinc create a unique principal
object instead of adding the attributes to the existing user object is
not useful however it is still supported by the ldap backend.  My
concern is providing a consistent UI amongst other things.

BTW, how does one create a new principal that is associated with a user
object entry?

> On Tue, 6 Jun 2006, Sam Hartman wrote:
> 
> > >>>>> "Rahul" == Rahul Srinivas <srahul at novell.com> writes:
> > 
> >     Rahul> If loading all principals from the Kerberos db2 database
> >     Rahul> directly into the realm subtree (LDAP database) is what is
> >     Rahul> desired, then implementing a basic 'load' command in
> >     Rahul> 'kdb5_ldap_util' would be the way to go
> > 
> > Why would this be the way to go?
> > Why should load be ldap-specific?
> > Why can't kdb5_util load use the DAL to simply create principals?

-- 
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)