3

This is what I did on my Windows 2008r2

  1. Logged in as Administrator (UAC is disabled for a test sake)

  2. Select a folder

  3. Edit Advanced Permissions

  4. Uncheck"Include inheritable permissions" and click on Remove button to remove inheritable permissions

  5. Got a message "No one will be able to access the folder except for the owner". At this point I thought that Administrator should still have access and "no one" doesn't apply to me :)

  6. After answering OK, I lost all control over the permissions window and got "Access denied" message. The only option was to take ownership and put back Administrator with Full Control.

Is there a Linux root equivalent in Windows that can have access to a file without granting full control?

If not, is the only option to administrate files in Windows is to give Administrator Full Control to ALL files (I'm excluding the take ownership option as not practical)?

1

Is there a Linux root equivalent in Windows that can have access to a file without granting full control?

No. Unless your Administrator user has permissions to perform an action on a file (either explicitly, or through group membership), he will not be able to perform the action on the file.

The exception, which you have noted, is file/folder ownership. An administrative user will always be able to take ownership of a file, and change permissions that way.

If not, is the only option to administrate files in Windows is to give Administrator Full Control to ALL files (I'm excluding the take ownership option as not practical)?

It's not especially clear what you mean by this, but in general, if you want a user to administer a file or folder, yeah, they need to have the filesystem permissions to do so.

  • Thanks for a quick response. In my second question I meant, that I will need to set Administrators group Full Control on the drive level and let all folders and files to inherit from it to be able to administer all folder/files in the file system. Is that the best practice? – Bibi195 Jan 25 '15 at 4:39
  • 1
    @Bibi195 No. An administrator can always take ownership of a file or folder and get full control permissions that way. – HopelessN00b Jan 25 '15 at 4:43
  • Sorry I'm new to this... So I will need to take ownership change permissions and then change owner back to the original owner? Is that the best practice? To add to this the original owner will not be able to use the files while I'm doing it. – Bibi195 Jan 25 '15 at 4:48
  • @Bibi195 Changing the owner back is optional, but generally a good idea, yes. – HopelessN00b Jan 25 '15 at 4:51
  • Actually it more than that (if I understand it correctly). To set permissions I will need to: 1. Take ownership 2. Assign Full Control to Administrators 3. Set permissions 4. Change owner back to original – Bibi195 Jan 25 '15 at 5:03
2

Is there a Linux root equivalent in Windows that can have access to a file without granting full control?

You could make sysadmins use plain User accounts and give them accounts with Administrator access when they need to do administrative tasks like assign permissions . The security dialogs all support UAC now, after all. However, elevation through impersonation is not easy or practical in every environment or situation, and there are still oddball tasks that make administrator-through-elevation-prompt-only difficult at best. Most third party vendors, IMX, still require full Administrator rights to the systems that their software is installed on because developers hate documenting what security they need and vendor technicians hate having to deal with security on a system they won't manage.

To actually answer the question directly, the equivalent on on Windows to Linux root would be impersonating the SYSTEM account (NT AUTHORITY\SYSTEM, aka LocalSystem), which is technically possible but has always been considered extremely poor practice (outside a few narrow scopes like WMI queries) and you should never do it because you never need to (and, indeed, the account isn't allowed interactive logon and you're not allowed to set the account's password, though I think you execute in that context with AT.EXE tasks). You will, of course, have software vendors who insist their product run services as SYSTEM. Again, they do this because the developers don't want to document or maintain documentation for what permissions their program actually needs, not because they actually need SYSTEM access.

The SYSTEM account, like root, has the real highest permissions and certain things only it can do. Only SYSTEM has access to the files that store the security databases, even though those passwords are stored encrypted. Only services and the kernel run as SYSTEM. This is why it's best practice not to let non-Windows services run as SYSTEM. It's far more permissions than they need.

However, you still can remove SYSTEM access to files and folders. As you discovered, it's possible with NTFS to have folders or files for which no ACE exists, and therefore no account can access the file or folder, including SYSTEM (although the system is always allowed to still enumerate the item, the ACL, and the owner, just not any contents or children of the object). The file or folder owner is the only means to restore access in this state.

If not, is the only option to administrate files in Windows is to give Administrator Full Control to ALL files (I'm excluding the take ownership option as not practical)?

It's not practical not to use Full Control. You need to assign the Administrators group Full Control to what they need to administer because Full Control grants the Change Permissions permission. You could try to figure out what permissions you need to manage an entire folder using just the components, but you'll quickly find you'll have to basically grant Full Control to be able to do any real administration anyways.

Take Ownership is primarily intended to be used when file permissions are accidentally completely removed (like your experience) or when user accounts are delete/disabled. Unlike chown, you can only assign ownership to yourself or to the Administrators group. Depending on how your backup software works, however, you might need a script to take control of files on your file servers.

Also note that Administrators have Take Ownership on the root folder of every disk in the system. You're not actually preventing a malicious member of the group from doing anything. They already have the keys to the kingdom, as it were. It's not defense in depth because there's no actual additional security mechanism. You just have to ask for ownership and you get it.

Here is an article that has more information than you'd ever want to know about Windows ACLs, including some good documentation on the older SDDL Access Control Entry format. This method has fallen out of favor a bit because Get-ACL and Set-ACL are so much easier to use... not that that is saying a whole lot.

  • Thanks for the quick response... So even using SYSTEM account will not help me set permissions on the entire file system. Are you saying that the best practice would be to remove Administrators Full Control and use take ownership when needed to set permissions or administer the file in any other way? Or would you rather say setting Administrators Full Control at the drive level and inheriting from it is the best practice? – Bibi195 Jan 25 '15 at 5:02
  • @Bibi195 The latter. Much of an Administrator's authority comes from the fact that they have full control of the file system, particularly %windir% and %programfiles%. The best practice option is to have sysadmins have two accounts: one in Users that they log in with and use normally, and one in Administrators that they elevate to as needed. However, that's a lot of overhead, and not everything works with RunAs or UAC elevation. It's putting hoops up that are harder to jump through than sudo or su, so many locations have sysadmins log in as Admins and rely on UAC as much as possible. – Bacon Bits Jan 25 '15 at 15:09
  • @Bibi195 I guess my question would be: what are you trying to accomplish by removing Full Control? Are you trying to prevent casual privacy violations? Do you have non-sysadmins with Administrator permissions? Or are you just trying to administer Windows like it was Linux? Because there's a lot of philosophical differences that resulted in design differences between the platforms, so not every practice is portable. It's perfectly possible to secure Windows, but you don't necessarily do it by copying what you do on Linux. – Bacon Bits Jan 25 '15 at 15:13
  • thanks a lot for you your answers. I mentioned Linux root specifically regarding permissions handling. Since this is a different question already I started a new thread here serverfault.com/questions/662235/… – Bibi195 Jan 25 '15 at 15:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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