Introduction

This is a quick guide for end-users. The end-user does not need to know all of the details about Kerberos, NIS, protocols, configuration, etc. The end user needs to know how to login to the system and get work done!

First of all, why are we using Kerberos passwords and NIS anyway? What's the point and why should you care? You are using the Distributed Authentication System for the following reasons:

Why We're Using the DAS:

Step-by-step Instructions

Logging In:

Assuming your administrator has allowed you to login to a specific machine, you can enter your Kerberos username and password at the console prompt or the GUI console prompt window. One you have done this, you are "logged-in" and you now have a Kerberos 5 (Kerb) ticket authorizing you to use resources on the network. By default, this ticket is good for 10 hours.

To take a look at your ticket, you can use this command:

[kitty@labdemo2 kitty]$ klist
Ticket cache: FILE:/tmp/krb5cc_6000_NkLqXp
Default principal: kitty@KERB.ORG
 
Valid starting     Expires            Service principal
05/11/04 14:29:58  05/12/04 00:29:58  krbtgt/KERB.ORG@KERB.ORG
        renew until 05/11/04 14:29:58
 
 
Kerberos 4 ticket cache: /tmp/tkt6000
klist: You have no tickets cached

As you can see, you now have a Kerb ticket. It expires after 10 hours, around 00:30 tonight. Since we are only using Kerberos 5, you don't need to worry about the Kerberos 4 tickets. You can also use the same username and password when you login via SSH. On GNU/Linux systems, this will also obtain a Kerb ticket and place it in the cache for you.

Also note that the "principal" name is kitty@KERB.ORG. "kitty" is the username, "KERB.ORG" is the realm. The whole thing is used to uniquely identify you.

SSH Logins:

On GNU/Linux systems, logging in via SSH2 works exactly the same way. After you have been successfully authenticated, your ticket will automatically be cached. When you logout, your ticket will automatically be destroyed. FreeBSD is the exception:  even after successful authentication, you will need to run kinit manually if you need a ticket for single-sign-on applications and services.

Logging Out:

When you logout, the ticket is automatically destroyed with the kdestroy program. If you need to manually get a ticket or destroy a ticket, here is how you would do it:

[kitty@labdemo2 kitty]$ kinit
Password for kitty@KERB.ORG:
[kitty@labdemo2 kitty]$ klist
Ticket cache: FILE:/tmp/krb5cc_6000_NkLqXp
Default principal: kitty@KERB.ORG
                                                                                                           
Valid starting     Expires            Service principal
05/11/04 15:01:31  05/12/04 01:01:31  krbtgt/KERB.ORG@KERB.ORG
                                                                                                           
Kerberos 4 ticket cache: /tmp/tkt6000
klist: You have no tickets cached
[kitty@labdemo2 kitty]$ kdestroy
[kitty@labdemo2 kitty]$ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_6000_NkLqXp)
                                                                                                           
Kerberos 4 ticket cache: /tmp/tkt6000
klist: You have no tickets cached

Changing Your Password:

To change your password, you will use the kpasswd command instead of the standard Unix passwd command. The network administrator probably attached a policy to your account specifying some restrictions on the password. The restrictions may include length, complexity, dictionary check, and whether or not you have used the password previously. You will want to choose a good password.

Here is an example of a successful password change:

[kitty@labdemo2 kitty]$ kpasswd
Password for kitty@KERB.ORG:
Enter new password:
Enter it again:
Password changed.

Here are some examples of password change failures. The password changes fail because the password policy is violated:

[kitty@labdemo2 kitty]$ kpasswd
Password for kitty@KERB.ORG:
Enter new password:
Enter it again:
Password change rejected: New password does not have enough character classes.
The character classes are:
        - lower-case letters,
        - upper-case letters,
        - digits,
        - punctuation, and
        - all other characters (e.g., control characters).
Please choose a password with at least 2 character classes.

[kitty@labdemo2 kitty]$ kpasswd
Password for kitty@KERB.ORG:
Enter new password:
Enter it again:
Password change rejected: New password is too short.
Please choose a password which is at least 7 characters long.

[kitty@labdemo2 kitty]$ kpasswd
Password for kitty@KERB.ORG:
Enter new password:
Enter it again:
Password change rejected: New password was used previously. Please choose a different password.

Summary

As a typical user, you won't normally need to type in any Kerberos commands. Authentication and ticket operations will occur behind the scenes, without your active involvement. kinit and kdestroy are called automatically during login and logout. kpasswd will probably be the only Kerberos-specific command you will ever use.

Single-Sign-On Environment

Once you have your Kerb ticket, you may be able to use other network services without having to enter your username and password again. Kerberos was designed with this in mind. Your network administrator or IT department should let you know what Kerberized services are available. Here is a list of standard Kerberized network services, most of them being replacements for insecure standard Unix commands:

"These programs have all of the original features of the corresponding non-Kerberos rlogin, telnet, ftp, rsh, rcp, and su programs, plus additional features that transparently use your Kerberos tickets for negotiating authentication and optional encryption with the remote host. In most cases, all you'll notice is that you no longer have to type your password, because Kerberos has already proven your identity."

Except for ksu, all of these commands can take -x as an argument. This will cause the session to be encrypted with the DES algorithm.

On the lab network, rlogin -x, rsh, and rcp are the only Kerberized, single-sign-on (SSO) network service normally available. The unencrypted versions is not allowed. Below, you can see an example of Kerberized, encrypted RLOGIN:

[kitty@labdemo2 kitty]$ rlogin -x labsrv1
This rlogin session is using DES encryption for all data transmissions.
Last login: Tue May 11 16:02:16 from labdemo2
                                                                                                        
#######################
#       LABSRV1       #
#######################
                                                                                                        
You have mail.

[kitty@labsrv1 kitty]$ exit

[kitty@labdemo2 kitty]$ klist
Ticket cache: FILE:/tmp/krb5cc_6000_NkLqXp
Default principal: kitty@KERB.ORG
                                                                                                        
Valid starting     Expires            Service principal
05/11/04 16:00:47  05/12/04 02:00:47  krbtgt/KERB.ORG@KERB.ORG
05/11/04 16:01:11  05/12/04 02:00:47  host/labsrv1.kerb.org@KERB.ORG
                                                                                                        
                                                                                                        
Kerberos 4 ticket cache: /tmp/tkt6000
klist: You have no tickets cached

As you can see, the user was not prompted for a password when logging into host LABSRV1. The session is DES encrypted. When you logout of LABSRV1, you now have a Kerberos host ticket for LABSRV1.


Conclusion

As an end-user, using Kerberos is a piece of cake. It increases network and computer security, and it makes your life easier. If you are interested in learning more, please read the manual listed in the "reference" section.


References