Manual Administration Using kadmin

You can use the command-line administrator to administer the principal database. It enables principals with administrative privileges to maintain the principal database. You must include all the users, clients, and services authenticated by the Kerberos server into the principal database.The following types of command-line interfaces are available:

Local command-line administrator, kadminl
Remote command-line administrator, kadmin

The local command-line administrator, kadminl, is available only on the primary security server. You can install the remote command-line administrator, kadmin, on the secondary security servers and clients to remotely administer the principal database.

The local administrator, kadminl, is situated in the following directory on the primary security server:

/opt/krb5/admin

The remote administrator, kadmin, is situated in the following directory on secondary security servers and clients:

/opt/krb5/bin




	NOTE: You must add the first administrative principal on the local administrator, `kadminl`, located on the primary security server before you log on to the remote command-line administrator, `kadmin`, from a secondary security server or client.

You can use kadmin to perform the following tasks:

Add, modify, inquire, or delete principals.
Change the password of an existing principal.
Extract a key for an existing prinicpal.
Extract service principal information to the service key table.

Only a user with root permission can invoke the local command-line administrator, kadminl.

To log on to the remote administrator, kadmin, use a principal account that has an entry in admin_acl_file and an account that has at least inquire privileges. For complete access to all functions, use an unrestricted administrative principal account, one with the * permissions in admin_acl_file. The account must at least have inquire privileges. For more information on administrative permissions, see “The admin_acl_file File”.

When you start kadmin, you must specify a principal name at the command prompt; otherwise, the default logon name with the admin instance appended to the default logon name is used. If you specify the -n switch, the default logon name is used and the admin instance is not automatically appended to the logon name.

The kadmin command-line administrator uses the following methods to authenticate the administrator:

The first method prompts administrators for a password.
The second method uses the -k switch, which notifies kadmin to search the v5srvtab file for the key. With the -k switch, you can write shell scripts to automate administrative tasks. Read the permissions in the v5srvtab file to use this switch.

The communication between the kadmin client and the server daemon are encrypted to prevent disclosure of information across the network.

After you are authenticated, use the kadmin commands to manage the principal database. The kadmin commands are discussed in the subsequent sections of this chapter.




	NOTE: You cannot use `kadmin` to control the following parameters of the user principals: Administrative permissions Default group prinicpal Maximum ticket lifetime and renew times Addition of new realms Alter key types HP recommends that you use the graphical user interface administrative utility, `kadminl_ui`, to administer these parameters.

Adding a New Principal

You must specify the add administrative privilege in admin_acl_file to add a principal to the database.

To add a new principal, type kadmin add at the HP-UX prompt. This command adds a new principal with the specified name and password to the principal database. When you add a principal by using the add command, the principal inherits the default group principal settings for the key type and salt types.

The general syntax for adding a new principal is as follows:

command: add




	NOTE: You must specify values for all the mandatory LDAP attributes while creating a Kerberos principal. These attributes need to be specified only if the LDAP DN does not exist in the Directory server. You are prompted for mandatory attributes based on the default object class template that you specified while configuring your Kerberos server with LDAP as the backend. You are not prompted for LDAP attributes if the default object class template consists of only one mandatory attribute.

When creating principal names, ensure that a principal name meets the following conditions:

Is case-sensitive.
Is shorter than 767 characters.
Is uniquely defined in the first 255 characters.
Do not contain a space, tab, # (pound sign), \ (backslash) 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 to the principal.

For example, to add a new principal admin, type kadmin at the HP-UX prompt, and specify the add command, the principal name, and the policy name. Following is a sample output of the add command:

command:  add
Name of Principal to add: admin
Enter password: <password>
Re-enter password for verification: <password>
Enter policy name (Press enter key to apply default policy):
Enter LDAP DN name (Press enter key to apply default policy):
 
Principal added

Adding a Random Key

Service principals use the addrnd command to add the specified principal with a randomly generated password.

The general syntax for adding a principal with a randomly generated password is as follows:

command: addrnd

For example, to add a principal admin with a randomly generated password, type kadmin at the HP-UX prompt, and specify the addrnd command, the principal name, and the policy name. Following is a sample output of the addrnd command:

