This page has instructions for users, background info, and instructions for admins. There is a separate page for user examples

For earlier info, see version 61.

2010/09

Machines, keys and tickets are split into "old" and "new" worlds.

The old world was forced to use only "DES cbc mode with RSA-MD5", so "klist -k -e /etc/krb5.keytab" generated output such as

KVNO Principal
---- --------------------------------------------------------------------------
   4 nfs/sur.cl.cam.ac.uk@AD.CL.CAM.AC.UK (DES cbc mode with RSA-MD5) 
   4 host/sur.cl.cam.ac.uk@AD.CL.CAM.AC.UK (DES cbc mode with RSA-MD5) 

The new world offers a number of types, e.g.

Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   5 host/sur.cl.cam.ac.uk@AD.CL.CAM.AC.UK (DES cbc mode with CRC-32) 
   5 host/sur.cl.cam.ac.uk@AD.CL.CAM.AC.UK (DES cbc mode with RSA-MD5) 
   5 host/sur.cl.cam.ac.uk@AD.CL.CAM.AC.UK (ArcFour with HMAC/md5) 
   5 host/sur.cl.cam.ac.uk@AD.CL.CAM.AC.UK (AES-256 CTS mode with 96-bit SHA-1 HMAC) 
   5 host/sur.cl.cam.ac.uk@AD.CL.CAM.AC.UK (AES-128 CTS mode with 96-bit SHA-1 HMAC) 
   5 nfs/sur.cl.cam.ac.uk@AD.CL.CAM.AC.UK (DES cbc mode with CRC-32) 
   5 nfs/sur.cl.cam.ac.uk@AD.CL.CAM.AC.UK (DES cbc mode with RSA-MD5) 
   5 nfs/sur.cl.cam.ac.uk@AD.CL.CAM.AC.UK (ArcFour with HMAC/md5) 
   5 nfs/sur.cl.cam.ac.uk@AD.CL.CAM.AC.UK (AES-256 CTS mode with 96-bit SHA-1 HMAC) 
   5 nfs/sur.cl.cam.ac.uk@AD.CL.CAM.AC.UK (AES-128 CTS mode with 96-bit SHA-1 HMAC) 

The old world worked with MIT versions before 1.8, but in order to "discourage" people from using weak crypto such as DES, in 1.8 they changed things. allow_weak_crypto  cahnged to default to false. When set to true, NFS sec=krb5 worked, but other authentication did not. This code was put into distributions around 2010/04, so Ubuntu 10.04, Fedora 12 and later releases do not work in the Lab.

A new script is being used to generate keytabs, which allows machiens using adsrv01 to use other types.

User Setup

To permit ssh access to a machine which doesn't have a kerberos ticket (e.g. an alien, home or college machine), a local copy of the user's ssh key has to be stored on the machine. To do this on systems using the patches mechanism (e.g. Redhat) use "cl-update-authorized-keys" or "cl-asuser cl-update-authorized-keys" or on SUSE systems use "sudo /usr/local/bin/update-authorized-keys".

User Use

To access file space, a valid ticket is required. When logging on at the console of a machine, a side effect of checking the user password is to generate a kerberos ticket, which can be inspected using the klist command. If there is no valid ticket, a new one can be generated using kinit.

The lifetime of the ticket generated at login by pam is set by the the maximum value of the ticket_lifetime or renew_lifetime settings in the [libdefaults] section of /etc/krb5.conf, or if none is set, the settings in the pam section of the [appdefaults] section. The kinit command can have the value set on the command line using the -l or -r flags, defaulting to the [libdefaults] value. As of 2009/03, the server imposes a maximum lifetime of ten days.

The ticket initially lasts for 10 hours, but can be "refreshed" up to the ticket lifetime using "kinit -R". Tools such as krenew can be used to automate this refreshing, and some will attempt to generate a new ticket if the old one expires.

User Problems

remote ssh access

ssh access from "local" machines should work by forwarding the local ticket as an authorisation token. Windows machines need the quest version of PuTTY to use GSSAPI-with-MIC, which users should be able to install from the SCCM / SMS "available programs" window (see also "Control Panel -> Get Programs -> Install program" and on 64b machines "View 32bit control panel items". It is also available at \\didcot\swdist\putty\).

However, machines without a valid ticket have to use ssh user keys. The called machine has to check whether the key is permitted by looking in the AuthorizedKeysFile file as defined in /etc/ssh/sshd_config. However, as this defaults to .ssh/authorized_keys and thus lives on the user's home directory, it cannot be accessed as the user doesn't have a ticket for $HOME.

To circumvent this, use update-authorized-keys to make a local copy of the key, or use an ssh tunnel to get a ticket. To do the latter, make a copy of a Lab /etc/krb5.conf but set the kdc and admin_server to localhost:8888 for AD.CL.CAM.AC.UK in the [realms] section. Then arrange to portforward localhost:8888 to one of the Lab server KDCs using

ssh -N -f -o TCPKeepAlive=yes -L 8888:kdc:88  $CRSID@ssh-relay.cl.cam.ac.uk

assuming that the user has $CRSID. kdc.cl.cam.ac.uk has a round robin A RR set, so if one of the KDCs is not working it may be necessary to open a new ssh connection (and hope it picks a working one) or select an explicit server (typically called adsrv0<N> - see windows servers for details or use "hosts -t ptr kdc.cl.cam.ac.uk" for a hint). kinit can then be used to create a ticket.

If the called host doesn't have a valid ticket (use-K with the ssh connection to forward a local one), use kinit to generate one to allow access to the filer if needed.

remote ssh access examples

Here are some example uses. The -oPreferredAuthentications=* flags should not normally be needed, but ensure that the expected mechanisms are used.

Note that $HOST may need to be the canonical name for kerberos to work, e.g. slogin-serv7 rather than slogin-test-krb5 in this case:

$ host slogin-test-krb5
slogin-test-krb5.cl.cam.ac.uk is an alias for slogin-serv7.cl.cam.ac.uk.
slogin-serv7.cl.cam.ac.uk has address 128.232.0.78
slogin-serv7.cl.cam.ac.uk mail is handled by 99 mail-reject.cl.cam.ac.uk.
$

For services with multiple servers, try doing a "ptr" loookup:

$ host -t ptr slogin-cos
slogin-cos.cl.cam.ac.uk is an alias for slogin-cos5.cl.cam.ac.uk.
slogin-cos5.cl.cam.ac.uk domain name pointer slogin-serv2.cl.cam.ac.uk.
slogin-cos5.cl.cam.ac.uk domain name pointer slogin-serv8.cl.cam.ac.uk.
$ 

gdm auto WM selection

When the user has been selected at the X console, gdm looks to see which window manager should be used, and sets the default session type accordingly in the pulldown list. However, if no valid ticket is availale from an earlier connection, access to $HOME fails, so the system default is used. If the user default is different, the selected session should be checked before performing the login.

cron and at jobs may have problems

cron or at jobs should run fine if they do not need to use NFS, e.g. use the internet and local disc. If the user logs in each week to get a new ticket, and runs krenew, it should work. However, if the job requires NFS access and the user may not refresh the ticket each week, consider setting up a cron job on cron-serv* machines.

If possible, for resilience, setup jobs on more than one server, to run out of step with each other. Consider file locking to ensure only one instance is running if appropriate. If a timestamp file is used, whichever crond runs the script after the next due time will cause it to run.

long running jobs have problems

If a long running job is accessing the filer, when the ticket expires, the job will fail.

The local command cl-krenew can be used to arrange that a ticket is renewed, allowing normal ssh user key access. See "cl-krenew -h" for further details.

Use klist to check the expiry and renew times, and "ps x | grep krenew" to check that an instance such as "krenew -b -K 10" is running to keep renewing the ticket.

setgid commands accessing NFS files do not work as expected

e.g. cl-personal-www-log

Kerberos Servers

There were experiments using Unix servers, but now only the Active Directory AD.CL.CAM.AC.UK realm on kdc.cl.cam.ac.uk is used.

Some clients (WXP, Netapp) can only easily use one KDC.

The current full server is a WXP implementation of Kerberos, running as part of a Windows Domain on replicated Active Directory servers. It is used by Windows users to authenticate logins and CIFS access to the file servers, and by most Linux users to login (and at some point get NFS access to the file servers).

There are extensions and limitations of this server. Limitations include not having numeric userID and Posix groups. There has been a request to have these added, but it didn't happen, so (what??)

A requirement for users to login to the Unix world using Kerberos is that the account in the Active Directory exists and is enabled. This can be checked directly in the AD use the Users and Computer MMC snapin or via the managment front end database https://dbserv.ad.cl.cam.ac.uk/SCG/UserAdministration.aspx, the account usage field should be 512, the '2' bit (0x0002) indicates a disabled account, the '16' bit (0x0010) that the account has been locked out by an excessive number (currently 15) of attempts with a bad password. This latter fault will clear in 30 minutes. If the account does not have the '512' bit (0x0200) set then it is not a valid account for authentication.

