concerns with ldap plugin and 1.5

[Henry B. Hotz]

On Jun 9, 2006, at 12:56 PM, Ken Raeburn wrote:

> 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

You ought to be able to infer the dn from the principal name, based  
on the (probably default) realm's configuration information.  In  
other words "add hotz" should do the right thing.

In my case my principal is hotz at JPL.NASA.GOV, and my DN is  
"uid=hotz,ou=personnel,dc=dir,dc=jpl,dc=nasa,dc=gov".  The Sun LDAP  
server nicely allows us to define exactly that mapping from the the  
Kerberos principal to DN and also to reject non-JPL user (cross- 
realm) tickets for SASL/GSSAPI binds.  The mappings can be pretty  
arbitrary so you could e.g. map */admin users to the same place, or a  
different place entirely.  (OK, it'll be another month or two before  
SASL is supported, but that's the naming we use.)

Shouldn't I be able to do the same thing for an LDAP back-end for the  
Kerberos service?

> 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?)

Around here people are people and where they sit in the organization  
is just an attribute or two.  Some part of the org tree probably  
changes weekly.  Also it's a matrix organization so everyone exists  
in at least two org trees.  Maybe that makes my case especially  
simple, but I still think that the -x userdn... option should be  
omittable most of the time.

I guess you want to handle the case that the Kerberos realm tree  
doesn't map easily to the LDAP DIT.  Frankly I think you're screwed  
in that case.  Better to just give up and put the Kerberos info in a  
completely different branch from the organization info.  Otherwise  
you'd have to do something *really* hard like manually specify the DN  
for each and every user.  ;-)

Just my opinion, of course.

>> 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

------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu