Does UAC Drop Privileges From Inbuilt Groups Other Than Administrators?

  • Thread starter Thread starter x
  • Start date Start date
X

x

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.
 
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.
 
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.
Click to expand...

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.
Click to expand...

You're welcome :)
 
Back
Top