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

[Dave B]

To followup a bit...

yes, the simplicity of the red X and the lock icon is great for our very
un-savvy computer users.

Because much of the other functionaliy in the afscreds app is deprecated,
doesn't work for various reasons, or has been replaced by other tools (mapping
drives, configuring the client, starting/stopping the service), I would not
object if the functionality of afscreds was reduced to ONLY
obtaining/viewing/destroying tokens. This is all we use it for ourselves,
generally -- and even then, it's mostly just used to verify that one got
tokens during integrated login and if not, for some reason (or the tokens
expired) to get new tokens.

On Thu, Oct 08, 2009 at 03:32:43PM -0400, Jeffrey Altman wrote:
> 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
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 

-- 
********************************
David William Botsch
Programmer/Analyst
CNF Computing
botsch@cnf.cornell.edu
********************************