Heimdal

Added ok-as-delegate support to the KDC and kadmin tonight, I just realised we didn’t support it when I finally got around to writing ok-as-delegate support to GSS-API. I’m somewhat unhappy with unparse_flags() in roken, it not very future proof, unknown bits causes the world to catch on fire and it does interesting things.

The part of ok-as-delegate in the GSS-API lib was simpler to implement then what I expected, quite a low number or rows was needed, most of the infrastructure was already there thanks to compatibility option.

I’ve started to put done in words all ideas I have integrating Kerberos in Stockholms Univerity’s enviroment (sorry, in swedish). There is a need for such document to explain to our sysadmins and developers why the enviroment look likes it does. Hopefully I’ll get around to implement (or have someone else do it) them now that I know what order the diffrent part needs to be.

First out is storing cleartext-passwords in the KDC so that new enctypes can easily be added. I guess they really should be encrypted using public key encrytion, but that wont do since we need to expose them to our helpdesk. Don’t ask why, its just that way now.

I started to use the new HDB extensions to implement new
functionality in Heimdal. First was to use it were storing a date for
last password change and storing the password of the user.

Storing password in the database is problematic for several reason,
and a by default its turned off. The really big problem is
that if the database is compromised, the users have their passwords
spilled to all system they use the same password. If the string to key
function salts the key using something unique for the realm and the
user (like the principal string), the password exposed itself isn’t
exposed. The password is still open to dictionary attacks, so for that
reason I think its OK do do it this way.

The main reason what I added this functionallity is that we it for some support systems at Stockholm Univerity. If we didn’t need to do that, I would
be fine with not storing the password.

A good thing with storing the password is that we now can “upgrade” a
user to new encryption types without requesting the user to change
password. So when AES is replaced with something newer, or we add
digest-md5 support, we have no reason to force people to change
passwords just to take advantage of the new encryption type.

Lately I’ve been fixing many bugs, removing warnings that we get with
gcc4, and merging code from Samba4 code base. I’ve also deployed a new
snapshot to Stockholm University’s KDC so they can use the new
password storing code. Its kind of exciting to deploy new code when
there are about 1000 new principals created each day. So far so good.