Permissions set to Administrators group but members can't access f

I am setting up Vista Enterprise and have files and folders that any member
of the Administrators group needs access to when they login and want to load
some as part of the logon script. The file/folder permissions are set to
Administrators but when members of that group login, only the user that
created the files has access unless they do a runas administrator. So the
files fail to load at logon.

If I create a group called something other than administrators and assign
that group to the files or folder, everything works as expected.

From my web searches on this problem, this appears to be a normal part of
UAC behavior, though I noticed in one posting there is a
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Pol icies\system\LocalAccountTokenFilterPolicy
registry key that changes the token filtering behavior when accessing from
the network.

Does anyone know of any registry or group policy settings to change UAC
behavior to allow any user of the Administrators group to access files that
have their permissions set to Administrators? I really don't want to have to
create and maintain an extra group if it can be avoided.

Hello,

is there another user group set for permissions on that folder, such as
"Users"? If yes, it is possible that the Users permissions override the
Administrators', since they're users, too.

Greetings,
P. Di Stolfo
--
////////////////////////////
http://blog.lysorp.com - Small Windows blog in German language
///////////////////////////

"ventech" <ventech@discussions.microsoft.com> schrieb im Newsbeitrag
news:763EA274-7D03-487C-9284-C372F07A792D@microsoft.com...

>I am setting up Vista Enterprise and have files and folders that any member
> of the Administrators group needs access to when they login and want to
> load
> some as part of the logon script. The file/folder permissions are set to
> Administrators but when members of that group login, only the user that
> created the files has access unless they do a runas administrator. So the
> files fail to load at logon.
>
> If I create a group called something other than administrators and assign
> that group to the files or folder, everything works as expected.
>
> From my web searches on this problem, this appears to be a normal part of
> UAC behavior, though I noticed in one posting there is a
> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Pol icies\system\LocalAccountTokenFilterPolicy
> registry key that changes the token filtering behavior when accessing from
> the network.
>
> Does anyone know of any registry or group policy settings to change UAC
> behavior to allow any user of the Administrators group to access files
> that
> have their permissions set to Administrators? I really don't want to have
> to
> create and maintain an extra group if it can be avoided.

In Vista, the Administrators group is only recognized for "allow"
permissions when the program doing the accessing is running elevated. Deny
permissions are always considered.

So, in order for an admin to have the access that is granted to them as
members of the administrators group, the program that is accessing the file
must be elevated.

The best solution is to have another group. Otherwise, you can cripple or
disable UAC.


--
- JB
Microsoft MVP Windows Shell/User

"ventech" <ventech@discussions.microsoft.com> wrote in message
news:763EA274-7D03-487C-9284-C372F07A792D@microsoft.com...

>I am setting up Vista Enterprise and have files and folders that any member
> of the Administrators group needs access to when they login and want to
> load
> some as part of the logon script. The file/folder permissions are set to
> Administrators but when members of that group login, only the user that
> created the files has access unless they do a runas administrator. So the
> files fail to load at logon.
>
> If I create a group called something other than administrators and assign
> that group to the files or folder, everything works as expected.
>
> From my web searches on this problem, this appears to be a normal part of
> UAC behavior, though I noticed in one posting there is a
> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Pol icies\system\LocalAccountTokenFilterPolicy
> registry key that changes the token filtering behavior when accessing from
> the network.
>
> Does anyone know of any registry or group policy settings to change UAC
> behavior to allow any user of the Administrators group to access files
> that
> have their permissions set to Administrators? I really don't want to have
> to
> create and maintain an extra group if it can be avoided.

Thanks for the suggestion but in this case, only Administators have
permissions on the folders so the rights of another group would not be the
problem.

"P. Di Stolfo" wrote:

> Hello,
>
> is there another user group set for permissions on that folder, such as
> "Users"? If yes, it is possible that the Users permissions override the
> Administrators', since they're users, too.
>
> Greetings,
> P. Di Stolfo
> --
> ////////////////////////////
> http://blog.lysorp.com - Small Windows blog in German language
> ///////////////////////////
>
> "ventech" <ventech@discussions.microsoft.com> schrieb im Newsbeitrag
> news:763EA274-7D03-487C-9284-C372F07A792D@microsoft.com...

>
>

I suspected this might be the case, but had hoped there might be a more
elegant solution than my work around. Perhaps Microsoft will add something
in the future. Thanks for the feedback.

ventech

"Jimmy Brush" wrote:

> In Vista, the Administrators group is only recognized for "allow"
> permissions when the program doing the accessing is running elevated. Deny
> permissions are always considered.
>
> So, in order for an admin to have the access that is granted to them as
> members of the administrators group, the program that is accessing the file
> must be elevated.
>
> The best solution is to have another group. Otherwise, you can cripple or
> disable UAC.
>
>
> --
> - JB
> Microsoft MVP Windows Shell/User
>
> "ventech" <ventech@discussions.microsoft.com> wrote in message
> news:763EA274-7D03-487C-9284-C372F07A792D@microsoft.com...

>