Richard: I too am frustrated by the lack of information being distributed by the MIT Kerberos Consortium regarding the future of KFW. I heard a rumor that Network Identity Manager was being removed from KFW last Summer and then KFW 3.2.3 Alpha shipped once again with v1.3. The Consortium Roadmap doesn't even make a reference to KFW.
http://k5wiki.kerberos.org/wiki/Roadmap Whether or not the Consortium decides to stop shipping Network Identity Manager with KFW, it is not going away. Version 2.0 has been in a state of being just about ready for nearly six months. There are also active project proposals to implement Network Identity Manager on Linux and MacOS X. If you are aware of issues with Network Identity Manager that have not already been addressed I would like to hear about them. Many of the issues that I am aware of at large sites with complex multi-realm environments such as MIT can be avoided by applying the appropriate configuration information to the MSI as a transform or publishing configuration data via Group Policy to managed machines. One of the areas which has been confusing for sites that deploy Network Identity Manager is a lack of understanding that not all of the functionality that is exported via the user interface is actually part of Network Identity Manager. One of the primary development goals of Network Identity Manager was to remove the burden from the MIT Kerberos team of maintaining support for third party derivative credential types such as AFS tokens. Network Identity Manager provides an agnostic framework into which Identity Providers, Credential Providers, and Tool Providers permit the customization of the user experience for the organization based upon the identity sources and credential types required for the organization. Since the MIT Kerberos team could not support arbitrary credential types, there was always pressure from outside to add something new or tweak the support for AFS in a manner required by a local institution. The failure of MIT to respond was a forking of the user experience across institutions. Stanford, UMich, Cornell, Rose-Hulman, and many others had to expend resources to develop their own local credential management tools. Once the credential management tools are being distributed locally the temptation to fork the KFW sources and produce incompatible libraries is quite high. Incompatible libraries at different sites result in a high support cost for application developers. Convincing developers to add support for Kerberos is already hard enough without such challenges. The experience of Secure Endpoints when it was responsible for supporting MIT had significant input into the Network Identity Manager design. MIT has a centralized identity provider (the ATHENA.MIT.EDU realm) but it also has a large number of decentralized Windows domains that are also Kerberos providers. To obtain access to central resources and many of the department AFS cells the ATHENA.MIT.EDU identity must be used. However, the local Windows domain identity was required for accessing other resources. It was critical that users be able to make use of both identities when they are available. The primary frustrations that I am aware of with v1.3 is the Leash32 style "obtain credentials dialog" which requires the user to enter the user name, realm, and password along with the lack of a wizard to walk the user through the configuration of third party providers such as the OpenAFS provider. The OpenAFS provider was broken by the referrals support that went into KFW 3.2.x. No bug reports were filed against OpenAFS for more than a year. It was fixed immediately after a report was received but if your users had one of the broken builds I'm sure they were quite frustrated. In any case, Network Identity Manager v2 includes significant new functionality that is the result of feedback received at the 2007 SOAP conference at Carnegie-Mellon where the application underwent a usability evaluation as well as from the sites which rely upon it as their primary user interface to end users: 1. A new identity creation wizard which prompts the user for the type of identity and walks the user through the creation of the identity and configuration of all of the available credential providers that are compatible with that identity. 2. A new obtain credentials dialog which avoids the need for users to enter their name and realm for each request. Instead, once an identity is defined the users simply select it from a list. 3. Support for multiple identity providers. Kerberos v5 is no longer exclusive. This will permit the addition of X.509 identities in the future which can be used to obtain credentials for multiple Kerberos v5 principals perhaps from multiple realms. 4. A Keystore identity provider is included which permits acquiring TGTs and derived credentials for multiple identities with one local authentication. 5. A new progress dialog that explains what the various credential providers are doing during a new credential acquisition or a renewal. 6. User assignment of icons to each network identity 7. Addition of an animated battery for each identity which shows valid lifetime and can be used to initiate renewal. 8. Addition of a star to indicate the current default identity instead of a color palette change. Here are some screen shots: * http://www.secure-endpoints.com/netidmgr/v2/nim-basic-icons.PNG * http://www.secure-endpoints.com/netidmgr/v2/nim-new-creds-idsel.PNG * http://www.secure-endpoints.com/netidmgr/v2/nim-new-creds-basic-ks.PNG * http://www.secure-endpoints.com/netidmgr/v2/nim-new-creds-idspec.PNG * http://www.secure-endpoints.com/netidmgr/v2/nim-new-creds-adv-ks.PNG * http://www.secure-endpoints.com/netidmgr/v2/nim-new-creds-progress.PNG A presentation on Network Identity Manager v2 was given at the 2009 AFS & Kerberos Best Practices Workshop by Asanka Herath, Daniel KouĊil, and myself. http://workshop.openafs.org/afsbpw09/thu_3_3.html Many peer institutions including Stanford University, Carnegie Mellon and FermiLab are extremely happy with Network Identity Manager and Secure Endpoints has a direct channel to their help desks. Whenever there were problems with Network Identity Manager, they were addressed in subsequent releases. I should point out that due to MIT's discomfort with the switch from Leash32 to NetIdMgr that the KFW 3.2.x 32-bit MSI does include the leash32 binary and MIT can apply a transform to the MSI that will install leash32 and not Network Identity Manager 1.3. If the reason that MIT has continued to ship KFW 2.6.5 for all of these years is a dislike for Network Identity Manager, it has done so for no good reason. Of course, this is only true for 32-bit platforms because Leash32 will not compile on 64-bit platforms. Regarding Network Identity Manager release schedules, I am hoping to be able to ship v2 by the end of this month. I do not know whether it will be shipped as part of a KFW package, or standalone, or whether the Network Identity Manager distribution will include a bundled Kerberos distribution. If you have any questions regarding Network Identity Manager, please feel free to ask them. Jeffrey Altman Secure Endpoints Inc. Richard Edelson wrote: > I actually wanted to get rid of 2.6.5 this summer but I'm still holding off > because of issues people are having with NIM. I heard NIM is going > away.....do you have info on upcoming release schedules? > > Richard > > > -----Original Message----- > From: Jeffrey Altman [mailto:[email protected]] > Sent: Monday, October 05, 2009 5:26 AM > To: [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: Fwd:Windows 7 Kerb bug > > Richard Edelson wrote: >> I have a separate installer the pismere build machine made of 2.6.5 which >> works fine, it's on DFS: >> \\win.mit.edu\dfs\msi\MIT Windows Utilities\KfW\kfw2005-12-20.msi > > While you may believe that kfw 2.6.5 works fine on Vista and Win7, it > really doesn't. Microsoft Crash Reporting receives more than 6000 > crash reports a month from 2.6.5 leash32.exe, gssapi32.dll and > krb5_32.dll. > >
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
