Principals

A principal is a specific entity to which you can assign a set of credentials. Principals are users and network services that are included in your security network.

The general syntax for a principal is as follows:

identifier/instance@REALM

where:

identifier

Specifies the name of the network service or a user. This parameter is mandatory and you must specify the identifier.

/instance

Specifies the group used to further identify the name. The instance can identify the duties, organization, or any other information about the principal.

For a user, the instance is often used to describe the intended use of the corresponding credentials.

For a host, the instance is the fully qualified domain name. You can specify up to 255 instances. You must precede each additional instance with a slash (/).

The commands rlogind, ftpd, rshd, rcpd, and telnetd use the instance to indicate the name of the system on which the network service resides.

An instance may also imply special privileges. For example, a security administrator can have a principal account with an admin instance to use when performing administration tasks.

The /instance parameter is not mandatory.

Realm

Specifies the realm in which the principal resides. By convention, realm names are the fully qualified domain name of the primary security server.

This parameter is mandatory and you must specify the realm name.

When creating principal names, ensure that a principal name:

Is case sensitive.
Cannot be longer than 767 characters.
Must be uniquely defined in the first 255 characters.
Cannot contain a space, tab, pound symbol (#), backward slash (\) or colon (:).
Does not subscribe to a NULL policy. If you subscribe to a policy that does not exist in the password.policy file, the default policy * is applied for the principal.




	NOTE: You can use the slash (`/`) character in a principal name to delineate an instance.

Following are the different types of principals:

User principal
A user principal is an account assigned to an individual in your organization. Each individual must have at least one account. You may choose to add multiple accounts for one individual if you intend to use the accounts for different purposes. Use the instance parameter of the principal name to designate the intended use of the account. Following are the special categories for user principals:
Administrative principals are user accounts with administrative permissions assigned in admin_acl_file. HP recommends that you use the /admin instance to distinguish these accounts.
Service principal
A service principal is a principal account assigned to a service in your security network. Examples of service principals include secured daemons or services that are accessible on the network, and host/ principals created for a host system of the user.

Adding User Principals

The Kerberos server enables you to add user principals to the principal database. The only limit on the number of principals in the database is the disk space available on the primary security server and on each of the secondary security servers.

When adding a user principal to the database, assign the principal identifier, instances (if used), and the realm name. You must also designate a temporary password for the principal. You may assign specific attributes and properties to the account. Any attributes and properties that are not specifically set for the principal are inherited from the default group principal.

Establish a secure method for transferring the temporary password information to the user to avoid a security breach. Communicate the temporary password before the user authenticates with the new principal account. Make sure the user knows that he or she is required to change the password during the first authentication attempt.

Adding New Service Principals

The Kerberos server enables you to add service principals to the principal database. Use service principal accounts for a UNIX host system, a Kerberos-secured service, or an application that is available to user principals in the network.

When the Kerberos server software is installed, the Kerberos server requires certain service principals that are automatically added to the principal database. You must manually add the service principal accounts used by the optional secured service applications to the principal database.

Each Kerberos-secured service or application must have the ability to provide its secret key during authentication. Therefore, service principal accounts must have the following specific attributes and properties, depending on the requirements of the application:

The application must be able to provide its unique principal name during authentication.
The instance portion of the service principal name must be the fully qualified domain name (FQDN) of the host on which the service resides. Although the FQDN in your network can use mixed-case characters, the instance portion of the principal name must be in lowercase.
For example, if the system name is IT.BAMBI.COM, the principal name must use the instance it.bambi.com.
If you fail to use this principal naming convention for the Kerberos server utilities, daemons, and services, the service principals cannot authenticate, and other principals cannot access when required.
You must set the Allow as Service attribute for the service principal account.
You must extract the secret key to the service key table file on the host of the service. Unlike user principals who type their password using the keyboard, a service principal must have its secret key automatically available during authentication. Storing the key in the service key table file ensures that the key is available when required. For more information on extracting a key, see “Extracting Service Keys”.

Reserved Service Principals

The Kerberos server requires that certain service principals be included in the principal database. These principal accounts use reserved names that have a special significance in the Kerberos server database.

Most of these reserved service principals are automatically created when you create the principal database or add a realm to the database.




	IMPORTANT: Do not modify the password policy name of the reserved service principals.

This section contains a detailed description of the reserved service principals.

K/M@REALM:

The K/M@REALM principal contains the secret key of the principal database. When creating the database, the Kerberos server adds the K/M@REALM principal to the default realm of the server to store the database secret key. All records in the principal database are encrypted using this key. The key for this principal is stored on each Kerberos server in the .k5.realm file.




	IMPORTANT: Do not remove, modify, or change the key type for this principal. Do not generate a new key for this principal.

default@REALM:

The default@REALM principal name contains the default group principal attributes for the realm. This principal is required in each realm. This principal, called the default group, is automatically created when a realm is added to the database.

The attributes and properties of this principal act as a template for adding principals to a realm in the principal database of the Kerberos server. This principal uses a random key. However, you must not extract this key to a service key table file. This principal is locked by default, eliminating the security risk of an external attack to authenticate using this principal account.




	IMPORTANT: Do not remove this principal entry or unlock this principal account.

krbtgt/REALM@REALM:

You can use the secret key of the krbtgt/REALM@REALM principal to encrypt and decrypt ticket-granting tickets (TGTs) issued by the Kerberos server for principals in the REALM.




	IMPORTANT: Do not remove or modify this principal entry, except when adding a 3DES key if you need to add support for this encryption type.

To configure interrealm authentication, create distinct reserved principals with the prefix name krbtgt/ for each realm.

If you change any attribute or password of the krbtgt/REALM@REALM principal for the default realm, that is, the realm that contains the K/M@REALM principal, you must close all administrative programs, including kadmin, kadminl_ui, and kdcd. Then, restart all administrative services and daemons in that realm for the changes to take effect.

kadmin/REALM@REALM:

The Kerberos administrative graphical user interface and command-line interface utilities use the kadmin/REALM@REALM principal name. This principal is required in each realm. It automatically adds the principal name when you add a realm to the database.

This principal uses a random key, but you do not need to extract the key to a service key table file.




	IMPORTANT: Do not remove or modify this principal entry.

kadmin/changepw@REALM:

The Kerberos v5 standard set/change password protocol requires the kadmin/changepw@REALM principal. This principal is automatically added to the database when a realm is created.

This principal uses a random key, but you do not need to extract the key to the service key table file.




	IMPORTANT: Do not remove or modify this principal entry.

kcpwd/REALM@REALM:

The kcpwd/REALM@REALM principal name is the change password service for Kerberos. This principal is required in each realm. It is automatically added when you add a realm to the database.

This principal uses a random key. However, you do not need to extract this key to a service key table file.




	IMPORTANT: Do not remove or modify this principal entry.

host/fqdn@REALM:

Kerberos servers and application services such as the following use the host/fqdn@REALM principal name:

Primary and secondary security servers, depending on the requirement of the database propagation.
Secure connection utility daemons and client applications.

You must enter the fqdn in lowercase letters , and the fqdn instance must be the fully qualified domain name of the host system for the server or service.

These principals are not automatically added to the principal database when you install the Kerberos servers or application services.

Removing User Principals

You may need to delete user principals from the database. When you delete a principal account from the database, the principal name, attributes, and properties are removed from the database and you cannot use the principal to authenticate to the Kerberos server. To delete a principal, use the HP Kerberos Administrator or the command-line interface administrative utility.

For user principals, you may need to perform additional steps to remove the special privilege settings.

For user principals that use a UNIX system, every UNIX host that a principal uses contains the host/service principal. If this system is unused, delete the service key from the host and remove the host/<fqdn> principal from the database.

Removing Special Privilege Settings

If the principal has special privileges, remove these privileges. Examples of special privileges are as follows:

Administrative principal that is aware of the UNIX root password. Ensure that you change the root or administrator password according to your password requirements.
Administrative principal using kadmin. Ensure that you remove the administrative principal entry in admin_acl_file.




	NOTE: When you delete an administrative principal using the HP Kerberos Administrator, any reference to that principal is automatically removed from `admin_acl_file`.

Protecting a Secret Key

A user principal must provide its password during authentication to create the secret key of the user principal. For best security, all users must periodically change their passwords.

This version of Kerberos contains the following methods to enforce user principals to change their password:

You can enable the Password Change Required attribute to enforce the users to change their passwords during next logon.
When the password expiration date is exceeded, the user principal must change his or her password. The password policy file or the date set for the principal account using one of the Kerberos server administrative utilities contain the password expiration time.

In all these cases, users can use the UNIX command kpasswd to change their passwords. When users execute the kpasswd command at the HP-UX prompt, they must enter the current password, then enter the new password twice to verify the new password string. The new password of the principal is automatically checked against the password policy file to ensure that it meets the enterprise criteria for secure passwords. Using the password policy file, you can specify rules that require users to create passwords that can prevent easy discovery of the password. For more information on the Password Policy File, see “Password Policy File”.

If you are using a principal account with the required administrative permissions, you can change the password of the user principal without knowing the current password of the principal.

When you change the password of a principal using one of the Kerberos administrative utilities, the password is not verified against the password policy file. Therefore, after you set a password, the user must change the password the next time he or she attempts to authenticate using the account. The Change Password Required attribute is automatically enabled. You must securely communicate the temporary password to the user so that users are aware of their temporary passwords during next logon.

Removing Service Principals

When you delete a service principal account from the database, the service account is no longer available on the network.

Deleting a service principal using one of the Kerberos administrative utilities removes the principal name, attributes, and properties from the database.

For a service principal, you need to perform an additional step of removing its secret key, which is stored in the service key table file on the host of the service. This key is not deleted when the service principal is removed from the database. Therefore, you must manually delete the secret key from the database.

If a host contains only one service, you can delete the service key table file. The default name for the file is v5srvtab.

If multiple services share the same service key table file, remove the service key for the deleted service principal account from the service key table file. For information on deleting keys from the service key table file, see “Deleting Older Keys from the Service Key Table File”.