[OpenAFS] W2K kdc and AFS saga continuing...

Christos Ricudis ricudis@itc.auth.gr
Tue, 8 Jul 2003 21:16:15 +0300


Here's what I succeeded so far to do in order to make a new AFS cell
to authenticate against a W2K KDC. When I finally finish the task, I 
will submit a wiki entry explaining the required steps in an almost  
disgusting level of detail - I think it might be useful in users 
trying this for the first time. 

I would like to thank Nathan Neulinger - I probably couldn't manage 
to get even that far without his help. 

-------------------------------------------------------------------


Setup : Two systems, one Windows 2000 Server with SP3 installed (hostname
konserba), and one Linux machine running Redhat 9 (hostname vermio)  

My test cell is lala.itc.auth.gr 

* I normally compile and install OpenAFS 1.2.9a. I proceed just to the
point BEFORE creating the admin and AFS principals using kas. I don't
delete the source code directory neither the dist/ directory, as they
will be used later on. 

* I obtain krb5-current.tar.gz from athena-dist.ai.mit.edu, 
Ken Hornstein's afs-krb5-2.0.tar.gz from grand.central.org, and Nathan 
Neulinger's umr.diff from /afs/umr.edu/software/krb5src/

* I untar krb5-current.tar.gz, and apply umr.diff

* I compile kerberos using the following options : 

./configure --with-afs=/home/ricudis/openafs-1.2.9a/i386_linux24/dest/ 
--with-krb4 --prefix=/usr/local/kerberos/ --enable-fakeka

* I perform the make and make install steps. Static kerberos builds are
rather large, so I strip the binaries in /usr/local/kerberos/bin/ and 
/usr/local/kerberos/sbin/ 

* I untar and compile afs-krb5-2.0.tar.gz. One note here. umr.diff
from Nathan Neulinger needs krb5-current, however NOT all of 
afs-krb5-2.0 compiles cleanly against -current. For my purpose, the
part that compiles seems just enough, so I don't bother too much. 

* I run configure in afs-krb5 src/ dir : 

./configure --with-krb5=/usr/local/kerberos/ --with-afs=/home/ricudis
/openafs-1.2.9a/i386_linux24/dest/ --with-krb5-src=/home/ricudis/krb5-
current/src/

* I edit the resulting Makefile, removing the afs2k5db, fakeka and 
keyfile_dump targets from line 64. fakeka is included in krb5-current
anyways, and I'm not concerned with migrating any existing databases 
(yet :/). I also modify line 46 of Makefile from 

KRB524LIB=-lkrb524

to 

KRB524LIB=-lkrb5

(libkrb524 is deprecated and its contents have been moved into libkrb5 
on -current). 

* I do make and make install steps

* I setup w2k, resource kit, active directory, etc. The active directory
domain is the same as my cell name, lala.itc.auth.gr

* Using AD "users and computers" tool, I create under the lala.itc.auth.gr
tree a new organizational unit container with name "Special Users" 

* I create a new user, "afs", with password OURAFSPASSWORD 

* I open a w2k command line window and give the following command : 

C:\> ktpass -princ afs/lala.itc.auth.gr@LALA.ITC.AUTH.GR -mapuser afs -pass OURAFSPASSWORD -out keytab.afs -kvno 0

* I move the keytab.afs file to the Unix machine

* I do 

asetkey add 0 /home/ricudis/keytab.afs afs/lala.itc.auth.gr@LALA.ITC.AUTH.GR

which succeeds. 

* using asetkey list I verify that the principal has been inserted
into the AFS keytab file. 

* I copy keytab.afs to /usr/local/kerberos/etc/krb5.keytab

* I create /usr/local/kerberos/etc/krb5.conf. I insert both hosts as 
KDCs



[libdefaults]
        default_realm = LALA.ITC.AUTH.GR
        default_keytab_name = /usr/local/kerberos/etc/krb5.keytab

