Kerberos V / AFS Project

3 September 2003   3364 words   ~16 mins
#afs

Table of Contents

Kerberos V / AFS Project

Miles Davis

Computer Science Department - Computer Facilities 

May 30, 2003

Stanford University Computer Science Department

$Id: index.html,v 1.7 2003/09/03 23:18:49 miles Exp $

Introduction

This project is designed to replace the existing NIS/NFS infrastructure for the Computer Science Department, Robotics and Theory with a KerberosV1/AFS infrastructure. The switch to KerberosV/AFS is designed to address the following problems. Reasons for Kerberos / AFS

Reasons for Kerberos / AFS

AreaProblemSolution
Multiple authentication methodsCurrently, there are a number of authentication methods in place for CS/Robotics/Theory, mainly accounts on individual systems and NIS.Kerberos will provide a unified authentication method, with a single account across all systems.
Insecure authenticationNIS is notoriously insecure – any user can see the encrypted passwords of all users, and the encryption is weak enough to be broken with existing tools (see Crack, John the Ripper).Kerberos encryption is stronger, and the encrypted passwords are not visible to the world.
Insecure file accessNFS file access is based on numeric user ids, and it trusts all the systems which mount a given file system. Thus, if somebody gets root on a client, they can effectively become any user and access any files on the NFS filesystem.AFS uses Kerberos to control access to files. Even if a user obtains root on a client system, they are not able to become another user because they are not able to get a ticket for that user without the user’s password.
Location transparencyWithout creating a forest of symlinks, NFS is still location dependent. If a file moves from /nfs/mount1 to /nfs/mount2, you must change path names or symlink /nfs/mount1/file to /nfs/mount2/file.AFS provides a single-root filesystem for all clients and servers, regardless of the physical location of the file.
Server transparencyEven with the symlinks described above, the mountpoint itself is still dependent on the server.The root cell of afs (/afs) is mounted once everywhere, no matter what servers or how many there are, or if they change later on.
User quotasFilesystem quotas are tricky on older Linux boxes, and we have had multiple problems with them. Because multiple users exist within a single filesystem, the quota information is stored separately for the user. If you move the user to a new filesystem, you have to recreate/modify the quota.In AFS, we can create a separate volume for each and every user. The quota stays with the volume, not it’s location. When you move the volume to a new AFS server, the location (say, /afs/cs/u/miles) doesn’t change.
RedundancyWith NFS, redundancy has to be done at the server side, using methods like RAID to provide failover capabilities. Currently, none of our servers use RAID. Even if the filesystems are protected, the server is not. If the NFS server goes down, access to the files is lost. Often, clients must be rebooted after an extended NFS server downtime.With AFS, volumes can be transparently replicated or mirrored across multiple servers, providing data and access redundancy. If one server fails, the files are still accessible through the volume mirrors, with no visible user impact.
Wasted disk spaceBecause of the redundancy problems of NFS, we try to limit the number of NFS servers. As a result, new systems acquired often have large amounts of local disk storage which goes to waste, or is only available locally to the system.With AFS, we can turn these secondary servers into file servers, taking advantage of the local disk storage. Because we can replicate across multiple servers, we can use the local disk storage in such a way that the state of a single (or even multiple) servers doesn’t affect any of the other clients.

Kerberos V / AFS setup scenarios:

Status Quo (with or without Krb5)

Pros

  • No interruption in service
  • No work to change
  • Little work to add kerberos authentication
  • Everybody is familiar with administration

Cons

  • Lacks filesystem security
  • Xenon continues to have quota problems causing crashed, and it’s not known when this will be resolved.
  • Still a pain to move users

Switch to Leland Accounts

Pros

  • Unified login across campus
  • Somebody else does the administrative work
  • Proven to work

Cons

  • We have to do it the ITSS way
  • Must pay for alumni accounts
  • Somebody else does the administrative work
  • Big pain to unify namespaces for users
  • Big pain to move existing accounts over
  • Department or Faculy must pay for new disk space – current disk space cannot be used
  • Some users will have to be renamed, and they might not like it

Switch to local AFS / Kerberos

Pros

  • We maintain local control, which is what our users pay for
  • Usernames are preserved as they are now
  • Can unify other groups in the department (Robo, Theory, SCCM) to amortize administrative tasks
  • Provides user self-restores for files < 24h old

Cons

  • Big pain to move existing accounts over

Kerberos 5 Installation and Setup

