Does UAC Drop Privileges From Inbuilt Groups Other Than Administrators?

User Account Control appears to be dropping privileges from inbuilt groups
other than just Administrators (except Authenticated Users)?

I use a separate logical drive for data and use "standard" user accounts.
The partition is NTFS-formatted. For convenience instead of adding each
login name that should have access to the drive with modify privileges (and
below) I just added the Power Users group (with modify and below) privileges
and made each user a member of Power Users. Because I don't want all users
to access the drive I removed "Authenticated Users" and "Users" from the
access list. The access list shows SYSTEM - Full Control, Administrators -
Full Control, Power Users - Modify.

This worked fine on XP but under Vista when any of the standard user
accounts are used, Computer shows no space information. When I click on the
drive, I get the message box saying "F:\ is not accessible. Access is
denied".
If I use Advanced Security, click the Effective Permissions tab, and type in
the group name of Power Users, all the boxes are checked apart from Full
Control, telling me that the logon on user should be able to read. write
etc.

To prove the security setup was okay, I turned UAC off, rebooted, and
retried. This time Windows Explorer shows space information for that drive,
any standard user account in the Power Users group can read and modify data
on it okay.

I turned UAC back on, rebooted and retried the test and the missing space
information and "F:\ is not accessible. Access is denied" problems returned.

I am aware that the Power Users group only exists for compatibility reasons
and thought it may be that it doesn't have any privileges any more so I
tried a couple of other groups, Backup Operators, and Network Configuration
Operators in place of Power Users but the same problems occur with UAC
turned on.

The only way I seem to be able to use groups with UAC is if I create a group
of my own instead of using the inbuilt groups. Then if I do the above test
using my Test group instead of Power Users/Backup Operators/Network
Configuration Operators it works.

I completely uninstalled my Internet Security system, including running the
vendor's special "cleanup" tool to ensure it was completely gone, used
MSCONFIG to turn off all startup items and non-Microsoft services, then
rebooted, but this made no difference to the results of the tests: UAC on,
no access. UAC off, access is okay.

My understanding of UAC is that it turns off Administrator privileges so
even if a logon is a member of the Administrators group the default
environment is non-Administrative. I've been searching documents and the
Internet and I haven't seen it mentioned anywhere that UAC also turns off
other privileges from other inbuilt groups.

By the way you may be wondering why I was keen on using Power Users instead
of a group name of my own making. It's because I use the same technique with
removable hard disks, which I switch between two systems. It worked fine in
XP and saved me having to mess about changing access lists permitting users
logons on each system to the drive every time I switched it (due to SID
differences). But my understanding is that if I create a group of my own, it
won't have the same SID on each system so I'd still have to mess about with
access lists when switching the disk between systems.

Regards,

Brian.

Hello,

UAC does indeed filter out "higher privilege" group memberships when
logged in with a standard user account that is assigned
higher-than-usual privileges.

Applications are put into one of three modes when they run (which is
determined by the application in their manifest), and these modes are
in effect even in non-admin accounts:

- asInvoker: The application will run with a filtered token. Any
excess privileges that the user is assigned are turned off, and if
they are in a higher privilege group assignment (such as
administrators or powers users), then this group membership is only
taken into account when processing DENY permissions.

- highestAvailable: The application will run with whatever privileges
are assigned to the user. If the user is an administrator, the
application will prompt. If the user is NOT an admin by has
higher-than-usual privileges (as in your case with the power user
membership), then there is NO prompt, but the extra privileges are
turned on.

- requiresAdministrator: The application must be run inside of an
administrator account and will prompt.

The problem you are encountering is that Windows Explorer runs in
asInvoker mode, so it is not using the extra group membership that
your user is assigned.

Unfortunately, there is no way to elevate an app from "asInoker" to
"highestAvailable".

If you run Regedit from the user's account in question with UAC on,
you can see this working as I described. Regedit is assigned
"highestAvailable". If you go to the File->Import screen in regedit,
you will be able to access the drive/folder in question, while you are
denied access in explorer.

This is an unfortunate shortcomming of the UAC, and you have found a
good workaround: nesting a system group inside of your custom group
membership.

