Andrew File System (AFS) is a distributed file system pioneered by Carnegie Mellon University as part of the Andrew Project. It has been a popular file sharing option (while being secure and efficient) in many academic institutes, including the Computer Sciences Department of UW - Madison, of which I am an alumni and hold a lifetime (hopefully) access to its AFS storage. This page that you are reading and my entire personal website reside on this file system. Normally, I would just use Notepad++ to develop my website over a FTP connection (using NppFTP) to a server which mounts the AFS system. That allows me to bypass the need to configure my own computer to directly mount the AFS system, which is not trivial. However, due to the recent outdated support of version control software on that server, I need to have my hands on the website files locally and use the version control software on my computer to track the site development. Although using a SFTP program to sync the AFS copy with a local copy would work, that requires manual operations for synchronization which I do not favor. There are also automatic synchronization programs, such as BitTorrent Sync, but they require installations on both ends and I definitely have no permission to install anything on the server that is connected to the AFS. Well, the question becomes, why not connect (or mount) the file system from my end? As a heavy Windows user, one cannot avoid learning through some official and non-official documents or blogs to get this done. I went through that head-shaking-and-nodding process and here comes my documentation for you to try.
A big picture is given below as our roadmap. In order to obtain the AFS service from an AFS server, one needs to communicate with the server in a secured way. AFS developers use the Kerberos communication protocol for AFS. Kerberos was originally developed by MIT for the Athena project. It is designed for the most vulnerable network environment, assuming neither the servers nor the clients are trustworthy. Only when a client and a service server hold matching credentials assigned by a third party (i.e., the Kerberos authentication server), they will trust each other (i.e., the mutual authentication). An in-depth tutorial of the Kerberos system can be found here for those of interests. As a result, one needs to install a Kerberos software layer to communicate to the authentication server to get the so called encrypted ticket and then hand it over to the AFS client for authentication with the AFS service server. Of course, due to mutual authentication, the AFS service server also needs a credential given by the authentication server to match the client's ticket, so it is trusted by the client. Normally, the AFS server and the authentication server are deployed by the same provider on different machines. The authentication server can also be a central node in charge of the authentication of other services the provider offers. In addition to the AFS client and the Kerberos software layer, the user might also find it handy to have a network identity manager program installed. Below are specific steps a user can follow to set up the client machine.
--------------------------
| network identity manager | authentication communication -------------------------------
-------------------------- ------------------------>| Kerberos authentication server|
| | | -------------------------------
----------- -------------- <------
| AFS client|<->|Kerberos layer|
----------- --------------
^
| service communication -----------
----------------------------------------------------------->| AFS server|
-----------
Here, I recommend using Heimdal's Kerberos as your Kerberos layer, which is recommended by the OpenAFS software that we will install later. You can also use the MIT's version. The Heimdal Kerberos can be downloaded at the Secure Endpoints website: https://www.secure-endpoints.com/heimdal/. When you have the .msi installation file for your processor type downloaded, simply run it and follow the wizard to complete the installation.
Once you are done, you might want to look into the configuration file of Heimdal Kerberos, which normally resides in the folder [System Drive]:\ProgramData\Kerberos\ and is named "krb5.conf", while the file name may be changed according to a future release of Kerberos. This file contains plain text that specifies parameters that the Kerberos layer will use. For this tutorial, I won't be able to get into the details of the file content, but assume that you will be able to get help from your AFS service provider on correctly setting it up. Just as an example, below is the configuration given by the staff from the CS Department of UW - Madison for their Kerberos system.
[libdefaults]
default_realm = CS.WISC.EDU
default_tgs_enctypes = des-cbc-crc rc4-hmac
default_tkt_enctypes = des-cbc-crc rc4-hmac
default_keytab_name = /etc/v5srvtab
krb4_config = /s/krb4/lib/krb.conf
krb4_realms = /s/krb4/lib/krb.realms
ticket_lifetime = 2592000
renew_lifetime = 2592000
allow_weak_crypto = yes
forwardable = true
[realms]
CS.WISC.EDU = {
kdc = kerberos.CS.WISC.EDU:88
kdc = kerberos-1.CS.WISC.EDU:88
kdc = kerberos-2.CS.WISC.EDU:88
kcrap = kerberos.CS.WISC.EDU:49288
kcrap = kerberos-1.CS.WISC.EDU:49288
kcrap = kerberos-2.CS.WISC.EDU:49288
admin_server = kerberos.CS.WISC.EDU
default_domain = CS.WISC.EDU
}
AD.CS.WISC.EDU = {
kdc = bunyan.ad.cs.wisc.edu:88
kdc = babe.ad.cs.wisc.edu:88
}
[domain_realm]
.cs.wisc.edu = CS.WISC.EDU
cs.wisc.edu = CS.WISC.EDU
.stat.wisc.edu = CS.WISC.EDU
stat.wisc.edu = CS.WISC.EDU
ad.cs.wisc.edu = AD.CS.WISC.EDU
[appdefaults]
afs_krb5 = {
CS.WISC.EDU = {
afs = false
afs/cs.wisc.edu = false
}
}
pam = {
minimum_uid = 1
forwardable = true
ccache_dir = /var/adm/krb5/tmp/tkt
afs_cells = cs.wisc.edu
keytab = /etc/v5srvtab
external = true
krb4_use_as_req = false
krb4_convert_524 = false
force_pag = true
use_shmem = true
}
If you install the MIT Kerberos in the first step, the Network Identification Manager is already included. Otherwise, it is available via Secure Endpoints at https://www.secure-endpoints.com/netidmgr/v2/.
For AFS client, OpenAFS is recommended just because it is free and functioning and I am not aware of any other better AFS client. Installers are provided at http://www.openafs.org/windows.html and 64-bit Windows users must use two .msi installers to complete the installation. I recommend a complete installation option when prompted. For the default cell field during the installation process, type in whichever AFS server address your provider gives you. When you are done, restart you machine.
When the machine restart, the AFS client and the Network Identity Manager should already be running. You will see their trays downright (a yellow lock and a man shadow containing box). Clicking either will bring up the same Network Identity Manager window. For the first time, the AFS client may be running without any connection to the AFS server (with a red cross over its tray), simply because you haven't obtained the corresponding Kerberos ticket. To get a ticket, in the Network Identity Manager window, go to "Options>Identities>Identities>Add new identity" and type in your username and the Kerberos realm name given by your provider (which is normally the capitalization of the AFS cell name. Then, click "Finish." Restart your Network Identity Manager and you should see your new identity listed above "My Keystore". Right click your new identity and obtain new credentials. Follow the prompts and type in your password, you should be on the way. When you see your AFS client tray without a red cross, you can use the Windows Explorer to navigate to your AFS drive using the address: \\afs\[the AFS cell name]\[path to your target directory]\. You can also map this path to a particular Drive letter on your machine for easy access.