Note these instructions are obviously out of date and are left here for history.

Kerberos KDCs

I installed all of the compiled packages on the system:

cs-kdc-1# rpm -Uvh krb5-devel-1.2.7-2* krb5-server-1.2.7-2* krb5-libs-1.2.7-2 krb5-workstation-1.2.7-2*

Following tips in: http://www.ofb.net/~jheiss/krbldap/howto.html#kerbserv I did the following:

Setting up the Kerberos master KDC

  1. Edit /etc/krb5.conf:

    • Replace EXAMPLE.COM with CS.STANFORD.EDU. Replace example.com with cs.stanford.edu.
    • Set krb4_convert to true (not sure if needed)

  2. Define a record in NetDB (DNS) for cs-kdc-1.stanford.edu

  3. Edit /var/kerberos/krb5kdc/kdc.conf

    • Replace EXAMPLE.COM with CS.STANFORD.EDU
    • Change master_key_type to: des3-hmac-sha1
    • Add des3-hmac-sha1:normal to supported_enctypes.

  4. Create the Kerberos Database:

    cs-kdc-1# /usr/kerberos/sbin/kdb5_util create -s

Initializing database
'/var/kerberos/krb5kdc/principal' for realm 'CS.STANFORD.EDU',
master key name 'K/[email protected]'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:

  5. Edit /var/kerberos/krb5kdc/kadm5.acl:

    Replace EXAMPLE.COM with CS.STANFORD.EDU

  6. Create a Kerberos user with administrative privileges:

    cs-kdc-1# /usr/kerberos/sbin/kadmin.local -q "addprinc miles/admin"
Authenticating as principal
miles/[email protected] with password.
WARNING: no policy specified for miles/[email protected]; defaulting to no policy
Enter password for principal "miles/[email protected]":
Re-enter password for principal "miles/[email protected]": Principal "miles/[email protected]" created.

cs-kdc-1# /usr/kerberos/sbin/kadmin.local -q "addprinc miles"
Authenticating as principal
miles/[email protected] with password.
WARNING: no policy specified for [email protected]; defaulting to no policy
Enter password for principal "[email protected]":
Re-enter password for principal "[email protected]": Principal "[email protected]" created.

  7. Create the users needed by AFS:

    Following tips provided in http://ismene.csl.uiuc.edu/afs-mig/doc/README.txt and also http://www.mathematik.uni-karlsruhe.de/~iwrmm/Persons/Schulz/Unix/afs/afs-krb5.html.

    cs-kdc-1# /usr/kerberos/sbin/kadmin.local -q "addprinc admin"
Authenticating as principal
miles/[email protected] with password.
WARNING: no policy specified for [email protected]; defaulting to no policy
Enter password for principal "[email protected]":
Re-enter password for principal "[email protected]": Principal "[email protected]" created.

cs-kdc-1# /usr/kerberos/sbin/kadmin.local -q "addprinc admin/admin"
Authenticating as principal
miles/[email protected] with password.
WARNING: no policy specified for admin/[email protected]; defaulting to no policy
Enter password for principal "admin/[email protected]":
Re-enter password for principal "admin/[email protected]": Principal "admin/[email protected]" created.

    Important: Key type needs to be des-cbc-crc:v4:

    cd-kdc-1# /usr/kerberos/sbin/kadmin.local -e des-cbc-crc:v4 -q "addprinc -randkey afs/cs.stanford.edu"
Authenticating as principal
miles/[email protected] with password.
WARNING: no policy specified for afs/[email protected]; defaulting to no policy
Principal "[email protected]" created.

cs-kdc-1# /usr/kerberos/sbin/kadmin.local -e des-cbc-crc:v4 -q "addprinc afs/admin"
Authenticating as principal
miles/[email protected] with password.
WARNING: no policy specified for afs/[email protected]; defaulting to no policy
Enter password for principal "afs/[email protected]":
Re-enter password for principal "afs/[email protected]": Principal "afs/[email protected]" created.

cd-kdc-1# /usr/kerberos/sbin/kadmin.local -q "modprinc -kvno 0 afs/[email protected]"
Authenticating as principal
miles/[email protected] with password.
Principal "[email protected]" modified.

  8. Now let’s start the Kerberos servers:

    cs-kdc-1# service kadmin start
cs-kdc-1# service krb5kdc start
cs-kdc-1# service krb524 start

Creating slave (backup) KDCs

