%META:TOPICINFO{author="JosephHVilas" date="1109197863" format="1.0" version="1.21"}% ---+ Installing Kerberos & AFS %TOC% AFS includes its own implementation of Kerberos, the KAServer. However, new installs of KAServer are not recommended as it is based on a draft version of the obsolete Kerberos 4 protocol. Even though AFS doesn't support KerberosV directly, it is highly recommended that you set up a KerberosV realm for your AFS cell and *not* install the KAServer. See KerberosV for the many advantages of using the latest Kerberos for your network authentication. Note that this document is under development. Also, I don't try to explain the OpenAFS specific parts of the install -- This document describes only the changes that have to be made to create a new OpenAFS cell with KerberosV authentication. If you have followed these instructions and are still having problems please email the openafs-info mailing list. Derrick wrote nice pages at: http://www.cs.cmu.edu/afs/andrew.cmu.edu/usr/shadow/www/afs/afs-with-kerberos.html http://www.contrib.andrew.cmu.edu/~shadow/afs/afs-with-kerberos.html Main.DenizKanca [[https://lists.openafs.org/pipermail/openafs-info/2003-January/007799.html][posted]] her notes at http://www.arayan.com/da/yazi/OpenAFS_Kerberos_5.html. Main.JeffreyHutzelman posted a good [[https://lists.openafs.org/pipermail/openafs-info/2003-July/010159.html][summary]] of all these component to OpenAFS-info on 25-Jul-2003. Be sure to check to follow-ups for some minor clarifications. ---++ Basics To continue, you need a working Kerberos realm. See SettingUpAuthentication for the implementation options, and refer to the documentation that comes with your particular version of Kerberos to establish your realm. It is easiest if your realm name is the caps version of your cell name, which in turn is the same as your site's domain name. For example if your site's domain is 'greekmythology.com', your Kerberos realm name should be 'GREEKMYTHOLOGY.COM' and your AFS cell name should be 'greekmythology.com'. See KerberosTerms if you are confused on what a "realm" is. Once you have a working Kerberos realm, ie. you can "kinit" as yourself and receive valid Kerberos tickets, you are ready to continue on installing OpenAFS. (NOTE: If you are working on the Red Hat Linux platform, there is an RPM available that may ease your pain considerably. See LinuxAFSInstall.) ---++ OpenAFS ---+++ Starting the Install Now we will begin the OpenAFS installation. The relevant part of the OpenAFS documentation can be found at [[http://www.openafs.org/pages/doc/QuickStartUnix/auqbg005.htm#HDRWQ17][OpenAFS installation documentation]]. Follow the instructions in [[http://www.openafs.org/pages/doc/QuickStartUnix/auqbg005.htm#Header_32][Creating AFS Directories]] and begin the [[http://www.openafs.org/pages/doc/QuickStartUnix/auqbg005.htm#HDRWQ20][Platform Specific Procedures]] as appropriate for your operating system. *SKIP* the "Enabling AFS Login" section of your operating system's instructions. Also note that you may need to reboot during this procedure (particularly on Solaris). Now you are ready to continue on to [[http://www.openafs.org/pages/doc/QuickStartUnix/auqbg005.htm#HDRWQ50][Starting the BOS Server]] (... someone want to chime in here and explain how one can use pt_util etc to do this part without running in -noauth??). Proceed to [[http://www.openafs.org/pages/doc/QuickStartUnix/auqbg005.htm#HDRWQ51][Defining Cell Name]]. During the [[http://www.openafs.org/pages/doc/QuickStartUnix/auqbg005.htm#HDRWQ52][Starting Database Servers]] section, *do not* issue the ==bos create== command to add the kaserver. ---+++ Create AFS Keys and Administrators First you will need to create a principal "afs" or "afs/greekmythology.com" in your KerberosV database. The latter is the preferred alternative, especially if you will support more than one [[AFSCell]] with a single KerberosRealm. In case you have KerberosIV, create afs or afs.greekmythology.com respectively. Your KerberosV realm must support krb524 for aklog to work, typically. In other words, it has to be able to respond to your version 4 requests (as AFS is based on KerberosIV protocol). Next we will create an AFS KeyFile and an administrator principal in the Kerberos database. The procedure for creating an AFS KeyFile depends on which Kerberos implementation you have chosen to use, but the logic is the same. Things to remember about AFS KeyFile: they must contain a key using the des-cbc-crc encryption type and the key must have exactly same kvno as the afs/greekmythology.com@GREEKMYTHOLOGY.COM in the Kerberos database. If cell is same as lowercased GREEKMYTHOLOGY.COM name, you can create afs@GREEKMYTHOLOGY.COM instead of afs/cell@GREEKMYTHOLOGY.COM. ---++++ KerberosVMIT * set up krb524d. You will need to make sure your krb524d server host includes something like this in krb5.conf. Only one of the 2 entries should be needed for a realm, depending on how you did the setup in your KerberosV database. [appdefaults] afs_krb5 = { REALM.NAME = { afs = false afs/cell.name = false } } * use ==kadmin get== command and ==ktutil copy== similarly as described in section Heimdal to create afs key in a database or use for the last step instead of ktutil ==asetkey== as below * The AFS-Kerberos5 migration kit includes a program ==asetkey== Save the AFS key from kerberos KDC to a file, possibly using kadmin(see KTH KerberosIV section above), and the use either ==asetkey== or use ==ktutil== (see HeimdalKTH section below) to convert the format and save into KeyFile. asetkey add 0 /etc/srvtab.afskey afs.cell@REALM The `0' above means kvno (key version number 0). Use ktutils list or similar like ==kadmin get== command to see, what kvno has the afs key in Kerberos database. Use exactly same number when running ==asetkey==. There's ---++++ HeimdalKTH * http://www.pdc.kth.se/heimdal * kdc will service krb524 requests * edit /etc/krb5.conf similar to the example below [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [ktutil] dns_lookup_realm = false dns_lookup_kdc = false [libdefaults] dns_lookup_realm = false dns_lookup_kdc = false ktype_is_etype = true encrypt = yes forward = yes srv_lookup = no srv_try_txt = no srv_try_rfc2052 = no default_realm = GREEKMYTHOLOGY.COM clockskew = 300 kdc = 127.0.0.1 v4_instance_resolve = true krb4_get_tickets = yes forwardable = true v4_name_convert = { host = { rcmd = host ftp = ftp } plain = { something = something-else } } [realms] GSF.DE = { kdc = 127.0.0.1 admin_server = 127.0.0.1 krb525_server = 127.0.0.1 v4_name_convert = { ftp = ftp pop = pop rcmd = host } v4_instance_convert = true default_domain = greekmythology.com } [domain_realm] .greekmythology.com = GREEKMYTHOLOGY.COM greekmythology.com = GREEKMYTHOLOGY.COM [kadmin] kdc = # you can disable fallback DNS queries, if don't have registered name like kerberos.yourdomain dns_lookup_realm = false dns_lookup_kdc = false default_keys = v4 v5 afs3 afs-cell = greekmythology.com v4-realm = GREEKMYTHOLOGY.COM [kdc] enable-kerberos4 = true afs-cell = enable-524 = true v4-realm = GREEKMYTHOLOGY.COM The HeimdalKTH distribution's ==ktutil== can copy directly into an AFS KeyFile and removes salt from keys kadmin --admin-server=my_kdc_server kadmin> add --random-key afs/cell kadmin> del_enctype afs/cell@REALM des3-cbc-sha1 kadmin> get afs/cell@REALM kadmin> list * kadmin> ext -k /etc/afskeytabfile.krb5 kadmin> quit ktutil -k /etc/afskeytabfile.krb5 list ktutil copy FILE:/etc/afskeytabfile.krb5 AFSKEYFILE:/usr/afs/etc/KeyFile After you have a working KeyFile installed in the appropriate directory (/usr/afs/etc/KeyFile for transarc-paths, ???? otherwise) and with the appropriate permissions (0600, owner root), we can create administrative users for AFS. This is a two step process as we first create an authentication principal in the Kerberos database then add the admin user in the authorization ("protection") database in the AFS server. 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) ---++++ KTH Kerberos4 * http://www.pdc.kth.se/kth-krb : You can create afs key using "kadmin add", you had to specify password on interactively. That's quite weak password. Much better is to do ==kadmin get==. ==kadmin== will try to download the key from KDC, and if it's not present, it will create one, using random key. That's what we want. ksrvutil(1) does similar and doesn't require from you to have kadmind(1) running on your machine. The "get" command does same: downloads or (in our case) creates new afs principal using random password. The next example expects that joe.admin is you and you know the proper password to get full access to you kerberos database: mv /etc/srvtab /etc/srvtab.orig /usr/athena/sbin/ksrvutil -p joe.admin get Name [rcmd]: afs Instance [hostname]: greekmythology.com Realm [GREEKMYTHOLOGY.COM]: GREEKMYTHOLOGY.COM Is this correct? (y,n) [y] Add more keys? (y,n) [n] Password for joe.admin@GREEKMYTHOLOGY.COM # list keys in /etc/srvtab, look for the AFS key and it's kvno ksrvutil list mv /etc/srvtab /etc/srvtab.afskey mv /etc/srvtab.orig /etc/srvtab If you want to make the above more complicated, you will need ==/usr/athena/sbin/ext_srvtab== utility to extract already existing key from Kerberos KDC and save it into /etc/srvtab. It will ask you for your master kerberos password (but if you installed kerberos in the "proper" way, you've used random password which you don't know at all), so better use ==ksrvutil== as described above and forget ==ext_srvtab==. Now you should have the afs key in /etc/srvtab.afskey. Import this AFS key from Kerberos keyfile (/etc/srvtab format) into AFS /usr/afs/etc/KeyFile using ==asetkey== utility, which is I think from /afs/transarc.com/public/afs-contrib asetkey add 0 /etc/srvtab.afskey afs.greekmythology\.com@GREEKMYTHOLOGY.COM This KeyFile with the AFS-key you can just always re-copy to new AFS machines. Be sure that the key version number KVNO is always same in this KeyFile and in Kerberos database. On all these machines you of course need afs.hostname.REALM key loaded into their ==/etc/srvtab== (create them with =='/ust/athena/bin/ksrvutil get'==). You can test if you have same keys in kerberos and AFS like this: kauth username tokens If you have some tokens now, then it works and you can now shutdown kaserver. Users, which you have created under kaserver are stored in /usr/afs/db/kaserver.*, but you can just forget them. Create these users again in Kerberos. With KerberosIV from KTH they get stored under /var/kerberos, when using Heimdal under /var/heimdal/. ---+++ Finishing OpenAFS installation Now we will use the ==pts== command in OpenAFS to add this joe.admin user to the AFS administrators group named system:administrators. The username could be just "joe" or "admin", but it's a good habit to have .admin appended to it (it is called instance). Please note the notation "joe.admin", not "joe/admin" as would be typical in Kerberos5 style: pts createuser -name joe.admin -cell greekmythology.com -noauth pts adduser joe.admin system:administrators -cell -noauth where greekmythology.com is the name of your local cell. After your complete this step, you can continue on to... Activate the new AFS KeyFile by executing: bos restart -all -cell -noauth After this restart, try using kinit to get Kerberos tickets for admin then (if necessary) use aklog to get an AFS token or use afslog if afsd client cache is already running. Basically ensure that the AFS KeyFile is valid: /usr/heimdal/sbin/ktutil copy AFSKEYFILE:/usr/afs/etc/KeyFile FILE:/etc/afskeytabfile.krb5 /usr/heimdal/bin/kinit -k -t /etc/afskeytabfile.krb5 afs/greekmythology.com # you should be able to autenticate against KDC using the /etc/afskeytabfile.krb5 # where is saved your afs key in keytab form recognizable by Kerberos5 /usr/heimdal/klist # you should see you have afs/greekmythology.com ticket having some expiration time etc. Proceed to the [[http://www.openafs.org/pages/doc/QuickStartUnix/auqbg005.htm#HDRWQ60][Starting File Server]] section of the OpenAFS documentation. The rest of the documentation can be completed without any changes. (What about replacing NTP with something recent, though...? See FAQ [[AdminFAQ#NTP][3.22]] and [[FurtherReading#NTP][[NTP]]]) ---++ Setting up Transparent Login In its current state, you have to manually log into your AFS cell through kinit and possibly aklog (explain aklog..., debugging using "tokens" etc). There are several methods to enable transparent login to both local resources (the machine itself) and AFS through a single password. See KerberosV and SettingUpAuthentication for some information. The best option if you are using pam is probably the pam_krb5 project on sourceforge. -- Main.JasonGarman - 05 Feb 2002 -- Main.DerrickBrashear - 26 Nov 2002