Chapter 23 SEAM Reference

This chapter includes information on getting, viewing and destroying tickets and choosing or changing a Kerberos password on a system running SEAM. In addition, this chapter lists many of the SEAM product files. Also, a more detailed description of how the Kerberos authentication system works is provided.

• "Ticket Management"

• "Password Management"

• "SEAM Files"

• "SEAM Daemons"

• "Ticket Reference"

• "How the Authentication System Works"

• "Gaining Access to a Service Using SEAM"

• "Using the gsscred Table"

Ticket Management

This section explains how to obtain, view, and destroy tickets. For an introduction to tickets, see "How SEAM Works".

Do You Need to Worry About Tickets?

PAM can be set up to automatically get tickets when you log in. It is possible that your SEAM configuration does not include this automatic forwarding of tickets, but it is the default behavior.

Most of the Kerberized commands also automatically destroy your tickets when they exit. However, you might want to explicitly destroy your Kerberos tickets with kdestroy when you are through with them, just to be sure. See "How to Destroy Tickets" for more information on kdestroy.

For information on ticket lifetimes, see "Ticket Lifetimes".

How to Create a Ticket

Normally a ticket is created automatically when you log in and you need not do anything special to obtain one. However, you might need to create a ticket in the following cases:

• Your ticket expires.

• You need to use a different principal besides your default principal. (For example, if you use rlogin -l to log in to a machine as someone else.)

To create a ticket, use the kinit command.

% /usr/bin/kinit 

kinit prompts you for your password. For the full syntax of the kinit command, see the kinit(1) man page.

Example--Creating a Ticket

This example shows a user, jennifer, creating a ticket on her own system.

% kinit
Password for jennifer@ENG.ACME.COM:  <enter password>

Here the user david creates a ticket good for three hours with the -l option.

% kinit -l 3h david@ACME.ORG
Password for david@ACME.ORG:  <enter password>

This example shows david creating a forwardable ticket (with -f) for himself. With this forwardable ticket, he can (for example) log in to a second system, and then telnet to a third system.

% kinit -f david@ACME.ORG
Password for david@ACME.ORG:     <enter password>

For more on how forwarding tickets works, see "Types of Tickets".

How to View Tickets

Not all tickets are alike. One ticket might be, for example, forwardable; another might be postdated; while a third might be both. You can see which tickets you have, and what their attributes are, by using the klist command with the -f option:

% /usr/bin/klist -f

The following symbols indicate the attributes associated with each ticket, as displayed by klist:

"Types of Tickets" describes the various attributes a ticket can have.

Example--Viewing Tickets

This example shows that the user jennifer has an initial ticket, which is forwardable (F) and postdated (d), but not yet validated (i).

% /usr/bin/klist -f
Ticket cache: /tmp/krb5cc_74287
Default principal: jenniferm@ENG.ACME.COM
 
Valid starting                 Expires                 Service principal
09 Mar 99 15:09:51  09 Mar 99 21:09:51  nfs/ACME.SUN.COM@ACME.SUN.COM
        renew until 10 Mar 99 15:12:51, Flags: Fdi

The example below shows that the user david has two tickets that were forwarded (f) to his host from another host. The tickets are also (re)forwardable (F):

% klist -f
Ticket cache: /tmp/krb5cc_74287
Default principal: david@ACME.SUN.COM
 
Valid starting                 Expires                 Service principal
07 Mar 99 06:09:51  09 Mar 99 23:33:51  host/ACME.COM@ACME.COM
        renew until 10 Mar 99 17:09:51, Flags: fF
 
Valid starting                 Expires                 Service principal
08 Mar 99 08:09:51  09 Mar 99 12:54:51  nfs/ACME.COM@ACME.COM
        renew until 10 Mar 99 15:22:51, Flags: fF

How to Destroy Tickets

Tickets are generally destroyed automatically when the commands that created them exit; however, you might want to explicitly destroy your Kerberos tickets when you are through with them, just to be sure. Tickets can be stolen, and if this happens, the person who has them can use them until they expire (although stolen tickets must be decrypted).

To destroy your tickets, use the kdestroy command.