Tickets

The tickets generated are a merge of the limits set by the server and the options requested by the client. Linux client defaults are in /etc/krb5.conf in the pam section of [appdefaults], e.g.

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

(this appears to have no effect under F9 or SUSE 10.3. Setting ticket_lifetime (or renew_lifetime!) in [libdefaults] sets the lifetime). As of 2009/03 the server restricts tickets to be renewable up to 10 days (to allow weekly manual creation of tickets), with an initial period of ten hours.

They are typically stored in /tmp/ with the prefix krbcc_ followed by the numeric userid (root uses krb5cc_machine_AD.CL.CAM.AC.UK or such like so long as the machine has a valid /etc/krb5.keytab). To allow "per session" keys (e.g. GSSAPICleanupCredentials in /etc/ssh/sshd_config determines whether the ticket is removed on logout) a 'random' suffix is added, e.g. /tmp/krb5cc_104_N3vXuM, and the environment variable KRB5CCNAME is set to the location, e.g. KRB5CCNAME=FILE:/tmp/krb5cc_104_N3vXuM. This allows command started by the shell to locate its session's ticket.

As NFS traffic doesn't know about the shell variable of the calling programme, it relies on a root command such as rpc.gssd to look in all the files in /tmp (by default) for user tickets.

Client service uses

Below are the client uses (login and NFS Sec RPC), and systems which support them (WXP, SuSE, RH/FC/Fedora and debian/Ubuntu)

Login

Most managed Windows and Linux systems now use KRB5 for user login. Some machine are "standalone" and use /etc/passwd.

NFS Secure RPC

This is used on some SUSE systems and is being tested on some Redhat systems.

There are some problems with acccess before a suitable ticket is available (and others in the User Problems section).

ssh accessing authorized_keys

ssh logins from outside the Lab cannot normally use gssapi, so are instead based on ssh user keys. By default this requires sshd to access ~/.ssh/authorized_keys (or ~/.ssh/authorized_keys2), which will fail without a suitable ticket. By editing /etc/ssh/sshd_config to set AuthorizedKeysFile (or the undocumented AuthorizedKeysFile2) to refer to a local filesystem, a user can at least login (to run kinit).

The update-authorized-keys command can be used to copy the user key into /var/spool/ssh/$USER/ allowing a system (e.g. SUSE boxes) to have "AuthorizedKeysFile /var/spool/ssh/%u/authorized_keys", which restricts ssh user key access to those users thus registered.

To allow anyone to be able to install a local authorized_keys without needing root access, AuthorizedKeysFile can be set to something like /local/scratch/%u/.ssh/authorized_keys instead.

Both these systems mean that users who have a valid ticket but no ~/.ssh/authorized_keys, will be unable to login.

It is likely that any two of the above methods can be used by setting AuthorizedKeysFile and AuthorizedKeysFile2 appropriately.

If more than two are needed "AuthorizedKeysFile /var/ssh/%u/authorized_keys" can be used where /var/ssh1 is an autofs union filesystem, e.g.

sudo bash -c "echo /var/ssh /etc/auto.ssh >> /etc/auto.master"
sudo bash -c "echo '*       -rw,nosuid,noac,bg,vers=3,tcp,timeo=600,rsize=32768,wsize=32768,hard,intr :/var/spool/ssh/& :/local/scratch/&/.ssh elmer:/vol/userfiles/&/unix_home/.ssh' > /etc/auto.ssh"
cl-asuser autofs restart

ssh X forwarding

As with ssh user key auth above, ssh X tunneling uses xauth to forward a capability which is normally stored in .Xauthority in $HOME. However, as xauth uses the XAUTHORITY variable for the file location2, and as ssh can forward certain variables, it can be arranged that the capability is stored in a local filesystem. Add "AcceptEnv XAUTHORITY" to /etc/ssh/sshd_config, allowing users use xon with a suitable flag, or

ln -s ~/.Xauthority /tmp/${USER}_Xa
XAUTHORITY=/tmp/${USER}_Xa ssh -X -oSendEnv=XAUTHORITY $host

ssh using gssapi-with-mic

