[1100] in Kerberos_V5_Development
OV admin system integration plan
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Fri May 3 17:32:47 1996
Date: Fri, 3 May 1996 17:32:36 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU
All,
First, an explanation: I have started working as a consultant on krb5.
Like Marc was, I am being funded by ISC. Generally, my plan is to
work at least through the release of krb5 1.0, but nothing is set in
stone yet.
The first thing I'm doing is taking over Marc's work of integrating
the OV admin system into krb5. Ted asked me to produce a integration
plan, and the first draft is enclosed below. I have not yet really
begun the design spec part, only the functional spec. Please read and
comment; also, try to think of other issues that will arise that are
not discussed. This document lives in
/mit/krb5/doc/specs/admin/integration/admin-integration.txt.
Thanks!
Barry
--- snip snip ---
OV Admin System Integration
Functional and Design Specification
$Id: admin-integration,v 1.3 96/05/03 17:25:05 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 DB for its own databases, and DBM to access the KDC database.
This presents something of a complication because DB exports its own
definitions of the standard DBM functions, implemented in terms of DB
primitives. Thus, a single program cannot access both a DBM and DB
library using standard code.
There are two obvious solutions to this problem. We can change
libkadmsrv to use a DB principal database instead of a DBM principal
database, or we can modify the DB library not to export DBM functions
so that the principal database remains in a DBM database. OV took the
latter approach, and it worked fine. The former would require
substantially more work. I propose that we modify the DB library not
to export DBM symbols, and keep the KDC using DBM for now.
\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. Rename the functions from ovsec_kadm_* to kadm_*, but
leave the ovsec_kadm_* as functions that take the correct arguments
and pass them directly to kadm_*. Similarly rename data types, error
code constants, and so forth, leaving identical ovsec_kadm versions
behind for compatibility.
o Programs, libraries, header files. 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 libkadmsrv.a instead of libkadmclnt.a and libgssrpc.a.
kdb5_create, ovsec_adm_create kdb5_create
kdb5_edit, ovsec_adm_cli kadmin{,.local}
ovpasswd kpasswd{,.local?}
ovsec_edit_keytab ktabutil{,.local}
(only if not in cli)
ovsec_adm_server kadmind
ovsec_v4adm_server kadmind.v4
libovsec_admclnt.a libkadmclnt.a
libkdb.a, libovsec_admsrv.a libkadmsrv.a
include/ovsec_admin/admin.h include/kadmin/kadmin.h
include/ovsec_admin/* include/kadmin/*
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
keytab/
ktabutil, ktabutil.local
lib/kadm/
libkadmclnt, libkadmsrv, headers
I'm a little unhappy with the disjointedness of "kdb5_*" in a few
places and "kadmin" in others, but "kadmin_create" does not feel quite
right. Or does it?
\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 ovsec_kadm's versioning support.
o The new libkadmclnt and libkadmsrv 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.
