[OpenAFS] aklog: unable to obtain tokens for cell folkvang.org (status: 11862791).
Kevin
openafs@gnosys.biz
Tue, 10 Feb 2004 00:36:56 -0500
Hi All-
I'll apologize in advance for a long post, but after spending 3 days with
this project now, I figured that more detail was better than less in
asking for assistance.
I'm trying to get up and running from scratch with an OpenAFS 1.2.11
system authenticating against an MIT Kerberos 5 v1.3.1 system. Based
upon having seen many strong recommendations that when starting from
scratch, I should not use kaserver but rather MIT Kerberos, I'm trying to
do just that. Problem is, severe lack of current documentation. I've
even seen this lamented by others elsewhere.
I recently reported build problems with version 2 (from March 2003) of Ken
Hornstein's migration kit with 1.2.11 of OpenAFS and 1.3.1 of MIT
Kerberos 5, and Jeffrey Hutzelman noted that the errors were limited to
the afs2k5db (which I wouldn't need for a 'from-scratch install') and
suggested that I just hack as necessary to build the executables that I
really need for starting from scratch with OpenAFS v1.2.11 and MIT
Kerberos 5 v1.3.1.
So I started doing that by just removing afs2k5db from the PROGS variable
in the Makefile (after configuring as Ken suggests in his README). That
was near completion I think, but it failed, apparently because it can't
find a library. The error message was:
adam@zeus:~/kafs/afs-krb5/src> make
gcc -o aklog aklog.o aklog_main.o aklog_param.o krb_util.o linked_list.o
adderrtable.o -L/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib -lkrb5
-lk5crypto -lcom_err -lresolv -lkrb524 -L/usr/local/lib
-L/usr/local/lib/afs -lsys -lprot -lubik -lauth -lrxkad -lrx -llwp -ldes
-lsys /usr/local/lib/afs/util.a
/usr/lib/gcc-lib/i586-suse-linux/3.3.1/../../../../i586-suse-linux/bin/ld:
cannot find -lkrb524
collect2: ld returned 1 exit status
make: *** [aklog] Error 1
adam@zeus:~/kafs/afs-krb5/src>
So it seemed to be looking for a krb524 library, and in my newly built
(and functional) 1.3.1 Kerberos system, I don't have such a library.
Guessing that the code that used to be in this library is now in some
other library (probably already linked against in the build attempt), I
just renamed the krb524 library in the Makefile to krb5 and tried again.
That got me past this problem and gave me an executable binary for
asetkey and aklog (which I think is all I need...), although the rest of
the build failed.
Unfortunately, I'm still having problems, so I've come up with a list of
questions:
1) Has anyone built Ken's AFS-MIT Kerberos 5 migration kit lately? Clues
on how to do it with current sources for OpenAFS and MIT Kerberos?
2) My key stumbling block is in the subject header: Ken's aklog apparently
won't get me a token. So my very general question about that is: how do
I fix it... Sorry I can't be more specific, but maybe if I explain what
I've done already.
What I've done (BTW, this is a SuSE 9 distro):
1) Built and tested MIT Kerberos 5 v1.3.1. I can kinit as a principal and
use the TGT to get a host ticket and telnet into the kdc itself running
the MIT Kerberos telnetd with -a valid arguments and with kerberos ticket
for authentication (no passwd challenge). The configure line for this
build was:
./configure --enable-dns --enable-dns-for-kdc --enable-dns-for-realm
--enable-kdc-replay-cache --enable-shared # --with-afs
On Ken's recommendation (in his README), I tried using the commented out
--with-afs option to configure, but the make failed when I did so, so I
commented it out and the make worked. There is no --with-afs option
mentioned when I do a ./configure --help, so maybe it's gone now?
2) Built OpenAFS and have some of the code running. Configure line for
this build was:
./configure --with-afs-sysname=i386_linux24 --enable-transarc-paths
--with-linux-kernel-headers=/usr/src/linux-include/default/
3) Read (and think I understand) all of Ken's docs (README, THEORY, et.
al.)
4) Followed docs from openafs.org website (quick start), specifically:
#Installing the First AFS Machine
# Requirements and Configuration Decisions
# Overview: Installing Server Functionality
# Choosing the First AFS Machine
# Creating AFS Directories
# Performing Platform-Specific Procedures
# Getting Started on Linux Systems
# Loading AFS into the Linux Kernel
# Configuring Server Partitions on Linux Systems
# Starting the BOS Server
# Defining Cell Name and Membership for Server Processes
# Starting the Database Server Processes
# Initializing Cell Security
except that where appropriate above, I followed Ken's docs from his README
and also the notes I found at
http://grand.central.org/twiki/bin/view/AFSLore/?topic=KerberosAFSInstall
and
http://www.arayan.com/da/yazi/OpenAFS_Kerberos_5.html
and
http://www-2.cs.cmu.edu/afs/andrew.cmu.edu/usr/shadow/www/afs/afs-with-kerberos.html
and
https://lists.openafs.org/pipermail/openafs-info/2003-July/010159.html
My krb5.conf file is:
=============================
adam@zeus:~/kafs/afs-krb5/src> cat /etc/krb5.conf
[libdefaults]
default_realm = DUMMY.ORG
clockskew = 300
[realms]
DUMMY.ORG = {
kdc = kerberos.dummy.org:749
admin_server = kerberos.dummy.org
kpasswd_server = kerberos.dummy.org
}
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log
# default = SYSLOG:NOTICE:DAEMON
# kdc = FILE:/var/log/kdc.log
# kadmind = FILE:/var/log/kadmind.log
[appdefaults]
# from http://grand.central.org/twiki\
# /bin/view/AFSLore/?topic=KerberosAFSInstall
afs_krb5 = {
DUMMY.ORG = {
afs = false
afs/dummy.org = false
}
}
=============================
I have DNS CNAME records mapping kerberos.dummy.org to zeus.dummy.org (the
KDC and the first single OpenAFS server machine---will be running all
OpenAFS server processes).
My kdc.conf file is:
=============================
[kdcdefaults]
kdc_ports = 88,749,750
v4_mode = nopreauth
[realms]
DUMMY.ORG = {
database_name = /usr/local/var/krb5kdc/principal
admin_keytab = /usr/local/var/krb5kdc/kadm5.keytab
acl_file = /usr/local/var/krb5kdc/kadm5.acl
dict_file = /usr/local/var/krb5kdc/kadm5.dict
key_stash_file = /usr/local/var/krb5kdc/.k5.DUMMY.ORG
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
supported_enctypes = des3-hmac-sha1:normal \
des-cbc-crc:normal des-cbc-crc:v4
}
=============================
I made the afs server principal by
# kadmin.local
> addprinc -e "des-cbc-crc:normal des-cbc-crc:v4" \
afs/dummy.org@DUMMY.ORG
> ktadd -e "des-cbc-crc:normal des-cbc-crc:v4" \
afs/dummy.org@DUMMY.ORG
(I noticed that this removes the v4 salt key and makes it just a no-salt
encryption type, but guess that's ok...)
> getprinc afs/dummy.org
Principal: afs/dummy.org@DUMMY.ORG
Expiration date: [never]
Last password change: Tue Feb 10 00:04:50 EST 2004
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Tue Feb 10 00:04:50 EST 2004 (adam/admin@DUMMY.ORG)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 2, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
> quit
# asetkey add 2 /etc/krb5.keytab afs/dummy.org@DUMMY.ORG
Ken says I can remove the key from the krb5.keytab now, and I've tried
doing this (removing it) and not doing it---no difference.
When I do a asetkey list, I see the key and checksum, and can see the new
file /usr/afs/etc/KeyFile.
I then followed the guidance at twiki, specifically:
"Create a user ("joe/admin" in this example) using the appropriate kadmin
utility with your KerberosV distribution. Set a secure password, and note
that setting Kerberos admin rights for this user does not affect his AFS
rights. Please note, that "joe/admin@REALM" is KerberosV notation and
that KerberosIV? is using "joe.admin@REALM". As AFS is based on
KerberosIV?, you should specify "joe.admin@REALM" or just "joe.admin". (I
did this mistake recently and for days was hunting for an explanation,
why while having valid tickets, valid AFS tokens with proper kvno (key
version number as the one in Kerberos KDC) fileserver, ptserver and
bosserver complain about my AFS token being invalid. Yes, I had in
the /usr/(afs|vice)/etc/UserList file "joe/admin@REALM"). In
OpenAFS-1.2.8, you can possibly enable Kerbero5 syntax for usernames (See
this message to openafs-devel)"
I tried with the / for the instance separator and with the .
When I do an aklog -d, it seems to want the joe.admin form, so left it at
that.
then did
pts createuser -name joe.admin -cell greekmythology.com -noauth
pts adduser joe.admin system:administrators -cell -noauth
(with my names of course)
# ./pts membership adam.admin -cell dummy.org -noauth
Groups adam.admin (id: 1) is a member of:
system:administrators
and then
bos restart <machine name> -all -cell <cell name> -noauth
I also followed along in the Quick Start Guide for this part and saw that
it was pretty similar.
So now I authenticate as the admin user (adam/admin in my case), klist
shows the tgt. Then I just run:
# aklog
(I don't need any modifiers/options on the command line?)
That gives me:
aklog: unable to obtain tokens for cell dummy.org (status: 11862791).
So I tried:
# aklog -d
which gives me:
Authenticating to cell dummy.org (server zeus).
We've deduced that we need to authenticate to realm DUMMY.ORG.
Getting tickets: afs/dummy.org@DUMMY.ORG
About to resolve name adam.admin to id in cell dummy.org.
Id 1
Set username to AFS ID 1
Setting tokens. AFS ID 1 / @ DUMMY.ORG
aklog: unable to obtain tokens for cell dummy.org (status: 11862791).
zeus:/usr/afs/bin #
Now when I do a:
# klist
I see:
zeus:/usr/afs/bin # /usr/local/bin/klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: adam/admin@DUMMY.ORG
Valid starting Expires Service principal
02/10/04 00:19:01 02/10/04 10:19:01 krbtgt/DUMMY.ORG@DUMMY.ORG
renew until 02/11/04 00:19:01
02/10/04 00:19:17 02/10/04 10:19:01 afs/dummy.org@DUMMY.ORG
renew until 02/11/04 00:19:01
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
So I do have the ticket, but I guess it's not getting converted into a
token? Or not getting stored in the kernel? How do I check for the
presence of the token in the kernel?
#lsmod | grep afs
shows
libafs-2.4.21-144-default 444384 0 (unused)
Does it matter that the bosserver is still running in -noauth mode? None
of the docs have asked me to change this so I left it.
Do I need to run fakeka from MIT (or from Ken)?
I have krb524 running:
#ps aux |grep krb
root 4401 0.0 0.1 2708 1192 ? S Feb09
0:00 /usr/local/sbin/krb5kdc
root 4404 0.0 0.1 2672 1116 ? S Feb09
0:00 /usr/local/sbin/krb524d -m
and
#ps aux |grep kadmind
root 4406 0.0 0.1 2524 1136 ? S Feb09
0:00 /usr/local/sbin/kadmind
The kerberos logs don't show much interesting. It seems to be working
properly from the kerberos perspective. The OpenAFS logs don't show much
of anything happening.
If I look at Ken's theory, it looks like the process is failing here > <
So with these things known, here's a list of things that would happen
if you authenticated to AFS using Kerberos 5:
- User runs "kinit" or logs in via a Kerberos 5 login, and enters a
password.
- A Kerberos 5 ticket-granting ticket is requested from the KDC.
- The KDC sends you a TGT, encrypted with your secret key.
- Your password is converted to an encryption key. Note that the
string-to-key function used is dependent on the salt type returned by
the KDC.
- The key generated above is used to decrypt the TGT.
- The TGT is written into a file in /tmp, and "kinit" or "login" exits.
- User runs "aklog".
- Aklog takes the user's TGT out of the file in /tmp, and sends a request
for an AFS ticket (using the previously mentioned TGT).
- An AFS ticket is sent back, encrypted with the TGT session key.
>>>>>>>>>> <<<<<<<<<<<
- Since this is a V5 ticket, send it to a Kerberos 5 to 4 daemon to have
it converted to a V4 ticket (you cannot convert it yourself, since it
needs to be encrypted with the AFS server key, which you do not know).
- Take the converted V4 ticket and store it in the kernel to be used by
the AFS Cache Manager.
If anyone needs any other info to help, please let me know and I'll
provide it.
And since the problem of current documentation seems to be such a problem,
if I can get this problem solved, I hereby make this solemn promise to
the group: I will do this whole thing again, keeping detailed written
notes, and from those, write comprehensive docs for this subject and post
and/or distribute as needed so that the problem is not a problem anymore.
Many thanks in advance for any help.
Best regards,
Kevin