I've been spending the quiet period after Christmas working on some scripts. For some time now I've felt the need for a report of permissions, hierarchically by directories in the DFS, and also per trustee. Reports like that would let me see a lot of things I want to see:
- Permissions on users: no users should have direct permissions
- Permissions on uncontrolled groups: if it's not a ROLE group it shouldn't deliver any access in the departmental filing
- Everyone/all users permissions: almost never correct
- I could run them on servers as part of the compliance checks
They would also remind me that there are things I want to address:
- ACEs referring to deleted accounts and groups -- There's a handy subinacl option to remove this
- "Domain Admin" permissions -- one of the techs here solved admin file access problems that way -- when what he needed was local administrator permissions
- Permissions delivered by SID-historied groups that need to be dropped or replaced
A good thing all round. The only problem is that they are very hard to get. It seems like there would be tools to do this, but I can't find anything suitable. Only after spending days hunched over a hot interpreter have I found why: it's moderately difficult, and the semantics of the report are surprisingly tricky.
- The simple approach doesn't work. If you build a hierarchy and read and report the ACL masks for each file and directory, the output is unusably difficult to understand. Even on one object there can be multiple ACEs for each trustee.
- And there's just too much data. Even if people could understand the access options implied by mask bits and types, there are ten million objects on our file servers. No-one reads a ten-million-line report.
The approach I've come up with with pretty crude, but I'm hoping it's going to do something useful:
- Don't try and represent the subtleties of permissions. Boil everything down to (none) Read, Write and Deny in that increasing order of priority. For any given trustee, only even think of reporting the highest priority. Fancy stuff like "deny execute, allow read" just shows up as the single "highest" permission: in this case it's Deny. (Oh yes, at this level, Deny is a permission, regardless of DACL type flags and ACE masks)
- Don't distinguish between inherited access and directly granted. What matters for reporting is the actual access. When you come to rectify, you'll need to know how it got there, but the Windows tools are good for that.
- Do use the concept of inheritance to trim down the report. The only permissions you need to report are where something changes. If a trustee gets a permission in the root of a ten-thousand-directory, 300-thousand-file volume, and every file and directory inherits it or has had it applied, then your report for that trustee is one line, not a third of a million lines.
- Assemble your basic reports for each trustee -- it makes the purging much easier. If you want to report a single directory structure with entries for all trustees, you can mash that together later.
- I've found three levels of interest in files (when they need a report at all)
- Leave them off entirely -- seems brutal but it cuts the run-times and you don't lose much
- Report them as a single aggregated pseudo-name "[one or more files]" for each directory -- this effectively raises a warning if any file is more permissive than the settings on its directory
- Report each individually following the same rules as for directories
- Expect to translate between the names you use to extract the permissions, and the names you report. Consider a DFS for example.
The down side of all this simplification is this: it's simple. That Everyone/Full permission that appears at the root and inherits all the way down is highly significant, but easy to miss. After all, it'll only be the one line. I think this means that we still need to apply automatic policy exception detection, but that is a project for the future.