Server replication is handled by the kprop command. kprop must be run on the primary master KDC. It should be run in a scheduled cron job to keep the principal database in sync.

  1. On the slave, set up ACLs for kpropd. Edit /var/kerberos/krb5kdc/kpropd.acl, adding one line for each KDC, master and slave:

    host/[email protected]
host/[email protected]

    The kpropd.acl file should only exist on the slave Kerberos server. In RedHat, kadmin will not run on a Kerberos server on which /var/kerberos/krb5kdc/kpropd.acl exists.

  2. Next you’ll need to create host keys for your master and slave Kerberos servers:

    cs-kdc-1# kadmin.local
kadmin.local:  addprinc -randkey host/cs-kdc-1.stanford.edu
kadmin.local:  addprinc -randkey host/cs-kdc-2.stanford.edu

  3. The next step is to extract these keys to the keytab file:

    kadmin.local:  ktadd host/cs-kdc-1.stanford.edu
kadmin.local:  ktadd host/cs-kdc-2.stanford.edu

  4. Copy the keytab over to the slave server so that it has the keys it needs available to authenticate.

    cs-kdc-2# scp root@cs-kdc-1:/etc/krb5.keytab /etc

  5. Copy over the kdc.conf and create the stash:

    cs-kdc-2# scp root@cs-kdc-1:/var/kerberos/krb5kdc/kdc.conf /etc
cs-kdc-2# /usr/kerberos/sbin/kdb5_util stash
kdb5_util : Cannot find/read stored master key while reading master key
kdb5_util: Warking: proceeding without master key
Enter KDC database master key:

  6. Start kpropd:

    service kpropd start

  7. Test that the propagation works by running:

    /usr/kerberos/sbin/kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans
/usr/kerberos/sbin/kprop -f /var/kerberos/krb5kdc/slave_datatrans cs-kdc-2.stanford.edu

    You’ll want to stick that in a cron job on the master KDC.

  8. Turn kerberos services on:

    chkconfig krb5kdc on
chkconfig kprop on
chkconfig krb524 on

OpenAFS Installation and Setup

OpenAFS1 information here.

Installing the first AFS server

  1. Install openafs components:

    cs-afs-1# apt-get install openafs openafs-client openafs-server openafs-kernel openafs-krb5

  2. Add our cell name (cs.stanford.edu) to the appropriate files:

    cs-afs-1# echo ">cs.stanford.edu" >> /usr/vice/etc/CellServDB
cs-afs-1# echo "171.64.64.10      #cs.stanford.edu" >> /usr/vice/etc/CellServDB
cs-afs-1# rm -rf /usr/vice/etc/ThisCell
cs-afs-1# echo "cs.stanford.edu" > /usr/vice/etc/ThisCell

  3. Temporarily, change the following variables in /etc/sysconfig/afs to have the values below:

    AFS_CLIENT=off
AFS_SERVER=off

  4. Start afs:

    cs-afs-1# service afs start
Found libafs-2.4.18-19.8.0-i686.o from SymTable... Loading...
Starting AFS services.....

  5. Set Cellname, create server instances:

    cs-afs-1# /usr/afs/bin/bosserver -noauth &
cs-afs-1# bos setcellname cs-afs-1.stanford.edu cs.stanford.edu -noauth
cs-afs-1# bos create cs-afs-1.stanford.edu buserver simple /usr/afs/bin/buserver -cell cs.stanford.edu -noauth
cs-afs-1#  bos create cs-afs-1.stanford.edu ptserver simple /usr/afs/bin/ptserver -cell cs.stanford.edu -noauth
cs-afs-1# bos create cs-afs-1.stanford.edu vlserver simple /usr/afs/bin/vlserver -cell cs.stanford.edu -noauth
cs-afs-1# bos adduser cs-afs-1.stanford.edu admin -cell cs.stanford.edu -noauth

  6. Generate and Import Kerberos 5 key:

    cs-kdc-1# /usr/kerberos/sbin/kadmin.local -e des-cbc-crc:v4 -q "ktadd -k /var/kerberos/krb5kdc/afs.keytab afs/[email protected]"
Authenticating as principal
miles/[email protected] with password.
Entry for principal [email protected] with kvno 1, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/var/kerberos/krb5kdc/afs.keytab.

    Copy the keytab over to the afs server and import:

    cs-afs-1# /usr/sbin/asetkey add 1 /tmp/afs.keytab afs/cs.stanford.edu
