[1327] in Kerberos_V5_Development
kadm5 status
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Mon Jun 17 13:42:36 1996
Date: Mon, 17 Jun 1996 13:42:29 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU
This message describes the current status of the new kadm5 admin
system and its integration into Kerberos 5. It is a draft and will of
course change as the status changes. It will also probably evolve
into release notes for the kadm5 system.
Soon it will be time to merge the kadm5 system and the other Kerberos
changes it requires into the main krb5 branch.
* Sources
The sources live in /marc/krb5/src on beeblebrox.mit.edu; backups have
been made in /mit/krbdev/backup.. The admin code itself lives in
/marc/krb5/lib/kadm5 and /marc/krb5/src/kadmin.ov, both of which are
still under RCS and not yet checked into the CVS tree. The rest of
the Kerberos tree in /marc/krb5/src is a branch of pre-beta 6+. Some
changes have been made to existing Kerberos components (mainly libkdb
that I'm aware of) that will have to be merged back into the main
branch.
The kadm5 system is still using the gmake-based build system created
at OpenVision. It needs to be converted to use autoconf.
* Functionality
Almost all of the end-user and administrator components of the admin
system have been ported, including: the client and server side kadm5
libraries, kpasswd, kadmin client, kadmind server, kadm5_create,
kadm5_import and kadm5_export (equivalent of kdb5_edit dump/load for
policy information). The automated unit tests, based on dejagnu, for
the kadm5 libraries and kpasswd have also been ported and all of them
pass.
The only component of the OV admin system that has not been ported is
the modified V4 kadmind that uses the kadm5 api instead of the libkdb
api directly, and thus enforces the kadm5 password policies. I just
haven't gotten to it yet. The standard V4 kadmind that already exists
in the MIT tree can still be used with the new system, but it will not
enforce the kadm5 policies.
NOTE: There is an oustanding issue involving the libkdb library. A
bug exists somewhere in its locking mechanism that causes it to give
incorrect information to a caller, and perhaps corrupt the database,
in certain circumstances. The bug has been fixed in the version of
libkdb in beeblebrox, but Chris Provenzano intends to fix the bug in a
different manner.
* Backwards compatibility
** Krb5 b6 and previous releases
*** Database, dump and restore
The kadm5 system is database-compatible with whatever versions of the
KDC database the current libkdb supports.
The kdb5_edit dump/load format has not been changed, so any kdb5_edit
dump file that kdb5_edit knows how to read can still be used with the
new admin system. kadm5-specific information is dumped and loaded
separately via kadm5_export and kadm5_import. Ultimately, this
functionality should be merged into a single dump/load program, but
for now keeping them separate was faster.
*** GSS-API
The GSS-API library has changed to use the new, correct OID and the
correct behavior for computing checksums. Application servers
(programs that call gss_accept_sec_context()) linked against the new
library will support clients linked against either the old or new
GSS-API library, based on the OID in the initial context establishment
token.
GSS-API clients (programs that call gss_init_sec_context()) linked
against the new library will *not* work with servers linked against
the old library. There are a few possible solutions to this problem,
but none are perfect and it is not clear that a solution is really
needed.
** OpenVision's Secure (Authenticate) product
The new kadm5 system defines KADM5_API_VERSION_2 as its primary API
version. This section describes compatibility with
KADM5_API_VERSION_1 and OVSEC_KADM_API_VERSION_1 source code and
programs.
*** API and library
The existing ovsec_kadm api was renamed to kadm5 in this release. The
new libraries and header files still support all of the old ovsec_kadm
names, however. The functionality of OVSEC_KADM_API_VERSION_1 is
identical to that of KADM5_API_VERSION_1; thus, any mention of
KADM5_API_VERSION_1 also refers to OVSEC_KADM_API_VERSION_1.
The new kadm5 libraries support KADM5_API_VERSION_1 and
KADM5_API_VERSION_2 and compile and link time. In other words, you
can link existing version 1 objects against the new libraries, or you
can recompile them and then link with the new libraries, without
changing any code. The selection of version 1 or version 2 at compile
time is made with a #define symbol (which can be set on the compile
line via make). No specification of version 1 or version 2 is
necessary at link time.
*** Wire protocol
Existing client executables written to KADM5_API_VERSION_1 will
continue work with the new kadm5 kadmind. Client executables using
version 1 that are re-compiled or re-linked against the new kadm5
libraries will also work with the new kadm5 kadmind.
New clients linked against the new kadm5 libraries that use
KADM5_API_VERSION_1 will also work against the existing OpenVision
admin server, provided that they use the old OVSEC_KADM_ADMIN_SERVICE
or OVSEC_KADM_CHANGEPW_SERVICE constants for the service_name
arguments; the new KADM5 versions of those constants will not work,
since the actual Kerberos service principal names have changed.
*** Databases
The format of the kadm5 kadmind databases has changed. Existing
OpenVision sites must use ovsec_adm_export to dump their admin
principal and policy information, and then the new kadm5_import with
the -merge_princs flag to load it into the new database.
kadm5_export can be used to dump the admin-relevant information from a
new database back into a format compatible with ovsec_adm_import, by
giving it the -ovsec command-line option.
$Id: admin-status,v 1.2 96/06/17 13:42:12 bjaspan Exp $