command:  addrnd
Name of Principal to add: admin
Enter policy name (Press enter key to apply default policy):
Enter LDAP DN name (Press enter key to apply default policy):
Principal added

Specifying a New Password

The cpw command enables you to specify a new password for the principal.

The general syntax for specifying a new password is as follows:

command: cpw

For example, to enable a new password for the principal admin, type kadmin at the HP-UX prompt, and specify the cpw command and the principal name. Following is a sample output of the cpw command:

command: cpw
Name of Principal: admin
Enter password: password
Re-enter password for verification: password
Principal modified

Changing Password to a New Randomly Generated Password

The cpwrnd command changes the password of a principal to a new randomly generated password.

The general syntax for the cpwrnd command is as follows:

command: cpwrnd

For example, to change the password of the principal admin to a new randomly generated password, type kadmin at the HP-UX prompt, and specify the cpwrnd command and the principal name. Following is a sample output of the cpwrnd command:

command: cpwrnd Name of Principal: admin Principal modified

Deleting a Principal

To delete a principal, you must specify the delete administrative privilege in admin_acl_file.

The general syntax for deleting a principal is as follows:

command: del

For example, to delete the principal admin, type kadmin at the HP-UX prompt, and specify the del command and the principal name. Following is a sample output for the del command:

command: del Name of Principal to delete: admin Principal removed

The message Principal removed indicates that the principal is deleted.

Extracting a Principal

The ext command securely extracts the key of the principal into a local service key table file. By default, the host/fqdn@REALM principal is extracted into the v5srvtab file, where fqdn is the fully qualified domain name of the host system.

If the principal does not exist in the principal database, it is added with the name that you have specified. If the service key table file does not exist, it is created with the name that you have specified.

If the principal exists, kadmin resets the key version to 1 by overwriting the previous key and extracting the key that is created using a new password and no salt key. To extract the key without any modifications, use the -n option.

The general syntax for extracting a principal and a key to a local service key table file is as follows:

command: ext

For example, to extract the principal admin to a local service key table file, SrvTab, type kadmin at the HP-UX prompt and specify the ext command, the principal name, and the service key table file name. Following is a sample output for the ext command:

command: ext Name of Principal (host/fqdn@REALM): admin Service Key Table File Name (/opt/krb5/v5srvtab):/opt/SrvTab Principal modified Key extracted

The optional parameters are as follows:

[-n]

Extracts the key for an existing principal without changing the key or the salt type.

[-p keytype]

Defines the key type for the primary key, and extracts it to the service key table file. Supported values for keytype are 1 for DES-CRC, 3 for DES-MD5, and 5 for 3DES.

[-a keytype]

Defines the key type for the secondary key, and extracts it to the service key table file.

Supported values for key type are 0 for no secondary key, 1 for DES-CRC, 3 for DES-MD5, and 5 for 3DES.

[principal]

Specifies an alternate principal to extract other than the default host/fqdn@REALM principal, for example, ext finance@BAMBI.COM

After ext executes, it prompts you for the service key table file name. The default file name is /krb5/v5srvtab.

Listing the Attributes of a Principal

The inq command lists the attributes of the principal, if it exists. The kadmin utility displays the following message if the principal does not exist in the database:

Principal does not exist

The general syntax for listing the attributes of the principal is as follows:

command: inq

For example, to list the attributes of the principal admin, type kadmin at the HP-UX prompt, and specify the inq command and the name of the principal. Following is a sample output for the inq command:

command: inq Name of Principal: admin

Modifying a Principal

To modify attributes of a principal in the database, use the kadmin mod command. In addition to the name of the principal, you must also specify the type of parameter.

You can modify the following parameters:

attr: Specifies properties associated with the principal.
fcnt: Specifies the number of failed authentication attempts allowed for a principal. The number must be an integer between 0 and 255.
vno: Specifies the key version number. The number must be an integer between 0 and 255. When you create a principal, its key version number (vno) is 1 and the version number automatically increments by one each time the key is changed.
policy: Specifies the new policy name. If you do not specify a policy name, the default policy is applied.
dn: Specifies the LDAP DN name. If you do not specify an LDAP DN name, the default policy is applied.

The general syntax for modifying an existing principal is as follows:

command: mod