% /usr/bin/kdestroy

kdestroy destroys all your tickets. You cannot use it to selectively destroy a particular ticket.

If you are going to be away from your system and are concerned about an intruder using your permissions, you should either use kdestroy or a screensaver that locks the screen.

One way to help ensure that tickets are always destroyed is to add the kdestroy command to the .logout file in your home directory.

In cases where the PAM module has been configured, tickets are destroyed automatically upon logout, so adding a call to kdestroy to your .login file is not necessary. However, if the PAM module has not been configured, or if you don't know whether it has or not, you might want to add kdestroy to your .login file to be sure that tickets are destroyed when you exit your system.

Password Management

With SEAM installed, you now have two passwords: your regular Solaris password, and a Kerberos password. You can make both passwords the same or they can be different.

Non-Kerberized commands, such as login, can be set up through PAM to authenticate with both Kerberos and UNIX. If you have different passwords, you must provide both passwords to log on with the appropriate authentication. However, if both passwords are the same, the first password you enter for UNIX is also accepted by Kerberos.

Unfortunately, using the same password for both can compromise security. That is, if someone discovers your Kerberos password, then your UNIX password is no longer a secret. However, using the same passwords for UNIX and Kerberos is still more secure than a site without Kerberos, because passwords in a Kerberos environment are not sent across the network. Usually, your site will have a policy to help you determine your options.

Your Kerberos password is the only way Kerberos has of verifying your identity. If someone discovers your Kerberos password, Kerberos security becomes meaningless, for that person can masquerade as you -- send email that comes from "you," read, edit, or delete your files, or log into other hosts as you -- and no one will be able to tell the difference. For this reason, it is vital that you choose a good password and keep it secret. You should never reveal your password to anyone else, not even your system administrator. Additionally, you should change your password frequently, particularly any time you believe someone might have discovered it.

Advice on Choosing a Password

Your password can include almost any character you can type (the main exceptions being control keys and the Return key). A good password is one that you can remember readily, but which no one else can easily guess. Examples of bad passwords include:

• Words that can be found in a dictionary

• Any common or popular name

• The name of a famous person or character

• Your name or username in any form (for example: backward, repeated twice, and so forth)

• A spouse's, child's, or pet's name

• Your birth date or a relative's birth date

• Your Social Security number, driver's license number, passport number, or similar identifying number

• Any sample password that appears in this or any other manual

A good password is at least eight characters long. Moreover, a password should include a mix of characters, such as upper- and lower-case letters, numbers, and punctuation marks. Examples of passwords that would be good if they didn't appear in this manual include:

• Acronyms, such as "I2LMHinSF" (recalled as "I too left my heart in San Francisco")

• Easy-to-pronounce nonsense words, like "WumpaBun" or "WangDangdoodle!"

• Deliberately misspelled phrases, such as "6o'cluck" or "RrriotGrrrlsRrrule!"

Don't use these examples. Passwords that appear in manuals are the first ones an intruder will try.

Changing Your Password

You can change your Kerberos password in two ways:

• With the usual UNIX passwd command. With SEAM installed, the Solaris passwd command also automatically prompts for a new Kerberos password.

  The advantage of using passwd instead of kpasswd is that you can set both passwords (UNIX and Kerberos) at the same time. However, generally you do not have to change both passwords with passwd; often you can change only your UNIX password and leave the Kerberos password untouched, or vice-versa.

  ---

  Note -

  The behavior of passwd depends on how the PAM module is configured. You may be required to change both passwords in some configurations. For some sites the UNIX password must be changed, while others require the Kerberos password to change.

  ---

• With the kpasswd command. kpasswd is very similar to passwd. One difference is that kpasswd changes only Kerberos passwords -- you must use passwd if you want to change your UNIX password.

  Another difference is that kpasswd can change a password for a Kerberos principal that is not a valid UNIX user. For example, david/admin is a Kerberos principal, but not an actual UNIX user, so you must use kpasswd instead of passwd.

Using kpasswd requires the use of the SEAM 1.0 administration system which is included in the SEAS 3.0 release. In addition, privacy support must be loaded to protect the requests to change the password.

