Sun Microsystems, Inc.
spacerspacer
spacer www.sun.com docs.sun.com |
spacer
black dot
 
 
10.  Administering Principals and Policies (Tasks) Administering Policies How to Delete a Policy  Previous   Contents   Next 
   
 

Example--Deleting a Policy (Command Line)

In the following example, the delete_policy command of the kadmin command is used to delete the build11 policy.

kadmin: delete_policy build11 
Are you sure you want to delete the policy "build11"? (yes/no): yes
kadmin: quit

Before you delete a policy, you must cancel the policy from all principals that are currently using it. To do so, you need to use the modify_principal -policy command of kadmin on the affected principals. The delete_policy command fails if the policy is in use by a principal.

SEAM Tool Reference

This section provides reference information for the SEAM Tool.

SEAM Tool Panel Descriptions

This section provides descriptions for each principal and policy attribute that you can either specify or view in the SEAM Tool. The attributes are organized by the panel in which they are displayed.

Table 10-2 Attributes for the Principal Basics Panel

Attribute

Description

Principal Name

The name of the principal (the primary/instance part of a fully-qualified principal name). A principal is a unique identity to which the KDC can assign tickets.

If you are modifying a principal, you cannot edit a principal's name.

Password

The password for the principal. You can use the Generate Random Password button to create a random password for the principal.

Policy

A menu of available policies for the principal.

Account Expires

The date and time on which the principal's account expires. When the account expires, the principal can no longer get a ticket-granting ticket (TGT) and might be unable to log in.

Last Principal Change

The date on which information for the principal was last modified. (Read-only)

Last Changed By

The name of the principal that last modified the account for this principal. (Read-only)

Comments

Comments that are related to the principal (for example, "Temporary Account").

Table 10-3 Attributes for the Principal Details Panel

Attribute

Description

Last Success

The date and time when the principal last logged in successfully. (Read-only)

Last Failure

The date and time when the last login failure for the principal occurred. (Read-only)

Failure Count

The number of times that there has been a login failure for the principal. (Read-only)

Last Password Change

The date and time when the principal's password was last changed. (Read-only)

Password Expires

The date and time when the principal's current password expires.

Key Version

The key version number for the principal. This attribute is normally changed only when a password has been compromised.

Maximum Lifetime (seconds)

The maximum length of time for which a ticket can be granted for the principal (without renewal).

Maximum Renewal (seconds)

The maximum length of time for which an existing ticket can be renewed for the principal.

Table 10-4 Attributes of the Principal Flags Panel

Attribute (Radio Buttons)

Description

Disable Account

When checked, prevents the principal from logging in. This attribute provides an easy way to temporarily freeze a principal account.

Require Password Change

When checked, expires the principal's current password, which forces the user to use the kpasswd command to create a new password. This attribute is useful if there is a security breach, and you need to make sure that old passwords are replaced.

Allow Postdated Tickets

When checked, allows the principal to obtain postdated tickets.

For example, you might need to use postdated tickets for cron jobs that must run after hours, but you cannot obtain tickets in advance because of short ticket lifetimes.

Allow Forwardable Tickets

When checked, allows the principal to obtain forwardable tickets.

Forwardable tickets are tickets that are forwarded to the remote host to provide a single-sign-on session. For example, if you are using forwardable tickets and you authenticate yourself through ftp or rsh, then other services, such as NFS services, are available without your being prompted for another password.

Allow Renewable Tickets

When checked, allows the principal to obtain renewable tickets.

A principal can automatically extend the expiration date or time of a ticket that is renewable (rather than having to get a new ticket after the first ticket expires). Currently, the NFS service is the ticket service that can renew tickets.

Allow Proxiable Tickets

When checked, allows the principal to obtain proxiable tickets.

A proxiable ticket is a ticket that can be used by a service on behalf of a client to perform an operation for the client. With a proxiable ticket, a service can take on the identity of a client and obtain a ticket for another service, but the service cannot obtain a ticket-granting ticket.

Allow Service Tickets

When checked, allows service tickets to be issued for the principal.

You should not allow service tickets to be issued for the kadmin/hostname and changepw/hostname principals. This practice ensures that these principals can only update the KDC database.