cs-afs-1# rm /tmp/afs.keytab

  7. Create Admin user for AFS:

    cs-afs-1# pts createuser -name admin -cell cs.stanford.edu -noauth
cs-afs-1# pts adduser admin system:administrators -cell cs.stanford.edu -noauth
cs-afs-1# pts membership admin -cell cs.stanford.edu -noauth

  8. Restart and Create Fileserver Instances:

    cs-afs-1# bos restart cs-afs-1.stanford.edu -all -cell cs.stanford.edu -noauth
cs-afs-1# bos create cs-afs-1.stanford.edu fs fs /usr/afs/bin/fileserver /usr/afs/bin/volserver /usr/afs/bin/salvager -cell          cs.stanford.edu -noauth

  9. Stuff Specific to the First AFS Server in Cell:

    This is specific to the first afs server: We are creating root.afs

    cs-afs-1# /usr/sbin/vos create cs-afs-1.stanford.edu /vicepa root.afs -cell cs.stanford.edu -noauth

    Again, this is specific to the first afs server. We are distributing /usr/afs/etc by way of the upserver functionality. I am not distributing /usr/afs/bin this way – we use the RPMs, which we update on every client.

    cs-afs-1# bos create cs-afs-1.stanford.edu upserver simple "/usr/afs/bin/upserver -crypt /usr/afs/etc" -cell cs.stanford.edu -noauth

  10. Disabling AFS’s Time Synch Mechanism

    Important: This assumes you have a working ntp installation. Kerberos (and therefore AFS) require machines to be time synched closely. We run ntpd on all our machines, therefore we need to disable AFS’s time synch mechanism.

    Edit /etc/rc.d/init.d/afs and change AFSD_OPTIONS to:

    AFSD_OPTIONS="$OPTIONS $VERBOSE -nosettime"

  11. Restart:

    cs-afs-1# bos shutdown cs-afs-1.stanford.edu -wait -noauth

    Kill the bosserver process:

    cs-afs-1# ps -ef | grep bosserver
root     1101     1  0 12:10 ?        00:00:00 /usr/afs/bin/bosserver -noauth
cs-afs-1# kill 1101

  12. Change: /etc/sysconfig/afs to read:

    AFS_CLIENT=on
AFS_SERVER=on

  13. Stop AFS:

    cs-afs-1# /etc/rc.d/init.d/afs stop

    Stopping AFS should unload the afs module from the kernel, but it does not. Therefore:

    cs-afs-1# /sbin/lsmod | grep afs
libafs-2.4.18-19.8.0-i686  479472   0
cs-afs-1# /sbin/rmmod libafs-2.4.18-19.8.0-i686

    Now we should be able to cleanly start AFS again:

    cs-afs-1# /etc/rc.d/init.d/afs start
cs-afs-1# chkconfig afs on

  14. Defining root.cell and Mount Points:

    First become admin:

    cs-afs-1# kinit admin
Password for [email protected]:
cs-afs-1# aklog
cs-afs-1# fs setacl /afs system:anyuser rl
cs-afs-1# /usr/sbin/vos create cs-afs-1.stanford.edu /vicepa root.cell
cs-afs-1# fs mkmount /afs/cs.stanford.edu root.cell
cs-afs-1# fs setacl /afs/cs.stanford.edu system:anyuser rl
cs-afs-1# cd /afs
cs-afs-1# ln -s cs.stanford.edu cs
cs-afs-1# fs mkmount /afs/.cs.stanford.edu root.cell -rw

    Now we add replication points. This will be added to as we add new

    machines to cell:

    cs-afs-1# /usr/sbin/vos addsite cs-afs-1.stanford.edu /vicepa root.afs
cs-afs-1# /usr/sbin/vos addsite cs-afs-1.stanford.edu /vicepa root.cell
cs-afs-1# /usr/sbin/vos release root.afs
cs-afs-1# /usr/sbin/vos release root.cell
cs-afs-1# fs checkvolumes

Installing an AFS file server:

A simple file server machine runs only the processes that store and deliver AFS files to client machines. You can run as many simple file server machines as you need to satisfy your cell’s performance and disk space requirements.

  1. Install openafs components:

    cs-afs-2# apt-get install openafs openafs-client openafs-server openafs-kernel openafs-krb5

  2. Copy afs esrver files over from another afs server:

    cs-afs-2# scp cs-afs-1:/usr/afs/etc/* /usr/afs/etc
