This page was last updated 02/19/10
Network Identity Manager 1.3.1 and Kerberos for Windows 3.2.2 were released on 22 October 2007. Download MIT KFW 3.2.2 from MIT or digitally signed versions from the Secure Endpoints web server:
Support customers are provided access to private builds that include security fixes and and functional enhancements. Under agreement with MIT, Secure Endpoints may not publicly distribute modified versions of KFW.
After the formation of the MIT Kerberos Consortium the development of MIT Kerberos shifted priorities. The Board members of the Consortium do not believe that Kerberos for Windows is worth developing as an end-user product. There have been no public statements to this effect but based upon private discussions it is the opinion of Secure Endpoints Inc. that MIT will focus its future efforts on developing Kerberos v5 and GSS libraries for developers in the form of an SDK. In order words, post 3.2.x KFW releases will not include single sign-on integration with the Windows Logon service nor will it include a credential management tool similar to Network Identity Manager.
Secure Endpoints Inc. is continuing to invest in the development of Network Identity Manager version 2 using internal resources. We hope to be able to ship a stand-alone product in the near future that includes a much improved user experience and a keystore identity provider that permits multiple Kerberos v5 identities to be acquired via a single authentication.
Network Identity Manager version 2.0 implements the long awaited support for multiple Identity Providers as well as many usability improvements that were recommended during the SOUPS 2007 conference at Carnegie Mellon University in July 2007.
An Identity Provider in Network Identity Manager is the module that determines which credential type can be used to define a Network Identity. In Network Identity Manager v1 there was a restriction of one Identity Provider at a time and the only Identity Provider supported Kerberos v5 credentials. Many other credential types have been supported including AFS, Kerberos v4, Kerberized X.509 certificates, and proprietary web browser credentials. These credentials could all be obtained using the Kerberos v5 identity credential but none of them could be used to define a Network Identity. Multiple Identity Providers permit Network Identity Manager to become a general purpose end-user management tool for Network Identities. No longer will be be tied strictly to Kerberos v5.
The second Identity Provider is a KeyStore provider. The KeyStore is an Identity Provider that permits a user to obtain credentials for multiple Network Identities with a single local authentication. A typical use case is a user that has Kerberos v5 identities in multiple Kerberos v5 realm that do not have a cross-realm key exchange. Using the KeyStore provider, the passwords for multiple Kerberos v5 identities can be encrypted and stored in the Windows Profile or on removable storage. When the obtains new credentials using the KeyStore identity, the user unlocks the KeyStore and all of the configured Network Identities protected by the KeyStore will fetch their credentials and all of the derived credentials.
Another Identity Provider that could be implemented in the future is an X.509 Certificate Identity Provider which can be used to obtain Kerberos v5 credentials via PKINIT. As there is no PKINIT support provided by MIT KFW at the present time, this provider has not yet been implemented.
At SOUPS 2007 there were several usability issues that highlighted. For starters, why does a user need to remember both a username and realm and enter them separately? This interface was a hold over from the user interfaces of the 90s. When Network Identity Manager was being designed we repeatedly received feedback from help desk personnel saying "Please do not make the user interface different from Leash32 and similar Kerberos Ticket Managers. The users are already trained to enter user, realm, password." It turns out that although the users may have been trained to go things that way, that is not the way that users would like to select their identity. Once a Network Identity is configured the user would much prefer to select it from a list of identities than type the identity names each time.
Another frequently heard complaint about Network Identity Manager v1 is that it is too complicated to configure a Network Identity to obtain all of the required credentials. At many sites Network Identity Manager is used not only to obtain a Kerberos v5 TGT but also to obtain a Kerberized X.509 certificate for use in web or grid authentication, AFS tokens to one or more AFS cells and perhaps a Kerberos v4 TGT for use with applications such as Zephyr that have yet to be migrated to Kerberos v5. Each credential provider must be configured by the user but there was no step during Network Identity creation that walked the user through these dialogs.
To address this we have added a New Identity Wizard.
From the Obtain New Credentials ... dialog the user chooses to create a new network identity.
Then selects the identity type and specifies the network identifiers.
Finally the user configures the credentials and optionally stores the secret and the identity configuration into the KeyStore.
Finally, the user interface has been spiffed up quite a bit. Each Network Identity can be assigned its own icon. It can be one that represents the institution or one that the user selects to make the Network Identity recognizable. The battery control not only displays the relative lifetime remaining for the identity credentials but can also be pressed to initiate a renewal. The newly added star is used to indicate which Network Identity is the default identity. This replaces the rather awkward shading that was used in version 1.
Network Identity Manager version 2 is now in public beta. Please see http://www.secure-endpoints.com/netidmgr/v2/.
If after reviewing the following list of features your organization decides to help support the on-going development of Network Identity Manager, please send e-mail to: firstname.lastname@example.org.
PKINIT functionality is being added to MIT's Kerberos implementation with a dependency on OpenSSL. A PKINIT identity provider for NIM should be implemented permitting the acquisition of Kerberos v5 initial ticket granting tickets via the use of a certificate or smart card.
Estimated implementation time: 60 to 80 hours
This feature can be developed when KFW provides PKINIT support or Heimdal is ported to Microsoft Windows.
The NIM Kerberos v5 Credential Module does a poor job of providing an interface for graphically editing the Kerberos v5 Configuration which is stored in the krb5.ini file. With the release of Microsoft Vista and its User Account Control (UAC) functionality, it become necessary functionality that alters system configuration whether stored in files or the registry be removed from tools that are not executed with administrator privileges. Otherwise, a failed attempt to write the configuration will automatically result in the write being redirected to a virtualized copy of the file or registry key whose lifetime is the current session. Won't the users be surprised when their configuration changes disappear when they logout.
The proposal is to remove the existing Configuration Editor functionality from the NIM Kerberos v5 module and replace it with a Microsoft Management Console Snap-In that supports the existing functionality plus domain_realm mappings and capaths. The MMC would be made accessible via a button on the NIM Options->Kerberos v5 configuration page. This button would launch the Kerberos v5 MMC as an administrative process as required by the UAC specifications.
This same MMC can be used as an alternative to Microsoft's KSETUP for configuring the Microsoft Kerberos SSP. The Vista/Win7 Kerberos SSP supports domain_realm mappings and capaths although there is currently no user interface available to configure them.
Once the Microsoft Management Console Snap-In has been implemented, the Network Identity Manager Kerberos v5 Realms page will be removed and the Configuration page will be re-implemented to remove those operations that require administrator privileges. In their place a button to launch the Kerberos Management Console with privileges will be added.
Estimated implementation time: 80 to 110 hours
When a property sheet is displayed for an identity or credential the contents of the property sheet are a snapshot of the object's state at a fixed point in time. Instead, the property sheet should refresh automatically over time.
Estimated implementation time: 16 to 24 hours
Microsoft Vista permits Kerberos for Windows to write to the LSA credentials store. This will permit NIM to make credentials acquired via Kerberos for Windows to Microsoft Kerberos SSP applications whether or not the user logged in with a Domain Account. Even when a Domain Account has been used, Kerberos for Windows can be used to overwrite the credentials with those of a new identity.
NIM should be modified to support a new MSLSA mode that creates a backup of the LSA identity within an API credential cache and writes the default identity's credentials to the LSA credential cache.
Estimated implementation time: 32 to 48 hours.
NIM should be enhanced to take advantage of the latest user interface functionality provided by Aero.
Estimated implementation time: to be determined
NIM can detect that the Vista Sidebar is open and install itself as a running widget. The widget would provide the contents of the "basic" identity view listing just the identities, whether or not they have initial credentials, when those credentials expire, and permit the selection of the default identity. The addition of the Vista Widget support would not alter the existing functionality of Network Identity Manager.
Estimate implementation time: 54 to 72 hours
NIM can detect that Google Desktop Sidebar is open and install itself as a running gadget. The gadget would provide the contents of the "basic" identity view listing just the identities, whether or not they have initial credentials, when those credentials expire, and permit the selection of the default identity. The addition of the Google Desktop Gadget support would not alter the existing functionality of Network Identity Manager.
Estimate implementation time: 54 to 72 hours
On Microsoft Vista, applications are supposed to store their configuration files under the \All Users\Application Data\Company\Product\ path instead of in the Windows directory or the Program Files directory. This is to enable 32-bit and 64-bit versions of the applications to share the same instance of the configuration files as well as permit application specific access control.
Estimated implementation time: 4 to 8 hours
Due to User Account Control restrictions on accounts that are members of the local machine Administrators group (including Domain Administrators), it is not possible to use the MSLSA credential cache. In order to permit use of the MSLSA credential cache, all MSLSA requests must be forwarded to a process that has been granted elevated privileges by the user.
Estimated implementation time: 40 hours
KFW 3.x and previous releases do not install the Kerberos and GSS libraries as side-by-side assemblies. As a result it is not possible to safely install more than one version of KFW on the machine at a time and all of the Kerberos and GSS libraries must reside in a directory that is installed in the PATH environment variable. By converting the installation of KFW to use Side-by-Side Assemblies, it becomes possible for different revisions of KFW to be installed at the same time.
Estimated implementation time: 100 hours
Send additional feature requests to email@example.com.