As for the SID issue, you are correct - custom groups would have
unique SID's on each system. I must say you found a rather creative
solution to this problem on Windows XP systems, except for having to
make users you want to have access to the restricted info power users,
which is probably not the best idea.

--
-JB
Microsoft MVP - Windows Shell
Windows Vista Support FAQ - http://www.jimmah.com/vista/

On Wed, 16 May 2007 17:23:52 +0100, "x" <Noname@Nowhere> wrote:

>User Account Control appears to be dropping privileges from inbuilt groups
>other than just Administrators (except Authenticated Users)?
>
>I use a separate logical drive for data and use "standard" user accounts.
>The partition is NTFS-formatted. For convenience instead of adding each
>login name that should have access to the drive with modify privileges (and
>below) I just added the Power Users group (with modify and below) privileges
>and made each user a member of Power Users. Because I don't want all users
>to access the drive I removed "Authenticated Users" and "Users" from the
>access list. The access list shows SYSTEM - Full Control, Administrators -
>Full Control, Power Users - Modify.
>
>This worked fine on XP but under Vista when any of the standard user
>accounts are used, Computer shows no space information. When I click on the
>drive, I get the message box saying "F:\ is not accessible. Access is
> denied".
>If I use Advanced Security, click the Effective Permissions tab, and type in
>the group name of Power Users, all the boxes are checked apart from Full
>Control, telling me that the logon on user should be able to read. write
>etc.
>
>To prove the security setup was okay, I turned UAC off, rebooted, and
>retried. This time Windows Explorer shows space information for that drive,
>any standard user account in the Power Users group can read and modify data
>on it okay.
>
>I turned UAC back on, rebooted and retried the test and the missing space
>information and "F:\ is not accessible. Access is denied" problems returned.
>
>I am aware that the Power Users group only exists for compatibility reasons
>and thought it may be that it doesn't have any privileges any more so I
>tried a couple of other groups, Backup Operators, and Network Configuration
>Operators in place of Power Users but the same problems occur with UAC
>turned on.
>
>The only way I seem to be able to use groups with UAC is if I create a group
>of my own instead of using the inbuilt groups. Then if I do the above test
>using my Test group instead of Power Users/Backup Operators/Network
>Configuration Operators it works.
>
>I completely uninstalled my Internet Security system, including running the
>vendor's special "cleanup" tool to ensure it was completely gone, used
>MSCONFIG to turn off all startup items and non-Microsoft services, then
>rebooted, but this made no difference to the results of the tests: UAC on,
>no access. UAC off, access is okay.
>
>My understanding of UAC is that it turns off Administrator privileges so
>even if a logon is a member of the Administrators group the default
>environment is non-Administrative. I've been searching documents and the
>Internet and I haven't seen it mentioned anywhere that UAC also turns off
>other privileges from other inbuilt groups.
>
>By the way you may be wondering why I was keen on using Power Users instead
>of a group name of my own making. It's because I use the same technique with
>removable hard disks, which I switch between two systems. It worked fine in
>XP and saved me having to mess about changing access lists permitting users
>logons on each system to the drive every time I switched it (due to SID
>differences). But my understanding is that if I create a group of my own, it
>won't have the same SID on each system so I'd still have to mess about with
>access lists when switching the disk between systems.
>
>Regards,
>
>Brian.
>

Hello,

I appreciate the in-depth explanation. Now I understand why Vista is
behaving like it.

For XP, Power Users suited well - not only for solving the SID issue but I
found the users needed Power Users anyway as a Standard User under XP ran
into quite a few problems.

I'll keep UAC on in Vista and live with its limitations because the gains
far outweigh those limitations in my opinion.

Thanks once again for your help.

Regards,

Brian.

** LEGAL DISCLAIMER **

This E-mail and any attachments may contain confidential information
intended only for the use of the person(s) to whom it is addressed.
Unauthorised disclosure, copying or distribution of the E-mail or its
content may result in legal liability.

If you have received the E-mail in error, please permanently delete it and
notify me by return E-mail.

Although this e-mail and any attachments are believed to be free of any
virus, or other defect which might affect any computer or system into which
they are received and opened, Internet communications can not be guaranteed
to be secure or error-free and therefore it is the responsibility of the
recipient to ensure that they are virus free. I cannot accept any liability
for any loss or damage from receipt or use thereof which arises as a result
of Internet transmission.

