next up previous contents
Next: API Handles Up: KADM5 Library and Server Previous: Contents   Contents

Overview

The KADM5 administration system is designed around the KADM5 API. The ``server-side'' library libkadm5srv.a implements the KADM5 API by operating directly on the underlying KDC and admin databases. The ``client-side'' library libkadm5clnt.a implements the KADM5 API via an RPC mechanism. The administration server kadmind accepts RPC requests from the client-side library and translates them into calls to the server-side library, performing authentication, authorization, and logging along the way.

The two libraries, libkadm5clnt.a and libkadm5srv.a, export the identical kadm5 interface; for example, both contain definitions for kadm5_get_principal, and all other kadm5 functions. In most cases, the client library function just marshalls arguments and results into and out of an RPC call, whereas the server library function performs the actual operation on the database file. kadm5_init_*, however, are substantially different even though they export the same interface: on the client, they establish the RPC connection and GSS-API context, whereas on the server side the open the database files, read in the password dictionary, and the like. Also, the kadm5_free functions operate on local process memory in both libraries.

The admin server is implemented as a nearly-stateless transaction server, where each admin API function represents a single transaction. No per-client or per-connection information is stored; only local database handles are maintained between requests. The RPC mechanism provides access to remote callers' authentication credentials for authorization purposes.

The admin API is exported via an RPC interface that hides all details about network encoding, authentication, and encryption of data on the wire. The RPC mechanism does, however, allow the server to access the underlying authentication credentials for authorization purposes.

The admin system maintains two databases:

The per-principal information stored in the admin principal database consists of the principal's policy name and an array of the principal's previous keys. The old keys are stored encrypted in the key of the special principal ``kadmin/history'' that is created by the server library when it is first needed. Since a change in kadmin/history's key renders every principal's key history array useless, it can only be changed using the ovsec_adm_edit utility; that program will reencrypt every principal's key history in the new key.2 The server library refuses all requests to change kadmin/history's key.


next up previous contents
Next: API Handles Up: KADM5 Library and Server Previous: Contents   Contents
Autobuild 2009-09-05