Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am still using dual-boot on some of my computers, so I have two Windows 7 installations running. Most data is on a partition on a separate hard drive that both installations use.

For certain files I need to set NTFS permission, if I do this using a user account or a custom windows group it works fine on one installation. When booting into the second installation, the user has no access to the files because the entries in the ACLs are specific to the account from the first installation (and shown as 'unknown' in the security dialog)

To work around this, I could use one of the built-in Windows groups. Their sid's are the same on all installations of Windows.

The question is which of the built-in groups to use? I want to give the user as little extra permissions as possible:

Administrators                  S-1-5-32-544
Backup Operators                S-1-5-32-551
Cryptographic Operators         S-1-5-32-569
Distributed COM Users           S-1-5-32-562
Event Log Readers               S-1-5-32-573
Guests                          S-1-5-32-546
IIS_IUSRS                       S-1-5-32-568
Network Configuration Operators S-1-5-32-556
Performance Log Users           S-1-5-32-559
Performance Monitor Users       S-1-5-32-558
Power Users                     S-1-5-32-547
Remote Desktop Users            S-1-5-32-555
Replicator                      S-1-5-32-552
Users                           S-1-5-32-545

I don't want to use Administrators, Backup Operators or Power Users because accounts in these groups have powerful permissions. Which of the remaining is the least 'powerful'?

I also can't use 'Guests' because they should not have access to the files.

I can't use 'users' either because every normal user is in that group, but not every user should have access to the files in question.

share|improve this question
    
If these computers are part of the same domain, I would just give the ability to access to these files, based on the group's policy, create the group on the domain clearly. If your not connected to a domain we need more information. Most of those users should not actually be used. –  Ramhound Jan 25 '12 at 14:00
    
Not in a domain, otherwise I could just use domain groups. Just standalone machines. What ever information you need? –  Peter Hahndorf Jan 25 '12 at 14:34

3 Answers 3

up vote 1 down vote accepted

Is seems in Windows Vista and later the 'Power Users' group lost nearly all their powers and its members are essentially just as powerful as members of the 'users' group.

So the Power Users group is a good candidate for the given requirement.

Also the 'Replicator' group has no extra user rights and AFAIK has no permissions on any secure-able objects. It is a legacy group from the Windows NT days.

If you are using servers, the 'Print Operators' group is another candidate.

Edit: It turns out both the 'Power Users' and the 'Print Operators' group do not work for this purpose. Even when a user is a member of these groups and the groups have say write-permissions to a resource, the user does not have write-access to the resource.

Like the administrators group, these groups are special and when a user is in the group he gets a split-token at logon. The permissions earned through this group membership are not in his standard user token and therefor he has no access to the resource.

You can see this by typing

whoami /groups

The 'Power Users' group has an attribute of:

Group used for deny only

The 'Remote Desktop users' group does not have this, but has the side-effect that is enabled the user to logon through RDP. So the only group that can be used for this is the Replicator group

share|improve this answer

One very experimental approach would be to make both Windows installations use the same user database (SAM).

If you could manage to copy the SAM file (\Windows\System32\config\SAM) of installation 1 into installation 2 the users would be identical up to the SID level.

A similar approach would be to create a group on each installation and then try to edit the SAM file of one installation, changing it's SID o the one used by the other installation. As password reset tools modify the SAM this might be a possible way.

I never tried this myself - therefore before trying such approaches make sure you have a full backup of your system...

share|improve this answer
    
That's a big hack, what is so wrong with the pragmatic approach of using one of the built-in groups? It definitely works, I just like to minimize the side-effects. –  Peter Hahndorf Jan 26 '12 at 11:00
    
@PeterHahndorf - Because none of those other user groups are designed to be used by a daily user. How about just create your own group for the few users that require access to the file. the Power Users group is design for exactly this purpose. –  Ramhound Jan 26 '12 at 12:25
    
@Ramhound - Creating my own group does not work because its SID will be different on different installations, that was my whole point. I don't want to use 'Power Users' because that would give the users way too much power. –  Peter Hahndorf Jan 26 '12 at 12:50

1 word. Users.

Users is basically everyone who can be authenticated by that machine locally.

share|improve this answer
    
Yes that's the obvious one. I should have said why that is not an option. (I edited the question). I have several users that need to be in the 'users' group but not all of them should have access to the files I want to protect. –  Peter Hahndorf Jan 25 '12 at 14:37
    
If you're wanting to use "ACLs" from one workstation to another... you need some sort of central authority (domain controller) to keep common SIDs between each OS. There are tricks to change the SID on the workstation, but they're usually not a good idea. –  TheCompWiz Jan 25 '12 at 14:54
    
technet.microsoft.com/en-us/sysinternals/bb897418 <--- is designed to change your sid to a new one... but the tool won't let you set it to a specific value. Near the bottom it tells you how the tool works... and you can use those instructions to copy one SID to another OS. The next trick is to create groups with matching SIDs. –  TheCompWiz Jan 25 '12 at 14:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.