For example, to modify the principal admin, type kadmin at the HP-UX prompt and specify the mod command, the principal name, and the type of parameter. Following is a sample output for the mod command:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno, policy,dn or quit):<parameter_type>
Principal modified.

Enter the <parameter_type> to be modified at the command prompt. The principal is modified depending on the parameter that you have specified. The subsequent sections of this chapter contain a detailed description of the parameter types.

Number of Authentication Failures (`fcnt`)

When you create a principal, the failed authentication count is automatically set to zero. The user associated with that principal increments the failed authentication count by 1 for each failed authentication attempt.

If the user has more consecutive authentication failures than allowed by the MaxFailAuthCnt parameter in the password policy file, the principal is locked. Before the user can attempt to authenticate again, the administrator must unlock the principal, which resets the fcnt to zero.

If the user successfully authenticates before the maximum failed authentication count value, fcnt is automatically reset to zero.

For example, to modify the fcnt parameter for the principal admin, type kadmin at the HP-UX prompt and specify the mod command, the principal name, and the fcnt parameter.

Following is a sample output for the mod command with the fcnt parameter:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno,policy,dn or quit):fcnt
Failure Count (or quit): <enter count>
Principal modified.

Key Version Number Attribute

Every principal password has an associated version number that identifies the frequency of password changes.

When you create a principal, its password version number is inherited from the default group template. Every time you change a password, the version number is incremented by 1. However, the key version number is a writable field in the database, and you cannot consider the key version number as an accurate counter.

If you change the password for the default group principal, the key version number increments, and every new principal added to the database does not begin with 1. Because this may be confusing, HP recommends that you edit the version number for the default group principal to be 1 after you regenerate a key for the default principal.

For example, to modify the vno parameter for the principal admin, type kadmin at the HP-UX prompt and specify the mod command, the principal name, and the vno parameter.

Following is a sample output for the mod command with the vno parameter:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno,policy,dn or quit): vno
Remote Administrator version Number (or quit): <enter count>
Principal modified.

LDAP DN

This option specifies the LDAP DN name. The LDAP DN specifies the location of where all information for the client is found in the DIT. If you choose to use the default, press the return key.

For example, to modify the dn parameter for the principal admin, type kadmin at the HP-UX prompt and specify the mod command, the principal name, and the dn parameter.

Following is a sample output for the mod command with the dn parameter:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno, policy,dn or quit) :dn
Enter LDAP DN name or quit: <enter LDAP DN name>
Principal modified.

Policy Name

This option specifies the policy name subscribed by the principal. When the principal attempts to change its password, the rules of this policy are applied to the principal.

For example, to modify the policy parameter for the principal admin, type kadmin at the HP-UX prompt and specify the mod command, the principal name, and the policy parameter.

Following is a sample output for the mod command with the policy parameter:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno, policy,dn or quit) :policy
Enter policy name or quit: <enter policy name>
Principal modified.

Attributes

Attributes indicate the properties associated with a principal. To view a list of attributes, type kadmin at the HP-UX prompt and specify the attr command. Following is a sample output of the attr command:

Command: attr
Attribute (or quit): ?

The subsequent sections discuss the attributes associated with a principal.

Allow Postdated Attribute

The Allow Postdated attribute determines whether a principal is allowed ticket postdating. Postdating is a mechanism that allows a principal to obtain a ticket that is initially invalid, but that becomes valid in the future.

The Allow Postdated attribute applies to both user and service principals specified as follows:

You can issue either a postdated or postdatable ticket for user principals.
The server can issue postdated service tickets for the service.




	NOTE: Before the server issues a postdated service ticket, the requesting user must possess a postdatable TGT.

To modify the type of the parameter attr for the principal admin and to set the Allow Postdated attribute, type kadmin at the HP-UX prompt and specify the mod command, the principal name, the attr parameter type, and the attribute.

Following is a sample output of the Allow Postdated attribute:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno,dn or quit) :attr
Attribute (or quit): {postdate|nopostdate}
Principal modified.

Allow Renewable Attribute

The Allow Renewable attribute determines whether a principal is allowed to request renewable tickets. Renewable tickets are those that can be revalidated up to the maximum renewal time.

The principal database krbtgt/REALM@REALM principal contains the maximum ticket lifetime and the renewable time. You can use the Maximum Renew Time Setting in the General tab of the Principal Information window to limit individual principal accounts.

