[7615] in Kerberos

home help back first fref pref prev next nref lref last post

Problems with changing pw's with AFS salt types

daemon@ATHENA.MIT.EDU (Ken Hornstein)
Thu Jul 11 10:30:09 1996

To: kerberos@MIT.EDU
Date: 11 Jul 1996 00:15:04 -0400
From: kenh@cmf.nrl.navy.mil (Ken Hornstein)

So, I've been playing with converting our AFS ka database over to a
Kerberos 5 database.  This is going fine, except that things get hosed
up the first time the password is changed after the database migration.

It looks like the fault is right here, in lib/kdb/kdb_cpw.c:

        case KRB5_KDB_SALTTYPE_AFS3: {
            krb5_data * saltdata;
            if (retval = krb5_copy_data(context, krb5_princ_realm(context,
                                        db_entry->princ), &saltdata))
                return(retval);

            key_salt.data = *saltdata;
            /* key_salt.data.length = -1; *//*length actually used below...*/
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Since the length isn't set to -1, the AFS string-to-key function doesn't get
invoked on this key, and it's unusable later.

However, this really isn't a problem with what I'm trying to do.  I was
hoping that one you change your password, your database entry would get
converted to v5 and v4 key types, since I use:

	supported_enctypes = des-cbc-crc:normal des-cbc-crc:v4

in the kdc.conf file.  I was interesting in doing this so for those people
who still needed the odd v4 service, I could just say, "Change your password
and it will work".

If you change your password using kdb5_edit, this works fine.  But when you
change you password via kpasswd, it uses whatever salt type was in the
database, and in this case that's the AFS salt type.  In the case of kdb5_edit
it uses the info in the supported_enctypes array; in the kadmind5 server,
it doesn't.

Now, I know that the current kadmind5 is slated to go away down the road.
What I'm wondering is: what is the future behavior of password changes
supposed to be?  In later releases, are password changes supposed to use
keys for the supported encryption types, or just use the previous value in
the database?

The reason I'm asking this is because I can change kadmind5 to do whatever
I want, but I'd rather not depend on a feature that won't be around later.

--Ken

home help back first fref pref prev next nref lref last post