[OpenAFS] The removal of afscreds.exe and afs_config.exe on Windows Vista and Windows 7: Seeking Opinions

[Jeffrey Altman]

Anders Maegnusson wrote:
> No opinions about the stuff below, but from a support perspective it is
> really nice
> with the padlock down right.  When people have trouble with file
> accesses the two
> questions:
> 
> - Do you have a padlock down right?
> - Is there a red cross over the padlock?
> 
> are quite valuable.
> 
> -- Ragge

Agreed but there are two separate issues here.
First there is the problem that the code we inherited from IBM has
architectural design flaws that make the programs themselves
incompatible with the versions of Microsoft Windows Vista and above due
to the conflation of privileges that are required for the process to
succeed at performing its job.

1. in order to perform credentials acquisition or drive mapping
   the process must be unprivileged.

2. in order to start/stop the service or change configuration
   settings it must be "run as administrator"

Since it is impossible to be both there has been an unfunded item on the
road map for many years to separate the functionality into separate
processes.  The model that has been discussed at numerous best practice
workshops includes:

1. A Microsoft Management Console for configuration which Brant
   Gurganus worked on for GSoC but has yet to be completed.

2. Explorer Shell extensions to provide a tighter integration
   between AFS and the user desktop experience so that drive
   mapping would no longer be required.

3. Network Identity Manager for authentication.

There has not been any opposition to this direction that has been voiced
over the years.  JPL, Carnegie Mellon, Stanford, FermiLab, and Secure
Endpoints have each contributed to different pieces over the years.
However, there is still much that needs to be done.  Mockups and time
estimates have been available on the Secure Endpoints web pages for many
years.

  http://www.secure-endpoints.com/openafs-windows-roadmap.html
  http://www.secure-endpoints.com/netidmgr/roadmap.html

What has been voiced as part of this thread by Chaz and Dave and perhaps
by Ragge (not sure yet) is that there is a desire to have an AFS
identity centric model in preference to a Kerberos v5 identity centric
model when it comes to authentication.  afscreds was designed when
authentication for AFS was obtained via kaserver.  There was no
separation of cell name and the realm name.  Enter the cell name, the
AFS PTS name, and a password and it just worked.  For those sites where
the cell name and Kerberos realm name are the same (except that the
realm is all uppercase).  The afscreds user interface works for multiple
cells as well as single cell environments provided that the user is
willing to enter a password for each new token that is required.

This model doesn't work for a large number of environments.  Which is
part of the reason why Stanford, Rose-Hulman, MIT, and many other sites
developed their own replacements for afscreds.  Network Identity Manager
was designed to be the replacement for all of the replacements.
However, v1.3 is Kerberos v5 centric.  The assumption is that you obtain
your Kerberos credentials and derive from them all of the afs tokens,
x.509 client certs, Kerberos v4 tickets, Site Minder web credentials,
etc. that are desired as part of the single sign-on experience.

There is no reason why the NetIdMgr Kerberos v5 identity provider could
not be replaced by an AFS identity provider that behaves exactly the
same way that afscreds does today.

For Ragge I'm wondering if the benefit he is seeking is that of the AFS
centric identity or the fact that the lock is easier to describe than
the NetIdMgr cube which either contains an identity, an expired
identity, or none at all.

In NetIdMgr v2 each identity can be assigned its own icon.  Both Asanka
and I believe it may make sense to show the identity icons in the
notification area as an indication that the credentials have been
obtained.  What do people think of that idea?

Jeffrey Altman