Skip navigation

STANFORD UNIVERSITY

INFORMATION TECHNOLOGY SERVICES

Installing Kerberos on Solaris 8 and 9

The Kerberos that comes with Solaris 8 and 9 is not sufficient for most uses. Because of that, IT Services provides downloadable kits for Solaris 8 and 9. These kits will probably not be changing significantly in the future, and at some point we will likely drop Solaris support. These kits are provided for the convenience of campus administrators who need to keep Solaris 8 or 9 systems running until they can migrate to another operating system.

The kits are available at:

https://www.stanford.edu/services/kerberos/dist/

The sun4x_58 kits are for Solaris 8 and the sun4x_59 kits are for Solaris 9. There are two types of kits available: outgoing and full. The outgoing kits contain only clients to obtain Kerberos tickets and connect to services on other systems. The full kits contain everything that the outgoing kits contain, plus the software needed to accept incoming Kerberos-authenticated logins to the system.

You should decide before you start which kit you want to install. Then, download the kit for your system, unpack it in an empty directory, and run the provided install-krb script:

    uncompress kit.tar.Z
    tar -xvf kit.tar
    rm -f kit.tar
    ./install-krb

The installation script will ask you whether you want to install the software using stow (useful if you use stow to manage other software on your system) or by directly copying the binaries into /usr/local.

If you install the full Kerberos kits, it will also tell you to merge several files: /etc/services, to add ports for Kerberos services; /etc/inetd.conf, to run the Kerberos login daemons; and /etc/hosts.allow and /etc/hosts.deny, which handle access control.

Clients and Basic Configuration

Once you've installed either kit, you should ensure that your system's clock is accurate. Kerberos will not work unless your system clock is within five minutes of the clock on the Kerberos servers. If you're not already running a clock setting daemon such as ntpd, you can do this with:

    /usr/local/sbin/ntpdate time.stanford.edu

If your clock drifts, you can run this command periodically from cron, or install ntpd.

Now, you should be able to run kinit and obtain Kerberos tickets and klist to see your tickets. See the guide to UNIX Kerberos commands for more information.

The kits install software into /usr/local/bin. If you haven't already, you may want to add /usr/local/bin to the PATH of your users so that they can easily run the newly-installed software.

We also recommend that you rename the Kerberos software that Solaris provides in /usr/bin. These programs don't work as well as the ones that come with the kit, and having both available can be confusing. You can move these aside with the following commands:

    mv /usr/bin/kinit /usr/bin/kinit.orig
    mv /usr/bin/kdestroy /usr/bin/kdestroy.orig
    mv /usr/bin/klist /usr/bin/klist.orig
    mv /usr/bin/ktutil /usr/bin/ktutil.orig

Remote Logins

First, before enabling remote logins with Kerberos, you should make sure that all accounts on your system with logins enabled either match the SUNet IDs of those users or contain a .k5login file (which should be empty if Kerberos logins aren't permitted for that account). By default, the servers that accept Kerberos logins will allow a user to log in to an account if their Kerberos principal matches the account name. The presence of a .k5login file overrides this logic and only principals listed in that file will be permitted to log in to that account.

See UNIX Kerberos Commands in the user guide for more information on creating a .k5login file.

The servers that come with the full Kerberos kit, unlike stock Kerberos, require that every user have a .k5login file unless the file /etc/noklogin exists. We recommend creating .k5login files for all users, since that will work as expected for both these kits and with stock Kerberos.

To authenticate connections to your system using Kerberos, the system needs its own Kerberos service principal and a keytab for that principal. The service principal is an account in Kerberos, similar to a SUNet ID but for a service instead of a person. The keytab is, in essence, the password for that account stored in a file on your system. For information on how to obtain a service principal, see Downloading Keytabs with Wallet.

To support Kerberos authentication via SSH, you will need to download and install portable OpenSSH. You should be able to compile in GSSAPI support using the Kerberos libraries provided as part of the Kerberos kits.

To accept Kerberos rlogin, rsh, and rcp connections, you will need to add those services to /etc/services and to /etc/inetd.conf. Included in the full Kerberos kit is an inetd.conf.krb file that you can append to your existing /etc/inetd.conf file to enable Kerberos services. Similarly, there is a services.krb file that you can append to your existing /etc/services file. You should comment out, with a #, any services that you don't want to run (for example, most systems won't need to run Kerberos telnet). The lines provided in inetd.conf.krb run all services under TCP wrappers (provided with the kit), allowing you to control access to particular services with /etc/hosts.allow and /etc/hosts.deny.

Once you have changed /etc/inetd.conf and /etc/services to include the Kerberos services that you want to run, you should send a HUP signal to inetd. Use ps -ef to find the PID of the inetd process and then run:

    kill -HUP <pid>

to tell inetd to reload its configuration.

Afterwards, test logging on to your system or running a command on your system using the rlogin or rsh clients provided with the package to be sure everything is working properly. See the UNIX Kerberos Commands documentation for more details.

Local Logins

Logins with a username and password, which includes console logins, dtlogin, SSH with a username and password, and screen lock programs, use PAM to verify that password and to obtain user credentials such as Kerberos tickets. Therefore, enabling use of Kerberos passwords for local login means adding a Kerberos PAM module to your PAM configuration.

Solaris 8 and 9 use PAM, but do not include a Kerberos PAM module with the operating system. You can download the source for pam-krb5 and compile it with the Kerberos libraries that come with the kit. See its documentation for information on installation and configuration.

Last modified Thursday, 28-Feb-2008 10:25:03 AM

Stanford University Home Page