Principals

A Principal is a string that names a specific entity to which a set of credentials may be assigned. Principals are users and network services that are included in your security network.

The general syntax of a principal is:

identifier/instance@REALM

A principal name consists of three parts,

identifier

is the name of either the network service or a user.

This is a required parameter and has to be specified.

/instance

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

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

In case of a host, the instance, is the fully qualified domain name. Multiple instances of upto 255, are allowed. Each additional instance is preceded by a /.

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

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

This is an optional parameter that need not be specified

Realm

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

This a required parameter and has to be specified.

When creating principal names, note 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, number sign (#), backward slash (\) or colon (:)
NOTE: The forward slash (/) is an allowed character and is used to delineate the instance.

There are two types of principals:

user principals
User principals are accounts assigned to individuals in your organization. There must be at least one account for each individual. You may choose to add multiple accounts for one individual if the accounts are intended to be used for different purposes. Use the instance parameter of the principal name to designate the intended use of the account. There are two special categories of user principals:-
- Administrative principals are user accounts that have administrative permissions assigned to them.
  We recommend, that you use the /admin instance to distinguish these accounts. These principals have the administrative permissions assigned in the admin_acl_file.
service principals
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, or host/ principals that are created for a user's host system.

Adding User Principals

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

When adding a user principal to the database, you must assign the principal identifier, instances (if used) and realm. 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.

The temporary password must be communicated to the user before the user authenticates with the new principal account. The user provides the temporary password and is required to change the password during the first authentication attempt. A secure method must be established for transferring the temporary password information to the user to avoid a security breach.

Adding New Service Principals

The Kerberos Security Server allows you to add service principals to the principal database, as needed. A service principal account is used for a UNIX host system, or a Kerberos-secured service or application that is available in the network to user principals.

Certain service principals are required by the Kerberos Security Server and are automatically added to the principal database, when the Kerberos Server software is installed. Service principal accounts used by optional secured service applications must be added to the principal database manually.

Each Kerberos-secured service or application must have the ability to provide its secret key during authentication. For this reason, service principal accounts must have specific attributes and properties, as required by the application. These attributes and properties include:

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 lower case.
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 Security Server's utilities, daemons and services, the service principals are unable to authenticate, and this service cannot be accessed by other principals when required.
The service principal account must have the Allow as Service attribute set.
The secret key should be extracted to the service key table file on the service's host. Unlike user principals who type their passwords 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 Security 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 Security Server database.

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

K/M@REALM

The K/M@REALM principal contains the secret key of the principal database. When the database is created, this principal is added to the server's default realm to store the database secret key. All records in the principal database are encrypted using this key. The key for this principal is stashed on each security server in a file named .k5.realm.




	WARNING! 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 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 a Security Server's principal database.

This principal uses a random key. However, you should not extract this key to a service key table file. This principal is locked by default, eliminating the security risk of an attacker attempting to authenticate using this principal account.




	WARNING! Do NOT remove this principal entry. Do not unlock this principal account.

krbtgt/REALM@REALM

The krbtgt/REALM@REALM principal's secret key is used to encrypt and decrypt TGTs (ticket-granting tickets) issued by the security server for principals in the realm REALM.




	WARNING! 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 inter-realm authentication, you must create distinct reserved principals with the prefix name krbtgt/ for each realm.

If you change any attribute or the 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/daemons for that realm in order for the changes to take effect.

kadmin/REALM@REALM

The kadmin/REALM@REALM principal name is used by the administration tools: Administrator and the Command-Line-Administrator programs. 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, but you do not need to extract the key to a service key table file.




	WARNING! Do NOT remove or modify this principal entry.

kadmin/changepw@REALM

The kadmin/changepw@REALM principal is required by the Kerberos v5 standard set/change password protocol. 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.




	WARNING! Do NOT remove or modify this principal entry.

kcpwd/REALM@REALM

The kcpwd/REALM@REALM principal name is 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.




	WARNING! Do NOT remove or modify this principal entry.

host/fqdn@REALM

The host/fqdn@REALM principal name is used by various Security Servers and application services, including:

Primary and secondary security servers, as required for database propagation
Secure Connection Utilities daemons and client applications

The fqdn instance must be the fully qualified domain name (FQDN) of the host system for the server or service. The FQDN must be entered as lower-case characters.

These principals are not automatically added to the principal database when the security servers or application services are installed.

Removing User Principals

You may need to delete user principals from the database. When a principal account is deleted from the database, the principal can no longer be used to authenticate to the security server.

To delete a principal, use either the Administrator or Command-Line-Administrator. This removes the principal name, attributes, and properties from the database.

For user principals, there may be additional steps that must be performed to remove the special privilege settings.

For user principals that use UNIX systems, every UNIX host used by a principal 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.

Remove Special Privilege Settings

If the principal had special privileges, you must also remove those rights. Examples of special privileges include:

Administrative principal who are 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 the administrative principal entry in the admin_acl_file is removed.




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

Protecting Secret Keys

User principals must provide their passwords during authentication to create their secret keys. For best security, users should be required to periodically change their passwords.

This version of Kerberos has two methods of enforcing that users change their passwords. A user principal is required to change their passwords when:

A system administrator enables the Password Change Required attribute. In this case, the user principal must change their passwords at the next logon.
The password expiration date is exceeded. The expiration is calculated from the information in the password policy file, or the date set for the principal account using one of the Kerberos Server administrative tools. If the password has expired, the user principal must change its passwords.

In both the situations, users can change their passwords using kpasswd on UNIX. The user must enter the current password, followed by the new password twice to verify the new password string. The principal's new password 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 force users to build the kinds of passwords that can prevent easy discovery or cracking with brute-force methods. For more information on the Password Policy File, refer to “Password Policy File”.

An administrator using a principal account with the required administrative permissions can also change a user principal's password. The administrator is not required to know the current password to change the password.

When a principal's password is changed using one of the Kerberos Server's administrative tools, the password is not verified against the password policy file. For this reason, the password set by an administrator must, by default, be changed the next time the user attempts to authenticate using the account. The Change Password Required attribute is automatically enabled. The user must know the temporary password created by the administrator at the next log on, so you must develop a secure method for communicating the temporary password to the user.

Removing Service Principals

When a service principal account is deleted from the database, the service account is no longer available in the network.

Deleting a service principal using one of the administration tools removes the principal name, attributes, and properties from the database.

For a service principal, there is an additional step that must be performed to remove its secret key stored in the service key table file on the service's host. This key is not deleted when the service principal is removed from the database. It has to be manually deleted from the database.

If there is only one service on the host, 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, you must remove the service key for the deleted service principal account from the service key table file. Refer to “Deleting Older Keys From the Service Key Table File”, for information on deleting keys from the service key table file.