[1186] in Kerberos_V5_Development
Re: krb5_db_entry and kadm5 info
daemon@ATHENA.MIT.EDU (Bill Sommerfeld)
Wed May 15 21:18:31 1996
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: Your message of "Wed, 15 May 1996 15:56:08 -0400 ."
<9605151956.AA28601@starkiller.MIT.EDU>
Date: Wed, 15 May 1996 21:13:13 -0400
From: Bill Sommerfeld <sommerfeld@orchard.medford.ma.us>
-----BEGIN PGP SIGNED MESSAGE-----
There does not seem to be an explicit database entry versioning
system in place, though; however, we are probably going to force
users to do a dump/load cycle with krb5 1.0 anyway, so this is a
good time to introduce one.
Speaking as someone who drops the KDC on top of an *entirely*
different database (and who has customers who don't want to *know*
about dump/load cycles..)...
There are multiple reasons for retrieving info from the KDC database;
you may not want all of it at one time.
Just in the KDC, you use different sets of fields for a client vs. a
server.
Once you start introducing public key algorithms, you probably want to
attach a public key to each principal, and those are *big*; you
shouldn't have to haul that around on every access even if you're not
going to need it.
You don't need the password change history when you're just servicing
an AS_REQ; you don't need last-login information to find a server key,
etc., etc.,
When processing an AS_REQ, on a principal with multiple keys of
multiple etypes, you don't need *all* the client's keys, just the
one(s) which match the etype of the incoming request.
In DCE, we do invalid-password-based timed lockouts of accounts
(supply N bad passwords in X seconds, and all preauthenticated
AS_REQ's are bounced with a preauth failure even if you guess
correctly); you only need to fetch the login history in the AS_REQ,
not on server-side principals, but it costs us an extra database query
on every request to find the info (because it's in a different
table..).
There are ways of structuring attribute fetches which aren't that
painful to deal with...
- Bill
-----BEGIN PGP SIGNATURE-----
Version: 2.6.1
iQCVAwUBMZqBJbT+rHlVUGpxAQGtGwQAg1vWZmm92PAaoiVOI5IH5GgPnPWj8wLu
R+HFjBZNd/aBBukSTqvKMXvitOlAepmFvf3t6o+Tnk8l7uRise6TohlSu7vr6PmX
4yf2sfOariOlThcSwkiBUy+LbXeCb68DHCEw4QHG8ost2lZsldhD1WfbxnvktaSz
4E+iaWvuzaw=
=YQZG
-----END PGP SIGNATURE-----
