Kerberos for Windows 3.0 update

Release Candidate 1 of the OpenAFS plug-in for KFW 3.0's Network Identity Manager is now available from the Secure Endpoints web site. https://www.secure-endpoints.com.

This release provides the full set of functionality necessary to manage token acquisition for multiple cells from a single Kerberos 5 principal.

New Daily Builds of OpenAFS for Windows

Today there are new daily builds of OpenAFS for Windows in both 32-bit and 64-bit versions available from http://web.mit.edu/jaltman/Public/OpenAFS/. The builds are dated 20051219.

They include performance improvements when fcrypt is in use and better logging of messages to the Windows Event Log.

MIT Kerberos for Windows 3.0 and Network Identity Manager 1.0 finally ship

Its been a long week but MIT's Kerberos for Windows 3.0 and the NEW Network Identity Manager has finally been shipped. I cannot give enough praise to Asanka for all of his hard work on this project. It would not have happened without him.

OpenAFS for Windows 1.4.1 RC2 and MIT Kerberos for Windows 3.0 Beta 2

Yesterday was a busy day. OpenAFS for Windows version 1.4.1 RC2 has been announced as well as MIT Kerberos for Windows beta 2.

The OpenAFS release can be downloaded from http://dl.openafs.org/dl/openafs/candidate/1.4.1-rc2/winnt/

The MIT Kerberos release can be downloaded from http://web.mit.edu/kerberos/.

MIT Kerberos for Windows 3.0 marks a turning point in the products history. For the first time, KFW will allow, through the use of the new Network Identity Manager, the ability to manage multiple Kerberos 5 identities at once. The NetIdMgr is based on the Khimaira Identity Management Framework which was described in a talk at the 2005 AFS & Kerberos Best Practices Conference at CMU. A copy of the presentation can be found at: http://www.secure-endpoints.com/talks/AFS-BPW-2005-Khimaira.pdf

The Khimaira framework enables the concepts of "identity" and "credentials" to be managed separately. In the modules shipped with MIT KFW 3.0, a single Kerberos 5 identity manager is included that allows users to maintain identities based upon Kerberos 5 principal names represented by Kerberos 5 Ticket Granting Tickets. Credential Managers are then provided to manage policy and perform intial credential acquisition and renewals for each specific credential type. In KFW 3.0, two Credential Managers are provided, one for Kerberos 5 and one for Kerberos 4. The Kerberos 5 Credential Manager maintains policy such as whether or not TGTs obtained should be forwardable, renewable, with what lifetimes, and whether or not they should be renewed before expiration. The Kerberos 4 credential manager receives notifications whenever a Kerberos 5 TGT is obtained and based upon its policy determines whether or not to generate a Kerberos 4 TGT via krb524d.


Secure Endpoints is providing an AFS Credential Manager that can be used to obtain tokens for an arbitrary number of cells in response to a Kerberos 5 identity being updated with a new TGT.
It is hoped that other organizations will take advantage of this new framework to add support for automated X.509 Certificate Acquisition.

Happy Fifth Birthday OpenAFS!!!

OpenAFS 1.4.0 has been released on the 5th birthday of OpenAFS.org.

http://lists.openafs.org/pipermail/openafs-announce/2005/000129.html

OpenAFS vs ntvdm.exe wildcard searches

In the OpenAFS RT there has been a ticket open for over a year because 16-bit applications when executed out of AFS were crashing.  It turns out that ntvdm.exe will perform wildcard searches for files as FOO?????.C?? instead of FOO*.C*.  OpenAFS for Windows was failing to match this pattern to FOO.C as it implemented a semantic of '?' must match a single character other than (dot).  The real rule is that (dot) is the component separator and '?' matches a single character and may match no characters if it is at the end of a component and the input string is empty.
With this fix all of those people who wish to execute the DOS versions of Quatro or Microsoft Word out of AFS (you know who you are) can rejoice.

Today we setup a read/write volume that is moved between two servers every 30 minutes.  The MIT Stress Test was then run against this volume.   While the test fails (because the volume becomes busy for six minutes during the move), the OpenAFS client cleanly fails over from one server to the next.  Good job!!!

We have been tracking what appeared to be a weird but in the rx library for the last several weeks.   After some period of time a server would respond to a client with a last packet in a call.  The client would respond by sending an ACK and then terminating the call.   The client would create a new call and issue a request to the server.  The server would appear to have ignored the previous ACK and begin resending the last message of the previous call.   The client no longer believing the previous calls exists would ignore the duplicate messages but it would also *never* resend the first packet of the new call.  This deadlock situation would remain essentially forever. 

After pulling our hair out for several weeks we discovered that the hardware clock on the machine was set to the year 2015.  ntpupdate was reseting the clock to the correct time.  The reason the client wasn't resending the new call packet was because the resend timer was set to expire ten years from now.   I wonder if the server will still be there by the time the resend takes place.  :-D

Tested executing Microsoft Office 2003 out of AFS with OAFW Byte Range Locking support and it works when the 'k' privilege is provided as part of the ACLs for the directories containing the executables.   It would be useful to compile a list of applications that do and do not work.

We have discovered another instance in which a Windows client might be unable to access volume data.  If the volume was cached by the client and then moved, salvaged or otherwise taken offline, the Windows client would never move the volume from the "offline" state to the "not busy" state.   In this case, being "offline" is distinct from all of the known servers being "down".   In the "down" case, the Windows client has a background thread to periodically test the reachability of the server.   In this case, there was no code in place to attempt to find a new source for the volume data.
A correction for this problem has been developed and was committed to the OpenAFS repository.  The fix will be available in the final 1.4.0 release.

New installers for OpenAFS for Windows pre-1.4.1 with Byte Range Lock support have been uploaded to http://web.mit.edu/jaltman/Public/OpenAFS/ByteRangeLocks/.   The latest builds are dated 20051006.   These builds fix two issues related to lock management.  I am now confident that I can use this version on a daily basis.  Perhaps we should skip the 1.4.0 release.