Barry Jaspan
This document describes the Admin API that can be used to maintain principals and policies. It describes the data structures used for each function and the interpretation of each data type field, the semantics of each API function, and the possible return codes.
The Admin API is intended to be used by remote clients using an RPC interface. It is implemented by the admin server running on the Kerberos master server. It is also possible for a program running on the Kerberos master server to use the Admin API directly, without going through the admin server.
The versions of this API and a brief description of the changes for each are:
The OVSEC_KADM name compatibility will not be extended to new functionality in future versions because no existing OVSEC_KADM clients will use that functionality; new clients should be written to the KADM5 API.
The Admin API Password Quality mechanism provides the following controls. Note that two strings are defined to be ``significantly different'' if they differ by at least one character. The compare is not case sensitive.
This section describes the data structures used by the Admin API.
They are defined in
kadm5/admin.h
.
A Kerberos principal entry is represented by a kadm5_principal_ent_t. It contains a subset of the information stored in the master Kerberos database as well as the additional information maintained by the admin system. In the current version, the only additional information is the principal's policy and the aux_attributes flags.
The principal may or may not have a policy enforced on it. If the
POLICY bit (see section
) is set in aux_attributes, the
policy field names the principal's policy. If the POLICY bit is not
set in aux_attributes, no policy is enforced on the principal and the
value of the policy field is undefined.
The fields of an kadm5_principal_ent_t are interpreted as follows.
| Name | Value | |
| KRB5_KDB_DISALLOW_POSTDATED | 0x00000001 | |
| KRB5_KDB_DISALLOW_FORWARDABLE | 0x00000002 | |
| KRB5_KDB_DISALLOW_TGT_BASED | 0x00000004 | |
| KRB5_KDB_DISALLOW_RENEWABLE | 0x00000008 | |
| KRB5_KDB_DISALLOW_PROXIABLE | 0x00000010 | |
| KRB5_KDB_DISALLOW_DUP_SKEY | 0x00000020 | |
| KRB5_KDB_DISALLOW_ALL_TIX | 0x00000040 | |
| KRB5_KDB_REQUIRES_PRE_AUTH | 0x00000080 | |
| KRB5_KDB_REQUIRES_HW_AUTH | 0x00000100 | |
| KRB5_KDB_REQUIRES_PWCHANGE | 0x00000200 | |
| KRB5_KDB_DISALLOW_SVR | 0x00001000 | |
| KRB5_KDB_PWCHANGE_SERVICE | 0x00002000 | |
| KRB5_KDB_SUPPORT_DESMD5 | 0x00004000 | |
| KRB5_KDB_NEW_PRINC | 0x00008000 |
#1 linked
list. This field only exists in KADM5_API_VERSION_2.
#1
array. This field only exists in KADM5_API_VERSION_2.
typedef struct _krb5_tl_data {
struct _krb5_tl_data* tl_data_next;
krb5_int16 tl_data_type;
krb5_int16 tl_data_length;
krb5_octet * tl_data_contents;
} krb5_tl_data;
The KADM5 API only allows elements whose tl_data_type is greater than
or equal to 256. Values less than 256 are reserved for internal use
by the KADM5 or kdb system. They are filtered out of the list
returned by kadm5_get_principal, and generate an error if given to
kadm5_modify_principal.
The libkdb library defines the tagged data types KRB5_TL_LAST_PWD_CHANGE, KRB5_TL_MOD_PRINC, and KRB5_TL_KADM_DATA, all with values less than 256, which store the last password modification time, time and modifier of last principal modification, and administration system data. All of these entries are expected by the administration system and parsed out into fields of the kadm5_principal_ent_rec structure; as described above, they are not included in the tl_data list.
Tagged data elements with types greater than 256 are handled without interpretation by KADM5. Note that an application that calls kadm5_modify_principal with the KADM5_TL_DATA mask bit set is responsible for providing the complete tl_data list, which it necessarily must obtain from kadm5_get_principal. It is never possible for an application to construct a complete tl_data list from scratch.
If the POLICY bit is set in aux_attributes, the #1 name field
in the kadm5_principal_ent_t structure refers to a password policy
entry defined in a #1.
typedef struct _kadm5_policy_ent_t {
char *policy;
u_int32 pw_min_life;
u_int32 pw_max_life;
u_int32 pw_min_length;
u_int32 pw_min_classes;
u_int32 pw_history_num;
u_int32 policy_refcnt;
} kadm5_policy_ent_rec, *kadm5_policy_ent_t;
The fields of an kadm5_policy_ent_t are interpreted as follows. Note that a policy's values only apply to a principal using that policy.
The KADM5 API acquires configuration information from the Kerberos configuration file ($KRB5_CONFIG or DEFAULT_PROFILE_PATH) and from the KDC configuration file ($KRB5_KDC_CONFIG or DEFAULT_KDC_PROFILE). In KADM5_API_VERSION_2, some of the configuration parameters used by the KADM5 API can be controlled by the caller by providing a kadm5_config_params structure to kadm5_init:
typedef struct _kadm5_config_params {
u_int32 mask;
/* Client and server fields */
char *realm;
char *profile;
int kadmind_port;
/* client fields */
char *admin_server;
/* server fields */
char *dbname;
char *admin_dbname;
char *admin_lockfile;
char *acl_file;
char *dict_file;
char *admin_keytab;
/* server library (database) fields */
int mkey_from_kbd;
char *stash_file;
char *mkey_name;
krb5_enctype enctype;
krb5_deltat max_life;
krb5_deltat max_rlife;
krb5_timestamp expiration;
krb5_flags flags;
krb5_key_salt_tuple *keysalts;
krb5_int32 num_keysalts;
} kadm5_config_params;
The following list describes each of the fields of the structure,
along with the profile relation it overrides, its mask value, its
default value, and whether it is valid on the client, server, or both,
or neither.
In KADM5_API_VERSION_1, all principals had a single key. The encryption method was always DES, and the salt type was determined outside the API (by command-line options to the administration server).
In KADM5_API_VERSION_2, principals can have multiple keys, each with its own encryption type and salt. Each time a principal's key is changed with kadm5_create_principal, kadm5_chpass_principal or kadm5_randkey_principal, existing key entries are removed and a key entry for each encryption and salt type tuple specified in the configuration parameters is added. There is no provision for specifying encryption and salt type information on a per-principal basis; in a future version, this will probably be part of the admin policy. There is also presently no provision for keeping multiple key versions for a single principal active in the database.
A single key is represented by a krb5_key_data:
typedef struct _krb5_key_data {
krb5_int16 key_data_ver; /* Version */
krb5_int16 key_data_kvno; /* Key Version */
krb5_int16 key_data_type[2]; /* Array of types */
krb5_int16 key_data_length[2]; /* Array of lengths */
krb5_octet * key_data_contents[2]; /* Array of pointers */
} krb5_key_data;
The API functions for creating, retrieving, and modifying principals and policies allow for a relevant subset of the fields of the kadm5_principal_ent_t and kadm5_policy_ent_t to be specified or changed. The chosen fields are determined by a bitmask that is passed to the relevant function. Each API function has different rules for which mask values can be specified, and can specify whether a given mask value is mandatory, optional, or forbidden. Mandatory fields must be present and forbidden fields must not be present or an error is generated. When creating a principal or policy, optional fields have a default value if they are not specified. When modifying a principal or policy, optional fields are unchanged if they are not specified. When retrieving a principal, optional fields are simply not provided if they are not specified; not specifying undeeded fields for retrieval may improve efficiency. The values for forbidden fields are defined in the function semantics.
The masks for principals are in table
and the
masks for policies are in table
. They are
defined in
kadm5/admin.h
. The KADM5_ prefix has been removed
from the Name fields. In the Create and Modify fields, M means
mandatory, F means forbidden, and O means optional. Create fields
that are optional specify the default value. The notation ``K/M
value'' means that the field inherits its value from the corresponding
field in the Kerberos master principal, for KADM5_API_VERSION_1, and
from the configuration parameters for KADM5_API_VERSION_2.
All masks for principals are optional for retrevial, except that the KEY_DATA mask is illegal when specified by a remote client; for details, see the function semantics for kadm5_get_principal.
Note that the POLICY and POLICY_CLR bits are special. When POLICY is set, the policy is assigned to the principal. When POLICY_CLR is specified, the policy is unassigned to the principal and as a result no policy controls the principal.
For convenience, the mask KADM5_PRINCIPAL_NORMAL_MASK contains all of the principal masks except KADM5_KEY_DATA and KADM5_TL_DATA, and the mask KADM5_POLICY_NORMAL_MASK contains all of the policy masks.
|
kadm5/admin.h
includes a number of required header files,
including RPC, Kerberos 5, com_err, and admin com_err
defines. It contains prototypes for all kadm5 routines mentioned
below, as well as all Admin API data structures, type definitions and
defines mentioned in this document.
Before #1ing
kadm5/admin.h
, the programmer can
specify the API version number that the program will use by
#1ing USE_KADM5_API_VERSION; for example, define that symbol
to be 1 to use KADM5_API_VERSION_1. This will ensure that the correct
functional protoypes and data structures are defined. If no version
symbol is defined, the most recent version supported by the header
files will be used.
Some of the defines and their values contained in
kadm5/admin.h
include the following, whose KADM5_ prefixes have been removed.
Symbols that do not exist in KADM5_API_VERSION_2 do not have a KADM5_
prefix, but instead retain only with OVSEC_KADM_ prefix for
compatibility.
KADM5 errors are described in
kadm5/kadm_err.h
, which
is included by
kadm5/admin.h
.
The locations of the admin policy and principal databases, as well as
defines and type definitions for the databases, are defined in
kadm5/adb.h
. Some of the defines in that file are:
Client applications will link against libkadm5clnt.a and server programs against libkadm5srv.a. Client applications must also link against: libgssapi_krb5.a, libkrb5.a, libcrypto.a, libgssrpc.a, libcom_err.a, and libdyn.a. Server applications must also link against: libkdb5.a, libkrb5.a, libcrypto.a, libgssrpc.a, libcom_err.a, and libdyn.a.
The error codes that can be returned by admin functions are listed below. Error codes indicated with a ``*'' can be returned by every admin function and always have the same meaning; these codes are omitted from the list presented with each function.
The admin system guarantees that a function that returns an error code has no other side effect.
The Admin system will use #1 for error codes. Note that this
means #1 codes may be returned from functions that the admin
routines call (e.g. the kerberos library). Callers should not expect
that only KADM5 errors will be returned. The Admin system error code
table name will be ``ovk'', and the offsets will be the same as the
order presented here. As mentioned above, the error table include file
will be
kadm5/kadm_err.h
.
Note that these error codes are also used as protocol error code constants and therefore must not change between product releases. Additional codes should be added at the end of the list, not in the middle. The integer value of KADM5_FAILURE is 43787520; the remaining values are assigned in sequentially increasing order.
Two Kerberos principals exist for use in communicating with the Admin system: kadmin/admin and kadmin/changepw. Both principals have the KRB5_KDB_DISALLOW_TGT_BASED bit set in their attributes so that service tickets for them can only be acquired via a password-based (AS_REQ) request. Additionally, kadmin/changepw has the KRB5_KDB_PWCHANGE_SERVICE bit set so that a principal with an expired password can still obtain a service ticket for it.
The Admin system accepts requests that are authenticated to either service principal, but the sets of operations that can be performed by a request authenticated to each service are different. In particular, only the functions chpass_principal, randkey_principal, get_principal, and get_policy can be performed by a request authenticated to the kadmin/changepw service, and they can only be performed when the target principal of the operation is the same as the authenticated client principal; the function semantics descriptions below give the precise details. This means that administrative operations can only be performed when authenticated to the kadmin/admin service. The reason for this distinction is that tickets for kadmin/changepw can be acquired with an expired password, and the KADM system does not want to allow an administrator with an expired password to perform administrative operations on arbitrary principals.
Each Admin API operation authenticated to the kadmin/admin service requires a specific authorization to run. This version uses a simple named privilege system with the following names and meanings:
Privileges are specified via an external configuration file on the Kerberos master server.
Table
summarizes the authorization
requirements of each function. Additionally, each API function
description identifies the privilege required to perform it. The
Authorization checks only happen if you are using the RPC mechanism.
If you are using the server-side API functions locally on the admin
server, the only authorization check is if you can access the
approporiate local files.
The functions provided by the Admin API, and the authorization they
require, are listed in the table
. The
``kadm5_'' prefix has been removed from each function name.
The function semantics in the following sections omit details that are the same for every function.
| Function Name | Authorization | Operation | |
| init | none | Open a connection with the kadm5 library. OBSOLETE but still provided--use init_with_password instead. | |
| init_with_password | none | Open a connection with the kadm5 library using a password to obtain initial credentials. | |
| init_with_skey | none | Open a connection with the kadm5 library using the keytab entry to obtain initial credentials. | |
| destroy | none | Close the connection with the kadm5 library. | |
| flush | none | Flush all database changes to disk; no-op when called remotely. | |
| create_principal | add | Create a new principal. | |
| delete_principal | delete | Delete a principal. | |
| modify_principal | modify | Modify the attributes of an existing principal (not password). | |
| rename_principal | add and delete | Rename a principal. | |
| get_principal | get2 | Retrieve a principal. | |
| get_principals | list | Retrieve some or all principal names. | |
| chpass_principal | changepw2 | Change a principal's password. | |
| chpass_principal_util | changepw2 | Utility wrapper around chpass_principal. | |
| randkey_principal | changepw2 | Randomize a principal's key. | |
| setkey_principal | setkey | Explicitly set a principal's keys. | |
| decrypt_key | none | Decrypt a principal key. | |
| create_policy | add | Create a new policy. | |
| delete_policy | delete | Delete a policy. | |
| modify_policy | modify | Modify the attributes of a policy. | |
| get_policy | get | Retrieve a policy. | |
| get_policies | list | Retrieve some or all policy names. | |
| free_principal_ent | none | Free the memory associated with an kadm5_principal_ent_t. | |
| free_policy_ent | none | Free the memory associated with an kadm5_policy_ent_t. | |
| get_privs | none | Return the caller's admin server privileges. |
In KADM5_API_VERSION 1:
kadm5_ret_t kadm5_init_with_password(char *client_name, char *pass,
char *service_name, char *realm,
unsigned long struct_version,
unsigned long api_version,
void **server_handle)
kadm5_ret_t kadm5_init_with_skey(char *client_name, char *keytab,
char *service_name, char *realm,
unsigned long struct_version,
unsigned long api_version,
void **server_handle)
kadm5_ret_t kadm5_init(char *client_name, char *pass,
char *service_name, char *realm,
unsigned long struct_version,
unsigned long api_version,
void **server_handle)
In KADM5_API_VERSION 2:
kadm5_ret_t kadm5_init_with_password(char *client_name, char *pass,
char *service_name,
kadm5_config_params *realm_params,
unsigned long struct_version,
unsigned long api_version,
void **server_handle)
kadm5_ret_t kadm5_init_with_skey(char *client_name, char *keytab,
char *service_name,
kadm5_config_params *realm_params,
unsigned long struct_version,
unsigned long api_version,
void **server_handle)
kadm5_ret_t kadm5_init(char *client_name, char *pass,
char *service_name,
kadm5_config_params *realm_params,
unsigned long struct_version,
unsigned long api_version,
void **server_handle)
kadm5_ret_t kadm5_init_with_creds(char *client_name,
krb5_ccache ccache,
char *service_name,
kadm5_config_params *params,
krb5_ui_4 struct_version,
krb5_ui_4 api_version,
void **server_handle)
AUTHORIZATION REQUIRED: none
NOTE: kadm5_init is an obsolete function provided for backwards compatibility. It is identical to kadm5_init_with_password.
These three functions open a connection to the kadm5 library and initialize any neccessary state information. They behave differently when called from local and remote clients.
In KADM5_API_VERSION_2, these functions take a kadm5_config_params
structure instead of a realm name as an argument. The semantics are
similar: if a NULL pointer is passed for the realm_params argument,
the default realm and default parameters for that realm, as specified
in the krb5 configuration file (e.g. /etc/krb5.conf) are used. If a
realm_params structure is provided, the fields that are set override
the default values. If a parameter is specified to the local or
remote libraries that does not apply to that side, an error code
(KADM5_BAD_CLIENT_PARAMS or KADM5_BAD_SERVER_PARAMS) is returned. See
section
for a discussion of configuration
parameters.
For remote clients, the semantics are:
The caller should always specify KADM5_STRUCT_VERSION for the struct_version argument, a valid and supported API version constant for the api_version argument (currently, KADM5_API_VERSION_1 or KADM5_API_VERSION_2), and a valid pointer in which the server handle will be stored.
If any kadm5_init_* is invoked locally its semantics are:
RETURN CODES:
kadm5_ret_t kadm5_flush(void *server_handle)
AUTHORIZATION REQUIRED: none
Flush all changes to the Kerberos databases, leaving the connection to the Admin API open. This function behaves differently when called by local and remote clients.
For local clients, the function closes and reopens the Kerberos database with krb5_db_fini() and krb5_db_init(), and closes and reopens the Admin policy database with adb_policy_close() and adb_policy_open(). Although it is unlikely, any other these functions could return errors; in that case, this function calls kadm5_destroy and returns the error code. Therefore, if kadm5_flush does not return KADM5_OK, the connection to the Admin server has been terminated and, in principle, the databases might be corrupt.
For remote clients, the function is a no-op.
kadm5_ret_t kadm5_destroy(void *server_handle)
AUTHORIZATION REQUIRED: none
Close the connection to the Admin server and releases all related resources. This function behaves differently when called by local and remote clients.
For remote clients, the semantics are:
For local clients, this function just frees the storage space associated with server_handle after erasing its magic number.
RETURN CODES:
kadm5_ret_t
kadm5_create_principal(void *server_handle,
kadm5_principal_ent_t princ, u_int32 mask,
char *pw);
AUTHORIZATION REQUIRED: add
RETURN CODES:
kadm5_ret_t kadm5_delete_principal(void *server_handle, krb5_principal princ);
AUTHORIZATION REQUIRED: delete
RETURN CODES:
kadm5_ret_t
kadm5_modify_principal(void *server_handle,
kadm5_principal_ent_t princ, u_int32 mask);
Modify the attributes of the principal named in kadm5_principal_ent_t. This does not allow the principal to be renamed or for its password to be changed.
AUTHORIZATION REQUIRED: modify
Although a principal's pw_expiration is usually computed based on its policy and the time at which it changes its password, this function also allows it to be specified explicitly. This allows an administrator, for example, to create a principal and assign it to a policy with a pw_max_life of one month, but to declare that the new principal must change its password away from its initial value sometime within the first week.
RETURN CODES:
kadm5_ret_t
kadm5_rename_principal(void *server_handle, krb5_principal source,
krb5_principal target);
AUTHORIZATION REQUIRED: add and delete
Note that since the principal name may have been used as the salt for the principal's key, renaming the principal may render the principal's current password useless; with the new salt, the key generated by string-to-key on the password will suddenly be different. Therefore, an application that renames a principal must also require the user to specify a new password for the principal (and administrators should notify the affected party).
Note also that, by the same argument, renaming a principal will invalidate that principal's password history information; since the salt will be different, a user will be able to select a previous password without error.
RETURN CODES:
kadm5_ret_t
kadm5_chpass_principal(void *server_handle, krb5_principal princ,
char *pw);
AUTHORIZATION REQUIRED: changepw, or the calling principal being the same as the princ argument. If the request is authenticated to the kadmin/changepw service, the changepw privilege is disregarded.
Change a principal's password. See section
for a
description of how the keys are determined.
This function enforces password policy and dictionary checks. If the new password specified is in the password dictionary, and the policy bit is set KADM5_PASS_DICT is returned. If the principal's POLICY bit is set in aux_attributes, compliance with each of the named policy fields is verified and an appropriate error code is returned if verification fails.
Note that the policy checks are only be performed if the POLICY bit is set in the principal's aux_attributes field.
RETURN CODES:
kadm5_ret_t
kadm5_chpass_principal_util(void *server_handle, krb5_principal princ,
char *new_pw, char **pw_ret,
char *msg_ret);
AUTHORIZATION REQUIRED: changepw, or the calling principal being the same as the princ argument. If the request is authenticated to the kadmin/changepw service, the changepw privilege is disregarded.
This function is a wrapper around kadm5_chpass_principal. It can read a new password from a user, change a principal's password, and return detailed error messages. msg_ret should point to a char buffer in the caller's space of sufficient length for the error messages described below. 1024 bytes is recommended. It will also return the new password to the caller if pw_ret is non-NULL.
Detailed messages:
RETURN CODES:
In KADM5_API_VERSION_1:
kadm5_ret_t
kadm5_randkey_principal(void *server_handle, krb5_principal princ,
krb5_keyblock **new_key)
In KADM5_API_VERSION_2:
kadm5_ret_t
kadm5_randkey_principal(void *server_handle, krb5_principal princ,
krb5_keyblock **new_keys, int *n_keys)
AUTHORIZATION REQUIRED: changepw, or the calling principal being the same as the princ argument. If the request is authenticated to the kadmin/changepw service, the changepw privilege is disregarded.
Generate and assign a new random key to the named principal, and
return the generated key in allocated storage. In
KADM5_API_VERSION_2, multiple keys may be generated and returned as an
array, and n_new_keys is filled in with the number of keys generated.
See section
for a description of how the keys are
chosen. In KADM5_API_VERSION_1, the caller must free the returned
krb5_keyblock * with krb5_free_keyblock. In KADM5_API_VERSION_2, the
caller must free each returned keyblock with krb5_free_keyblock.
If the principal's POLICY bit is set in aux_attributes and the caller does not have modify privilege , compliance with the password minimum life specified by the policy is verified and an appropriate error code is returned if verification fails.
RETURN CODES:
This function can also be used as part of a sequence to create a new principal with a random key. The steps to perform the operation securely are
The three steps are necessary to ensure secure creation. Since an attacker might be able to guess the initial password assigned by the client program, the principal must be disabled until the key can be truly randomized.
kadm5_ret_t
kadm5_setkey_principal(void *server_handle, krb5_principal princ,
krb5_keyblock *new_keys, int n_keys)
AUTHORIZATION REQUIRED: setkey. This function does not allow the use of regular changepw authorization because it bypasses the password policy mechanism.
This function only exists in KADM5_API_VERSION_2.
Explicitly sets the specified principal's keys to the n_keys keys in the new_keys array. The keys in new_keys should not be encrypted in the Kerberos master key; this function will perform that operation itself (the keys will be protected during transmission from the calling client to the kadmind server by the AUTH_GSSAPI RPC layer). This function completely bypasses the principal's password policy, if set.
RETURN CODES:
This function can also be used as part of a sequence to create a new principal with an explicitly key. The steps to perform the operation securely are
The three steps are necessary to ensure secure creation. Since an attacker might be able to guess the initial password assigned by the client program, the principal must be disabled until the key can be truly randomized.
In KADM5_API_VERSION_1:
kadm5_ret_t
kadm5_get_principal(void *server_handle, krb5_principal princ,
kadm5_principal_ent_t *ent);
In KADM5_API_VERSION_2:
kadm5_ret_t
kadm5_get_principal(void *server_handle, krb5_principal princ,
kadm5_principal_ent_t ent, u_int32 mask);
AUTHORIZATION REQUIRED: get, or the calling principal being the same as the princ argument. If the request is authenticated to the kadmin/changepw service, the get privilege is disregarded.
In KADM5_API_VERSION_1, return all of the principal's attributes in allocated memory; if an error is returned entry is set to NULL. In KADM5_API_VERSION_2, fill in the fields of the principal structure specified in the mask; memory for the structure is not allocated. Typically, a caller will specify the mask KADM5_PRINCIPAL_NORMAL_MASK, which includes all the fields except key_data and tl_data to improve time and memory efficiency. A caller that wants key_data and tl_data can bitwise-OR those masks onto NORMAL_MASK. Note that even if KADM5_TL_DATA is specified, this function will not return internal tl_data elements whose type is less than 256.
The caller must free the returned entry with kadm5_free_principal_ent.
The function behaves differently for local and remote clients. For remote clients, the KEY_DATA mask is illegal and results in a KADM5_BAD_MASK error.
RETURN CODES:
kadm5_ret_t kadm5_decrypt_key(void *server_handle,
kadm5_principal_ent_t entry, krb5_int32
ktype, krb5_int32 stype, krb5_int32
kvno, krb5_keyblock *keyblock,
krb5_keysalt *keysalt, int *kvnop)
AUTHORIZATION REQUIRED: none, local function
Searches a principal's key_data array to find a key with the specified enctype, salt type, and kvno, and decrypts the key into keyblock and keysalt if found. entry must have been returned by kadm5_get_principal with at least the KADM5_KEY_DATA mask set. Returns ENOENT if the key cannot be found, EINVAL if the key_data array is empty (as it always is in an RPC client).
If ktype or stype is -1, it is ignored for the search. If kvno is -1, ktype and stype are ignored and the key with the max kvno is returned. If kvno is 0, only the key with the max kvno is returned and only if it matches the ktype and stype; otherwise, ENOENT is returned.
kadm5_ret_t
kadm5_get_principals(void *server_handle, char *exp,
char ***princs, int *count)
Retrieves the list of principal names.
AUTHORIZATION REQUIRED: list
If #1 is NULL, all principal names are retrieved; otherwise,
principal names that match the expression exp are retrieved.
#1 is filled in with a pointer to a NULL-terminated array of
strings, and #1 is filled in with the number of principal names
in the array. #1 must be freed with a call to
#1.
All characters in the expression match themselves except ``?'' which
matches any single character, ``*'' which matches any number of
consecutive characters, and ``[chars]'' which matches any single
character of ``chars''. Any character which follows a ``
''
matches itself exactly, and a ``
'' cannot be the last
character in the string.
kadm5_ret_t
kadm5_create_policy(void *server_handle,
kadm5_policy_ent_t policy, u_int32 mask);
Create a new policy.
AUTHORIZATION REQUIRED: add
RETURN CODES:
kadm5_ret_t kadm5_delete_policy(void *server_handle, char *policy);
Deletes a policy.
AUTHORIZATION REQUIRED: delete
RETURN CODES:
kadm5_ret_t
kadm5_modify_policy(void *server_handle,
kadm5_policy_ent_t policy, u_int32 mask);
Modify an existing policy. Note that modifying a policy has no affect on a principal using the policy until the next time the principal's password is changed.
AUTHORIZATION REQUIRED: modify
RETURN CODES:
In KADM5_API_VERSION_1:
kadm5_ret_t kadm5_get_policy(void *server_handle, char *policy, kadm5_policy_ent_t *ent);
In KADM5_API_VERSION_2:
kadm5_ret_t kadm5_get_policy(void *server_handle, char *policy, kadm5_policy_ent_t ent);
AUTHORIZATION REQUIRED: get, or the calling principal's policy being the same as the policy argument. If the request is authenticated to the kadmin/changepw service, the get privilege is disregarded.
In KADM5_API_VERSION_1, return the policy's attributes in allocated memory; if an error is returned entry is set to NULL. In KADM5_API_VERSION_2, fill in fields of the policy structure allocated by the caller. The caller must free the returned entry with kadm5_free_policy_ent
RETURN CODES:
kadm5_ret_t
kadm5_get_policies(void *server_handle, char *exp,
char ***pols, int *count)
Retrieves the list of principal names.
AUTHORIZATION REQUIRED: list
If #1 is NULL, all principal names are retrieved; otherwise,
principal names that match the expression exp are retrieved. #1
is filled in with a pointer to a NULL-terminated array of strings, and
#1 is filled in with the number of principal names in the
array. #1 must be freed with a call to
#1.
All characters in the expression match themselves except ``?'' which
matches any single character, ``*'' which matches any number of
consecutive characters, and ``[chars]'' which matches any single
character of ``chars''. Any character which follows a ``
''
matches itself exactly, and a ``
'' cannot be the last
character in the string.
void kadm5_free_principal_ent(void *server_handle,
kadm5_principal_ent_t princ);
In KADM5_API_VERSION_1, free the structure and contents allocated by a call to kadm5_get_principal. In KADM5_API_VERSION_2, free the contents allocated by a call to kadm5_get_principal.
AUTHORIZATION REQUIRED: none (local operation)
void kadm5_free_policy_ent(kadm5_policy_ent_t policy);
Free memory that was allocated by a call to kadm5_get_policy. If the argument is NULL, the function returns succesfully.
AUTHORIZATION REQUIRED: none (local operation)
void kadm5_free_name_list(void *server_handle,
char **names, int *count);
Free the memory that was allocated by kadm5_get_principals or kadm5_get_policies. names and count must be a matched pair of values returned from one of those two functions.
void kadm5_free_key_data(void *server_handle,
krb5_int16 *n_key_data, krb5_key_data *key_data)
Free the memory that was allocated by kadm5_randkey_principal. n_key_data and key_data must be a matched pair of values returned from that function.
kadm5_ret_t kadm5_get_privs(void *server_handle, u_int32 *privs);
Return the caller's admin server privileges in the integer pointed to by the argument. The Admin API does not define any way for a principal's privileges to be set. Note that this function will probably be removed or drastically changed in future versions of this system.
The returned value is a bitmask indicating the caller's privileges:
| Privilege | Symbol | Value |
| Get | KADM5_PRIV_GET | 0x01 |
| Add | KADM5_PRIV_ADD | 0x02 |
| Modify | KADM5_PRIV_MODIFY | 0x04 |
| Delete | KADM5_PRIV_DELETE | 0x08 |
| List | KADM5_PRIV_LIST | 0x10 |
| Changepw | KADM5_PRIV_CPW | 0x20 |
There is no guarantee that a caller will have a privilege indicated by this function for any length of time or for any particular target; applications using this function must still be prepared to handle all possible KADM5_AUTH_* error codes.
In the initial MIT Kerberos version of the admin server, permissions depend both on the caller and the target; this function returns a bitmask representing all privileges the caller can possibly have for any possible target.