concerns with ldap plugin and 1.5

[Ken Raeburn]

On Jun 9, 2006, at 13:45, Henry B. Hotz wrote:
>>> BTW, how does one create a new principal that is associated with a
>>> user
>>> object entry?
>>
>> add_principal -x userdn=<FDN of user object> <principal name>
>
> It seems to me that the extra argument ought to be associated with
> the realm configuration.  It should not be required on every single
> add command.

How would that work?  I assume it would be used sort of like:

add_principal -x userdn="cn=Ken Raeburn,ou=IS&T,dc=mit,dc=edu"  
raeburn at ATHENA.MIT.EDU
add_principal -x userdn="cn=John Doe,ou=HR,dc=mit,dc=edu"  
jdoe at ATHENA.MIT.EDU

If every user entry were in the same container and with a name  
matching the principal name (i.e., user name rather than real name),  
then a realm parameter would make sense.  But if people are broken  
down into organizations, and named differently from the principals, I  
don't think a single parameter for the realm is sufficient.  (Perhaps  
it might let you abbreviate the userdn spec somehow?)

> You define how the Kerberos data for a realm fits into the rest of
> the schema (and whether it's separate or included with the other user
> data).  With that mapping as a common background, would it be that
> hard to unify the ldap and db2 utility programs?  (And would it be
> that hard to have migration just be a dump/configure/load as I asked
> earlier.)

I'm starting to think a script interface to some of the kadmin/ 
kdb5_util/kdb5_ldap_util type functionality may be desirable for the  
migration code... but just as we haven't finished tweaking the kadmin  
protocol, I'm not sure we're ready to tackle this one just yet  
either, at least not in a form we'd support for future releases.

Ken