locked
NTFS Folder Owner Question RRS feed

  • General discussion

  • We are working with an image made for us by another agency. I have found several problems with it. The image is Windows 7 Enterprise.

    >

    One of the primary problems was with NTFS permissions. Computer\Users and Authenticated Users were allowed to inherit the Delete permission from the NTFS permissions set on C:\. This allowed them to have permission to delete files and folders in C:\Windows

    >

    To correct this, I had to stop permission inheritance from to C:\Windows from C:\.

    >

    In order to stop inheritance and remove the Delete permission, I had to change the Owner of C:\Windows\ to Computername\Administrators (it already showed the Owner as being Computername\Administrators, but I had to apply it to all child objects to prevent numerous access denied errors).

    >

    Then I was able to remove the delete permission the Users and Authenticated Users had inherited from C:\.

    >

    I looked at other Windows 7 Enterprise operating systems that are on other networks (a different image than the one I am working with), and they show the Owner of C:\Windows\ and being TrustedInstaller. So I restored ownership of C:\Windows\ to TrustedInstaller.

    >

    Is TrustedInstaller the correct Owner for C:\Windows\? I am asking because after changing ownership of C:\Windows\ to Computername\Administrators, then removing the Delete permission Users had inherited from C:\, I found several updates for .NET Framework 4 were failing to install. I researched and it was suggested I do a repair of the .NET Framework 4 Client Profile, then the updates installed successfully.

    >

    I don't know if the two issues are related. Thanks for any input on this.



    Sunday, May 6, 2012 8:24 PM

All replies

  • 1. Do you know how the image was prepared? WAIK and sysprep should be applied to set default profile correctly

    2. I miss important information if W 7 are part of workgroup or active directory domain.

    3. Follow the concept of LEAST PRIVILEDGES. Here is comprehensive reference book that might help you:

    http://www.amazon.com/Least-Privilege-Security-Windows-Vista/dp/1849680043

    My rule that has prevented me from doing too many bad mistakes repeatedly: Do not change the permissions/sharing/inheritance/etc., unless you know all the consequences exactly.

    Regards

    Milos



    Monday, May 7, 2012 9:43 AM
  • Hi,
     
    Based on my knowledge, it is true that the default owner of C:\Windows is TrustedInstaller.
     
    And when installing or updating .NET Framework 4, it will install some files to C:\Windows. Therefore, in my opinion, the issue may related to the owner changed.
     
    Hope this helps.

    Jeremy Wu

    TechNet Community Support

    Tuesday, May 8, 2012 2:14 PM
  • I can't confirm the two are related but I have had to change ownership on everything on C: to Administrators and then had problems with .Net updates.  Unfortunately the problems with updates don't occur every time.  

    Changing the ownership of everything on C: has become SOP in my environment.  We've just started rolling out Win7 and Server2008R2 to systems.

    -Chris

    Thursday, May 10, 2012 3:15 PM
  • Well, the agency that built the image of Windows 7 Enterprise I'm working with released it with several very big security flaws. Every copy of Windows 7 Enterprise or Ultimate I've looked at have the same general characteristics:

    1. The owner of C:\ and all subfolders is TrustedInstaller, and Computername\Users have read/execute/delete on C:\

    2. There is no inheritance of permissions from C:\ to its subfolders, and Computername\Users have only read/execute. Creator Owner, Administrators and TrustedInstaller have Full on all of C:\ subfolders.

    >

    What they did was permit inheritance to the subfolders of C:\. This created the situation I discovered in which Computername\Users (non-Administrators) inherited the right to delete any system file that isn't locked by the OS. They don't even get a UAC prompt. Also, they set the owner of C:\ subfolders as Computername\Administrators (rather than TrustedInstaller)

    >

    I could create a GPO that applies to non-Administrators and it will reside in C:\Windows\System32\GroupPolicyUsers. Then with non-Administrator user log in, they could simply go and delete the folder GroupPolicyUsers (!)

    >

    Working with this image, the only compromise I can use until they fix this is to remove inheritance from C:\Windows\System32, then remove the Computername\Users delete permission. In order to do this, I had to apply ownership of C:\Windows\System32 to Computername\Administrators (it already showed Computername\Administrators as the Owner, but if I didn't apply to all child objects I would receive numerous access denied errors)

    >

    If I tried to remove inheritance on C:\Windows from C:\ to remove the Computername\Users delete permisison, it will not work unless I give ownership of C:\Windows to Computername\Administrators and pass to child objects (otherwise it only removes the Computername\Users delete permission from the parent folder)

    >

    This then causes certain WSUS patch installation failures, namely the most recent patch for .NET Framework 4 and MS Silverlight.

    >

    I'm living with the compromise of only removing the Computername\Users delete permission from C:\Windows\System32 for now since it protects the all-important GroupPolicy and GroupPolicyUsers folders inside System32

    >

    That's where I'm at for the moment. The other problem is I have so many workstations to image in a certain timeframe that I just have to hope this is the best compromise between reasonable computer security and the ability of WSUS to properly install its patches (which we have to monitor and upchannel the report by scanning with a vulnerability scanner monthly.

    >

    Thanks for all responses. I'm hoping the image builder will correct these issues on the next release. I have no idea how they managed to get it so fouled up and then to release it that way as a distributable SDC image.

    Thursday, May 10, 2012 10:10 PM
  • The other problem with this image I'm working with is that either a local or a domain user (non-Administrator) can simply click Start, type gpedit.msc, hit Enter, and the Group Policy editor will open. Then they have the right to make changes to either Computer or User Administrative Templates!

    >

    When I originally posted about this on Technet, people said, "Well your users have to be members of the Administrators group for that to happen". They are not. In fact, I corrected that by creating a GPO for non-Administrators (the settings that populate the folder C:\Windows\System32\GroupPolicyUsers) which restrict their right to use authoring mode for the MMC and its nodes.

    >

    So how on earth can a Computername\User who is not a member of the Administrators group (or any other elevated group, I confirmed that by checking all groups), not only run the GP editor, but make changes to the Administrative Templates that affect the computer? If I log in as an administrator, I get a UAC prompt before the Group Policy editor will open. With a non-Administrator log in, there is no UAC prompt, the GP editor just opens up!

    >

    Just posting this to give you an idea of how goofed up they have the image I'm working with.



    Thursday, May 10, 2012 10:25 PM