[realms]

        LALA.ITC.AUTH.GR = {
                supported_enctypes = des3-cbc-raw:normal des3-cbc-raw:norealm des3-cbc-raw:onlyrealm des3-cbc-sha1:normal des3-cbc-sha1:norealm des3-cbc-sha1:onlyrealm des-cbc-crc:v4 des-cbc-crc:afs3 des-cbc-crc:normal des-cbc-crc:norealm des-cbc-crc:onlyrealm des-cbc-md4:v4 des-cbc-md4:afs3 des-cbc-md4:normal des-cbc-md4:norealm des-cbc-md4:onlyrealm des-cbc-md5:v4 des-cbc-md5:afs3 des-cbc-md5:normal des-cbc-md5:norealm des-cbc-md5:onlyrealm des-cbc-raw:v4 des-cbc-raw:afs3 des-cbc-raw:normal des-cbc-raw:norealm des-cbc-raw:onlyrealm des-cbc-sha1:v4 des-cbc-sha1:afs3 des-cbc-sha1:normal des-cbc-sha1:norealm des-cbc-sha1:onlyrealm
                default_domain = LALA.ITC.AUTH.GR
                kdc = vermio.itc.auth.gr
                kdc = konserba.itc.auth.gr
        }

[domain_realm]
        itc.auth.gr = LALA.ITC.AUTH.GR
        .itc.auth.gr = LALA.ITC.AUTH.GR

[logging]
        kdc = FILE:/usr/local/kerberos/log/krb5kdc.log
        admin_server = FILE:/usr/local/kerberos/log/kadmin.log
        default = FILE:/usr/local/kerberos/log/krb5lib.log


* I run krb524d : 

krb524d -k -t /usr/local/kerberos/etc/krb5.keytab

----------------------------------------------------------------------


And here are where actual problems start : 

* I create a user named test in the Active Directory and try to obtain
a TGT from w2k 

[root@vermio log]# krb524d -k -t /home/ricudis/keytab.afs -nofork &
[1] 12081
[root@vermio log]#
[root@vermio log]# kdestroy
[root@vermio log]# kinit test
Password for test@LALA.ITC.AUTH.GR:
[root@vermio log]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: test@LALA.ITC.AUTH.GR

Valid starting     Expires            Service principal
07/08/03 20:04:01  07/09/03 06:04:08  krbtgt/LALA.ITC.AUTH.GR@LALA.ITC.AUTH.GR
        renew until 07/09/03 20:04:01


Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

....which suceeds. And now I try to obtain an AFS token :  

[root@vermio log]# aklog -d -noprdb
Authenticating to cell lala.itc.auth.gr (server vermio).
We've deduced that we need to authenticate to realm LALA.ITC.AUTH.GR.
Getting tickets: afs/lala.itc.auth.gr@LALA.ITC.AUTH.GR
got kvno from file = 0
Not resolving name test to id (-noprdb set)
Set username to test
Setting tokens. test /  @ LALA.ITC.AUTH.GR
aklog: unable to obtain tokens for cell lala.itc.auth.gr (status: 11862791).
[root@vermio log]#

There I am, completely stuck. Any suggestions? 

BTW, isn't the KRB5 principal format supposed to be 
{service|username}/hostname@realmname? Why does aklog request an 
afs/realm@REALM ticket? Shouldn't that be afs/konserba.itc.auth.gr@LALA.ITC.GR 
for example?. It seems to make no difference if I create the windows keyfile for principal 
afs/konserba.itc.auth.gr@LALA.ITC.AUTH.GR, aklog still tries to get a token for 
afs/lala.itc.auth.gr@LALA.ITC.AUTH.GR, failing prematurely :>) 

Thank you very much, 

Christos Ricudis


-- 
Christos Ricudis				ricudis@itc.auth.gr
Systems Administrator				+30-2310-998305
IT Support Center
Aristotles University of Thessaloniki, GREECE