Differences between version 2 and previous revision of WinXP+Krb5+AFS.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 2 | Last edited on Tuesday, September 5, 2006 9:22:53 pm | by GuyThornley | Revert |
| Older page: | version 1 | Last edited on Tuesday, September 5, 2006 6:23:10 pm | by GuyThornley | Revert |
@@ -1,20 +1,27 @@
-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.
+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 havn'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 5to4
type things going on.
+You will need a correctly configured Kerberos5 domain and AFS server, which is probably its own set of headaches. I havn'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 3.
-* OpenAFS Windows client 1.4.1
-* OpenAFS plugin 1
.1 for
NetIDMgr
+* 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 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
+!!
!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]
@@ -39,12 +46,8 @@
<pre>
ksetup /setdomain ''{REALM}''
ksetup /setmachpassword ''{passwd}''
ksetup /mapuser * *
-</pre>
-
-If you have working SRV records for Kerberos, you can omit this step. Otherwise, you need to also:
-<pre>
ksetup /addkdc ''{REALM}'' ''{kdc}''
</pre>
passwd:
@@ -53,9 +56,76 @@
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}''. This is obtained from DNS using
SRV records if
not configured explicity
.
+ 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 MIT
Kerberos
+!!
!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.) 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 arn'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...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 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.
