Getting SLAC AFS tokens at a Remote Site

Contents

Why is klog being turned off?

SLAC is moving to using the more secure kerberos 5 protocol and a separate program to obtain AFS tokens. At SLAC this is combined in one program since we us the heimdal version of kinit. Remote sites can still get AFS tokens but if they use the default RHEL3 based rpms will need to install and configure two separate programs, kinit and aklog.

Using kinit and aklog from remote sites

Kerberos 5 uses two different means to locate the authentication servers, the first is via DNS SRV records. If this is enabled at your site you should be able to use these commands

	kinit userid@SLAC.STANFORD.EDU
	aklog -c SLAC.STANFORD.EDU

Note: upper case is required, realm names are case sensitive, but in general are all upper case for historical reasons. If you are using kerberos 5 at your site, you will probably want to put the SLAC credentials into a different file. You can use the environmental variable KRB5CCNAME to do this

	env KRB5CCNAME=/tmp/my.slac.tgt kinit userid@SLAC.STANFORD.EDU

Then use aklog to obtain a token.

	env KRB5CCNAME=/tmp/my.slac.tgt aklog -c SLAC.STANFORD.EDU

If the above method does not work at your site, please see the Problems and work-arounds section.

Installing kinit and aklog

Problems and work-arounds

"unable to reach any KDC in realm"

• Edit the /etc/krb5.conf file on your machine and change these two lines.

  dns_lookup_realm = false
  dns_lookup_kdc = false
  

  to pre

  dns_lookup_realm = true
  dns_lookup_kdc = true 
  

• If this is not allowed at your site, you should ask the local administrator to include this stanza in the [realms] section of your krb5.conf

  SLAC.STANFORD.EDU = {
        kdc = k5auth1.slac.stanford.edu:88 k5auth2.slac.stanford.edu:88 k5auth3.slac.stanford.edu:88
        master_kdc = k5auth1.slac.stanford.edu:88
        admin_server = k5admin.slac.stanford.edu
        kpasswd_server = k5passwd.slac.stanford.edu
        default_domain = slac.stanford.edu
       }

  If that is not possible, then get a copy of /etc/krb5.conf from any SLAC machine and use the environmental variable KRB5_CONFIG to specify that kerberos should use that conf file.

  env KRB5_CONFIG=/tmp/slac.krb5.conf kinit userid@SLAC.STANFORD.EDU

  env KRB5_CONFIG=/tmp/slac.krb5.conf aklog -c SLAC.STANFORD.EDU

kinit works but aklog doesn't.

This is due to older versions of OpenAFS that don't fully implement kerberos 5. We recommend OpenAFS 1.4.4 or later versions of aklog. You can either copy over the version of aklog from /usr/afsws/bin/aklog or install a new version of OpenAFS. The latter is highly recommended as there are significant improvements in the 1.4.x versions of OpenAFS. Using addressless tickets can also help with this problem. You can check this by using

klist -a

kinit -A userid@SLAC.STANFORD.EDU

Java version of kinit

Versions 1.4 and 1.5 of java contain a kinit program that is largely broken. The fix is to either change your $PATH variable to have the MIT kinit path come first or turn off the execute bit on the kinit program. Java version 1.6 appears to not have this executable. It would be a good idea to do the same for the java version of klist in the same directory as well.

Reference

Man pages for the kinit and aklog commands

man -M /usr/kerberos/man kinit

Kerberos and OpenAFS information elsewhere