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