concerns with ldap plugin and 1.5

[Will Fiveash]

On Tue, Jun 06, 2006 at 05:17:28PM +0530, Rahul Srinivas wrote:
> On Mon, 5 Jun 2006, Will Fiveash wrote:
> 
> > On Sat, Jun 03, 2006 at 05:28:19PM -0500, Will Fiveash wrote:
> > > On Sat, Jun 03, 2006 at 02:18:49PM -0400, Sam Hartman wrote:
> > > > >>>>> "Rahul" == Rahul Srinivas <srahul at novell.com> writes:
> > > > 
> > > >     Rahul> Hi, Principals are created by default under the realm's
> > > >     Rahul> subtree (the 'subtree' argument to 'kdb5_ldap_util create')
> > > >     Rahul> as service principals.  This can be overridden by one of
> > > >     Rahul> the following database specific options in 'kadmin'
> > > >     Rahul> 1. userdn=<user_dn> : Specifies the user object with which
> > > >     Rahul> the Kerberos user principal is to be associated.
> > > >     Rahul> 2. containerdn=<container_dn> : Specifies the container
> > > >     Rahul> object under which the Kerberos service principal is to be
> > > >     Rahul> created.
> > > > 
> > > > OK, so if kdb5_util were made to have a clean enough interface so that
> > > > it didn't assume db2 and you tried loading a dump, it would work, you
> > > > would just get an ugly directory structure resulting.
> > > 
> > > That was my expectation.
> > 
> > To elaborate, I was expecting that I could do a kdb5_util load and it
> > would recreate the KDB under the ldap_kerberos_container_dn.  I
> > understand that the problem becomes harder if one has krbPrincipalAux
> > attributes associated with non-krb structural classes like user or host.
> 
> Firstly, a small correction. Kerberos principals are not created under 
> 'ldap_kerberos_container_dn'. 'ldap_kerberos_container_dn' specifies the 
> location of a Kerberos container in the directory. It contains objects of 
> objectclass 'krbRealmContainer'. There is one realm-container per realm. 
> The realm container contains only special principals like 'krbtgt', 
> 'kadmin/admin' etc. All other principals are created under the realm 
> subtree (the 'subtree' argument to 'kdb5_ldap_util create').
> 
> If loading all principals from the Kerberos db2 database directly into the
> realm subtree (LDAP database) is what is desired, then implementing a basic
> 'load' command in 'kdb5_ldap_util' would be the way to go. On doing a
> 'load' we would then end up with a flat structure in the directory where
> all principals will be in directory under the realm subtree. But we don't
> think this is going to be useful. As Praveen explained earlier, 'load'
> should also be able to associate Kerberos principals with existing user
> objects in the Directory.

As a user I would expect that kdb5_util load to the directory would
place the principals under the realm subtree.  If one wanted to
automatically associate certain principal's attributes with existing
objects one could use a directory server plugin to do this (I believe
this is possible with the Java Enterprise DS).  Of course if this
facility is not available or the rule based mapping of principal name to
object entry is not possible then I can see use of a migration utility
when one intends to join principal attributes to existing objects.

Can't we add a subtree parameter to the ldap [dbmodules] stanza that
would allow kdb_util to create princs under the proper subtree?

BTW, does kadmin/kadmind work in regards to managing principals in the
directory or is this also disabled?

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