The Allow Renewable attribute applies to both user and service principals. If this attribute is set to a user principal, the principal can be issued a renewable ticket. If this attribute is set to a service principal, the server can issue a renewable ticket for the service.




	NOTE: Before the server issues a renewable service ticket, the requesting user must possess a renewable TGT.

To modify the type of the parameter attr for the principal admin and to set the Allow Renewable attribute, type kadmin at the HP-UX prompt and specify the mod command, the principal name, the attr parameter type, and the attribute.

Following is a sample output of the Allow Renewable attribute:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno, policy,dn or quit) :attr
Attribute (or quit): {renew|norenew}
Principal modified.

Allow Forwardable Attribute

The Allow Forwardable attribute determines whether a principal is allowed ticket forwarding. Forwarding is a mechanism to send a TGT to a remote system, from one network host to another. On behalf of the principal, you can use the forwarded TGT to generate a new service ticket on the second host system. This eliminates the need for the user to reauthenticate and re-enter the password on the second host.

The Allow Forwardable attribute applies to both user and service principals. If this attribute is set for a user principal, you can issue a forwarded or forwardable ticket to the principal. If this attribute is set for a service principal, the server can issue a forwarded service ticket for the service.




	NOTE: Before the server issues a service ticket on the remote host, the requesting user must possess a forwarded TGT.

To modify the type of the parameter attr for the principal admin and to set the Allow Forwardable attribute, type kadmin at the HP-UX prompt and specify the mod command, the principal name, the attr parameter type, and the attribute.

Following is a sample output of the Allow Forwardable attribute:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno, policy,dn or quit) :attr
Attribute (or quit): {forward|noforward}
Principal modified.

Allow Proxy Attribute

The Allow Proxy attribute determines whether a principal is allowed proxy tickets. Proxy tickets allow applications that a principal accesses with a TGT to request a special class of service ticket. You can move this type of service to another host on the network that acts on behalf of the principal, for example, a print service printing a file for a user.




	NOTE: You can use the authorization fields of the ticket and authenticator to hold restrictions on the proxy ticket.

The Allow Proxy attribute applies to both user and service principals. If this attribute is set for a user principal, you can issue a proxy ticket to the principal. If this attribute is set for service principal, the server can issue a proxy service ticket for the service.




	NOTE: Before the server issues a proxy service ticket, the requesting user must possess a proxy TGT.

To modify the type of parameter attr for the principal admin and to set the Allow Proxy attribute, type kadmin at the HP-UX prompt and specify the mod command, the principal name, the attr parameter type, and the attribute.

Following is a sample output of the Allow Proxy attribute:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno, policy,dn or quit) :attr
Attribute (or quit): {proxy|noproxy}
Principal modified.

Allow Duplicate Session Key Attribute

The Allow Duplicate Session Key attribute determines whether a principal is allowed to use a duplicate session key. A duplicate session key applies to user-to-user authentication and determines which key is used to encrypt the requested service tickets.

This setting controls the security protocol between a client application, initiator, and a service called the acceptor. The following processes occur when an initiator application requests for a duplicate session key:

The initiator application sends the TGT of the initiator and the acceptor as a request to the ticket-granting service (TGS). The Allow Duplicate Session Key attribute is set. The service ticket returned to the initiator is encrypted with the session key in the TGT of the acceptor.
The service ticket returned to the initiator application is encrypted with the secret key of the acceptor when the Allow Duplicate Session Key attribute is not set.

This attribute is set by default, thereby allowing an initiator application to request a duplicate session key for the application of the acceptor. You must assign the Allow as Service attribute to principal accounts that use duplicate session keys.

To modify the type of parameter attr for the principal admin and to set the Allow Duplicate Session Key attribute, type kadmin at the HP-UX prompt and specify the mod command, the principal name, the attr parameter type, and the attribute.

Following is a sample output of the Allow Duplicate Session Key attribute:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno, policy,dn or quit) :attr
Attribute (or quit): {dskey|nodskey}
Principal modified.

Require Preauthentication Attribute

The Require Preauthentication attribute determines whether a principal is required to preauthenticate when requesting a TGT. Preauthentication implies that the client logon program attaches known encrypted data to a ticket request, providing additional security when the TGT is presented to access a secured service.