Linux systems which have a suitable host/$host.cl.cam.ac.uk @AD.CL.CAM.AC.UK principal in /etc/krb5.keytab can be connected to if the caller has a suitable ticket and GSSAPIAuthentication is set (default on Redhat, not on SUSE or debian) for the calling ssh programme. Without forwarding the ticket, it can be used to login to a remote machine without NFS $HOME (and thus X11 forwarding) and run kinit to create a ticket.

If the remote sshd accepts an XAUTHORITY by having "AcceptEnv XAUTHORITY" in /etc/ssh/sshd_config, an alternative path (e.g. in /tmp/) can be passed, allowing X forwarding to work even without write access to $HOME. The "-tx" flag to cl-xon can be used to use this method.

If the ticket is forwardable ("F" flag in klist -f output) and GSSAPIDelegateCredentials is set (default not) in the ssh programme (or the -K flag is set), then the ticket is forwarded (delegated) allowing sec=krb5 access to NFS $HOME (and thus X11 forwarding, e.g. if cl-xon is passed the -K flag).

Testing

At various stages it's possible to test that things are working

Sample Errors

Sample errors are:

Client system uses

The plan is that user WSs and most servers move to using krb5 access to the filer, although there are a few which need sec=sys

WXP - login and CIFS

SUSE - login and NFS for some machines

Using Lab managed opensuse Linux -> Remote logins describes how to setup ssh user key based access.

In /etc/sysconfig/autofs set

DEFAULT_MASTER_MAP_NAME="auto_master"

DEFAULT_MAP_OBJECT_CLASS="automountMap"
DEFAULT_ENTRY_OBJECT_CLASS="automount"
DEFAULT_MAP_ATTRIBUTE="automountMapName"
DEFAULT_ENTRY_ATTRIBUTE="automountKey"
DEFAULT_VALUE_ATTRIBUTE="automountInformation"

(the DEFAULT_ prefix has been dropped, but still works)

Fedora - local and ssh login and NFS for some machines

The users credentials are cached in a file settable using the environment variable KRB5CCNAME defaulting to /tmp/krb5cc_$userid, e.g. /tmp/krb5cc_104. If ssh delegates credentials, the filename of the form is /tmp/krb5cc_$userid_$random, e.g. /tmp/krb5cc_104_jFxuI14099.

Fedora comes with kernels which can hold per user credentials so it should be possible to use NFS over Secure RPC (V3 or V4).

If multiple KDCs are used, KRB5CCNAME must be used to select the cache so that they don't trample each other. Note that the file should be on a local file system.

Setting a machine to use sec=krb5 NFS

The user can apply the "safe" patches as described above, then an admin can remove "sec=sys" access and add the user to wheel.

The individual steps, identified by their patch file names, are:

P-sysconfig-nfs-krb5

rpc.gssd needs to be started. This needs the line SECURE_NFS=yes in /etc/sysconfig/nfs to ensure it starts. It also needs a /etc/krb5.keytab which can be setup and checked

-bash-3.2$ sudo klist -k -t /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   2 07/14/08 09:30:56 host/add.cl.cam.ac.uk@AD.CL.CAM.AC.UK
   2 07/14/08 09:30:56 nfs/add.cl.cam.ac.uk@AD.CL.CAM.AC.UK
-bash-3.2$

The patch edits /etc/sysconfig/nfs to have SECURE_NFS="yes". Arrange to have rpcgssd running

cl-asuser chkconfig rpcgssd on
cl-asuser service rpcgssd start

If it fails with

Starting RPC gssd: can't open libgssapi_krb5.so: libgssapi_krb5.so: cannot open shared object file: No such file or directory
rpc.gssd: Unable to obtain list of supported mechanisms. Check that gss library is properly configured.

rpc.gssd: Problem with gssapi library 

then cd to /usr/lib64 or /usr/lib as appropriate, and "sudo ln -s libgssapi_krb5.so.2 libgssapi_krb5.so". (OR: maybe tweak /etc/gssapi_mech.conf ??)

To test manual mounting using sec=krb5, try "sudo mount -o sec=krb5 elmer:/vol/userfiles/pb22/unix_home /mnt".

P-auto.master-krb5

There is a separate LDAP schema to access "sec=krb5" entries (rather than the old HACK 3). Edit /etc/auto.master to "+auto_master" (rather than +auto.master). It should not be necessary to uncomment the Sun Schema lines in /etc/sysconfig/autofs

