Home
Main website
Display Sidebar
Hide Ads
Recent Changes
View Source:
WinXP+Krb5+AFS
Edit
PageHistory
Diff
Info
LikePages
Getting WinXP to authenticate to a MIT [Kerberos5] KDC and use [AFS], all with single-sign-on, is not too difficult. However it does not appear to be completely (or correctly) documented anywhere. You will need a correctly configured Kerberos5 domain and AFS server, which is probably its own set of headaches. I haven't done that; it was already setup correctly. I simply connected a WinXP client. The OpenAFS network here is using Kerberos5 natively. There is no krb524 type things going on. Software I used: * WindowsXP Pro, service pack 2 * MIT Kerberos for Windows (KfW) 3.0 from [http://web.mit.edu/Kerberos/dist/index.html] * OpenAFS Windows client 1.4.2rc1 from [http://openafs.org/release/latest.html] * OpenAFS plugin for NetIDMgr from [https://www.secure-endpoints.com/] As of Sep 5 2006, new versions of KfW and the OpenAFS NetIDMgr plugin are available. You must always get the OpenAFS NetIDMgr plugin built for the version of KfW you are installing. The approach documented here is a very basic configuration with some caveats: * This does not use Active Directory (ldap), the client still needs a local user account * This cannot use NT roaming profiles The overall process: # Get WinXP to authenticate to MIT Kerberos5 domain # Installing and configuring MIT Kerberos; obtaining regular Krb5 tickets from the WinXP ones # Installing and configuring OpenAFS # Tieing it all together !!!Authenticating using Kerberos5 Some useful background reading, if you care: * [http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/kerbinop.mspx] * [http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/kerberos.mspx] * [http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.mspx] To authenticate your WinXP client against an external MIT Kerberos5 server, you need: * A user principal in the Kerberos domain (duh :)) * A host principal account in the Kerberos domain for the WinXP client * A local account on the WinXP client for the user The host principal (called a "machine account" by Microsoft) is needed by WinXP. If this is absent or incorrect, you cannot login. I'm not sure what WinXP uses the host prinicipal for; perhaps it is some form of mutual authentication, where WinXP uses the machine account to protect against a fake domain controller. The host principle ''must'' be encrypted with the __des-cbc-crc__ method; nothing else seems to work. Yeah, I know, its a ''really'' weak encryption method. If you want to use a random password (which is probably reccomended), make sure you write it down; you need to type this into the WinXP client too. This restriction on encryption methods applies ''only'' to the host principal; my own user principal is encypted with with __des3-cbc-sha1__ method, and that works just fine. The local account on the WinXP client is part of the odd "trust" relationship that ends up in place between the Kerberos5 domain and the WinXP client. The client maps the Kerberos principal to a local account for the purposes of file permissions, group membership, and so on. (The stuff typically kept in ldap). I added myself the "Administrators" built-in group, and did not worry about it; AFS enforces its own permissions. The host prinicipal is added using the <tt>kadmin</tt> tool like any regular Kerberos5 principal: <pre> kadmin q "addprinc -edes-cbc-crc:normal pw ''{passwd}'' host/''{fqdn}''" </pre> On the WinXP client, execute the following in a command prompt window: <pre> ksetup /setdomain ''{REALM}'' ksetup /setmachpassword ''{passwd}'' ksetup /mapuser * * ksetup /addkdc ''{REALM}'' ''{kdc}'' </pre> passwd: The host prinicipal password for the machine account fqdn: The fully-qualified domain name for the WinXP client. I've only tested a situation where the DNS domain is the same as the Kerberos domain, where the mapping is trivial. REALM: The Kerberos realm. These are typically all uppercase version of the the domain name. kdc: The DNS name of a KDC for ''{REALM}''. Using SRV records does not work correctly. The <tt>ksetup</tt> program has lots of options; you can see them all by using <tt>ksetup /h</tt>. Finally you must reboot your WinXP client. When it starts up again, you should hopefully have the option to login to your Kerberos realm. Even better, if you did everything right, it should work! Woohoo! !!!Installing KfW Next, you need to install KfW. The OpenAFS client for Windows cannot use the WinXP credentials directly; KfW will import the WinXP credentials into a traditional Kerberos5 ticket for regular Kerberos software, such as OpenAFS. The latest version (3.0) of KfW comes with a new pluggable framework called the "Network Identity Manager". The idea is that different packages or authentication schemes can install their own plugins into the NetIDMgr; then the user can manage all of their credentials from a single place. Personally I find it very quirky. However, once configured, it will grab your WinXP credentials and convert them into regular Kerberos5 ones. Unfortunately, I find that is the only useful thing it does, and isnt particularly good at that, either; but you need it, so you live with it. Once you have installed KfW, start the Network Identity Manager. Use the <tt>View -> Layout -> By Location</tt> menu sequence; you should see some credentials under the <tt>MSLSA:</tt> location. It may have already imported them, too; I cant remember the default configuration. If you select the <tt>MSLSA:</tt> credential, and use the <tt>Credential -> Import Credentials</tt> menu option you'll get Kerberos API credentials, which are called <tt>API:</tt> credentials in the list. Open up the NetIDMgr configuration dialogue using the <tt>Options -> General</tt> menu option. Under the "Kerberos 5" tree item, there is an "Import Tickets" option. Set it to "always". We aren't quite finished with this yet, we'll be coming back to it later. !!!Installing OpenAFS client for WinXP Installing the OpenAFS client asks you a few questions: # You are given the option of installing AFS' own MS Loopback interface. I must have done this when I first installed OpenAFS; now I have a strange "AFS" network adapter with the IP address 10.254.254.253 with netmask 255.255.255.252. If this bugs you, try unchecking it. The strange thing is that 127.0.0.1 still seems to work, dispite not being bound to any network adapter (!). # When asked about the CellServDB configuration, if you are given the "Use existing" option, then use it. Otherwise, select the "Use packaged" option. # It will then prompt for the cell name. Enter your AFS cell name here. The settings for the other options are: * Crypt security - no * Freelance client - yes * Use DNS - yes * Integrated logon - no # Then you are presented a "AFS Credentials Configuration" dialogue: * Start at login - yes * Auto initialise - yes * Renew mappings - yes * IP address change detection - yes * Quiet - yes * Show credentials on startup - no Our AFS SRV records in DNS are working, so configuration is quite simple. Once the obligatory reboot is over, you'll be offered a "Obtain new AFS tokens" dialogue when you login. Just press cancel; AFS native authentication is not being used (its going to come from Kerberos). Don't worry! This dialogue is offered only once, not every time you login. If your SRV records are not working, you'll need to manually edit the CellServDB file. If you have a working unix client, the same file should work. Probably you'll need to restart the AFS client after changing/replacing the CellServDB file. Once the AFS client has started, you should be able to Run the <tt>\\afs\all</tt> location, and see your cell. !!!Tieing it all together By now there should be: # WinXP authenticates using Kerberos # KfW imports the WinXP tickets automatically # OpenAFS client starts, and gives you access to <tt>\\afs\all</tt> The last step remains: getting Kerberos5 tickets into OpenAFS. OpenAFS for Windows client comes with the familar <tt>aklog.exe</tt> program that does just that. Find it using the Windows Explorer, and run it. The AFS Client window should change from saying "You do not have tokens" to listing the token imported from Kerberos5. If you install the OpenAFS plugin for NetIDMgr, then when you use the NetIDMgr to get new Kerberos5 credentials you can automatically get OpenAFS credentials. However I find this approach has quite a few limitations: * It doesn't work when you import credentials * It doesn't work when you renew credentials * it doesn't notice when the <tt>MSLSA:</tt> credential is renewed (eg, password-protected screen saver) * It works *only* when you use NetIDMgr to get *new* credentials However, installing the plugin allows you to see the tokens in the AFS cache, as well as the copy stored by Kerberos. To work around those absurd problems, I use the following friendly batch file called <tt>afs.bat</tt> which has a shortcut in the "Startup" folder: <pre> c: cd "\program files\mit\kerberos\bin" ms2mit cd "\program files\openafs\client\program" aklog </pre> The <tt>ms2mit</tt> program forces KfW to import the <tt>MSLSA</tt> credentials. The useful feature is that it does not exit until that is done, so makes a useful synchronisation point. Then <tt>aklog</tt> puts the ticket into OpenAFS. !!!Bugs, issues, gotchas, etc * I have experienced AFS cache corruption. The symptom of this were strange failures when accessing commonly accessed AFS directories. Empty listings, strange errors, etc, are all symptoms of this. The solution is to shutdown the AFS client, delete the AFS cache file (which is <tt>%TEMP%\AFSCache</tt> by default). * The limitations of NetIDMgr are really a pain. The <tt>afs.bat</tt> file is going to be your friend. You might like to shortcut it from the desktop or quick start bar. * WinXP decided, fairly arbitarily, it would like to synchronise my AFS home directory and make an offline copy. If your client starts doing the same, open up Windows Explorer, use the <tt>Tools -> Synchronize</tt> menu option, and un-check the AFS paths. * AFS tokens tend to expire. Don't use it for long-running processes like BitTorrent, and so on. * *Do not* run the "Network Setup Wizard" ever again, it will trash your configuration and leave you unable to login!
One page links to
WinXP+Krb5+AFS
:
AndrewFileSystem
