[1534] in Kerberos_V5_Development
additional bugs for Beta 7
daemon@ATHENA.MIT.EDU (Sam Hartman)
Mon Aug 12 03:15:24 1996
Date: Mon, 12 Aug 1996 03:15:19 -0400
From: Sam Hartman <hartmans@MIT.EDU>
To: krbcore@MIT.EDU
Because things were getting mildly more stable than they had
been over the last week, I decided to partially deploy Beta 7 in a
semi-controlled real-world environment. I installed it on a backup kdc
running on an Alpha (OSF 3.2) and changed my krb5.conf to use that
machine as a kdc.
* Upgrading from a Beta6 database worked correctly; all the principals
that kadmin needed were created and old data was preserved.
* If I ran kadmind, and then used the add_policy command with kadmin,
I got a "server communications failure" trying to add the policy. If
I added the policy in kadmin.local, I could modify it using kadmin.
* How is the default policy suposed to work? I created a policy
called default, then added a new principal, and the default policy had
a reference count of one. Yet, nothing on the getprinc info for the
principal I was using indicated it was using the default policy, even
though the reference count on default dropped tozero when I deleted
the new principal. However, there were other principals alread in the
database created before the default policy was created. Weere these
using the default policy? What would have happened to the reference
count had I deleted two of these?
* Somehow the kdb code in kdb_dbe_find_enctype to deal with making
sure DES-MD5 == DES-CRC == DES-RAW got mangled. I got some supported
enctype errors I don't think I should have gotten, but I need to play
around with it some. (I use a few DES3 keys in this database, so it's
mildly confusing.)
* The code in libgssapi_krb5 that forces the key to be a single-des
key was removed in the shuffle. I mention this becausse while I
realize we don't support DES3 in this release, it would be nice if the
DES3 support could be deployed incrementally, and this job will be
much easier if the clients will use single-DES keys in the presence of
DES3 keys than if they break. I don't want to get into a big
discussion of this now, as it would confuse things, but unless people
strongly object I'm going to check in a fix for this. (It's one line
in init_sec_context.c.)
* We should either fix the ftp client to try the old mechanism ID if
the new one fails, or document that people need to upgrade all servers
before clients. (Actually, this is kind of hard with shared libraries
if you have machines that act as both servers and clients.)
* Several of the GSSAPI applications (ftp, gss-client) are not
displaying usefulKerberos error messages for me, but instead are
display "unknown code krb5xxx".
I have not yet tested dumping a b7 database to a b6 kdc, or
kprop in either direction. Question: should kprop be using kdb5_util,
or kdb5_edit?
--Sam
