If you will be using this system on the UW network, you may request an address assignment from UW Technology. We recommend an address on the 172 network.

We will be installing Fedora™ 11 (i686, KDE) from a Live CD image. Download the ISO image file and either burn it to a CD or boot directly from the ISO file.

Upon booting, the Live CD will present you with a desktop showing the Install to Harddrive icon within a Desktop Folder. Double-click the installer icon and proceed as prompted, choosing the defaults in most cases. You will be prompted for a keyboard layout, hostname, timezone, and root password. Reboot when the installation is completed.

After rebooting, you will be prompted to configure the operating system. After a click-through license screen, create a local user account. This account will be used for more detailed configuration later.

Do not press the Use Network Login... button at this time. You will be configuring Kerberos and LDAP after you have configured your static IP address. Likewise, set the date and time on the following screen, but wait to configure the network time service until later. Click the Finish button on the last (Hardware Profile) screen.

After the initial configuration, you will see a login screen. Login with the local account you have just created for yourself. A few minutes later, a software update (KPackageKit) popup message will likely appear. Now is a good time to apply any updates it has found. Rebooting after all updates have been applied is recommended.

Login as the local user created earlier. Configure the network interface settings for the DNS records you have obtained previously. Click the Fedora logo (ƒ) in the lower left-hand corner of the desktop to open the menu system (Kicker/Kickoff). Navigate to the Network Configuration applet as shown in the sequence below:

If you need to increase resolution to see the entire applet, you can do so here:

Double-click the correct interface under the Devices tab. Be sure to set Activate Device when computer starts, Statically set IP addresses, Manual IP address settings, and Primary DNS and Secondary DNS servers. When you are done, save your settings with File » Save. Logout of your session, and reboot.

Upon reboot, login again as the local user, and check your network settings from the shell:

Later on, you will want to run administrative commands from the shell using sudo. Now is a good time to configure for this, so type su in the Terminal to become root and then edit the /etc/sudoers file with the visudo command, adding a line like this (directly under a similar line for the root user):

Save your changes and close the editor. Changes to this file should take effect immediately. Exit the root shell and try the following command: sudo cat /etc/sudoers. You will be prompted for your password and the contents of the /etc/sudoers file should print to the screen.

It is important that the hostname command returns the fully qualified domain name (FQDN) for your system. Make sure the hostname found in the following file is the correct one:

For extra certainty that the system will associate its FQDN with the DNS IP address, you can add a line (as shown below) to your /etc/hosts file using the command sudo vi /etc/hosts

Where the IP address is followed by the FQDN and then by the short version of the hostname.

What you do not want is for your hostname to appear on the same line as localhost.

Open the Authentication Configuration utility as shown in the sequence below:

We will first configure Kerberos. Click the Authentication tab and check the checkbox labeled Enable Kerberos Support. Click the Configure Kerberos... button. Enter the following values:

Leave the checkboxes unchecked and press the OK button. Press the Options tab and check the checkboxes labeled Local authorization is sufficient for local users and Create Home directories on the first login. Press the OK button.

You should now be able to open Terminal and use kinit netid to create a Kerberos ticket, klist to list the ticket information, and then ssh netid@host to open a kerberized login session to a UW server such as homer, without being prompted again for your NetID password.

If you only want to use UW Kerberos to authenticate local user accounts on this machine, and you do not need NFSv4 or LDAP-based authorization, then all you need to do is create local accounts in:

The local account name must match the UW NetID username for UW Kerberos authentication to work. At this point, one can use this username to login to a desktop session, using either the the local password or the UW NetID password.

You may also lock the local password so that only the UW NetID password will work. You can configure this in User and Groups, when editing the properties of a user account. Select the user account, then press the Properties button. Click the Account Info tab and place a check mark on the Local password is locked checkbox.

If Kerberos authentication for local accounts satisfies your needs, then you can skip the rest of this tutorial.

The remainder of this document assumes you have an LDAP server which contains user account information such as home directory pathname and group membership.

Open the Authentication Configuration utility as shown in the sequence below:

Under the User Information tab, click the Enable LDAP Support checkbox. Click the Configure LDAP... button. Check the Use TLS to encrypt connections checkbox. Press the Download CA Certificate button. Enter the URL to the the certificate in the Certificate URL textbox and click the OK button. For LDAP Search Base DN enter the search base. Enter the LDAP server in the LDAP Server textbox. Press the OK button to close LDAP Settings dialog box and the Authentication Configuration dialog box.

