more ldap concerns

[Will Fiveash]

On Mon, Jun 05, 2006 at 04:51:10PM -0500, Will Fiveash wrote:
> On Fri, Jun 02, 2006 at 06:28:19PM -0400, Ken Raeburn wrote:
> > On Jun 2, 2006, at 17:18, Jeffrey Hutzelman wrote:
> > >> then the code uses an internal version of the
> > >>enctype parameter to determine what enctypes to use.  This is good
> > >>because if the code is updated to support new enctypes, the k*.conf
> > >>files do not have to change.  If you are specifying these  
> > >>parameters in
> > >>various objects in the directory by default you are limiting the krb
> > >>code and possibly creating more work for the admin.  I don't think  
> > >>the
> > >>enctype parameters should be instantiated by default, only if the  
> > >>admin
> > >>specifies the parameter settings via the command line.
> > >
> > >I question the utility of setting these parameters in the directory  
> > >at all.
> > >KDC configuration is not directory information.
> > 
> > Things like this would presumably be per-realm configuration, not per- 
> > KDC configuration.
> > Though, in fact, I don't think it's anything the KDC even looks at;  
> > I'm not sure where in the code this list (or the "default enctype"  
> > for the realm, a term that bothers me) is used.  So I'm not sure what  
> > it's intended for...
> 
> I saw that also with cscope.  I'd also like to know what the realm
> default enctype is used for (what current kdc.conf realm stanza
> parameter does is map to?).

(more enctype issues...)

After running:

kdb5_ldap_util -D "cn=directory manager" -w my_password create -P my_password -subtree "dc=south,dc=sun,dc=com"

then:

$ ./kadmin.local -q 'getprinc krbtgt/ACME.COM'
Authenticating as principal willf/admin at ACME.COM with password.
Principal: krbtgt/ACME.COM at ACME.COM
Expiration date: [never]
Last password change: [never]
Password expiration date: [none]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Tue Jun 06 16:53:52 CDT 2006 (cn=directory manager at ACME.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
            ???????????????????????????????????????????
Attributes:
Policy: [none]

This was using the defaults for enctypes (no enctype parameters were
specified in the k*.conf or kdb5_ldap_util).  I'm bothered by the fact
that krbtgt only has a DES3 key.  The db2 krbtgt princ created using
defaults had 2 keys (des3 and des-cbc-crc).  Even this seems weird to
me.  By default Solaris creates a krbtgt princ with keys for all
supported enctypes on the KDC.  Why isn't this the case with the MIT
code?

Note that my realm object in the directory contains:

dn: cn=ACME.COM,cn=krbcontainer,dc=south,dc=sun,dc=com
cn: ACME.COM
objectClass: top
objectClass: krbrealmcontainer
krbSubTree: dc=south,dc=sun,dc=com
krbDefaultEncType: 16
krbDefaultSaltType: 0
krbSupportedSaltTypes: 0
krbSupportedSaltTypes: 1
krbSupportedSaltTypes: 2
krbSupportedSaltTypes: 3
krbSupportedSaltTypes: 4
krbSupportedEncTypes: 1
krbSupportedEncTypes: 2
krbSupportedEncTypes: 3
krbSupportedEncTypes: 16
krbSupportedEncTypes: 17
krbSupportedEncTypes: 18
krbSupportedEncTypes: 23

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