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. | |
Remove a service principal from a keytab file | Use the ktremove command of kadmin to remove a service from a keytab file. | |
Display the keylist (Principals) in a keytab file | Use the ktutil command to display the keylist 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
Make sure that the principal already exists in the Kerberos database.
See "How to View the List of Principals" for more information.
Become superuser on the host that needs a principal added to its keytab file.
Start the kadmin command.
# /usr/sbin/kadmin
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.
Quit the kadmin command.
kadmin: quit