O
ovi
Guest
All production Windows networks need to have resources (folders, files, documents, spreadsheets, etc) made available from servers so users on the network can access them. The way this is done is through the use of shared folders configured on the servers which house the resources. The concept of shared folders has not changed over the generations of Windows operating systems and versions, but the protection of the resources has slightly changed. Whether you are new to the concept of shared folders or an expert, this article will take an in-depth look at the pitfalls and suggested methods on how to protect the resources that are shared from servers to users on the network.
The concept of a network of computers is not new or revolutionary. Servers, typically kept in locked rooms, store the company resources (folders, files, documents, spreadsheets, etc). These servers are locked behind closed doors so that the only access that employees have to the resources is over the network. So, one level of security for protecting the resource is the physical security that is provided by not allowing employees direct access to the hardware upon which the resource is located.
In order for employees to access the resources stored on the servers, the server must be configured to allow the employees to access the resources over the network. For a Windows environment, this is done through shared folders. When a folder is shared it becomes available over the network so that all users on the network can see the shared folder name.
In order to protect the resources that are made available through shared folders, administrators must configure �permissions� for the folders and files that are made available over the network. There are two types of permissions that can be configured on shared folders: share and NTFS. We are going to focus on the share permissions, discussing some pitfalls that are exposed when you use them, as well as some recommended methods to successfully configure permissions for shared folders.
A Tale of Two Permissions
To make sure that I am clear about my description of the permissions available on a shared folder, I wanted to start off by describing the two different permissions that can be configured on each shared folder. The two permissions are: share and NTFS.
NTFS permissions are an attribute of the folder or file for which they are configured. The NTFS permissions include both standard and special levels of settings. The standard settings are combinations of the special permissions, making the configuration more efficient and easier to establish. These permissions include the following:
* Full Control
* Modify
* Read & Execute
* List Folder Contents
* Read
* Write
There are 14 special permissions for folders, which include detailed control over creating, modifying, reading, and deleting subfolders and files contained within the folder where the permissions are established.
NTFS permissions are associated with the object, so the permissions are always connected with the object during a rename, move, or archive of the object.
Share permissions are only associated with the folder that is being shared. For example, if there are 5 subfolders below the folder that is shared, only the initial shared folder can have share permissions configured on it. NTFS permissions can be established on every file and folder within the data storage structure, even if a folder is not shared.
Share permissions are configured on the Sharing tab of the shared folder. On this tab, you will have a Permissions button, which exposes the share permissions when selected.
As you can see, the share permissions standard list of options is not as robust as the NTFS permissions. The share permissions only provide Full Control, Change, and Read. There are no special permissions available for share permissions, so the standard permissions are as granular as you can go for this set of access control.
The share permissions are not part of the folder or file, so when the share name is changed, the folder is moved, or the folder is backed up, the share permissions are not included. This makes for a fragile control of the share permissions if the folder is modified.
Historic Share Permissions
Microsoft has historically configured all new shared folders with very open share permissions. The default share permissions for Windows NT, Windows 2000 (Server and Professional), and Windows XP (pre Service Pack 1) is that the Everyone group has Full Control access.
This might seem insecure with Full Control access, but when the NTFS permissions are combined with the share permissions, the most secure of the two permissions controls the access to the resource.
In the past, when share permissions are altered from Everyone having Full Control, it can cause more problems than it is worth. For example, when a company typically does not use share permissions, it can take a longer cycle to fix access to resources when they are used. When share permissions are configured incorrectly on a shared folder, the share permissions are not the initial configuration to be checked. In most cases, I have found that it can take hours before the share permissions are investigated. During the troubleshooting procedures, users can be added to �admin� groups, given elevated user rights, and added directly to the ACL of the resource. When the share permissions are finally investigated and fixed, it can be hard to remember all of the other configurations that have been made in an attempt to fix the users access to the resource. Of course, this leaves the resource and overall network in an insecure state, all due to share permissions being configured incorrectly.
New Share Permissions
With all of the confusion that old share permissions could cause, Microsoft decided to change the rules for default share permissions with the release of Windows XP Service Pack 1. With every operating system after this service pack release (including Windows Server 2003), the new default permissions for all new shared folders is Everyone having Read only access, as shown in Figure 3.
This seems like a good security setting, until you consider how many resources on your network can actually have �read-only� access for everyone. There are not many, due to the fact that users need to modify and alter the contents of most resources to be productive.
In almost every instance the share permissions will need to be changed from Read access. This sets up the administrator to configure detailed share permissions, which can cause the issues that we discussed before with regard to troubleshooting resource access with the old share permissions being modified. With the share permissions being changed by default, I have found that many administrators don�t feel that they need to configure NTFS permissions anymore, as they rely on the share permissions to protect the resource. This is a gross error and leaves the network and resources in a very vulnerable state. Share permissions are only valid when the resource is accessed over the network, but not when it is accessed locally, using Terminal Services, etc. Also remember that share permissions are not backed up with resource, so all backed up files are vulnerable as well, without any permissions protecting them.
Share Permissions Best Practice
As a best practice, it is most efficient to configure share permissions with Authenticated Users having Full Control access. Then, the NTFS permissions should configure each group with standard permissions. This provides excellent security for local and network access to the resource. It also provides excellent protection of the resource for when it is backed up and when the resource name is changed or relocated. As I said earlier, the NTFS permissions will protect the resource even if the share permissions are set to Full Control access.
Summary
Share permissions are not inherently bad, but there are many ways to use them incorrectly. If documentation and the administrative staff are very savvy, share permissions can be used in conjunction with NTFS permissions to further lock and secure network resources. However, if there is little documentation and high turnover in the IT staff, it is a best practice to not use share permissions and to leave the security of network resources to the NTFS permissions. Even though Microsoft has changed the share permissions to be Read for the Everyone group, this does not indicate a real world solution. It is just Microsoft�s best attempt at increasing security on network resources, which is not a very good attempt unfortunately.
Source: windowsecurity.com/articles/Share-Permissions.html
The concept of a network of computers is not new or revolutionary. Servers, typically kept in locked rooms, store the company resources (folders, files, documents, spreadsheets, etc). These servers are locked behind closed doors so that the only access that employees have to the resources is over the network. So, one level of security for protecting the resource is the physical security that is provided by not allowing employees direct access to the hardware upon which the resource is located.
In order for employees to access the resources stored on the servers, the server must be configured to allow the employees to access the resources over the network. For a Windows environment, this is done through shared folders. When a folder is shared it becomes available over the network so that all users on the network can see the shared folder name.
In order to protect the resources that are made available through shared folders, administrators must configure �permissions� for the folders and files that are made available over the network. There are two types of permissions that can be configured on shared folders: share and NTFS. We are going to focus on the share permissions, discussing some pitfalls that are exposed when you use them, as well as some recommended methods to successfully configure permissions for shared folders.
A Tale of Two Permissions
To make sure that I am clear about my description of the permissions available on a shared folder, I wanted to start off by describing the two different permissions that can be configured on each shared folder. The two permissions are: share and NTFS.
NTFS permissions are an attribute of the folder or file for which they are configured. The NTFS permissions include both standard and special levels of settings. The standard settings are combinations of the special permissions, making the configuration more efficient and easier to establish. These permissions include the following:
* Full Control
* Modify
* Read & Execute
* List Folder Contents
* Read
* Write
There are 14 special permissions for folders, which include detailed control over creating, modifying, reading, and deleting subfolders and files contained within the folder where the permissions are established.
NTFS permissions are associated with the object, so the permissions are always connected with the object during a rename, move, or archive of the object.
Share permissions are only associated with the folder that is being shared. For example, if there are 5 subfolders below the folder that is shared, only the initial shared folder can have share permissions configured on it. NTFS permissions can be established on every file and folder within the data storage structure, even if a folder is not shared.
Share permissions are configured on the Sharing tab of the shared folder. On this tab, you will have a Permissions button, which exposes the share permissions when selected.
As you can see, the share permissions standard list of options is not as robust as the NTFS permissions. The share permissions only provide Full Control, Change, and Read. There are no special permissions available for share permissions, so the standard permissions are as granular as you can go for this set of access control.
The share permissions are not part of the folder or file, so when the share name is changed, the folder is moved, or the folder is backed up, the share permissions are not included. This makes for a fragile control of the share permissions if the folder is modified.
Historic Share Permissions
Microsoft has historically configured all new shared folders with very open share permissions. The default share permissions for Windows NT, Windows 2000 (Server and Professional), and Windows XP (pre Service Pack 1) is that the Everyone group has Full Control access.
This might seem insecure with Full Control access, but when the NTFS permissions are combined with the share permissions, the most secure of the two permissions controls the access to the resource.
In the past, when share permissions are altered from Everyone having Full Control, it can cause more problems than it is worth. For example, when a company typically does not use share permissions, it can take a longer cycle to fix access to resources when they are used. When share permissions are configured incorrectly on a shared folder, the share permissions are not the initial configuration to be checked. In most cases, I have found that it can take hours before the share permissions are investigated. During the troubleshooting procedures, users can be added to �admin� groups, given elevated user rights, and added directly to the ACL of the resource. When the share permissions are finally investigated and fixed, it can be hard to remember all of the other configurations that have been made in an attempt to fix the users access to the resource. Of course, this leaves the resource and overall network in an insecure state, all due to share permissions being configured incorrectly.
New Share Permissions
With all of the confusion that old share permissions could cause, Microsoft decided to change the rules for default share permissions with the release of Windows XP Service Pack 1. With every operating system after this service pack release (including Windows Server 2003), the new default permissions for all new shared folders is Everyone having Read only access, as shown in Figure 3.
This seems like a good security setting, until you consider how many resources on your network can actually have �read-only� access for everyone. There are not many, due to the fact that users need to modify and alter the contents of most resources to be productive.
In almost every instance the share permissions will need to be changed from Read access. This sets up the administrator to configure detailed share permissions, which can cause the issues that we discussed before with regard to troubleshooting resource access with the old share permissions being modified. With the share permissions being changed by default, I have found that many administrators don�t feel that they need to configure NTFS permissions anymore, as they rely on the share permissions to protect the resource. This is a gross error and leaves the network and resources in a very vulnerable state. Share permissions are only valid when the resource is accessed over the network, but not when it is accessed locally, using Terminal Services, etc. Also remember that share permissions are not backed up with resource, so all backed up files are vulnerable as well, without any permissions protecting them.
Share Permissions Best Practice
As a best practice, it is most efficient to configure share permissions with Authenticated Users having Full Control access. Then, the NTFS permissions should configure each group with standard permissions. This provides excellent security for local and network access to the resource. It also provides excellent protection of the resource for when it is backed up and when the resource name is changed or relocated. As I said earlier, the NTFS permissions will protect the resource even if the share permissions are set to Full Control access.
Summary
Share permissions are not inherently bad, but there are many ways to use them incorrectly. If documentation and the administrative staff are very savvy, share permissions can be used in conjunction with NTFS permissions to further lock and secure network resources. However, if there is little documentation and high turnover in the IT staff, it is a best practice to not use share permissions and to leave the security of network resources to the NTFS permissions. Even though Microsoft has changed the share permissions to be Read for the Everyone group, this does not indicate a real world solution. It is just Microsoft�s best attempt at increasing security on network resources, which is not a very good attempt unfortunately.
Source: windowsecurity.com/articles/Share-Permissions.html