MAP_OBJECT_CLASS="automountMap"
ENTRY_OBJECT_CLASS="automount"
MAP_ATTRIBUTE="automountMapName"
ENTRY_ATTRIBUTE="automountKey"
VALUE_ATTRIBUTE="automountInformation"

Access a FS, type "mount" and look for "sec=krb5" in the mount options.

If all works, add NFS_krb5 to the host's properties in hosts.props, and its "sec=sys" NFS access to elmer will be removed.

P-sshd_config-krb5

A user without a ticket will get "Permission denied" from df

-bash-3.2$ ls /usr/groups/linux
ls: cannot open directory /usr/groups/linux: Permission denied
-bash-3.2$ df /usr/groups/linux
Filesystem           1K-blocks      Used Available Use% Mounted on
df: `/Nfs/Mounts/sys-li1': Permission denied
-bash-3.2$ kinit
Password for pb22@AD.CL.CAM.AC.UK: 
-bash-3.2$ df /usr/groups/linux
Filesystem           1K-blocks      Used Available Use% Mounted on
elmer:/vol/vol3/sys-li1
                      52428800  38526488  13902312  74% /Nfs/Mounts/sys-li1
-bash-3.2$ 

Set AuthorizedKeysFile in /etc/ssh/sshd_config and export XAUTHORITY as above as appropriate.

P-krb5.conf-krb5 (CentOS only)

On a CentOS 5.2 system, starting rpcgssd logs in /var/log/messages lines such as "gss_kerberos_mech: unsupported algorithm 23" (Windows defaults to RC4) and "Failed to write downcall!". To fix this, in the "[libdefaults]" section of /etc/krb5.conf, add

default_tkt_enctypes = DES-CBC-CRC
default_tgs_enctypes = DES-CBC-CRC

and restart rpcgssd

Possible SELinux problem

SELinux appears not to want various file accesses, so it may be necessary 4 even if "setsebool -P allow_gssd_read_tmp=1" (which appears not to work) has been set, to load modules, such as the ones in /usr/groups/linux/ownfiles/add/selinux-cl/CLgssd*.pp.

F9 NFS works (add, greta)

Works having configured as above.

CentOS 5.2 NFS works with krb5.conf tweak (ramsey, towy)

With the P-krb5.conf-krb5 patch, it works

FC6 NFS works (starquake)

rt#72424 asked for NFS sec=krb5 on starquake which I assumed would fail as F8 failed. However, having added a keytab and uncommented 'SECURE_NFS="yes"' in /etc/sysconfig/nfs and started gssd, a manual sec=krb5 mount worked.

Having set 'OPTIONS=" -O sec=krb5" in /etc/sysconfig/autofs and commented out the /home HACK in /etc/auto.master, restarting automount caused it to correctly use sec=krb5.

/usr/groups/linux/ownfiles/Diffs/starquake-sec=krb5.diff has the "ownfiles" diff.

F8 NFS fails (whittlesford) OLD

OLD entry: "sec=krb5" mounts work, but users cannot access the files.

F12 problems with weak keys

Between 1.6 and 1.8 MIT changed the default for allow_weak_crypto from true to false causing (at least) NFS to fail. Setting it in /etc/krb5.conf causes NFS sec=krb5 to work.

Remaining problems:

debian - local and ssh login and NFS

To make autofs use "sec=krb5" add " -O sec=krb5" to "OPTIONS" in /etc/default/autofs and uncomment it.

U10 problems with weak keys

Between krb5-user 1.6 and 1.8 MIT changed the default for allow_weak_crypto from true to false causing (at least) NFS to fail. Setting it in /etc/krb5.conf causes NFS sec=krb5 to work.

Remaining problems after getting a new keytab:

Temp HACK: Use cl-update-authorized-keys (or otherwise) to make a local copy of your permitted public keys, thus allow ssh user key login. Having logged in, use kinit to get a ticket.

Mount Filer via CIFS on aliens domain or other non-Lab Unix machines

Using SSH and Kerberos. Install Kerberos on the target machine (package 'krb5-user' on Debian/Ubuntu). Take a copy of /etc/krb5.conf from a Lab machine and copy it into /etc on the target. Change it so that you have:

[realms]
 AD.CL.CAM.AC.UK = {
  kdc = localhost
  admin_server = localhost
 }

Then do something like the following:

sudo mkdir /mnt/homes-6
sudo ssh -N -f -o TCPKeepAlive=yes -L 88:kdc.cl.cam.ac.uk:88 -L  139:elmer.cl.cam.ac.uk:139 $LABUSER@slogin-serv1.cl.cam.ac.uk
sudo kinit $LABUSER
sudo smbmount "\\\filer\homes-6" /mnt/homes-6 -o krb,ip=127.0.0.1,fmask=700,dmask=700,uid=$LOCALUSER,gid=$LOCALUSER

(later systems may need "file_mode=0700,dir_mode=0700"). Replace $LABUSER with your lab CRSID and $LOCALUSER with the local user on the alien machine. Note that under NetApp's implementation of CIFS symbolic links can be read but not created.

Firefox

Firefox can be used in at least two ways

Firefox NTLM

gt says that NTLM can be used to access dbserv by authenicating the user.

Firefox delegation

Open about:config and filter on network.n to check that network.negotiate-auth.trusted-uris allows SPNEGO (defaults to https://), then set network.negotiate-auth.delegation-uris to a comma separated list of URIs. Restart firefox. It should then be possible to access dbwebserver and access the database using the forwarded ticket.

Creating a keytab

create 'DES+' keytab

Pro tem, manually create it on the server, or contact win-admin. Set "kdc = kdc.cl.cam.ac.uk" in /etc/krb5.conf. While elmer is still using DES, put "allow_weak_crypto = true" in /etc/krb5.conf.

For existing accounts the userAccountControl value needs to be reset to remove the "USE_DES_KEY_ONLY" setting. If you are going to generate a new keytab then this value is reset as part of the keytab generation process.

To create a new keytab for either an existing or a new host as a Domain Administrator login to adsrv01.ad (may need to use mstsc on a Windows box). Select Start, double click on "Command Prompt" or (type "cmd" in the search box if it's not there), and select "Open". Then use either of the equivalent command lines

cscript C:\scripts\keytab_cmd.vbs host/foo.cl.cam.ac.uk;nfs/foo.cl.cam.ac.uk
cscript C:\scripts\keytab_cmd.vbs foo

with your host name substituted for foo. The keytab will be written to the file named like /auto/groups/admin/kerberos/keytabs/hostFoo. Copy that file to the machine foo and ensure it is mode 0400, e.g. on an omnipotent server using the command

cd /usr/groups/admin/kerberos && sudo ./copykeytab2host foo

or on the machine itself

cl-onserver --keytab

If there are issues with the keytab then you may need to look for duplicated names in the Active Directory. There is a script called querySPN which is run as follows:-

cscript.exe c:\scripts\querySPN.vbs *foo*

which may be of help in debugging.

In addition if you want to check the key version number then you can do so by opening the properties of the user account for the machine (eg nfsAln). Click on the Attribute Editor tab. Then clcik on the Filter button (bottom right of the displayed attributes) and tick Constructed. Then scroll down to msDS-KeyVersionNumber and read the value.

To change the userAccountControl attributes manually either use the script which can take either a single Unix hostname or a comma separated list of principals

cscript.exe c:\scripts\setUserAccountControl hostFoo,nfsFoo
cscript.exe c:\scripts\setUserAccountControl foo

or modify the Active Directory as follows:-

User "Start -> Administrative Tools -> Active Directory Users and Computers", select "View -> Advanced Features". Open "ad.cl.cam.ac.uk", Left click on krb5ServicePrinicals}}}", and either delete both hostName and nfsName entries, or double click on them, select Atrribute Editor, and change userAccountControl from 0x200220 to 0x220 so that "USE_DES_KEY_ONLY" is no longer set, otherwise it will only ever use DES3.

For machines with aliases, use ktutil to merge the keys. Note that wkt appends to the existing file, so to add a key, simply "rkt $newfile" then "wkt /etc/krb5.keytab". To remove any keys, use delent, then write a new file and rename it as /etc/krb5.keytab.

Footnotes

  • 1 the path /var/ssh for the mount point is mostly arbitrary, but should be permitted by SELinux

  • 2 xauth enforces suitable access restrictions, so XAUTHORITY can point at /tmp

  • 3 autofs can be told to add "sec=krb5" to the information it gets from LDAP by setting OPTIONS="-O sec=krb5" and APPEND_OPTIONS="yes" in /etc/sysconfig/autofs

  • 4 SELinux problems can be disgnosed by running "cl-asuser setenforce 0", trying again, then "cl-asuser setenforce 1" to reenable it

SysInfo/Kerberos (last edited 2012-09-22 06:52:54 by PieteBrooks)