Chaz:

FYI, your response was sent to "openafs-info-ad...@openafs.org"
which is not the mailing list.  You might want to be aware of it
for the future.

u...@realm and user/ad...@realm are two different users.  NetIdMgr
explicitly permits you to maintain TGTs and AFS tokens for more than
one user at a time.  If you are using both u...@realm and user/ad...@realm
at the same time and configuring both to obtain tokens for the same
cell, then only one of the tokens can be active at a time.   There are
no PAGs on Windows and the cache manager can only associate one token
with a cell at a time.

Since this is a conflict, the AFS provider requires that you explicitly
approve the conflict when you add the same cell to multiple configurations
at the same time.   However, you need to be aware that you need to destroy
your credentials for one identity before using the second identity if you
wish to have consistent behavior. 

The difference between afscreds and netidmgr in this case is that when
using afscreds the identity is defined by the cell name and not the
Kerberos identity.   Therefore, even though you continue to have a TGT
for u...@realm after obtaining user/ad...@realm afscreds doesn't attempt
to renew them for you.  Whereas NetIdMgr will continue to renew all of
your identities that are currently active.  [Assuming of course that
you have configured NetIdMgr to perform auto-renewal which is on by
default.]

As someone who is often juggling multiple credentials including normal
and admin what I do is kick off a new command line session as a secondary
Windows user account intended for admin purposes and then obtain the
afs admin token under that account.  It ensures that I never mix my
regular user operations and my admin operations in the cells that I am
working on.

If you believe that you have found a bug even if you are not sure,
please file a report at openafs-b...@openafs.org.  If we aren't told
there is a problem there is no method for us to address it.

Jeffrey Altman


Chaz Chandler wrote:
> Perhaps it's just my setup, but I have on numerous occasions been able
> to get tokens only through afscreds.  netidmgr does work for this, but
> occasionally not.  I especially see issues when trying to get afs tokens
> for non-"default" pts users and/or switching between two users (like
> going back and forth between "user" and "user/admin" over the course of
> the workday).  afscreds consistently gets the tokens even when netitmgr
> does not.  Anyone else with this problem?
>
> Jeffrey Altman wrote:
>> Ever since the release of Windows Vista I have been worried about the
>> continued shipment of afscred.exe (AFS Authentication Tool) and
>> afs_config.exe (AFS Client Manager Configuration Tool) in the OpenAFS
>> installers.
>>
>> The Problem:
>>
>> Beginning with Windows Vista, Microsoft implemented a security barrier
>> referred to as User Account Control which tightens the noose on normal
>> user accounts and prevents them from being used to perform a variety of
>> operations such as starting and stopping services or writing to the
>> local machine registry hive which they were able to do in previous
>> Windows releases.   In addition, user accounts that are members of the
>> "Administrators" group always log on to the machine as normal users.  In
>> order for a process to be started with the extra special Administrators
>> bits and explicit click through approval is required by the user.  A
>> process that is started as an Administrative process shares the desktop
>> but is effectively in a separate logon session.
>>
>> afscreds.exe and afs_config.exe perform some functionality that must be
>> executed in the standard logon session and other functions that must be
>> performed as an administrative process.  A process cannot be both.  As a
>> result, depending on the user account type used and the mode the process
>> is started with different function sets will misbehave.  If the process
>> is started with Administrative bits, the process is unable to:
>>
>>  * access the MIT Kerberos v5 credential caches to obtain tokens
>>
>>  * create drive mappings
>>
>> If the process is started without the Administrative bits, the process:
>>
>>  * silently discards configuration changes that are saved in the registry
>>
>>  * is unable to start or stop the afsd service
>>
>> Based upon feedback received at the European AFS Workshop the shipment
>> and installation of these tools are creating a significant support burden. 
>>
>>
>> The Proposal:
>>
>> I propose that beginning with 1.5.66 (whenever that is) that the
>> afscreds.exe and afs_config.exe tools not be installed at all on any
>> Windows version Vista or beyond and that on 2000, XP and 2003 that these
>> tools not be installed as part of the default configuration.
>>
>>
>> The Impact:
>>
>> The afscreds tool provides three sets of functionality:
>>
>>  * token acquisition (and renewal if MIT KFW is present)
>>
>>  * drive mapping
>>
>>  * start/stop the afsd service
>>
>> Network Identity Manager has long been available as a replacement for
>> the token acquisition functionality and it is available on any system on
>> which MIT KFW is present.  The only systems that wouldn't have it are
>> clients of cells that are still using kaserver.  
>>
>> The drive mapping functionality has been documented as deprecated since
>> the addition of the loopback installation permitted the use of a
>> standard \\AFS UNC server name.  The recommended method for a user to
>> create a drive mapping is the Windows Drive Mapping user interface
>> provided as part of "[My] Computer" and the Explorer Shell.
>>
>> Starting and stopping the afsd service is an administration function
>> that can be performed using the Windows Service MMC.
>>
>> The afs_config.exe tool provides:
>>
>>  * configuration management including cell name, server preferences,
>> cellservdb editing,
>>    cache size, and advanced tuning parameters
>>
>>  * start/stop functionality
>>
>>  * drive mapping
>>
>> While it is not ready for general purpose use, Brant Gurganus has made
>> significant progress on his OpenAFS Cache Manager MMC snap-in.  This
>> tool has the potential to perform the first two functions in a more
>> complete manner than the afs_config tool ever did.  As for the drive
>> mapping, the Explorer Shell interface can be used.  As soon as this tool
>> is deemed ready for incorporation in the distribution it will be added.
>>
>>
>> Please Provide Feedback:
>>
>> If you are a Windows user or a system administrator that has a large
>> number of Windows users, please comment on whether or not you agree with
>> the proposed action.
>>
>> Thank you.
>>
>> Jeffrey Altman
>>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to