SetACL

This article presents two different detection types for insecure filesystem permissions on Windows endpoints: scanning for directories that are user-writable, and detecting processes that are started from user-writeable directories. Directory Scan With ListUserWriteableDirectories & SetACL My ListUserWriteableDirectories script is an implementation of the first detection type: it scans the filesystem listing any permissions not known to be safe.

What could be geekier than a t-shirt imprinted with actual source code from a tool that helps administrators around the world tame one of the most dreaded beasts in IT: permissions?

This is a complete listing of all Windows 7 HKEY_CURRENT_USER registry permissions. The list was generated on a 32-bit installation with SetACL. More default permission listings can be found here.

Due to a lack of visibility permission cleanup is performed far less frequently than it could, and probably should. As a result, ghost ACEs (permissions from deleted accounts) linger in the dark corners of the file system, threatening the unsuspecting admin with the horrors of unresolvable SIDs.

When you are planning a migration of user accounts between domains one task always pops up pretty quickly: reassigning the permissions of the users in the source domain to the corresponding users in the target domain, in other words reACLing the file server.

Last month SetACL reached the magic number of 500,000 downloads. That is a lot, especially for a command-line tool which is focused on a very specific aspect of system administration.

This is what I’ll be wearing at next week’s WINone: Setacl ShirtAnd yes, the letters are made up of actual source code ;-)

This article is part of Helge’s Profile Toolkit, a set of posts explaining the knowledge and tools required to tame Windows user profiles. When administrators migrate user accounts between domains, they typically re-ACL those server resources users have access to. In plain English: they copy or move the permissions from the accounts of the old domain to the corresponding accounts of the new domain. There are various ways to do that. In this article, I present a simple way to re-ACL roaming user profiles.

Here is an interesting tidbit related to Windows security: Create a test file share, e.g. C:\temp\test, and share it with full permissions for everyone (share, not NTFS permissions) as “test” Create the following directory hierarchy below the share: C:\temp\test\1\2\3\4 Assign ownership of the four folders 1, 2, 3 and 4 to any user (but do not use your own account, just anyone else’s) Set permissions on 1, 2, 3 and 4 that only the user from the previous step has full access, nobody else, not even the SYSTEM Now try to use SetACL to change the owner of directory “4” over the network (SetACL uses backup and restore privileges so this should be no problem) by issuing the following command locally: setacl -on \localhost\test\1\2\3\4 -ot file -actn setowner -ownr n:domain\administrator SetACL will fail with access denied (full message: “ERROR: Writing SD to <\?\UNC\localhost\test\1\2\3\4> failed with: Access is denied.”) Now issue the same command, but instead of using a UNC path use the local drive letter: setacl -on c:\temp\test\1\2\3\4 -ot file -actn setowner -ownr n:domain\administrator That works! Why is this so? I have no clue.

Updated: 2021-06-22 Every object that can have a security descriptor (SD) is a securable object that may be protected by permissions. All named and several unnamed Windows objects are securable and can have SDs, although this is not widely known. There does not even exist a GUI for manipulating the SDs of many object types! Have you ever tried to kill a system process in Task Manager and got the message “Access denied”? This is due to the fact that this process’ SD does not allow even administrators to kill the process. But it is, of course, possible, as an administrator, to obtain the necessary permissions, provided a GUI or some other tool is available.

On file servers in corporate environments one typically does not want users to change permissions, even on their own files. It might seem that it would be sufficient to simply grant change permissions instead of full control, but unfortunately that is not the case. The problem is that whenever a new file gets created, the user creating the file will be its owner. And owners can always change permissions, regardless of the contents of the DACL.