question about princ type assignment in krb5_ldap_get_principal()

[Will Fiveash]

On Fri, Jun 16, 2006 at 09:00:13PM +0530, Praveen Kumar Sahukar wrote:
> On Thu, 2006-06-15 at 16:32 -0500, Will Fiveash wrote:
> > On Thu, Jun 15, 2006 at 11:42:42PM +0530, Praveen Kumar Sahukar wrote:
> > > On Wed, 2006-06-14 at 11:07 -0400, Sam Hartman wrote:
> > > > >>>>> "Praveen" == Praveen Kumar Sahukar <psahukar at novell.com> writes:
> > > > 
> > > >     Praveen> Kerberos principals created on krbprincipal object class
> > > >     Praveen> (by extending with the krbprincipalaux aux class) are
> > > >     Praveen> considered as Kerberos service principals. Thus kerberos
> > > >     Praveen> principals like kadmin/admin, krbtgt/realmname ... are
> > > >     Praveen> created as krbprincipal object class.
> > > > 
> > > >     Praveen> Kerberos principals created by extending other structural
> > > >     Praveen> object classes with the krbprincipalaux aux class are
> > > >     Praveen> considered as the user principals.
> > > > 
> > > > This seems rather specific to your deployment.
> > > > 
> > > > What distinction does the code make based on this type?
> > > 
> > > Based on the principal type distinction a couple of eDirectory specific
> > > features are applied only to kerberos user principals and not to
> > > kerberos service principals.
> > 
> > Still the logic is suspect.  I just created a user principal and stored
> > it as a krbPrincipal object and this code sets the ptype to
> > KDB_SERVICE_PRINCIPAL.  I worry about this being misunderstood and
> > misused later.
> 
> The logic in the LDAP plug-in is to differentiate the Kerberos
> principals into 2 classes 'service' and 'user'. Any kerberos principal
> created as a krbPrincipal object will be treated as a kerberos service
> principal. The fact that the kerberos principal belongs to a
> krbPrincipal object makes it a kerberos service principal. So it is not
> possible to create a kerberos user principal with a krbPrincipal
> object. 
> 
> If a kerberos principal is associated with any other object class other
> krbPrincipal object class, then it will be treated as a kerberos user
> principal. 

I think this is too rigid.  What if someone has a non-krb host object
entry for foo.bar.com and wants to mix in host/foo.bar.com service princ
attributes?  What if I have more than one user principal I want to
associate with a posixAccount user object?

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