Friday, October 31, 2014

Why Effective Permissions Sometimes Aren't Correct

You may have noticed that Windows's "Effective Permissions" utility (somewhere in the Security tab on files) doesn't always report what permissions you have correctly, especially if you have local admin and not domain admin. This is due to a subtlety of SIDs.

A Security IDentifier (SID), uniquely (ding ding ding! there's the key) identifies a security principal - a user, group, or special claims-based thing like TrustedInstaller. Users on a domain each have a SID and that is unique across all computers. The Administrators group (for which most files have an ACL entry), however, is not specific to a domain or computer. Its SID is always S-1-5-32-544, whether it's the Administrators group on the domain (not the Domain Admins group), the Administrators group on the file server, or an Administrators group on some random client computer.

Suppose you're a local admin on your machine and therefore a member of S-1-5-32-544 on your computer. When you hand your impersonation token over to a file server and say "hey, I'm an admin, gimme this file!", it says "alright, let me check that", consults its impression of S-1-5-32-544 (because it has a group with that SID, of course), says "hey, you're not on that list!", and denies you access.

Your computer, on the other hand, sees the ACL entry for S-1-5-32-544, says "oh cool, you're a part of that, you can have all the access." The Effective Permissions utility does not ask the remote host; it only checks the SIDs on the ACL.

There might be other ACLs you can't see, like the ones in the mini-ACL editor you get when running the Advanced Sharing wizard. Those aren't on the file system like normal ACLs; they're extra restrictions processed by the LanMan service. You might also be subjected to restrictions for situation-based principals like Network (S-1-5-2), the faux-group of people who are remotely accessing the file.

No comments:

Post a Comment