[1337] in Kerberos_V5_Development
Re: V4 kadmin server
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Wed Jun 19 21:47:22 1996
Date: Wed, 19 Jun 1996 21:47:16 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: Barry Jaspan's message of Tue, 18 Jun 96 14:02:15 -0400,
<9606181802.AA25569@beeblebrox.MIT.EDU>
Date: Tue, 18 Jun 96 14:02:15 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
I have just porting the V4 kadmin server to work with the kadm5 admin
system. It works, and the automated tests we wrote at OV pass.
When we first wrote this code at OV, we #ifdef'ed all the changes so
that the V4 kadmin server could be compiled either to use the
ovsec_kadm (now kadm5) api or to use the libkdb interface. Now that
kadm5 is part of MIT Kerberos, I think it makes sense for the program
just to be written in terms of kadm5 without the #ifdef's. This will
result in a much cleaner, more flexible program that will also enforce
kadm5's password policies.
This seems reasonable....
I actually don't understand why you bothered with the #ifdefs at all
since we already had a fully-functional version of the V4 kadmin server
which used the libkdb interface.
The downside is that we only implemented the change-password function
of V4 kadmind. The other functions could be implemented easily
enough, and in fact that would be a good project for someone that
wants to learn the kadm5 api.
Implementing the other functions is extremely important for MIT, and
since our existing V4 kadmin server has this support, if we integrate in
the OV V4 kadmin server *without* this support, the net result will be a
loss of functionality, and functionality which is very badly needed at
MIT.
So I don't want to leave it as "functionality we can do later because
someone wants to learn the kadm5 API." This is something that we need
very badly now --- and I'm sure Cygnus's customers will be in the same
boat as MIT's.
- Ted