CellServDB           100% |*****************************|    67       00:00
KeyFile              100% |*****************************|   100       00:00
ThisCell             100% |*****************************|    15       00:00
UserList             100% |*****************************|     6       00:00
CellServDB           100% |*****************************|    67       00:00
cs-afs-2# scp cs-afs-1:/usr/vice/etc/CellServDB /usr/vice/etc
CellServDB           100% |*****************************|   271       00:00
cs-afs-2# scp cs-afs-1:/etc/krb* /etc
krb.conf             100% |*****************************|  2365       00:00
krb.realms           100% |*****************************|  1404       00:00
krb5.conf            100% |*****************************|   732       00:00

    Add our cell name (cs.stanford.edu) to the appropriate files:

    cs-afs-2# rm -rf /usr/vice/etc/ThisCell
cs-afs-2# echo "cs.stanford.edu" > /usr/vice/etc/ThisCell

  3. Temporarily, change the following variables in /etc/sysconfig/afs to have the values below:

    AFS_CLIENT=off
AFS_SERVER=off

  4. Start afs:

    cs-afs-2# service afs start
Found libafs-2.4.18-19.8.0-i686.o from SymTable... Loading...
Starting AFS services.....

  5. Set Cellname, create server instances:

    cs-afs-2# /usr/afs/bin/bosserver -noauth &

    ? cs-afs-2# bos setcellname cs-afs-2.stanford.edu cs.stanford.edu -noauth

  6. If adding a new DB machine:

    cs-afs-1# bos addhost cs-afs-1 cs-afs-2.stanford.edu
cs-afs-1# bos restart cs-afs-1 -all

cs-afs-2# bos create cs-afs-2.stanford.edu buserver simple /usr/afs/bin/buserver -cell cs.stanford.edu -noauth
cs-afs-2#  bos create cs-afs-2.stanford.edu ptserver simple /usr/afs/bin/ptserver -cell cs.stanford.edu -noauth
cs-afs-2# bos create cs-afs-2.stanford.edu vlserver simple /usr/afs/bin/vlserver -cell cs.stanford.edu -noauth

  7. Restart and Create Fileserver Instances:

    cs-afs-2# bos restart cs-afs-2.stanford.edu -all -cell cs.stanford.edu -noauth
cs-afs-2# bos create cs-afs-2.stanford.edu fs fs /usr/afs/bin/fileserver /usr/afs/bin/volserver /usr/afs/bin/salvager -cell          cs.stanford.edu -noauth
cs-afs-2# bos create cs-afs-2.stanford.edu  upclientetc simple  "/usr/afs/bin/upclient  cs-afs-1.stanford.edu  /usr/afs/etc" -cell cs.stanford.edu  -noauth

  8. Disabling AFS’s Time Synch Mechanism

    Important: This assumes you have a working ntp installation. Kerberos (and therefore AFS) require machines to be time synched closely. We run ntpd on all our machines, therefore we need to disable AFS’s time synch mechanism.

    Edit /etc/rc.d/init.d/afs and change AFSD_OPTIONS to:

    AFSD_OPTIONS="$OPTIONS $VERBOSE -nosettime"

  9. Restart:

    cs-afs-2# bos shutdown cs-afs-2.stanford.edu -wait -noauth

    Kill the bosserver process:

    cs-afs-2# ps -ef | grep bosserver
root     1101     1  0 12:10 ?        00:00:00 /usr/afs/bin/bosserver -noauth
cs-afs-2# kill 1101

  10. Change: /etc/sysconfig/afs to read:

    AFS_CLIENT=on
AFS_SERVER=on

  11. Stop AFS:

    cs-afs-2# service afs stop

Stopping AFS should unload the afs module from the kernel, but it does not. Therefore:

	cs-afs-2# /sbin/lsmod | grep afs
	libafs-2.4.18-19.8.0-i686  479472   0
	cs-afs-2# /sbin/rmmod libafs-2.4.18-19.8.0-i686

Now we should be able to cleanly start AFS again:

	cs-afs-2# service afs start
	cs-afs-2# chkconfig afs on