"Jimmy Brush" <jb@mvps.org> wrote in message
news:t7sm4357nhabqr6miq4cke5chehv81sjps@4ax.com...
> Hello,
>
> UAC does indeed filter out "higher privilege" group memberships when
> logged in with a standard user account that is assigned
> higher-than-usual privileges.
>
> Applications are put into one of three modes when they run (which is
> determined by the application in their manifest), and these modes are
> in effect even in non-admin accounts:
>
> - asInvoker: The application will run with a filtered token. Any
> excess privileges that the user is assigned are turned off, and if
> they are in a higher privilege group assignment (such as
> administrators or powers users), then this group membership is only
> taken into account when processing DENY permissions.
>
> - highestAvailable: The application will run with whatever privileges
> are assigned to the user. If the user is an administrator, the
> application will prompt. If the user is NOT an admin by has
> higher-than-usual privileges (as in your case with the power user
> membership), then there is NO prompt, but the extra privileges are
> turned on.
>
> - requiresAdministrator: The application must be run inside of an
> administrator account and will prompt.
>
> The problem you are encountering is that Windows Explorer runs in
> asInvoker mode, so it is not using the extra group membership that
> your user is assigned.
>
> Unfortunately, there is no way to elevate an app from "asInoker" to
> "highestAvailable".
>
> If you run Regedit from the user's account in question with UAC on,
> you can see this working as I described. Regedit is assigned
> "highestAvailable". If you go to the File->Import screen in regedit,
> you will be able to access the drive/folder in question, while you are
> denied access in explorer.
>
> This is an unfortunate shortcomming of the UAC, and you have found a
> good workaround: nesting a system group inside of your custom group
> membership.
>
> As for the SID issue, you are correct - custom groups would have
> unique SID's on each system. I must say you found a rather creative
> solution to this problem on Windows XP systems, except for having to
> make users you want to have access to the restricted info power users,
> which is probably not the best idea.
>
> --
> -JB
> Microsoft MVP - Windows Shell
> Windows Vista Support FAQ - http://www.jimmah.com/vista/
>
> On Wed, 16 May 2007 17:23:52 +0100, "x" <Noname@Nowhere> wrote:
>
>>User Account Control appears to be dropping privileges from inbuilt groups
>>other than just Administrators (except Authenticated Users)?
>>
>>I use a separate logical drive for data and use "standard" user accounts.
>>The partition is NTFS-formatted. For convenience instead of adding each
>>login name that should have access to the drive with modify privileges
>>(and
>>below) I just added the Power Users group (with modify and below)
>>privileges
>>and made each user a member of Power Users. Because I don't want all users
>>to access the drive I removed "Authenticated Users" and "Users" from the
>>access list. The access list shows SYSTEM - Full Control, Administrators -
>>Full Control, Power Users - Modify.
>>
>>This worked fine on XP but under Vista when any of the standard user
>>accounts are used, Computer shows no space information. When I click on
>>the
>>drive, I get the message box saying "F:\ is not accessible. Access is
>> denied".
>>If I use Advanced Security, click the Effective Permissions tab, and type
>>in
>>the group name of Power Users, all the boxes are checked apart from Full
>>Control, telling me that the logon on user should be able to read. write
>>etc.
>>
>>To prove the security setup was okay, I turned UAC off, rebooted, and
>>retried. This time Windows Explorer shows space information for that
>>drive,
>>any standard user account in the Power Users group can read and modify
>>data
>>on it okay.
>>
>>I turned UAC back on, rebooted and retried the test and the missing space
>>information and "F:\ is not accessible. Access is denied" problems
>>returned.
>>
>>I am aware that the Power Users group only exists for compatibility
>>reasons
>>and thought it may be that it doesn't have any privileges any more so I
>>tried a couple of other groups, Backup Operators, and Network
>>Configuration
>>Operators in place of Power Users but the same problems occur with UAC
>>turned on.
>>
>>The only way I seem to be able to use groups with UAC is if I create a
>>group
>>of my own instead of using the inbuilt groups. Then if I do the above test
>>using my Test group instead of Power Users/Backup Operators/Network
>>Configuration Operators it works.
>>
>>I completely uninstalled my Internet Security system, including running
>>the
>>vendor's special "cleanup" tool to ensure it was completely gone, used
>>MSCONFIG to turn off all startup items and non-Microsoft services, then
>>rebooted, but this made no difference to the results of the tests: UAC on,
>>no access. UAC off, access is okay.
>>
>>My understanding of UAC is that it turns off Administrator privileges so
>>even if a logon is a member of the Administrators group the default
>>environment is non-Administrative. I've been searching documents and the
>>Internet and I haven't seen it mentioned anywhere that UAC also turns off
>>other privileges from other inbuilt groups.
>>
>>By the way you may be wondering why I was keen on using Power Users
>>instead
>>of a group name of my own making. It's because I use the same technique
>>with
>>removable hard disks, which I switch between two systems. It worked fine
>>in
>>XP and saved me having to mess about changing access lists permitting
>>users
>>logons on each system to the drive every time I switched it (due to SID
>>differences). But my understanding is that if I create a group of my own,
>>it
>>won't have the same SID on each system so I'd still have to mess about
>>with
>>access lists when switching the disk between systems.
>>
>>Regards,
>>
>>Brian.
>>
>

