Ticket History #1349: rpcsec_gss compliant rpc replacement

As an internal note, we need to make sure that we pick up the security
fixes to rpc from the first part of this year as we integrate these
patches.


The handling of the minimum lifetime for kpasswd is broken. An
internal API from the server library is improperly duplicated in
src/kadmin/server/misc.c, and a prototype is randomly added to another
(non-header) file to access this. We need a cleaner way of getting at
the code.

The ifdef style is kind of unfortunate. Rather than removing old
code, the patches add ifdefs which should either be always true or
always false as I understand things. If there are cases where you
might define the ifdefs other than one way, I'd like to understand how
that would work. If my understanding is correct, I can run unifdef as
I apply the patches.


The changes related to using kadmin/fqdn instead of kadmin/admin are a
bit more far-reaching than I had hoped. I am also concerned they may
create problems for multi-homed admin servers and may create a support
load we don't want to deal with. I will revisit that issue on krbdev.


I have not yet audited (or even decided what approach if any to use in
order to audit) the actual RPC code. All I've done so far is to look
at the diffs to the rest of krb5. We need to at least confirm that
the RPC does not interact badly with an RPC from libc.

kwc@citi> I believe the bulk of the changes were in the testcases.
kwc@citi> Many of those changes were due to the change to use the
kwc@citi> non-rpc based kpasswd in the tests, not because of the
kwc@citi> kadmin principal change.


No, I'm actually thinking of:

* an API change to take the principal

* A change to generate the right principal in each client application.

* A dependence on a gethostname/gethostbyname pair in each application.
* A change to generate the kadmin key for the current hostname in
kdb5_util create.

Will have the rest of the discussion on krbdev.