From the website:

Known Issues:
On Windows 7 and Windows Server 2008 R2, it is not possible to execute an application out of AFS under the following conditions:
*The path is a drive letter mapping
*The application requires elevated privileges
Workaround: use SUBST instead of NET USE to assign drive letters to UNC paths.

So running as a different user/elevation to admin doesn't carry over the existing credentials? Is there a way to forward open credentials or generate temporary credentials when elevating? Or is this simply a limitation/security function in Windows?

On 9/16/11 12:53 PM, Lars Schimmer wrote:
On 16.09.2011 18:24, Douglas E. Engert wrote:
So far OpenAFS-1.7.1 gets around 2 issues we have been seeing
with previous versions.

OpenAFS client can recover from hibernation...

On W7 32 bit were the user does not have any admin rights
even with 1.6.0b they were not able to use AFS.
(The circumvention was to give the user admin rights)
With 1.7.1 this issue appears to have been fixed.

My users on Win 7 32bit were not admin and could get tokens/tickets/data from OpenAFS cells with previous 1.5.x and 1.6.x versions of OpenAFS.

The IFS client does get rid of smb protocol and shows some other nice side effects. My experiences here were great over the last 2 weeks, just a few small problems still appear: running software installations out of OpenAFS is often not possible with IFS (if it needs a change in user authorization).

MfG,
Lars Schimmer
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to