dced_keytab_add

dced_keytab_add_key(3dce)

Adds a key (server password) to a specified key table on a specific host

Synopsis

#include <dce/dced.h>

void dced_keytab_add_key(

dced_binding_handle_t dced_bh,

uuid_t *keytab_uuid,

dced_key_t *key,

error_status_t *status);

Parameters

Input

dced_bh
Specifies the dced binding handle for the keytab service on a specific host.

keytab_uuid
Specifies the UUID that dced uses to identify the key table to which the key is to be added.

Input/Output

key
Specifies the key to be added. Some fields are completed by dced. See dced_intro(3dce).

Output

status
Returns the status code from this routine. This status code indicates whether the routine completed successfully or, if not, why not.

Description
The dced_keytab_add_key( ) routine adds a key to a server's key table (file) on a specific host, without changing the key in the security registry. (Servers use sec_key_mgmt_set_key(3sec) to do this for their own local key table.)

Most management applications use the dced_keytab_change_key( ) routine to remotely change a key because it also changes the key in the Security Registry.

Managing the same key in multiple key tables is a more complex process. The Security Registry needs a copy of a server's key so that during the authentication process, it can encrypt tickets that only a server with that key can later decrypt. Part of updating a key in the Security Registry also includes automatic version number updating. When servers share the same principle identity they use the same key. If these servers are on different hosts, then the key must be in more than one key table. (Even if the servers are on the same host, it is possible for their keys to be in different key tables, although this is not a recommended key management practice.) When the same keys in different tables need changing, one (perhaps the master server or busiest one) is changed using dced_keytab_change_key( ) which also causes an automatic version update. However, all other copies of the key must be changed using the dced_keytab_add_key( ) routine so that the version number does not change again.

Prior to calling dced_keytab_add_key( ) the application must have established a valid dced binding handle to the keytab service by calling either the dced_binding_create( ) or dced_binding_from_rpc_binding( ) routine.

Errors

The following describes a partial list of errors that might be returned. Refer to the OSF DCE Problem Determination Guide for complete descriptions of all error messages.

error_status_ok

db_s_bad_index_type

db_s_key_not_found

dced_s_bad_binding

dced_s_key_v0_not_allowe

dced_s_key_version_mismatch

dced_s_need_privacy

dced_s_random_key_not_allowed

rpc_s_binding_has_no_auth

rpc_s_invalid_binding

rpc_s_wrong_kind_of_binding

sec_acl_invalid_permission