Adding Regular Users and Directories

  1. If you are not admin, first assume admin identity:

    cs-afs-1# kinit admin cs-afs-1# aklog

  2. Let’s first create a usergroup, users, with gid 100:

    cs-afs-1# pts creategroup -name users -id -100 cs-afs-1# pts adduser -user admin -group users cs-afs-1# pts chown users users

  3. All the user home directories will be here:

    cs-afs-1# mkdir /afs/.cs.stanford.edu/u cs-afs-1# vos release root.cell

  4. Creating sample user – miles (uid 9766 from CS database):

    cs-kdc-1# /usr/kerberos/sbin/kadmin.local -q “addprinc miles” cs-afs-1# pts createuser -name miles -id 9766 cs-afs-1# pts adduser -user miles -group users

  5. Creating user’s home directory, setting permissions, quota:

    cs-afs-1# /usr/sbin/vos create -name user.miles -server cs-afs-1.stanford.edu -partition /vicepa Volume 536870918 created on partition /vicepa of cs-afs-1.stanford.edu

Setting quota of 2GB and Creating the Mount Point:

cs-afs-1# /usr/sbin/vos setfields -id user.miles -maxquota 2000000
cs-afs-1# fs mkmount /afs/.cs.stanford.edu/u/miles user.miles -rw
cs-afs-1# /usr/sbin/vos release root.cell

Setting permissions:

cs-afs-1# fs setacl /afs/cs.stanford.edu/u/miles miles rlidwka
cs-afs-1# chown 9766:100 /afs/cs.stanford.edu/u/miles
cs-afs-1# chmod 700 /afs/cs.stanford.edu/u/miles

  1. User has to exist in /etc/passwd, NIS, or other name service:

    cs-afs-1# groupadd -g 100 users cs-afs-1# useradd -d /afs/cs.stanford.edu/u/miles -g users -u 9766 miles

Setting up a Kerberos Client

  1. Check that necessary packages are installed:

    • pam_krb5
    • krbafs
    • krbafs-develcs-afs-1# rpm -q pam_krb5 krbafs krbafs-devel

  2. Modify /etc/krb.conf and /etc/krb.realms

    • Modify /etc/krb.conf, add: CS.STANFORD.EDU CS.STANFORD.EDU cs-kdc-1.stanford.edu:88 CS.STANFORD.EDU cs-kdc-1.stanford.edu:749 admin server

    • Modify /etc/krb.realms, add: .CS.STANFORD.EDU CS.STANFORD.EDU

    • Modify pam stacks: /etc/pam.d/login should look like:

      #PAM-1.0 auth required /lib/security/pam_securetty.so auth optional /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so auth sufficient /lib/security/pam_krb5afs.so use_first_pass ignore_root account required /lib/security/pam_stack.so service=system-auth account sufficient /lib/security/pam_krb5afs.so use_first_pass ignore_root password required /lib/security/pam_stack.so service=system-auth password sufficient /lib/security/pam_krb5afs.so use_first_pass ignore_root session required /lib/security/pam_stack.so service=system-auth session optional /lib/security/pam_krb5afs.so session optional /lib/security/pam_console.so

  3. Change other pam setups as necessary. To enable KDE, I’ve had to modify /etc/pam.d/kde and to enable graphical login screens, I’ve had to change /etc/pam.d/gdm

    • d. Temporary work-around to bypass LDAP for now: At this point, we still don’t have ldap running. Therefore, the system has no way of looking up uid/gid for a given username. This will make logins fail. To bypass this problem, temporarily create a regular unix account, miles. I will undo this later on, when LDAP is ready to go. cs-afs-1# groupadd -g 600 staff cs-afs-1# useradd -d /afs/cs.stanford.edu/u/miles -g staff -u 9766 miles
    • e. All should be well: Try that users can log in and are placed in their home directories on AFS.
      1. Authenticating from the command line: From the command line, to switch identities (e.g. authenticate as regular user mehmet and gain access as the user), we need to do the following: cs-afs-1# kinit miles cs-afs-1# aklog

Mail setup using Exim

