OpenAFS and Kerberos on Windows

Software prerequisites

• Kerberos for windows. The current release of OpenAFS 1.7.4 recommends the Heimdal Kerberos implementation. Apparently MIT Kerberos for windows isn't really updated any longer by MIT though Secure Endpoints, Inc has released a 64-bit version and updated Identity Manager. I have also used MIT Kerberos successfully with an older release of OpenAFS but have not tried it in combination with the current release. Here is a comparison along with download links for 64 and 32 bit versions: https://www.secure-endpoints.com/heimdal/
• Network Identity Manager - it provides the interface to manage your credentials (tickets) and also has a keystore feature which allows for you to obtain credentials to several kerberos domains with one local authentication (for example, you might have identities in CERN.CH, ATLAS.UMICH.EDU, and UMICH.EDU required to access AFS locations at those institutions). Download here: https://www.secure-endpoints.com/netidmgr/v2
• OpenAFS for windows. Download a 32 or 64 bit version as appropriate. 64-bit users should download the 32-bit tools package as well. http://openafs.org/windows.html
• The current recommended release of Putty supports GSSAPI authentication. This will work on some UM ATLAS systems and for login to CERN systems (there are issues with kerberos on multi-homed hosts so I don't think it works for the interactive machines where it would be most useful). Since Putty is 32-bit, requires 32-bit Kerberos even on 64-bit systems. http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Procedure

Heimdal Kerberos

1. Run Installer program with defaults. If 64-bit windows be sure and install 32-bit components (should be default).
2. There won't be any visible indication of software installation - no icons, no start menu links. Heimdal will show up in the "uninstall programs" control panel as usual. In a command shell you can obtain tickets with "kinit" and AFS tickets with "aklog" as well as destroy tickets with "kdestroy" (after setting up configuration file below). You can also run "klist" but it did not show me any tickets even when I definitely had them. I prefer to install NIM to manage tickets.
3. Copy into place c:\ProgramData\Kerberos\krb5.conf. The attached krb5.conf will work. The attached file is nearly the same as the krb5.conf from any UM-ATLAS machine with the addition of "allow_weak_crypto = true" under [libdefaults] to be able to obtain AFS tokens in this particular application. Additionally, logging directives pointing to unix directories are removed (though safely ignored if in file) and references to private networks removed from [domain_realm] section. This file will enable you to obtain tickets from UM, UM-ATLAS, CERN, BNL, FNAL, and CITI.
4. Install Network Identity Manager

MIT Kerberos (deprecated, prefer Heimdal with current versions of OpenAFS)

1. Install 32-bit Kerberos for Windows. I recommend choosing yes to autostarting network identity manager. If you don't want to be prompted every time your tickets expire, deselect "ensure kerberos tickets are available throughout windows session".
2. 64-bit users install 64-bit Kerberos for windows. Be sure and install 64-bit version last in order.
3. Install Network Identity Manager
4. Replace c:\windows\krb5.ini with attached krb5.conf file. This will enable you to obtain tickets from UM, UM-ATLAS, and CERN.

OpenAFS

1. Install OpenAFS. Choose to install the IFS client. You may wish to do a custom installation and install the Client Configuration Tool (control panel applet).
2. I recommend you do not enable integrated login for laptop systems which may not always be on the network. If you do I recommend using the AFS Client Configuration control panel to reduce timeouts and login retries. For other systems, if your local login password matches your Kerberos password you could use this feature to obtain AFS credentials at the same time as system logon but I personally recommend not doing this. For information check http://www.openafs.org/dl/openafs/1.7.4/winxp/ReleaseNotes/html/ch03s06.html.
3. On 64-bit Windows also install the 32-bit AFS tools package.
4. Restart your system.
5. Continue setting up Network Identity Manager below...

Setting up Network Identity Manager

NOTE: I will be calling Network Identity Manager "NIM" from this point.

NOTE: It is not required to install NIM to obtain Kerberos and AFS credentials though I find it most convenient. From the Windows command shell ("cmd") you can type "kinit" and "aklog" the same as you would on a unix system. In my experience "klist" does not show any credentials but I was able to verify that credentials were obtained in the NIM GUI.

Network Identity Manager Keystore

The Network Identity manager installed during this process includes a "keystore". When setting up new identities you can choose to save the passwords in this keystore. By doing so you will be able to obtain kerberos credentials for all of your identities by entering the keystore password. There will be a checkbox for this option when you add new identities.

NOTE: The keystore does not work. No identities will be saved in it and it will not appear to ever save any password you set for it. You will be prompted to set the password every single time you select to save a credential. Directions regarding it are mentioned below and I encourage other users to try it and report if you have any success. If it does not appear to save your identities then you can ignore the keystore. To remove the keystore entirely after installation go to the "Programs and Features" control panel (aka "Add or Remove Programs" in Windows XP) and choose to change the Network Identity Manager installation. Remove the Keystore feature there. You can also choose not to install it during the initial installation. Disabling the plugin from the NIM options caused NIM to lock up or consume large amounts of memory on my system - recommend to uninstall the feature if you want to disable it.

Create New Identities

Network Identity Manager will be visible in your system tray by default. It is also available from the Start menu. It looks like this when open:

1. Open the menu Options -> Identities:
   
   

2. NOTE: On the "Kerberos v5" tab under global identity settings you should adjust ticket lifetimes to your preference before creating any identities. The krb5.conf file which is attached to this twiki specifies a 30 day lifetime but only the ATLAS.UMICH.EDU realm will grant tickets with a lifetime this long. Others will give tickets with the default 10 hour lifetime unless you change the defaults. UMICH.EDU and CERN.CH seem limited to a day or two at most.
3. Click on "Add New Identity" and enter your username and kerberos realm in the window that comes up. It may not be in the dropdown list. Possible realms with our configuration file are: ATLAS.UMICH.EDU, CERN.CH, UMICH.EDU, CITI.UMICH.EDU, FNAL.GOV, USATLAS.BNL.GOV. You may have identities in several of these. Most UMATLAS users will have identities for the first three in this list.
   
   
   
   
   

4. Repeat this action for additional realms
5. For each identity, click on that identity in the list on the left side of the identity options window. Go to the AFS tab, make sure that \x93Obtain AFS Credentials\x94 is checked and the cell name is \x93atlas.umich.edu\x94. Then Click the Add/Update button. It may already be in the list without requiring any action if it is the default AFS cell configured during AFS setup.
   
   

6. Click OK
7. In the main NIM window select View -> All Identities (if you have configured more than one).
8. Click on an identity to select it. Either from the right-click context menu or with the button at the top choose to "Obtain New Credentials":
   
   

9. Enter your password and check the "Save Password in My Keystore" if you wish to save the password there (as noted above, this did not ever work for me). If you have only one identity, there is no reason to save your password in the keystore since you will still have to enter the keystore password - it would not save you any time to store the kerberos password.
10. The first time you try to use it, you will be prompted to set a keystore password.

Accessing/Mapping AFS drives

1. AFS locations are accessed using the \\afs windows path. For example: \\afs\atlas.umich.edu\home\myname. If there are RO and RW replicas and you need to access the RW volume: \\afs\.atlas.umich.edu (not necessary for home volumes).
2. To write to any AFS location you will need to obtain Kerberos AFS tokens as described above.
3. In any explorer window or from Start->Run in windows XP or the search box in windows 7: \\afs\atlas.umich.edu for example.
4. To map a drive to a permanent drive letter in windows XP from Windows Explorer: Tools -> Map Network Drive. Enter a path as above, choose a drive letter.
5. To map a drive to a permanent drive letter in Windows 7 click on Computer in Windows Explorer. Map Network Drive will be a menu choice at the top of the window

More about Windows and Kerberos

Windows has some form of Kerberos natively built-in though it is apparently not possible or not obviously documented how to use this functionality to obtain AFS tickets or for programs such as Putty to utilize Windows Kerberos credentials. It is possible for a Windows workstation to authenticate to a non-Windows KDC. I haven't really explored the native windows Kerberos but here is a useful link for those who might be interested:

http://www.h5l.org/manual/HEAD/info/heimdal/Useful-links-when-reading-about-the-Windows.html#Useful-links-when-reading-about-the-Windows

OpenAFS and Kerberos on Linux

Kerberos configuration

NOTE: These are just some rough notes from an email responding to a question on this issue. Please let me know if you want to setup your personal system and have any other questions. In particular, DO NOT verbatim follow what I said about the system-auth config without some further research on the issue. It might be right, it might be wrong, and if you break system-auth you can't login anymore. You can start in single-user mode if you do break it.

'>> The main thing you need is an /etc/krb5.conf file with setups for all the
'>> realms you want to authenticate to. One copied from one of our
'>> interactive machines (umt3intXX) should work, or most desktops too.
'>> At that point without doing anything further you can "kinit
'>> myname@CERN.CH" (or ATLAS.UMICH.EDU, or UMICH.EDU). You can change
'>> the default realm in krb5.conf and then if you just type "kinit"
'>> that's the one it uses. Tickets for CERN.CH would let you ssh into
'>> machines there without password. "aklog" is additionally required for
'>> AFS authentication.
'>>
'>> Getting tickets at login is done by some lines in /etc/pam.d/system-auth:
'>> auth sufficient /lib/security/pam_krb5.so use_first_pass tokens
'>> account [default=bad success=ok user_unknown=ignore]
'>> /lib/security/pam_krb5.so
'>> password sufficient /lib/security/pam_krb5.so use_authtok
'>> session optional /lib/security/pam_krb5.so
'>>
'>> The combination of those ends up authenticating you to whatever is the
'>> default kerberos realm in /etc/krb5.conf. You could check any of our
'>> machines for a complete file. The only issue is you would be tied to
'>> our kerberos system to authenticate your laptop. I think if you
'>> create a local account then it can fall back to that if kerberos isn't
'>> available ("sufficient", not "required" for the pam_krb5 lines...a
'>> full file would include also a reference to pam_unix being sufficient
'>> - that is the local account password).
'>>
'>> The major difference with having both a local auth and kerberos auth
'>> is that you'll want the kerberos auth to come first in your
'>> system-auth file. That way the local account won't come into effect
'>> before pam_krb5 has a chance to collect tokens.

SSH client configuration

Here is a sample ssh_config that will enable kerberos ssh logins to all hosts. You need "GSSAPITrustDns yes" in your ssh_config file to login to CERN lxplus or svn systems because those are actually gateways to other hosts. In this sample it is enabled for all hosts but you can also add a separate host section for *.cern.ch for example.

Host *
        GSSAPIAuthentication yes
        GSSAPITrustDns yes
        # remote X11 clients will have full access to the original X11 display. As virtually no X11 client supports the untrusted mode correctly we set this to yes.
        ForwardX11Trusted yes

You can add this either to /etc/ssh/ssh_config system-wide or ~/.ssh/ssh_config per-user.

-- BenMeekhof - 17 May 2011