You should now be able to test basic LDAP functionality by using the id -Gn netid command to list the groups to which a NetID belongs. For further tests, you can install the openldap-clients package from the Terminal as follows:

Now you can confirm that the LDAP traffic is begin encrypted with TLS if the following shell command is successful:

You can also confirm encryption using a utility such as tcpdump to monitor the traffic as it flows through the network interface:

You would run this command in one Terminal window and then capture packets while running the ldapsearch command in another window.

This will enable a user with a UW NetID and account information in LDAP to log into the workstation.

The remainder of this document assumes you have already established your own Kerberos realm and that you have configured your KDC to use your LDAP server. These services will be used by the NFSv4 server for user authentication and authorization.

It is also assumed that your Kerberos KDC has a cross-realm trust with the UW Kerberos realm. Contact UW Technology for more information regarding UW authentication services.

Since the Fedora™ Authentication Configuration applet does not provide an interface to configure multiple Kerberos realms, you will need to edit your /etc/krb5.conf by hand.

Here is an example:

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = u.washington.edu
 dns_lookup_realm = false
 dns_lookup_kdc = false
 clockskew = 120

[realms]
 MYDEPT.EXAMPLE.COM = {
  kdc = mykdc1.mydept.example.com:88
  kdc = mykdc2.mydept.example.com:88
  admin_server = myadminserver.mydept.example.com:749
  default_domain = MYDEPT.EXAMPLE.COM 
 }
 u.washington.edu = {
  kdc = k5-kdc1.u.washington.edu
  kdc = k5-kdc2.u.washington.edu
  admin_server = k5-admin.u.washington.edu
  kpasswd_server = k5-admin.u.washington.edu
  default_domain = u.washington.edu
 }

[domain_realm]
 .mydept.example.com = MYDEPT.EXAMPLE.COM
 mydept.example.com = MYDEPT.EXAMPLE.COM
 .u.washington.edu = u.washington.edu
 u.washington.edu = u.washington.edu

[kdc]
 profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
   kdc_timeout = 1
   max_retries = 1
}

... where mydept.myexample.com would be replaced with your departmental subdomain.

Since Kerberos and LDAP require SASL GSSAPI in order to work together, you will need to install the cyrus-sasl-gssapi package. This can be done from the Terminal with yum:

Assuming kinit netid works and your Kerberos ticket has not yet expired, you can proceed to test GSSAPI using ldapsearch as follows:

You could now log out of your local account session and log back in using your NetID credentials. However, the login would be somewhat delayed and you would see warnings from SELinux in the setroubleshoot browser. Later on, as you configure the automounter to mount NFSv4 home directories on login, SELinux will generate even more serious errors. It would be great to work through and eliminate all of these errors with custom policy rules. However, for now we will disable SELinux. Open the SELinux Configuration applet:

Set System Default Enforcing Mode to Disabled. Close the applet and restart the system. You can check to make sure SELinux is now disabled, using either the applet or the shell command sestatus.

The remainder of this document assumes you have an NFSv4 server with the proper Kerberos principals for it and as well the principals for the NFSv4 client you are currently configuring. For information on creating these, see Doug Potter's Kerberos HOWTO.

To add the principals for your host to it's keytab, you can run these commands from a shell prompt (assuming you know the admin password for your Kerberos server):

To mount NFSv4 exports you will need to make small edits to two files.

Uncomment the following line in /etc/sysconfig/nfs:

Find the following lines in /etc/idmapd.conf (in different sections) and modify like this:

At this point you should reboot for the changes to take effect (or at least restart rpcgssd and rpcidmapd).

Log in as root for the next steps. This is so that we can setup automounted home directories (without files under /home being currently in use).

First of all, you can test your NFSv4 configuration by trying to mount an NFSv4 export:

Assuming that works, you need to move /home so that it can be automounted via NFSv4:

Any local accounts will need to have their home path modified to point to /var/local/home/:

You will also want to change the default HOME for local users in /etc/default/useradd.

We will assume the NFSv4 server nfs4svr.mydept.example.com has already been configured to export /home (as well as some shared workspaces) when the client attempts to mount nfs4svr.mydept.example.com:/& .

Create the file /etc/auto.nfs4 containing this one line:

Then add this line to /etc/auto.master:

Restart autofs for your changes to take effect:

Logout of the root session.

Log in using a UW Kerberos NetID account.

If that account has a home directory on the NFSv4 server, then the login sequence should mount the exported home directory. If the NFSv4 server also exports a directory for group access, and if the username has access rights to the directory as a group member, then access should be granted based on LDAP authorization.

And if that works, then you have successfully completed all of the steps of this tutorial.