In Part 3, we looked at permissions for applications. In the last part of our Permissions series, we’ll look at troubleshooting permissions and some best practices.
Troubleshooting permissions involves figuring out what is wrong with one of two distinct problems. If you are troubleshooting permissions in Windows and you do make any changes to group memberships as a part of your troubleshooting, remember to have your users log off and back on so that their logon picks up the new group membership(s.)
When a user has too many permissions, they can do things they should not, like edit a file that should be read only, or read a file to which they should not have access, or make changes to a system when they are not supposed to be an administrator. For file systems, look at effective permissions and then evaluate both group memberships and inheritance to see where a user is obtaining their effective permissions. Remember that except for “DENY ALL” Windows treats permissions as additive, so if I am in a group with READ ONLY and I am also in a group with CHANGE, then I get CHANGE.
The more common issue involves too few permissions, such as when you should be able to edit a file but it is limited to READ ONLY. While you can simply assign the permissions explicitly, often this is not caused by permissions at all, but rather by attributes. Don’t forget that a file can be flagged READ ONLY, and if it is, even though you do have permissions, you cannot edit or delete that file. Check the properties or the attributes and remove the READ ONLY if it is set.
If users have no permissions assigned to them or to a group to which they belong, then they won’t have access. But also remember that the DENY ALL permission is the trump card and will override any other permissions, including FULL CONTROL. Check effective permissions and if the user has none, add them to the appropriate group. If a user is in a group that has any permissions at all and still gets Access Denied, look for another group or higher up application of the DENY ALL permission.
Tools to use
In Windows, you can use Explorer to view and assign permissions. Right-click a file or folder to view properties, then go to the Sharing or Security Tab, and check assignments there. On the security tab, click the Advanced button to see whether inheritance is enabled or disabled. From there you can also access the Effective Access tab, which will let you view the effective permissions for any user or group. If you are an administrator, you can also enable auditing to get more details in the security logs when the user tries again. The command line tool CACLS can be used to display or modify permissions in the Windows file system.
In Active Directory, use Active Directory Users and Computers to do much the same as you would in the File System, including viewing properties to check inheritance and even effective permissions. The command line equivalent is DSACLS.
The security log in Event Viewer is a great way to see what is going on with access, but be sure you have enabled auditing to get sufficient detail.
When troubleshooting network applications, a network analyzer like Netmon or Wireshark is a great tool. Often you will see actual messages in the trace that an app doesn’t display or log, including those related to logon failures or Access Denied messages.
Here are some best practices that will help to reduce the amount of troubleshooting you need to do with permissions.
Leverage inheritance. It’s supposed to work as it does, and when you set permissions to something higher up in a tree, it should flow down to all objects underneath. If you find yourself wanting to disable inheritance, you’re probably going about things the wrong way. Move the child object(s) to a different level, or rethink your group memberships. You can run multi-TB-sized enterprise file systems and Active Directories for hundreds of thousands of users without ever having to disable inheritance anywhere in either.
No matter which operating system or application you’re using, the concept of least privilege is one that should be followed. No one has ever been fired and no security incident has ever occurred because an admin gave someone too few rights. If someone needs access to data, and the data owner has approved that, then they get READ ONLY unless they explicitly ask for and are permitted to have CHANGE. And no one gets FULL CONTROL unless they are the SysAdmin or data custodian responsible for granting others access.
Groups before users
Finally, if you are thinking about granting permissions to an individual, don’t. Always assign permissions to groups. That way, if others need similar permissions you can assign them membership in the group. If a user no longer needs access, you can remove them from the group. The only exception to this is for users’ own home directories. Anywhere else, stick with groups.
We hope you have enjoyed this mini-series on permissions and found it to be useful. We put this series together at the request of one of our readers, so if there is a topic or area that you would like us to blog about, leave a comment below.