How IT WorksNTFS Permissions, Part 2
Figure 1 NTFS Special Permissions
.gif)
Figure 3 Group Permissions
Figure 4 Group Membership and Permissions
.gif)
.gif)
.gif)
Richard Civil runs Civil Consulting and Training, and is Senior Technical Trainer at New Horizons in Beaverton, OR. A professional trainer since 1992, Richard also holds MCT, MCSE, MCP+I, SCPI, and IC3 certifications. Learn more about Richard at www.rcivil.com.
Original:
Richard Civil
While security is essential in today’s network, unfortunately some administrators think they are secure if they just have a good firewall. Various studies suggest that up to 65 percent of all network compromises happen from inside the firewall.
There are three areas of security where having a firewall will not help—and these are perhaps more important than having a firewall. Physical security is number one on my list. One of the Microsoft 10 Immutable Laws of Security states "If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore." You must ensure that any computer that has sensitive data stored on it is physically secure.
Number two on my list is a solid authentication method. Unfortunately, many organizations have very relaxed password policies. Another of the 10 Immutable Laws of Security states, "Weak passwords trump strong security." If I can impersonate you I do not need physical access.
Number three on the list, and the one that requires the most ongoing attention, is proper NTFS permissions. NTFS permissions can seem overwhelming at first. There is a lot to understand: file system permissions, share permissions, inherited and direct permissions, effective permissions, ownership, Kerberos, NTLM, Ticket Granting Tickets, Access Tokens, and more. Let’s see if I can help you make sense of all this and learn some neat tricks along the way.
Basics of NTFS Permissions
NTFS permissions include both standard and special permissions. Standard permissions on a folder are Full Control, Modify, Read & Execute, List Folder Contents, Read, and Write. Standard file permissions are the same, with the exception of List Folder Contents. Special permissions are considerably more granular, as you can see in Figure 1.
Figure 1 NTFS Special Permissions| Permission | Description |
| Full Control | Specifies whether a user has all other permissions for a file or folder. |
| Traverse Folder/Execute File | For folders, specifies whether a user can move through folders to reach other files or folders. For files, specifies whether a user can run an executable. |
| List Folder/Read Data | For folders, specifies whether a user can view file names and subfolder names within the folder. For files, specifies whether a user can view data in files. |
| Read Attributes | Specifies whether a user can view the attributes of a file or folder, such as read-only and hidden. |
| Read Extended Attributes | Specifies whether a user can view the extended attributes of a file or folder. |
| Create Files/Write Data | For folders, specifies whether a user can create files within the folder. For files, specifies whether a user can change files or overwrite data. |
| Create Folders/Append Data | For folders, specifies whether a user can create folders within the folder. For files, specifies whether a user can make changes to the end of the file, but not change, delete, or overwrite existing data. |
| Write Attributes | Specifies whether a user can change the attributes of a file or folder. |
| Write Extended Attributes | Specifies whether a user can change the extended attributes of a file or folder. |
| Delete Subfolders and Files | Specifies whether a user can delete a subfolder or file, even if the Delete permission has not been granted on the subfolder or file. |
| Delete | Specifies whether a user can delete a file or folder. |
| Change Permissions | Specifies whether a user can change permissions on a file or folder. |
| Take Ownership | Specifies whether a user can take ownership of a file or folder. |
Each permission, whether standard or special, has both an Allow and a Deny setting. Deny beats Allow if they are applied on the same file or folder. If the permissions are inherited, then the Allow and Deny work a bit differently (for more information regarding this topic, see my column in the November-December 2005 issue of TechNet Magazine at How IT works: NTFS Permissions.
So how do you control what objects receive the permissions you assign? Permissions do not have to apply to the default of "This folder, subfolders and files." You have quite a bit of control in this process, and there are some neat tricks as well. When you assign permissions to a user or group and click Advanced, you have the opportunity to assign very granular permission settings. Near the top of this property sheet is the Apply onto menu, shown in Figure 2. If you select This folder only, the permissions will be inherited by new objects placed in the folder, but existing files and folders will not be affected by the new permissions. With the Apply onto setting, you are controlling which object types will inherit the assigned permissions. These granular permission settings can be used in some very creative ways with useful results.
Figure 2 Specifying Where to Apply Permissions
Several of my clients have wanted a shared folder in which employees can add and modify their own files, but only have Read permission for the files other employees have created. This is an easy procedure.
- Grant the Read & Execute and Write permissions for This folder only (selected in the Apply onto list) to the users you want to have access to the folder.
- Grant the Read & Execute permission for the Subfolders and files only to the same users.
- Grant the Write permission to the special user Creator Owner.
The effect of this is that all of the users will be able to add files to the folder and read each other’s files, but only the user that created a file will be able to modify it.
One of the challenges of NTFS permissions is that it follows the discretionary access control list (DACL) model. The difficulty of the DACL model is that the creator of an object is the owner of that object and can set any permissions they choose. This can pose a major security challenge in a high security area of your file system. Unfortunately, not all users have the same level of discretion when it comes to security issues.
One of the better solutions I have come across involves scripting. You will find instructions for using the File Ownership Script Tool at HOW TO: Use the File Ownership Script Tool (Fileowners.pl) in Windows 2000. This Knowledge Base article should help you get started using the script even if you have limited scripting or programming skills.
Once you take ownership of the file or folder, the user who created the object cannot change the permissions you set unless, of course, you give them that permission. The next questions are when does the administrator take ownership, and what happens if the user changes the permissions before the administrator takes ownership. There is excellent information at Watching Folder Activity in VB.NET. You will need some programming skills and the Microsoft® .NET Framework installed, as well as Visual Studio® .NET (version 1.0 or later). This site takes you through the steps to create code that can monitor a folder for activity and direct how to respond to that activity. If you combine both of these resources, you can monitor a folder and take ownership automatically as soon as a user creates an item.
Permissions and File Systems
Maintaining the correct set of permissions is much easier if you have designed your file system with permissions in mind. Most of my clients have a complete jumble of permissions in each branch of the directory tree, which takes careful planning and lots of time to fix. To maintain security of your file system, one of the most important things you can do is arrange the system so that each branch of the directory tree has one set of permissions. This lets inheritance work for you instead of against you.
Let’s assume that you are using the D: drive for departmental files and each department has managers, workers, and assistants. To get started, create a global group for each job description and add the appropriate users to the appropriate group. It is a very good idea to give permissions to groups rather than individuals. (I’ll discuss more on this topic in a bit.) Next, assign the Administrators Group Full Control of D:\. Administrators will have full control of everything by inheritance. Finally, give the different groups the permissions shown in Figure 3.
Figure 3 Group Permissions| Group | Permissions |
| Managers | Modify |
| Workers | Read & Execute, Write |
| Assistants | Read & Execute |
Remember to use the permissions that are appropriate in your organization. If permissions have been modified in one of the departmental folders, it’s very easy to restore the permissions you set. To do so, just right-click on the departmental folder and choose Properties. In the properties dialog box, click on the Advanced tab, click the Advanced button, and check Replace permission entries on all child objects with entries shown here that apply to child objects. This will force the departmental folder permissions down the tree and will remove any other permissions. This will even force these permissions on files and folders that have inheritance blocked.
Groups and Permissions
Understanding groups and how to use them is essential to proper permissions. There are four different types of groups you can use: local, domain local, global, and universal. Each group type has its own rules for membership and where it can be used. Local groups exist on member servers and workstations. Local groups can only be used to assign permissions to resources on the local computer, but can have members from any domain in the forest. Domain local groups can have permissions to resources in the local domain and can have members from any domain in the forest. Global groups can have permissions anywhere in the forest (hence global), but can only have members from the local domain. Universal groups can have members from any domain in the forest and can have permissions to resources in any domain in the forest. The groups are summarized inFigure 4.
Figure 4 Group Membership and Permissions| Group Type | Member Scope | Permission Scope |
| Local | Any domain in the forest | Local machine |
| Domain Local | Any domain in the forest | Local domain |
| Global | Local domain | Anywhere in the forest |
| Universal | Any domain in the forest | Anywhere in the forest |
I like the way Microsoft now presents the groups as being in two categories: user groups and resource groups. The two user category groups are global groups and universal groups. Global groups are the primary group type for users. Add users that need access to the same resources into the same global group. If there are several domains in your forest and there are global groups in multiple domains that need access to resources in multiple domains, add the global groups to universal groups.
Domain local and local groups are considered to be resource groups. Essentially, you give permissions to a domain local or local group and then add global or universal groups to the domain local or local group to receive the assigned permissions. I’ll take a closer look at domain local and local groups later in this column.
The task of assigning permissions needs to be approached with care and attention to detail. Every time you assign permissions there is a chance to compromise the security of your data. The basic idea is to assign permissions to a group once, then add users to the group to get those permissions. That way, you assign permissions a minimum number of times.
In a smaller environment, it is often an acceptable practice to use global groups for both organizing users and for permissions. Name the global groups in a manner that gives you an idea of the group membership and group type. A global group containing accountants from the ABC domain might be named gg_acountants_ABC.
Larger environments necessitate a bit more complexity. Give permissions to domain local groups and add the global groups to the domain local groups to get the assigned permissions. Naming is also important with domain local groups. The name should reflect the group type, the resource, and the assigned permission. Say you have a folder named Data on a server named FileSrv1. If you want a domain local group to have Read permission for this folder, the group should have a name like DL_Data_FileSrv1_read. Give the domain local group the desired permission and add the global groups for the users that should get that permission. It can be time consuming to set up, but once it’s done you can easily control access to resources just by moving users into and out of global groups. The names of the groups should make it clear at a glance what permissions you are effectively granting.
If you hire a data entry person, you can just add him to the DataEntry global group and he automatically has access to all of the resources that data entry workers should have. If your new employee does a great job and the company promotes him to the help desk, you can take him out of the DataEntry group and add him to the HelpDesk Group.
It should be obvious at this point that a well-planned and carefully implemented file system and proper permissions are essential. Users can be in many global groups, which can be nested in many universal or domain local groups. Even with the best planning, it can be difficult to determine exactly what permissions a specific user has to a specific file or folder, though Windows® XP and Windows Server™ 2003 make it much easier.
Figure 5 Effective Permissions for a Particular User
To find the effective permissions for a user to access the property sheet of the file or folder, select the Security tab, click the Advanced button, and then select the Effective Permissions tab. Click the Select button and select the user you want to assess. Click OK and the property sheet will now show you the effective permissions for that user (see Figure 5). You can only read, not change, permissions on the Effective Permissions tab. Remember, though, that the information shown here only deals with the NTFS part of what comprises the actual effective permissions. Share Permissions must also be taken into account to find the user’s actual permission to a file or folder.
Share Permissions
To access a file or folder remotely, both NTFS and Share Permissions are evaluated to determine the actual rights the user has to that object. Between NTFS and Share Permissions, the effective permissions are whichever is most restrictive. If the NTFS permission is Read and the Share Permission is Full Control, the effective permission is Read because it is the most restrictive. If the NTFS and Share Permissions were reversed, Read would still be the effective permission.
NTFS and Share Permissions work quite differently from each other. NTFS has a rather complex process of inheritance (see "NTFS Permissions" in the November-December 2005 issue of TechNet Magazine) but essentially a user gets the combination of NTFS permissions assigned to them and any groups they are in, including nested groups. In general, Deny overrides Allow. You have to enter the file system on a remote computer by accessing a share. The Share Permissions are evaluated on the share you use to enter the file system. There is no inheritance with shares. The Share Permissions assigned on the share you used to enter the file system are the permissions you have in that branch of the directory tree, even if there is another share lower in the tree with different permissions.
Figure 6 Hierarchy of Shared Folders
For example, I share a folder named TestFolder and allow Full Control permis-sion to the Everyone group. There is a folder nested inside TestFolder named InsideTest. I share InsideTest and deny Full Control permission to the Everyone group (see Figure 6).
When I access the computer using a UNC path, I see both TestFolder and InsideTest as top-level shared folders. There is no indication that these are actually nested folders. If I double-click InsideTest, I am denied access, as expected, due to the Deny permission. If I double-click TestFolder and then in the window that opens double-click InsideTest, I have Full Control permission to that folder. I entered the file system through the TestFolder share, so I have the share permission of Full Control throughout that branch of the directory tree (see Figure 7).
Figure 7 Effective Share Permissions
In the previous example, the D: drive is being used for departmental files. Each department has managers, workers, and assistants that need specific permissions as well as the administrators who need full control of the entire volume. The administrators group has full control of each drive by default. Inheritance will propagate this to all of the departmental folders, so the NTFS permissions for the administrators group are granted automatically. The root of each drive is also shared as a hidden share (D$ in this case) with administrators having full control. Each departmental folder needs to be shared with department managers getting Change permission, department workers also getting Change permission, and department assistants assigned Read permission.
The first thing I usually do with both share and NTFS permissions is remove the Everyone group. Everyone includes anonymous accounts like Guest and IUSR_computername (the Internet guest account). In Windows NT® and Windows 2000 the Everyone group also includes null sessions. Authenticated Users includes all valid user and computer accounts in the forest, but does not include any guest or anonymous accounts. Most of the time if you want to give permissions to everyone, what you actually mean is Authenticated Users.
Permissions and Active Directory
Let’s take a quick look at how the processes of authentication and authorization work in Active Directory®. Windows 2000 and later uses Kerberos, a certificate-based secure protocol, for both of these processes.
When a user logs on to a domain, a Ticket-Granting-Ticket (TGT) is created. This ticket contains the security identifiers (SIDs) of the user as well as all groups that the user is a member of, including nested groups. If the user is in 25 global groups which are each in 25 domain local groups, that is a total of 650 SIDs on the TGT. A SID looks something like this: S-1-5-21-3204519953-1226544935-3965933272-1009. The first part of the SID identifies the database to which the account belongs. The last part is the Relative Identifier (RID). The RID of this account is 1009. The RID increments by one for each new account and Active Directory can create literally billions of accounts. The moral of this story is that SIDS can be large and having a TGT containing 650 SIDS will be very large. Most users will have considerably fewer than 650 SIDS on their TGT, but even a small TGT is a fairly substantial object.
The TGT is only part of the story. Every resource a user accesses on a remote computer causes quite a chain of events. Let’s say you try to access \\Computer1 through Explorer. Your computer sends your TGT (with all of the SIDs) to the domain controller with a request to access Computer1. The domain controller verifies the SIDs and puts them on a Session Ticket (ST), also called a Service Ticket, and sends it back to your computer. Your computer sends the ST to Computer1 with the request for access.
Practically speaking, this authentication process means that all of the SIDs hit the network three times for each network access. If you have plenty of bandwidth, this is fine. If you have bandwidth issues, especially when everyone first logs on for the day, consider using local groups instead of domain local groups.
When the ST arrives at the destination, Computer1 extracts the SIDs from the ST and searches the local Security Account Manager (SAM) database and retrieves the SIDs for local groups that the user belongs to. The SIDs of these local groups are added to the Access Token on the computer where they reside. Local groups never hit the wire. The SIDs on the Access Token are measured against the SIDs on the DACL to determine the user’s access level to the requested resource. In the previous example, if I used local groups instead of domain local groups, the tickets would have contained 25 SIDs instead of 650.
Another way to conserve on the number of SIDs on the tickets is to use each domain local group on multiple resources. Unfortunately, security tends to slip when domain local groups are multi-purposed. Say your organization has five administrators and each of these administrators has control of different resources. Administrator Alex creates a domain local group and gives it permission to several resources under her control. The other four administrators do the same. Now this one domain local group has been given access permissions to many resources under different administrators’ control.
Here’s where things come unglued. Some users from a specific department call administrator Alex and complain that they do not have access to one of the resources. Alex solves the problem by adding a global group containing the users in that department to the domain local group that has permissions to the resource. Now those users have access to all of the different resources that each of the administrators have given that domain local group access to. As you can see, it’s just too easy to combine users and groups in ways that affect permissions on many resources unintentionally.
I recommend single-purposing domain local groups (one group for one permission on one resource) unless you have a very organized IT department, or your organization has data that does not require much in the way of security.
Conclusion
Physically securing computers that contain sensitive data and establishing a solid authentication methodology such as smart cards or complex passwords are the first steps toward keeping your network secure. Within your network, you can create a group permissions strategy that works for your organization.
The Microsoft strategy is embodied in the cryptic A-G-DL-P. Accounts go into global groups, which go into domain local groups, which are assigned permissions to resources. This method will work for many organizations. Remember to avoid giving domain local groups permissions for multiple resources, which can circumvent your efforts at more granular control over permissions.
Also remember to carefully apply NTFS and share permissions. Give users the level of access that they need to do their job and no more. Permissions can be inherited through shares, so plan your file system and share strategy accordingly. A little foresight and planning will give you better results further down the road.
Original:
No comments:
Post a Comment