After you change your password, it takes some time for the change to propagate through a system (especially over a large network). Depending on how your system is set up, this might be anywhere from a few minutes to an hour or more. If you need to get new Kerberos tickets shortly after changing your password, try the new password first. If the new password doesn't work, try again using the old one.

Kerberos V5 allows system administrators to set criteria about allowable passwords for each user. Such criteria is defined by the policy set for each user (or by a default policy)-- see XREF for more on policies. For example, suppose that jennifer's policy (call it jenpol) mandates that passwords be at least eight letters long and include a mix of at least two kinds of characters. kpasswd will therefore reject an attempt to use sloth as a password:

% kpasswd
kpasswd: Changing password for jennifer@ENG.ACME.COM.
Old password:   <jennifer enters her existing password>
kpasswd: jennifer@ENG.ACME.COM's password is controlled by
the policy jenpol
which requires a minimum of 8 characters from at least 2 classes 
(the five classes are lowercase, uppercase, numbers, punctuation,
and all other characters).
New password: <jennifer enters 'sloth'>
New password (again):  <jennifer re-enters 'sloth'>
kpasswd: New password is too short.
Please choose a password which is at least 4 characters long. 

Here jennifer uses slothrop49 as a password. slothrop49 meets the criteria, because it is over eight letters long and contains two different kinds of characters (numbers and lowercase letters):

% kpasswd
kpasswd: Changing password for jennifer@ENG.ACME.COM.
Old password:  <jennifer enters her existing password>
kpasswd: jennifer@ENG.ACME.COM's password is controlled by
the policy jenpol
which requires a minimum of 8 characters from at least 2 classes 
(the five classes are lowercase, uppercase, numbers, punctuation,
and all other characters).
New password:  <jennifer enters 'slothrop49'>
New password (again):  <jennifer re-enters 'slothrop49'>
Kerberos password changed.

Examples--Changing Your Password

The following example shows david changing both his UNIX and Kerberos passwords with passwd.

% passwd
	passwd:  Changing password for david
	Enter login (NIS+) password:         <enter the current UNIX password>
	New password:                        <enter the new UNIX password>
	Re-enter password:                   <confirm the new UNIX password>
	Old KRB5 password:                   <enter the current Kerberos password>
	New KRB5 password:                   <enter the new Kerberos password>
	Re-enter new KRB5 password:          <confirm the new Kerberos password>

In the above example passwd asks for both the UNIX and Kerberos password; however, if try_first_pass is set in the PAM module, the Kerberos password is automatically set to be the same as the UNIX password. (That is the default configuration.) In that case, david must use kpasswd to set his Kerberos password to something else, as shown next.

This example shows him changing only his Kerberos password with kpasswd:

% kpasswd
kpasswd: Changing password for david@ENG.ACME.COM.
Old password:           <enter the current Kerberos password>
New password:           <enter the new Kerberos password>
New password (again):   <confirm the new Kerberos password>
Kerberos password changed.

In this example, david changes the password for the Kerberos principal david/admin (which is not a valid UNIX user). To do this he must use kpasswd.

% kpasswd david/admin
kpasswd:  Changing password for david/admin.
Old password:		   	     <enter the current Kerberos password>
New password:			       <enter the new Kerberos password>
New password (again):	   <confirm the new Kerberos password>
Kerberos password changed. 

SEAM Files

This section lists the files included in the SEAM product.

PAM Configuration File

The default PAM configuration file delivered with SEAM includes commented out entries to use the Kerberos capabilities. The new file includes entries for the authentication service, account management, session management, and password management modules.

For the authentication module, the new entries are for rlogin, login, and dtlogin. An example of these entries is shown below. All of these services use the new PAM library, /usr/lib/security/pam_krb5.so.1, to provide Kerberos authentication.

The first three entries employ the try_first_pass option, which requests authentication using the user's initial password. Using the initial password means that the user is not prompted for another password even if multiple mechanisms are listed. An other entry is included as the default entry for all entries requiring authentication that are not specified.

# cat /etc/pam.conf
 .
 .
rlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
login auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
dtlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
krlogin auth required /usr/lib/security/pam_krb5.so.1 acceptor
ktelnet auth required /usr/lib/security/pam_krb5.so.1 acceptor
krsh auth required /usr/lib/security/pam_krb5.so.1 acceptor
other auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass

For the account management, dtlogin has a new entry that uses the Kerberos library, as shown below. An other entry is included to provide a default rule. Currently no actions are taken by the other entry.

dtlogin account optional /usr/lib/security/pam_krb5.so.1 
other account optional /usr/lib/security/pam_krb5.so.1

The last two entries in the /etc/pam.conf file are shown below. The other entry for session management destroys user credentials. The new other entry for password management selects the Kerberos library.

other session optional /usr/lib/security/pam_krb5.so.1 
other password optional /usr/lib/security/pam_krb5.so.1 try_first_pass

SEAM Commands

This section lists some of the commands included in the SEAM product.

Changes to the share Command

In addition to the new SEAM commands, the Solaris 8 release includes new security flavors to be used with the share command. These modes are defined in the /etc/nfssec.conf file. These new security modes can be used by the share command:

krb5

Select Kerberos authentication

krb5i

Select Kerberos authentication with integrity

krb5p

Select Kerberos authentication with integrity and privacy

When multiple modes are included with the share command, the first mode listed is used by default if the client does not specify a security mode. Otherwise, the mode that the client selected is used.

If a mount request using a Kerberos mode fails, the mount completes using none as the security mode. This often occurs when the root principal on the NFS client is not authenticated. The mount request might succeed, but the user will be unable to access the files unless they are authenticated through Kerberos. Any transactions between the client and the server require Kerberos authentication, even if the file system is not mounted using a Kerberos security mode.

SEAM Daemons

The daemons that are used by the SEAM product are listed in the following table.

Ticket Reference

The following section presents additional information about tickets.

Types of Tickets

Tickets have properties that govern how they can be used. These properties are assigned to the ticket when it is created, although you can modify a ticket's properties later. (For example, a ticket can change from forwardable to forwarded.) You can view ticket properties with the klist command (see "How to View Tickets").

Tickets can be described by one or more of the following terms:

forwardable/forwarded

A forwardable ticket can be sent from one host to another, obviating the need for a client to reauthenticate itself. For example, if the user david obtains a forwardable ticket while on jennifer's machine, he can log in to his own machine without having to get a new ticket (and thus authenticate himself again). (See XREF for an example of a forwardable ticket.) Compare a forwardable ticket to a proxiable ticket, below.

initial

An initial ticket is one that is issued directly, not based on a ticket-granting ticket. Some services, such as applications that change passwords, can require tickets to be marked initial in order to assure themselves that the client can demonstrate a knowledge of its secret key -- because an initial ticket indicates that the client has recently authenticated itself (instead of relying on a ticket-granting ticket, which might have been around for a long time).

invalid

An invalid ticket is a postdated ticket that has not yet become usable. (See postdated, below.) It will be rejected by an application server until it becomes validated. To be validated, it must be presented to the KDC by the client in a TGS request, with the VALIDATE flag set, after its start time has passed.

postdatable/postdated

A postdated ticket is one that does not become valid until some specified time after its creation. Such a ticket is useful, for example, for batch jobs intended to be run late at night, since the ticket, if stolen, cannot be used until the batch job is to be run. When a postdated ticket is issued, it is issued as invalid and remains that way until: its start time has passed, and the client requests validation by the KDC. (See invalid, above.) A postdated ticket is normally valid until the expiration time of the ticket-granting ticket; however, if it is marked renewable, its lifetime is normally set to be equal to the duration of the full life of the ticket-granting ticket. See renewable, below.

proxiable/proxy

At times it can be necessary for a principal to allow a service to perform an operation on its behalf. (An example might be when a principal requests a service to run a print job on a third host.) The service must be able to take on the identity of the client, but need only do so for that single operation. In that case, the server is said to be acting as a proxy for the client. The principal name of the proxy must be specified when the ticket is created.