The Require Preauthentication attribute applies to user and service principals. If this attribute is set for a user principal, the user must run the logon software that performs authentication using the preauthentication protocol. If this attribute is set for a service principal, the service accepts TGTs only from user principals that obtained a TGT using a preauthentication protocol.




	NOTE: Client applications require preauthentication by default; however, a client can override this setting.

To modify the type of parameter attr for the principal admin and to set the Require Preauthentication attribute, type kadmin at the HP-UX prompt and specify the mod command, the principal name, the attr parameter type, and the attribute.

Following is a sample output of the Require Preauthentication attribute:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno, policy,dn or quit) :attr
Attribute (or quit): {preauth|nopreauth}
Principal modified.

Require Password Change Attribute

The Require Password Change attribute determines whether a principal must change the password of the user during the next authentication attempt. You must change the password when this attribute is set for a principal.

When a new principal is added to the database or when a password of the principal is changed, this attribute is controlled by the NoReqChangePwd setting in the password policy file of the principle. By default, NoReqChangePwd is set to 0 (zero), that is, the user must change the password at first logon.

If you designate a random key for a principal using the HP Kerberos Administrator window or the kadmin addrnd command, the Require Change Password attribute is not set by default. As a result, a service principal with an extracted key need not contain a new key extracted during the next authentication attempt.

To modify the type of parameter attr for the principal admin and to set the Require Password Change attribute, type kadmin at the HP-UX prompt and specify the mod command, the principal name, the attr parameter type, and the attribute.

Following is a sample output of the Require Password Change attribute:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno, policy,dn or quit) :attr
Attribute (or quit): {pwchg|nopwchg}
Principal modified.

Lock Principal Attribute

The Lock Principal attribute determines whether a principal account is usable or not. A locked principal exists in the principal database but is unable to use or provide security network services.

The Lock Principal attribute applies to both user and service principals. If you set this attribute for a user principal, no tickets can be issued to the user. If you set this attribute for a service principal, no tickets are issued for principals to use the service.

This attribute is set automatically when a principal exceeds the maximum number of failed authentication attempts specified in the password policy file. The default maximum number of failed authentication attempts allowed is 5. If a principal account is locked, a principal with the required administrative permissions must unlock the principal account before the user can authenticate again.

To modify the type of the parameter attr for the principal admin and to set the Lock Principal attribute, type kadmin at the HP-UX prompt and specify the mod command, the principal name, the attr parameter type, and the attribute.

Following is a sample output of the Lock Principal attribute:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno, policy,dn or quit) :attr
Attribute (or quit): {lock|nolock}
Principal modified.

Allow As Service Attribute

You must select the Allow As Service attribute for any principal that is used as a service.

This attribute applies to both the user principal and the service principal. Selecting this attribute does not necessarily mean that the principal account is being used by a network service application. Select this attribute for user principals that run programs requiring user-to-user authentication.

When you set the Allow As Service attribute, the name of the principal name appears in the server field of the service ticket. If you do not set this attribute, the Kerberos server cannot issue a service ticket for that principal because the name of the principal cannot appear in the server field of the service ticket.

This attribute is set by default, allowing principals to act as a service and enabling user-to-user authentication for user principals.

To modify the type of the parameter attr for the principal admin and to set the Allow As Service attribute, type kadmin at the HP-UX prompt and specify the mod command, the principal name, the attr parameter type, and the attribute.

Following is a sample output of the Allow As Service attribute:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno, policy,dn or quit) :attr
Attribute (or quit): {svr|nosvr}
Principal modified.

Require Initial Authentication Attribute

The Require Initial Authentication attribute specifies if the server is allowed to issue service tickets to a service principal on behalf of a user principal using an existing TGT.

The Require Initial Authentication attribute applies only to service principals. If you set this attribute, user principals must reauthenticate to the Kerberos server before the server issues a service ticket for that service. For example, the change password service requires a principal to enter a password to receive a ticket for the change password service before changing the password. If you set this attribute, the server may issue a service ticket based on the existing TGT of the user principal.




	NOTE: In Principal Information>Edit>Edit Administrative Permissions, if you select the `Require Initial Authentication` attribute, the `Allow as Service Attribute` is automatically selected.