Allow TGT-Based Authentication

When checked, allows the service principal to provide services to another principal. More specifically, this attribute allows the KDC to issue a service ticket for the service principal.

This attribute is valid only for service principals. When unchecked, service tickets cannot be issued for the service principal.

Allow Duplicate Authentication

When checked, allows the user principal to obtain service tickets for other user principals.

This attribute is valid only for user principals. When unchecked, the user principal can still obtain service tickets for service principals, but not for other user principals.

Required Preauthentication

When checked, the KDC will not send a requested ticket-granting ticket (TGT) to the principal until the KDC can authenticate (through software) that the principal is really the principal that is requesting the TGT. This preauthentication is usually done through an extra password, for example, from a DES card.

When unchecked, the KDC does not need to preauthenticate the principal before the KDC sends a requested TGT to the principal.

Required Hardware Authentication

When checked, the KDC will not send a requested ticket-granting ticket (TGT) to the principal until the KDC can authenticate (through hardware) that it is really the principal that is requesting the TGT. Hardware preauthentication can occur, for example, on a Java ring reader.

When unchecked, the KDC does not need to preauthenticate the principal before the KDC sends a requested TGT to the principal.

Table 10-5 Attributes for the Policy Basics Pane

Attribute

Description

Policy Name

The name of the policy. A policy is a set of rules that govern a principal's password and tickets.

If you are modifying a policy, you cannot edit a policy's name.

Minimum Password Length

The minimum length for the principal's password.

Minimum Password Classes

The minimum number of different character types that are required in the principal's password.

For example, a minimum classes value of 2 means that the password must have at least two different character types, such as letters and numbers (hi2mom). A value of 3 means that the password must have at least three different character types, such as letters, numbers, and punctuation (hi2mom!). And so on.

A value of 1 sets no restriction on the number of password character types.

Saved Password History

The number of previous passwords that have been used by the principal, and a list of the previous passwords that cannot be reused.

Minimum Password Lifetime (seconds)

The minimum time that the password must be used before it can be changed.

Maximum Password Lifetime (seconds)

The maximum time that the password can be used before it must be changed.

Principals Using This Policy

The number of principals to which this policy currently applies. (Read-only)

Using the SEAM Tool With Limited Kerberos Administration Privileges

All features of the SEAM Administration Tool are available if your admin principal has all the privileges to administer the Kerberos database. But it is possible to have limited privileges, such as being allowed to view only the list of principals or to change a principal's password. With limited Kerberos administration privileges, you can still use the SEAM Tool. However, various parts of the SEAM Tool will change based on the Kerberos administration privileges that you do not have. Table 10-6 shows how the SEAM Tool changes based on your Kerberos administration privileges.

The most visual change to the SEAM Tool occurs when you don't have the list privilege. Without the list privilege, the List panels do not display the list of principals and polices for you to manipulate. Instead, you must use the Name field in the List panels to specify a principal or policy that you want to manipulate.

If you login to the SEAM Tool, and you do not have sufficient privileges to perform tasks with it, the following message displays and you are sent back to the SEAM Administration Login window:

Insufficient privileges to use gkadmin: ADMCIL. Please try using another principal.

To change the privileges for a principal to administer the Kerberos database, go to "How to Modify the Kerberos Administration Privileges".

Table 10-6 Using SEAM Tool With Limited Kerberos Administration Privileges

Disallowed Privilege

Change the SEAM Tool

a (add)

The Create New and Duplicate buttons are unavailable in the Principal List and Policy List panels. Without the add privilege, you cannot create new principals or policies or duplicate them.

d (delete)

The Delete button is unavailable in the Principal List and Policy List panels. Without the delete privilege, you cannot delete principal or policies.

m (modify)

The Modify button is unavailable in the Principal List and Policy List panels. Without the modify privilege, you cannot modify principal or policies.

Also, with the Modify button unavailable, you cannot modify a principal's password, even if you have the change password privilege.

c (change password)

The Password field in the Principal Basics panel is read-only and cannot be changed. Without the change password privilege, you cannot modify a principal's password.

Note that even if you have the change password privilege, you must also have the modify privilege to change a principal's password.

i (inquiry to database)