A proxiable ticket is similar to a forwardable ticket, except that it is valid only for a single service, whereas a forwardable ticket grants the service the complete use of the client's identity. A forwardable ticket can therefore be thought of as a sort of super-proxy.

renewable

Because it is a security risk to have tickets with very long lives, tickets can be designated as renewable. A renewable ticket has two expiration times: the time at which the current instance of the ticket expires, and the maximum lifetime for any ticket. If a client wants to continue to use a ticket, it renews it before the first expiration occurs. For example, a ticket can be valid for one hour, with all tickets having a maximum lifetime of ten hours. If the client holding the ticket wants to keep it for more than an hour, the client must renew it within that hour. When a ticket reaches the maximum ticket lifetime (10 hours), it automatically expires and cannot be renewed.

For information on how to view tickets to see what their attributes are, see "How to View Tickets".

Ticket Lifetimes

Any time a principal obtains a ticket, including a ticket-granting ticket, the ticket's lifetime is set as the smallest of the following lifetime values:

• The lifetime value specified by the -l option of kinit, if kinit is used to get the ticket.

• The maximum lifetime value (max_life) specified in the kdc.conf file.

• The maximum lifetime value specified in the Kerberos database for the service principal providing the ticket. (In the case of kinit, the service principal is krbtgt/realm.)

• The maximum lifetime value specified in the Kerberos database for the user principal requesting the ticket.

The following figure shows how a TGT's lifetime is determined and illustrates where the four lifetime values come from. Even though the figure shows how a TGT's lifetime is determined, basically the same thing happens when any principal obtains a ticket. The only differences are that kinit doesn't provide a lifetime value, and the service principal providing the ticket provides a maximum lifetime value (instead of the krbtgt/realm principal).

Figure 23-1 How a TGT's Lifetime Is Determined

The renewable ticket lifetime is also determined from the minimum of four values, but renewable lifetime values are used instead:

• The renewable lifetime value specified by the -r option of kinit, if kinit is used to obtain or renew the ticket

• The maximum renewable lifetime value (max_renewable_life) specified in the kdc.conf file

• The maximum lifetime renewable value specified in the Kerberos database for the service principal providing the ticket (in the case of kinit, the service principal is krbtgt/realm)

• The maximum lifetime renewable value specified in the Kerberos database for the user principal requesting the ticket

Principal Names

Each ticket is identified by a principal name. The principal name can identify a user or a service. Here are examples of several of the principal names.

How the Authentication System Works

Applications allow you to log on to a remote system if you can provide a ticket that proves your identity and a matching session key. The session key contains information that is specific to the user and the service being accessed. A ticket and session key are created by the KDC for all users when they first log in. The ticket and matching session key form a credential. While using multiple networking services, a user can gather many credentials. The user needs to have a credential for each service running on a particular server. For instance, access to the ftp service on a server named boston requires one credential, and access to the ftp service on another server requires its own credential.

The process of creating and storing the credentials is transparent. Credentials are created by the KDC that sends the credential to the requestor. When received, the credential is stored in a credential cache.

Gaining Access to a Service Using SEAM

In order for a user to access a specific service on a specific server, the user must obtain two things. The first is a credential for the ticket-granting service (known as the TGT). Once the ticket-granting service has decrypted this credential, the service creates a second credential for the server for which the user requests access. This second credential can then be used to request access to the service on the server. After the server has successfully decrypted the second credential, the user is given access. This process is described in more detail below, and in the figures that follow.

Obtaining a Credential for the Ticket-Granting Service

1. To start the authentication process, the client sends a request to the authentication server for a specific user principal. This request is sent without encryption. There is no secure information included in the request, so it is not necessary to use encryption.

2. When the request is received by the authentication service, the principal name of the user is looked up in the KDC database. If a principal matches, the authentication service obtains the private key for that principal. The authentication service then generates a session key to be used by the client and the ticket-granting service (call it session key 1) and a ticket for the ticket-granting service (ticket 1). This ticket is also known as the ticket-granting ticket (TGT). Both the session key and the ticket are encrypted using the user's private key, and the information is sent back to the client.