On Thu, 17 May 2007 10:10:49 +0100, "x" <Noname@Nowhere> wrote:

>Hello,
>
>I appreciate the in-depth explanation. Now I understand why Vista is
>behaving like it.
>
>For XP, Power Users suited well - not only for solving the SID issue but I
>found the users needed Power Users anyway as a Standard User under XP ran
>into quite a few problems.

This is understandable. Running as a standard user in XP is an
experiment in frustration . I hope you re-evaluate this in Vista, as
it was one of the major goals in Vista to make this experience much
better.

>I'll keep UAC on in Vista and live with its limitations because the gains
>far outweigh those limitations in my opinion.
>
>Thanks once again for your help.

You're welcome

>Regards,
>
>Brian.
>
>** LEGAL DISCLAIMER **
>
>This E-mail and any attachments may contain confidential information
>intended only for the use of the person(s) to whom it is addressed.
>Unauthorised disclosure, copying or distribution of the E-mail or its
>content may result in legal liability.
>
>If you have received the E-mail in error, please permanently delete it and
>notify me by return E-mail.
>
>Although this e-mail and any attachments are believed to be free of any
>virus, or other defect which might affect any computer or system into which
>they are received and opened, Internet communications can not be guaranteed
>to be secure or error-free and therefore it is the responsibility of the
>recipient to ensure that they are virus free. I cannot accept any liability
>for any loss or damage from receipt or use thereof which arises as a result
>of Internet transmission.
>
>"Jimmy Brush" <jb@mvps.org> wrote in message
>news:t7sm4357nhabqr6miq4cke5chehv81sjps@4ax.com...
>> Hello,
>>
>> UAC does indeed filter out "higher privilege" group memberships when
>> logged in with a standard user account that is assigned
>> higher-than-usual privileges.
>>
>> Applications are put into one of three modes when they run (which is
>> determined by the application in their manifest), and these modes are
>> in effect even in non-admin accounts:
>>
>> - asInvoker: The application will run with a filtered token. Any
>> excess privileges that the user is assigned are turned off, and if
>> they are in a higher privilege group assignment (such as
>> administrators or powers users), then this group membership is only
>> taken into account when processing DENY permissions.
>>
>> - highestAvailable: The application will run with whatever privileges
>> are assigned to the user. If the user is an administrator, the
>> application will prompt. If the user is NOT an admin by has
>> higher-than-usual privileges (as in your case with the power user
>> membership), then there is NO prompt, but the extra privileges are
>> turned on.
>>
>> - requiresAdministrator: The application must be run inside of an
>> administrator account and will prompt.
>>
>> The problem you are encountering is that Windows Explorer runs in
>> asInvoker mode, so it is not using the extra group membership that
>> your user is assigned.
>>
>> Unfortunately, there is no way to elevate an app from "asInoker" to
>> "highestAvailable".
>>
>> If you run Regedit from the user's account in question with UAC on,
>> you can see this working as I described. Regedit is assigned
>> "highestAvailable". If you go to the File->Import screen in regedit,
>> you will be able to access the drive/folder in question, while you are
>> denied access in explorer.
>>
>> This is an unfortunate shortcomming of the UAC, and you have found a
>> good workaround: nesting a system group inside of your custom group
>> membership.
>>
>> As for the SID issue, you are correct - custom groups would have
>> unique SID's on each system. I must say you found a rather creative
>> solution to this problem on Windows XP systems, except for having to
>> make users you want to have access to the restricted info power users,
>> which is probably not the best idea.
>>
>> --
>> -JB
>> Microsoft MVP - Windows Shell
>> Windows Vista Support FAQ - http://www.jimmah.com/vista/
>>
>> On Wed, 16 May 2007 17:23:52 +0100, "x" <Noname@Nowhere> wrote:
>>
>>>User Account Control appears to be dropping privileges from inbuilt groups
>>>other than just Administrators (except Authenticated Users)?
>>>
>>>I use a separate logical drive for data and use "standard" user accounts.
>>>The partition is NTFS-formatted. For convenience instead of adding each
>>>login name that should have access to the drive with modify privileges
>>>(and
>>>below) I just added the Power Users group (with modify and below)
>>>privileges
>>>and made each user a member of Power Users. Because I don't want all users
>>>to access the drive I removed "Authenticated Users" and "Users" from the
>>>access list. The access list shows SYSTEM - Full Control, Administrators -
>>>Full Control, Power Users - Modify.
>>>
>>>This worked fine on XP but under Vista when any of the standard user
>>>accounts are used, Computer shows no space information. When I click on
>>>the
>>>drive, I get the message box saying "F:\ is not accessible. Access is
>>> denied".
>>>If I use Advanced Security, click the Effective Permissions tab, and type
>>>in
>>>the group name of Power Users, all the boxes are checked apart from Full
>>>Control, telling me that the logon on user should be able to read. write
>>>etc.
>>>
>>>To prove the security setup was okay, I turned UAC off, rebooted, and
>>>retried. This time Windows Explorer shows space information for that
>>>drive,
>>>any standard user account in the Power Users group can read and modify
>>>data
>>>on it okay.
>>>
>>>I turned UAC back on, rebooted and retried the test and the missing space
>>>information and "F:\ is not accessible. Access is denied" problems
>>>returned.
>>>
>>>I am aware that the Power Users group only exists for compatibility
>>>reasons
>>>and thought it may be that it doesn't have any privileges any more so I
>>>tried a couple of other groups, Backup Operators, and Network
>>>Configuration
>>>Operators in place of Power Users but the same problems occur with UAC
>>>turned on.
>>>
>>>The only way I seem to be able to use groups with UAC is if I create a
>>>group
>>>of my own instead of using the inbuilt groups. Then if I do the above test
>>>using my Test group instead of Power Users/Backup Operators/Network
>>>Configuration Operators it works.
>>>
>>>I completely uninstalled my Internet Security system, including running
>>>the
>>>vendor's special "cleanup" tool to ensure it was completely gone, used
>>>MSCONFIG to turn off all startup items and non-Microsoft services, then
>>>rebooted, but this made no difference to the results of the tests: UAC on,
>>>no access. UAC off, access is okay.
>>>
>>>My understanding of UAC is that it turns off Administrator privileges so
>>>even if a logon is a member of the Administrators group the default
>>>environment is non-Administrative. I've been searching documents and the
>>>Internet and I haven't seen it mentioned anywhere that UAC also turns off
>>>other privileges from other inbuilt groups.
>>>
>>>By the way you may be wondering why I was keen on using Power Users
>>>instead
>>>of a group name of my own making. It's because I use the same technique
>>>with
>>>removable hard disks, which I switch between two systems. It worked fine
>>>in
>>>XP and saved me having to mess about changing access lists permitting
>>>users
>>>logons on each system to the drive every time I switched it (due to SID
>>>differences). But my understanding is that if I create a group of my own,
>>>it
>>>won't have the same SID on each system so I'd still have to mess about
>>>with
>>>access lists when switching the disk between systems.
>>>
>>>Regards,
>>>
>>>Brian.
>>>
>>