Cryus imap rpms: http://home.teleport.ch/simix/ S/Ident: http://www.eyrie.org/~eagle/software/sident/

  1. Setup SASL on the mail server:

    Add to /etc/sysconfig/saslauthd:

    MECH=kerberos5

  2. Create host/hostname principal in kerberos:

    kadmin addprinc -randkey host/csmail-test.stanford.edu

  3. Add the host/hostname principal keys to keytab on the mail server:

    csmail-test# kadmin ktadd -k /etc/krb5.keytab host/csmail-test.stanford.edu

  4. Create cyrus kerberos principal, with a known password. This will be used for Cyrus administration.

  5. Turn on and start saslauthd:

    csmail# chkconfig saslauthd on csmail# service saslauthd start

  6. Install Cyrus IMAPd from RPMS

    rpm -ivh cyrus-imapd-2.1.15-1.i386.rpm rpm -ivh cyrus-imapd-utils-2.1.15-1.i386.rpm perl-Cyrus-2.1.15-1.i386.rpm

  7. Edit /etc/imapd.conf, add the line

    altnamespace: yes

  8. Edit /etc/syslog.conf, add the line

    local6.* /var/log/cyrus.log

  9. Start Cryus IMAPd

    chkconfig cyrus-imapd on service cyrus-imapd start

  10. Check to make sure you can connect to the server as the user cyrus:

    cyradm –user cyrus localhost

  11. Create a user mailbox:

    cm user.miles

  12. Try checking mail on the server via imap.

  13. Setup Exim (see instructions elsewhere).

  14. Comment out “check_local_user” in /usr/exim/configure under the ’localuser’ router. Also, set the transport to cyrus_socket.

  15. Add this to /usr/exim/configure, somewhere in the transports section:

    cyrus_socket: driver = lmtp command = “/usr/lib/cyrus-imapd/deliver -l” batch_max = 20 user = cyrus

    cryus_lmtp: driver = smtp protocol = lmtp hosts = localhost allow_localhost

  16. Mail should now work for any users who have a mailbox.

  17. Install SquirrelMail and prerequisites from RPMs:

    apt-get install php httpd rpm -ivh squirrelmail*rpm chkconfig httpd on service httpd start

  18. Configure Squirrelmail by running /usr/share/squirrelmail/config/conf.pl. Change these options:

    Select 2\. Server Settings
    Select A. Update IMAP Settings
    Select 8\. Server software, change to cyrus
    Select 9\. Delimiter, change to . (a period)

    Select R to return to main menu

    Select 3\. Folder Defaults
    Select 1\. Default Folder Prefix, change to none

    Select Q and save

  19. Setup SpamAssassin. See instructions elsewhere, but basically run

    apt-get install perl-CPAN export LANG=en_US perl -MCPAN -e ‘install Mail::SpamAssassin’

  20. Install MySQL:

    apt-get install mysql-server php-mysql chkconfig mysqld on service mysqld start

  21. Setup the spamassassin database:

    mysql -u root create database sa; CREATE TABLE userpref ( username varchar(100) NOT NULL, preference varchar(30) NOT NULL, value varchar(100) NOT NULL, prefid int(11) NOT NULL auto_increment, PRIMARY KEY (prefid), INDEX (username) ) TYPE=MyISAM;

    grant all privileges on sa.* to 'sa'@'%' identified by 'password';
grant all privileges on sa.* to 'sa'@'localhost identified by 'password';

  22. Make sure you can login to mysql by running ‘mysql -u sa -p sa’.

  23. Modify /etc/mail/spamassassin/local.conf (probably a globally distributed file, check first) with the DB info:

    user_scores_dsn DBI:driver:database:hostname[:port] user_scores_sql_username dbusername user_scores_sql_password dbpassword user_scores_sql_table tablename

  24. Modify /etc/init.d/spamassassin (copied from another system) to start spamd with the ‘-d -a -x -q’ flags.

  25. Install the SquirrelMail plugin. Unpack the SASql tarfile from squirrelmail.org into /usr/share/squirrelmail/plugins

  26. Follow readme file instructions; Basically, edit sasql_conf.php:

    $SqlDSN = 'mysql://sa:PASSWORD@localhost/sa';
    $SqlTable = 'userprefs';
  1. Enable plugin in SquirrelMail.

References

Revision History

$Log: index.html,v $
Revision 1.7  2003/09/03 23:18:49  miles
Added Exim+SA+SquirrelMail+Cyrus IMAP instructions.

Revision 1.6  2003/07/02 20:58:59  miles
Added shell script I'm working on to check to see if a principle exists in batch

Revision 1.5  2003/06/17 19:42:03  miles
Added user instructions

Revision 1.4  2003/06/12 20:21:36  miles
Added instructions for second AFS server

Revision 1.3  2003/06/10 20:14:44  miles
Added instructions for setting up slave KDCs, reformatting.

Revision 1.2  2003/06/05 23:38:47  miles

Docs, docs, and more docs.

Revision 1.1.1.1  2003/05/30 20:31:59  miles
Starting CSD KerberosV / AFS project

  1. http://www.openafs.org ↩︎ ↩︎

← prev next →