The Modify and Duplicate buttons are unavailable in the Principal List and Policy List panels. Without the inquiry privilege, you cannot modify or duplicate a principal or policy.

Also, with the Modify button unavailable, you cannot modify a principal's password, even if you have the change password privilege.

l (list)

The list of principals and policies in the List panels are unavailable. Without the list privilege, you must use the Name field in the List panels to specify the principal or policy that you want to manipulate.

Administering Keytab Files

Every host that provides a service must have a local file, called a keytab (short for key table). The keytab contains the principal for the appropriate service, called a service key. A service key is used by a service to authenticate itself to the KDC and is known only by Kerberos and the service itself. For example, if you have a Kerberized NFS server, that server must have a keytab file that contains its nfs service principal.

To add a service key to a keytab file, you add the appropriate service principal to a host's keytab file by using the ktadd command of kadmin. Because you are adding a service principal to a keytab file, the principal must already exist in the Kerberos database so that kadmin can verify its existence. On the master KDC, the keytab file is located at /etc/krb5/kadm5.keytab, by default. On application servers that provide Kerberized services, the keytab file is located at /etc/krb5/krb5.keytab, by default.

A keytab is analogous to a user's password. Just as it is important for users to protect their passwords, it is equally important for application servers to protect their keytab files. You should always store keytab files on a local disk, and make them readable only by the root user. Also, you should never send a keytab file over an unsecured network.

There is also a special instance to add a root principal to a host's keytab file. If you want a user on the SEAM client to mount Kerberized NFS file systems that use Kerberos authentication automatically, you must add the client's root principal to the client's keytab file. Otherwise, users must use the kinit command as root to obtain credentials for the client's root principal whenever they want to mount a Kerberized NFS file system, even when they are using the automounter. See "Setting Up Root Authentication to Mount NFS File Systems" for detailed information.


Note - When you set up a master KDC, you need to add the kadmind and changepw principals to the kadm5.keytab file. This step enables the KDC to decrypt administrators' Kerberos tickets to determine whether it should give the administrators access to the database.


Another command that you can use to administer keytab files is the ktutil command. ktutil is an interactive command that enables you to manage a local host's keytab file without having Kerberos administration privileges, because ktutil doesn't interact with the Kerberos database as kadmin does. So, after a principal is added to a keytab file, you can use ktutil to view the keylist in a keytab file or to temporarily disable authentication for a service.

Administering Keytabs Task Map

Task

Description

For Instructions

Add a service principal to a keytab file

Use the ktadd command of kadmin to add a service principal to a keytab file.

"How to Add a Service Principal to a Keytab File"

Remove a service principal from a keytab file

Use the ktremove command of kadmin to remove a service from a keytab file.

"How to Remove a Service Principal From a Keytab File"

Display the keylist (Principals) in a keytab file

Use the ktutil command to display the keylist in a keytab file.

"How to Display the Keylist (Principals) in a Keytab File"

Temporarily disable authentication for a service on a host

This procedure is a quick way to temporarily disable authentication for a service on a host without having to have kadmin privileges.

Before you use ktutil to delete the service principal from the server's keytab file, copy the original keytab file to a temporary location. When you want to enable the service again, copy the original keytab file back to its proper location.

"How to Temporarily Disable Authentication for a Service on a Host"

How to Add a Service Principal to a Keytab File

  1. Make sure that the principal already exists in the Kerberos database.

    See "How to View the List of Principals" for more information.

  2. Become superuser on the host that needs a principal added to its keytab file.

  3. Start the kadmin command.

    # /usr/sbin/kadmin
  4. Add a principal to a keytab file by using the ktadd command.

    kadmin: ktadd [-k keytab] [-q] [principal | -glob principal-exp]

    -k keytab

    Specifies the keytab file. By default, /etc/krb5/krb5.keytab is used.

    -q

    Displays less verbose information.

    principal

    Specifies the principal to be added to the keytab file. You can add the following service principals: host, root, nfs, and ftp.

    -glob principal-exp

    Specifies the principal expressions. All principals that match the principal.are added to the keytab file. The rules for principal expression are the same as for the list_principals command of kadmin.

  5. Quit the kadmin command.

    kadmin: quit
 
 
 
  Previous   Contents   Next