Do not enable this setting for user principal accounts. This attribute is applicable to selected service principals.

To modify the type of parameter attr for the principal admin and to set the Require Initial Authentication attribute, type kadmin at the HP-UX prompt and specify the mod command, the principal name, the attr parameter type, and the attribute.

Following is a sample output of the Require Initial Authentication attribute:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno, policy,dn or quit) :attr
Attribute (or quit): {tgt|notgt}
Principal modified.

The notgt command in kadmin is equivalent to selecting the Require Initial Authentication in the tgt command in kadmin is equivalent to clearing the Require Initial Authentication checkbox on the Principal Information window>Attributes tab.

You can use the kadmin inq command to view the attribute of the principal. With Require Initial Authentication selected (tgt), the inquire command shows TGT_BASED in the attributes field. Without the Require Initial Authentication setting (notgt), the text does not appear in the attributes field.

Table 8-18 “Require Initial Authentication Attribute Settings” displays the output of the HP Kerberos Administrator>Attributes tab setting that is equivalent to the kadmin command. It also indicates the attribute text that displays when you view the setting of the principal using the kadmin inq command.

Table 8-18 Require Initial Authentication Attribute Settings

Attributes Tab Check-Box Setting	HP Kerberos Administrator	kadmin inq Shows:
Select Require Initial Authentication	`notgt`	No text shows
Select Require Initial Authentication	`tgt`	`TGT_BASED`

Set As Password Change Service Attribute

The Set As Password Change Service attribute determines if a service principal can act as a change password service. If you set this attribute, a service principal receives initial tickets for user principals whose passwords have expired.




	NOTE: When you select the `Set As Password Change Service` attribute, the `Require Initial Authentication` attribute is automatically selected.

Normally, you select the Set As Password Change Service attribute only for the service principal defined as a change password service. You can add other change password service principals to the principal database if you have created custom applications that require different password service principals.

To modify the type of parameter attr for the principal admin and to set the Password Change Service attribute, type kadmin at the HP-UX prompt and specify the mod command, the principal name, the attr parameter type, and the attribute.

Following is a sample output of the Password Change Service attribute:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr, fcnt, vno, policy,dn or qui) :attr
Attribute (or quit): {cpwsrv|nocpwsrv}
Principal modified.

Password Expiration Attribute

A principal password may have a finite or an infinite lifetime. Following are the factors that control the expiration time of a password, including the principal type:

Service Principals - The secret key stored in the service key table file on the host of the service does not expire. However, HP recommends that you extract new random keys periodically for best security practices. See “Maintaining Secret Keys in the Key Table File”, for more information.

User principals - The expiration time for the password of a user depends on the settings designated for the principal account.

Activating the Password Expiration attribute holds a principal in accordance with the password expiration policy. You are prompted to change the password before the expiration date. If you do not enable the Password Expiration attribute, the password of the current principals never expires.




	NOTE: The password expiration date is stored on the Kerberos server with each principal. When you change the password, the current date and the expiration value also change in the password policy file.

Before the password expires, you are notified that the password is about to expire. The NotifyTime parameter controls the advance notice timing in the password policy file. If you ignore the advance notice and the expiration date elapses, you must change the password before you can obtain any more tickets from the Kerberos server.

Because the expiration time is calculated from the time you add a new principal to the database, the password change load on the server is distributed over time. Therefore, you can select a password expiration in the default group principal template without affecting the administrative load, provided you add new principals over a period of time.

To modify the parameter type attr of the principal admin to set the Password Expiration attribute, you need to execute the following:

Command: mod
Name of Principal to Modify: admin
Parameter Type to be Modified (attr,fcnt,vno, policy,dn or quit) :attr
Attribute (or quit): {cpwexp|nocpwexp}
Principal modified.

Principal Expiration Attribute

The Principal Expiration attribute determines the expiration time of a principal account. You can set the expiration time to a definite time or to never. An expired principal account is essentially locked; it can no longer be used to access the security network. However, this account can be re-enabled by resetting the expiration time, because the principal still exists in the principal database.

Setting a principal expiration time may be useful for granting access to temporary employees. However, if you specify an expiration date for the default group principal, all principals added using that template setting will expire at the same time. You must consider the administrative requirements of expiring all principal accounts on the same day.