[1120] in Kerberos_V5_Development
new draft of OV integration plan
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Mon May 6 15:06:46 1996
Date: Mon, 6 May 1996 15:06:11 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU
A new draft of the OV integration plan is enclosed below which
incorporates the comments so far. Change bars appear in the right
margin.
Barry
OV Admin System Integration
Functional and Design Specification
$Id: admin-integration.txt,v 1.5 96/05/06 15:03:37 bjaspan Exp $ |
\section{Functional Specification}
This section discusses various issues involved in integrating OV's
administration system into the MIT Kerberos distribution and defines
the functional behavior of the various components. For descriptions
of specific OV admin system programs, see their specifications in
/mit/krb5/doc/specs.
\subsection{The various kadmin systems}
(1) kadmin.new. Long ago, MIT developed a CLI for OV's admin system
in this directory, in preparation for a donation that never occurred.
The CLI was completed, given to MIT, and is now part of the OV admin
system donated to MIT. The directory is obsolete and contains nothing
of value. It should be deleted.
(2) kadmin.old. This directory contained the Sandia kadmin system,
which is no longer shipped as of beta 6. It should be deleted.
(3) kadmin. This directory contains the "simple password-changing
protocol" admin system which was also extended to perform some other
admin functions since no other system was available. Given OV's admin
system, there is no longer any need for this system to be enhanced,
but there may still be a place in the world for a simple
password-changing protocol. Such a system, however, should not
consume the more general name "kadmin". I suggest renaming this
directory to kadmin.pw or perhaps something like cpwsrv.
(3) kadmin.v4. This directory contains a hacked up V4 admin server
that speaks the V4 admin protocol but operates on a V5 database.
According to Ted, it "probably" understands the current V5 database
API and format but has not been tested recently. It certainly does
not understand whatever changes Marc has already made, and I may
continue to make, to the kdb library in order to make the OV admin
system work.
Even if the server understands the current database format, it may not
be able to coexist with the OV admin server. Obviously, the server
will not enforce password policies or history, but whether that is
acceptable can be simply left as a policy decision. It is also not
clear, however, whether the OV admin system will be able to tolerate
another program modifying the database without its knowledge. OV's
product, based on beta 4, absolutely requires that no other system
have modification access to the database. It is possible that the new
database format (in particular, having the OV admin server store its
per-principal data in the KDC database directly) will loosen this
restriction, but that seems unlikely without explicit effort.
The OV admin system contains a version of the V4 admin server that
knows how to work within the OV system. However, OV's current V4
compat server only accepts change-password requests, whereas MIT's V4
server accepts all V4 admin requests.
The primary requirement for a V4 compatibility server comes from MIT
itself; it is not critical for the public release to contain a
fully-functional V4 compat server. I propose the following actions:
o Remove the MIT V4 compat server from the public release.
o Examine the difficulty of enhancing the OV V4 compat server to
accept all V4 requests.
o If time allows enhancing the OV V4 compat server, include the
enhanced version in the public release, and use the enhanced version
at MIT.
o If time does not allow enhancing the OV V4 compat server, include
the current OV V4 compat server in the public release and use the MIT
V4 compat server at MIT. This may or may not preclude using the OV
admin system at MIT until the OV server can be completed.
\subsection{Database access}
The KDC currently uses libkdb, based on DBM, to access the KDC
database. libkdb provides get, put, delete, and iterate access to the
DBM database. The various kdb5_* utilitiees (kdb5_create, kdb5_edit)
and all previous administration systems also use this interface.
When OV's product was developed, the KDC database and libkdb were not
sufficiently flexible to implement the desired administration
functionality. Rather than modify libkdb and thus be completely
incompatible with MIT KDCs, OV decided to implement a new API
(ovsec_kadm) that accessed both the KDC database and new
administration databases. The ovsec_kadm API providers higher-level
access to the database and enforces the restrictions of the OV
administration system. It also provides seamless operation for both
local and remote clients.
The decision to implement a new API and new databases made sense when
OV wanted to maintain compatiblity with the MIT release. Now that the
admin system is part of the MIT release, however, it makes no sense
for different parts of Kerberos to access the database via separate
APIs. Therefore, all programs that access the Kerberos databases
should be modified to work through the ovsec_kadm API. The existing
libkdb will still be present and used underneath ovsec_kadm to
implement low-level KDC database access, but it will only be used by
libkadmsrv and not by programs.
The KDC database is currently stored using DBM. The OV admin system
uses libkdb to access the KDC principal database and BSD DB to access |
its own (policy) database. This presents something of a complication |
because DB exports its own definitions of the standard DBM/ndbm |
functions, implemented in terms of DB primitives. Thus, a single |
program cannot access both a DBM and DB library using standard code. |
|
There are several potential solutions to this problem: |
|
1. Change libkdb to use a DB principal database instead of a DBM |
principal database. The advantage is that krb5 will use only a single |
database layer, simplifying the configure/build process. The |
disadvantage is that the DB format is likely to change in the future |
so sites would have to perform a dump/reload cycle to update to the |
new format; this isn't a particularly big deal, however. Also note |
that to avoid this problem completely, we'd also have to change OV's |
system from DB to DBM which would entail extra work. |
|
2. We can modify the DB library not to export DBM functions and link |
against libdbm/ndbm so that the principal database remains in a DBM |
database. The OV system currently does this. The advantage is |
compatibility with existing KDC databases with no extra work to |
ourselves, although we're only saving a dump/load cycle. The |
disadvantage is that we'll have to modify the DB library not to export |
DBM symbols, and although that will be trivial it will be one more |
thing to do each release. |
|
3. We can leave the DBM symbols in the DB library so that libkdb uses |
the DBM interface but actually uses the DB library. There is no real |
advantage, since libkdb can use the DBM or DB interface with a |
#define. This approach increases the confusion factor by using a |
well-known interface of a library we won't be linking against. |
|
The current consensus seems to be option 1, accepting the risk of a |
format change that requires all sites to perform a dump/load cycle. |
\subsection{The KDC admin utilities}
The utiltiies kdb5_create, kdb5_edit, and kdb5_destroy support the
operation of Kerberos 5 without an administration system. This
obviously made sense when there was no admin system. When OV created
its admin system, it kept the distinction between its system and these
programs so as to minimize the changes from a stock Kerberos system.
Now that MIT's release will have a single, definitive admin system,
however, there is no logical reason for these programs to exist
separately. I propose the following actions:
o Merge kdb5_create and ovsec_adm_create into a single program,
kdb5_create. This program will create the physical databases
(currently two, one for principals and one for policies) and populate
the database with the mandatory initial values. Similarly, merge
kdb5_destroy and ovsec_adm_destroy into a single program,
kdb5_destroy.
o Discard MIT's kdb5_edit in favor of OV's CLI admin client. This
client has the advantage of presenting an identical interface for both
local and remote database access, with the exception that the local
version does not require tickets or a password. Unlike previous admin
clients, the OV CLI provides for full control of all fields in the
database (at least, it did as of V4; we will have to enhance OV's
entire admin system to support new features such as multiple keys per
principal). Note that the OV CLI does not currently provide for
keytab maintainance; that functionality is implemented in a separate
program, ovsec_edit_keytab, that can also be used locally or remotely.
It would be trivial, and may be desireable, to merge these two
programs.
\subsection{Naming and directory layout}
In light of the previous discussion, I suggest the following naming
scheme for the new MIT/OV admin system in the MIT public release.
Note that in general I am not concerning myself with changing the
functionality or usage of an existing program; V5's admin system has
never been good enough to warrant much pain in the name of backwards
compatibility.
o Admin API, libraries, headers. Rename the API from ovsec_kadm to |
kadm5. Change functions from ovsec_kadm_* to kadm5_*, but leave the |
ovsec_kadm_* as functions that take the correct arguments and pass |
them directly to kadm5_*. Similarly rename data types, error code |
constants, and so forth, leaving identical ovsec_kadm versions behind |
for compatibility. The following table summarizes how files will be |
renamed. |
|
libovsec_admclnt.a libkadm5clnt.a |
libkdb.a, libovsec_admsrv.a libkadm5srv.a |
include/ovsec_admin/admin.h include/kadm5/kadm5.h |
include/ovsec_admin/* include/kadm5/* |
|
o Programs. Merge kdb5 and OV utilities into a new suite, generally |
prefixed with "kadmin". The following table summarizes how files will |
be combined and renamed. Programs with a .local extension are |
identical to the non-local counterparts, except they are linked with |
libkadm5srv.a instead of libkadm5clnt.a and libgssrpc.a. |
kdb5_create, ovsec_adm_create kadmin_create |
kdb5_destroy kadmin_destroy |
kdb5_edit, ovsec_adm_cli kadmin{,.local}
ovsec_edit_keytab merge into kadmin |
ovpasswd kpasswd{,.local?}
ovsec_adm_server kadmind
ovsec_v4adm_server kadmind.v4
o Source tree layout. Each directory contains the sources for the
programs listed.
krb5/src/
kadmin/
create/
kdb5_create
cli/
kadmin, kadmin.local
destroy/
kdb5_destroy
passwd/
kpasswd, kpasswd.local (?)
server/
kadmind
v4server/
kadmind.v4
lib/kadm5/ |
libkadm5clnt, libkadm5srv, headers |
\subsection{Backwards compatibility}
In general, I do not believe we should feel too compelled to be
backwards compatible with previous MIT Kerberos administration
systems. They were all poor, and we should not constrain ourselves in
the future with mistakes from the past.
o Old KDC database dumps should be loadable into the new system;
either kadmin can understand the old format explicitly or we can write
a separate program to do it. Note that this will also enable
migrating an existing KDC database to the new format, since it can be
dumped from the old system and reloaded into the new one.
o The new kadmind should be protocol compatible with OpenV*Secure's
admin server, to support existing OpenV*Secure clients. This should
not be difficult given kadm5's versioning support. |
o The new libkadm5clnt and libkadm5srv should be compile-time compatible |
with existing ovsec_kadm clients. Again, this should come pretty much
for free because of the API version support. In fact, the libraries
will probably be link compatible as well.