3. The client uses this information to decrypt session key 1 and ticket 1, using the private key for the user principal. Since the private key should only be known by the user and the KDC database, the information in the packet should be safe. The client stores the information in the credentials cache.

Normally during this process, a user is prompted for a password. If the password entered is the same as the one used to build the private key stored in the KDC database, then the client can successfully decrypt the information sent by the authentication service. Now the client has a credential to be used with the ticket-granting service. The client is ready to request a credential for a server.

Figure 23-2 Obtaining a Credential for the Ticket-Granting Service

Obtaining a Credential for a Server

1. To request access to a specific server, a client must first have obtained a credential for that server from the authentication service (see "Obtaining a Credential for the Ticket-Granting Service"). The client then sends a request to the ticket-granting service, which includes the service principal name, ticket 1, and an authenticator encrypted with session key 1. Ticket 1 was originally encrypted by the authentication service using the service key of the ticket-granting service.

2. Because the service key of the ticket-granting service is known to the ticket-granting service, ticket 1 can be decrypted. The information included in ticket 1 includes session key 1, so the ticket-granting service can decrypt the authenticator. At this point, the user principal is authenticated with the ticket-granting service.

3. Once the authentication is successful, the ticket-granting service generates a session key for the user principal and the server (session key 2) and a ticket for the server (ticket 2). Session key 2 and ticket 2 are then encrypted using session key 1. Since session key 1 is known only to the client and the ticket-granting service, this information is secure and can be safely set over the net.

4. When the client receives this information packet, it decrypts the information using session key 1, which it had stored in the credential cache. The client has obtained a credential to be used with the server. Now the client is ready to request access to a particular service on that server.

Figure 23-3 Obtaining a Credential for a Server

Obtaining Access to a Specific Service

1. To request access to a specific service, the client must first have obtained a credential for the ticket-granting service from the authentication server, and a server credential from the ticket-granting service (see "Obtaining a Credential for the Ticket-Granting Service" and "Obtaining a Credential for a Server"). The client can send a request to the server including ticket 2 and another authenticator. The authenticator is encrypted using session key 2.

2. Ticket 2 was encrypted by the ticket-granting service with the service key for the service. Since the service key is known by the service principal, the service can decrypt ticket 2 and get session key 2. Session key 2 can then be used to decrypt the authenticator. If the authenticator is successfully decrypted, the client is given access to the service.

Figure 23-4 Obtaining Access to a Specific Service

Using the gsscred Table

The gsscred table is used by an NFS server when the server is trying to identify a SEAM user. The NFS services use UNIX IDs to identify users and these IDs are not part of a user principal or credential. The gsscred table provides a mapping from UNIX UIDs (from the password file) to principal names. The table must be created and administered after the KDC database is populated.

When a client request comes in, the NFS services try to map the principal name to a UNIX ID. If the mapping fails, the gsscred table is consulted. With the kerberos_v5 mechanism, a root/hostname principal is automatically mapped to UID 0, and the gsscred table is not consulted. This means that there is no way to do special remappings of root through the gsscred table.

Which Mechanism to Select for the gsscred Table

Choosing the correct mechanism for the gsscred table depends on several factors.

• Are you interested in improving the lookup time?

• Are you interested in increasing data access security?

• Do you need to build the file quickly?

This is a list of all of the back-end mechanisms that can be selected along with a description of advantages of the mechanism.

files

The gsscred table is stored on a file system. A local file system that is not shared provides the most secure back-end, since no transmissions are done over the net after the table is created. This version of the file builds the quickest.

xfn_files

The gsscred table is stored within the /var/fn file system. This file system can be shared or not. All xfn files take a long time to build.

xfn_nis

The gsscred table is stored within the NIS namespace. The lookups in this file system are not secure. All xfn files take a long time to build.

xfn_nisplus

The gsscred table is stored within the NIS+ namespace. The lookups in this file system are not secure. All xfn files take a long time to build.

xfn

The gsscred table is stored within the default system for xfn. All xfn files take a long time to build.

For the files back-end mechanism, the initial lookup can be slow. For the other mechanisms, the initial lookup can be faster using a name service. For all of the mechanisms, after the data is cached the retrieval time should be about the same.