Computers running Windows operating systems can work with various file systems such as FAT32 and NTFS. Without going into similarities, we can say one thing that they differ in the main - the NTFS file system allows you to configure security settings for each file or folder (directory). Those. For each file or folder, the NTFS file system stores so-called Access Control Lists (ACLs), which list all users and groups that have specific access rights to a given file or folder. The FAT32 file system does not have this capability.

In the NTFS file system, each file or folder can have the following security rights:

• Reading- Allows browsing folders and viewing the list of files and subfolders, viewing and accessing the contents of the file;
• Recording- Allows adding files and subfolders, writing data to a file;
• Reading and Executing- Allows browsing folders and viewing the list of files and subfolders, allows viewing and accessing the contents of the file, as well as launching the executable file;
• List of folder contents- Allows browsing folders and viewing only the list of files and subfolders. This permission does not give access to the contents of the file !;
• Change- Allows viewing content and creating files and subfolders, deleting a folder, reading and writing data to a file, deleting a file;
• Full access- Allows viewing content, as well as creating, modifying and deleting files and subfolders, reading and writing data, and modifying and deleting a file

The above rights are basic. Basic rights are made up of special rights. Special rights are more detailed rights from which the basic rights are formed. Using special rights gives you a lot of flexibility when setting up access rights.

List of special access rights to files and folders:

• Browse folders / Execute files- Allows moving through the folder structure in search of other files or folders, executing files;
• Folder content / Read data- Allows viewing the names of files or subfolders contained in a folder, reading data from a file;
• Reading Attributes- Allows viewing such attributes of a file or folder as "Read Only" and "Hidden";
• Reading additional attributes- Allows viewing additional attributes of a file or folder;
• File Creation / Data Writing- Allows creating files in a folder (applies only to folders), making changes to a file and overwriting existing content (applies only to files);
• Create folders / Add data- Allows creating folders in a folder (applies only to folders), adding data to the end of the file, but not modifying, deleting or replacing existing data (applies only to files);
• Attribute writing- Allows or denies the change of such attributes of a file or folder as "Read Only" and "Hidden";
• Writing additional attributes- Allows or denies the change of additional attributes of a file or folder;
• Removing subfolders and files- Allows deleting subfolders and files even if you do not have the "Delete" permission (applies only to folders);
• Deleting- Allows deleting a file or folder. If the file or folder does not have the Delete permission, you can still delete the object if you have the Delete subfolders and files permission on the parent folder;
• Reading Permissions- Allows reading of such file or folder access permissions as "Full Control", "Read" and "Write";
• Change permissions- Allows changing such permissions to access a file or folder, such as "Full Control", "Read" and "Write";
• Change of owner- Allows to take possession of a file or folder;
• Synchronization- Allows different streams to wait for files or folders and synchronize them with other streams that might be occupying them. This permission applies only to programs running in multithreaded mode with multiple processes;

!!! All basic and special rights are both permissive and prohibitive.

All file and folder permissions are divided into two types: explicit and inherited. The inheritance mechanism implies the automatic transfer of something from the parent to the child. In a file system, this means that any file or folder can inherit its rights from the parent folder. This is a very convenient mechanism that eliminates the need to assign explicit rights to all newly created files and folders. Imagine that you have several thousand files and folders on some disk, how can you give them all access rights, sit and assign each one? No. The inheritance mechanism works here. We created a folder in the root of the disk, the folder automatically received exactly the same rights as the root of the disk. Changed the rights for the newly created folder. Then another subfolder was created inside the created folder. This newly created subfolder will inherit permissions from the parent folder, and so on. etc.

The result of the use of explicit and inherited rights will be the actual rights to a specific folder or file. At the same time, there are a lot of pitfalls. For example, you have a folder in which you allow the user "Vasya" to delete files. Then you remember that there is one very important file in this folder, which Vasya should not delete under any circumstances. You set an explicit ban on an important file (special ban right "Removal")... It would seem that the deed is done, the file is clearly protected from deletion. And Vasya calmly enters the folder and deletes this super-protected file. Why? Because Vasya has the right to delete from the parent folder, which in this case are priority.

Try not to use the assignment of rights directly to files, assign rights to folders.

!!! Try to assign rights only to groups, this greatly simplifies administration. The assignment of rights to specific users is not recommended by Microsoft. Do not forget that a group can include not only users, but other groups as well.

For example. If a computer is included in a domain, then the Domain Users group (domain users) is automatically added to its local Users group, and the Domain Admins group (domain administrators) is automatically added to the local Administrators group, and accordingly, assigning to any folder rights to a group of local users, you automatically assign rights to all users of the domain.

Do not be discouraged if everything described above is not very clear at once. Examples and independent work will quickly fix the situation!

Let's get down to specifics.

All examples I will show on the example of Windows XP windows. In Windows 7 and higher, the essence remained the same, only there were a little more windows.

So, in order to assign or change the rights to a file or a pack, you need to right-click on the desired file or folder in the explorer, select the menu item "Properties"

You should open a window with a bookmark. "Security"

If there is no such tab, then we do the following. Launch Explorer, then open the menu "Service"—"Folder properties…"

In the window that opens, go to the "View" tab and uncheck the parameter Use Basic File Sharing (Recommended)

That's it, now all the properties of the NTFS file system are available to you.

Back to the bookmark "Security".

A lot of information is available to us in the window that opens. Above is the list "Groups and users:", which lists all users and groups that have access rights to this folder (arrow 1). The lower list shows the permissions for the highlighted user / group (arrow 2). In this case, this is the SYSTEM user. In this list of permissions, you can see the base permissions. Please note that in the column "Allow" check marks are faded and not editable. This indicates that these rights are inherited from the parent folder. Once again, in this case, all SYSTEM user rights to the folder "Working" are completely inherited from the parent folder, and the SYSTEM user has all rights ( "Full access")

By highlighting the desired group or user in the list, we can see the basic rights for this group or user. Highlighting the user "Guest user ( [email protected])» you can see that he has all explicit rights

And here is the group "Users (KAV-VM1 \ Users" has combined rights, some of them are inherited from the parent folder (gray squares opposite Read and Execute, "List of folder contents", "Reading"), and the part is explicitly established - this is the right "Change" and "Record"

!!!Attention. Pay attention to the names of users and groups. The parentheses indicate the belonging of the group or user. Groups and users can be local, i.e. created directly on this computer, and can be domain. In this case, the group "Administrators" local, since the entry in brackets indicates the name of the KAV-VM1 computer, and the slash is followed by the name of the group itself. On the contrary, the user "Guest user" is a user of the btw.by domain, as indicated by the full name record [email protected]

Often, when viewing or changing rights, you can limit yourself to a window with basic rights, but sometimes this is not enough. Then you can open a window in which you change the special permissions, the owner, or view the effective permissions. How to do it? Click on the button "Additionally"... This window opens.

In this window in the table Permission Items all users who have rights to this folder are listed. In the same way as for basic permissions, we select the desired user or group and click the button "Change"... A window opens showing all the special permissions for the highlighted user or group

Similar to base permissions, special permissions inherited from the parent folder will be shown in a dim gray color and will not be editable

As you may have noticed, there are several lines in the special permissions window for some users or groups.


This is because for one user or group there can be different types of rights: explicit and inherited, allowing or denying, differing in the type of inheritance. In this case, read rights for the Users group are inherited from the parent folder, and edit rights are explicitly added.

Examples of assigning rights.

!!! All examples will come with increasing complexity. Read and deal with them in the same sequence as they go in the text. I will omit actions of the same type in the following examples in order to reduce the amount of text. 🙂

Example 1. Granting read-only access to a folder to a specific local security group.

First, we will create a local group, into which we will include the entire list of users we need. It is possible without a group, but then for each user you will need to configure the rights separately, and every time you need to give rights to a new person, you will need to do all the operations again. And if you grant the rights to a local group, then only one action is required to set up a new person - including this person in the local group. We read how to create a local security group in the article "Configuring local security groups".

So. We have created a local security group named Read Colleagues


to which all the necessary users have been added.

Now I set up access rights to the folder. In this example, I will make the access rights of the created group "To Colleagues for Reading" per folder "Photo".

Right click on the folder "PHOTO" and select the menu item "Properties", go to the bookmark "Security".

In the opened tab "Security" the current folder rights are displayed "PHOTO"... Having selected groups and users in the list, you can see that the rights of this folder are inherited from the parent folder (gray checkmarks in the column "Allow"). In this situation, I do not want anyone other than the newly created group to have at least some access to the folder "PHOTO".

Therefore, I must remove the inheritance of rights and remove unnecessary users and groups from the list. I press the button "Additionally"... In the window that opens,


uncheck the box "Inherit from parent object permissions applicable to child objects, adding them to those explicitly set in this window." ... This will open a window in which I can choose what to do with the current inherited rights.

In most cases, I advise you to click the button here. "Copy", because if you choose "Delete", then the list of rights becomes empty, and you can actually take the rights from yourself. Yes, don't be surprised, it's very easy to do. And if you are not an administrator on your computer, or not a user of the group "Archive Operators", then it will be impossible for you to restore the rights. The situation is like a door with an automatic latch that you close while leaving the keys inside. Therefore, it is better to always press the button. "Copy", and then delete the unnecessary.

After I pressed "Copy", I again return to the previous window, only with the unchecked box.

I press "OK" and go back to the basic rights window. All rights are now available for editing. I need to leave the rights for the local group "Administrators" and user SYSTEM, and delete the rest. I select unnecessary users and groups one by one and click the button "Delete".

As a result, I get the following picture.

Now I just have to add the group "To Colleagues for Reading" and assign read rights to this group.

I press the button "Add", and in the standard selection window I select the local group "To Colleagues for Reading"... How to work with the selection window is described in detail in the article.

As a result of all the actions, I added the group "For colleagues for reading" to the list of basic rights, while the rights for this group were automatically set Read and Execute, "List of folder contents", "Reading".

Everything, it remains to press the button "OK" and the rights are assigned. Now any user who belongs to the local security group "To Colleagues for Reading", will be able to read the entire contents of the folder "PHOTO".

Example 2. Granting personal access to users to their subfolders in a folder.

This situation is also common in practice. For example, you have a folder for new scanned documents. In this folder, a separate subfolder has been created for each user. After scanning the document is taken by the user from his subfolder. The task is to assign rights so that each user can see the contents of only their subfolder and cannot access the colleague's subfolder.

For this example, I'll rephrase the assignment a little. Let's say we have a shared folder "PHOTO", which has a subfolder for each user. It is necessary to configure the rights so that the user has all the rights in his subfolder, and the subfolders of other users would be inaccessible to him.

For this setup, I completely repeat all the steps from the first example. As a result of the repetition, I get the rights for the whole group. "To Colleagues for Reading" to read to all subfolders. But my task is to make only "my" subfolder visible to the user. Therefore, in the basic rights window, I click the button "Additionally"

and go to the special rights window, in which I select the group "To Colleagues for Reading" and press the button "Change"

In the window that opens, I change the inheritance rules, instead of the value in the field "Apply:" i choose value "Only for this folder".

This is the key point of this example. Meaning "Only for this folder" causes the group read permissions "To Colleagues for Reading" only apply to the root of the folder "PHOTO" but not to subfolders. Thus, each user will be able to get to his folder, but he will not be able to look into the neighboring one, he does not have the right to view subfolders. If you do not give such a right to a group at all, then users will not be able to get into their subfolders at all. The file system will not let them pass even to the folder "PHOTO".

As a result, users will be able to enter the folder "PHOTO" but they will not be able to go further into the subfolders!

In the special rights window, click "OK" and exit to the previous window, now in the column "Apply to" opposite the group "To Colleagues for Reading" worth the value "Only for this folder".

Click in all windows "OK" and we leave.

Everything. Now it remains to set up personal rights for each subfolder. This will have to be done for each subfolder, the rights are personal for each user.

You have already done all the necessary actions in the first example, we will repeat the past 🙂

On a subfolder "User1" I press the right mouse button, select the menu item "Properties", go to the bookmark "Security"... I press the button "Add"

and in the standard selection window I select a domain user with the name "User1".

It remains to check the box for the permissive right "Change"... In this case, a checkmark for the permissive right "Record" will be installed automatically.

Push "OK"... We leave. It remains to repeat the same steps for all subfolders.

Example 3. Granting personal access to a user to his subfolder for writing, while prohibiting changes or deletions.

I understand that it sounds hard, but I will try to clarify. I call this kind of access a latch. In everyday life, we have a similar situation with the usual mailbox into which we throw paper letters. Those. You can throw a letter into the box, but you cannot take it out of the box. In the computer economy, this can be useful for a situation when someone writes a report to your folder. Those. the file is written by the user, but then this user can no longer do anything with this file. Thus, you can be sure that the creator will no longer be able to change or delete the submitted report.

As in the previous example, we repeat all the actions, except that we do not immediately give the user full rights to his folder, initially in the basic permissions we give only read access, and press the button "Additionally"

In the window that opens, select "User1" and press the button "Change"

In the window that opens, we see the standard read permissions

In order to give the right to the user to create files, set the permission to the right "Create Files / Write Data", but on the right "Removing subfolders and files" and "Removal" we put a ban. Leave standard inheritance "For this folder, its subfolders and files".

After pressing the button "OK" and return to the previous window, you can see significant changes. Instead of one entry for "User1" two appeared.

This is because two types of rights are installed, one prohibiting, they go first in the list, the second permissive, they are second in the list. Since special rights are non-standard, in the column "Permission" worth the value "Special"... When the button is pressed "OK" a window appears to which windows warns that there are denying rights and that they have a higher priority. Translated, this means the same situation with a self-closing door, the keys to which are inside. I described a similar situation in the second example.

Everything. The rights are established. Now "User1" will be able to write any file to its folder, open it, but will not be able to change or delete it.

But what about the complete analogy with a real mailbox?

To prevent the user from opening or copying the recorded file, you need to do the following. Again, open the permitting special permissions for "User1", and in the field "Apply:" change the value to "Only for this folder"

In this case, the user does not have the right to read or copy the file.

Everything. Now the analogy with a physical mailbox is almost complete. He will only be able to see the names of files, their size, attributes, but he will not be able to see the file itself.

View your current rights.

I want to say right away that the ability to view the current rights for a folder or file is a complete fiction. In my opinion, such tools should provide guaranteed information. In this case, this is not the case. Microsoft itself acknowledges that this tool does not consider many factors that affect the resulting entitlements, such as terms of entry. Therefore, using such a tool is only to mislead oneself about real rights.

The case described at the very beginning of the article, with a ban on deleting a file from a folder, in this case is very eloquent. If you simulate a similar situation and look at the rights of a file protected from deletion, you will see that the file's rights for deletion are prohibited. However, it is not difficult to delete this file. Why Microsoft did this - I don't know.

If you nevertheless decide to look at the current rights, then for this you need to click the button in the basic rights window "Additionally", and in the special rights window go to the tab "Valid Permits".

Then you need to press the button "Select" and select the required user or group in the standard selection window.

Once selected, you can see the "approximate" valid permissions.

In conclusion, I want to say that the topic of NTFS file system rights is very extensive, the above examples are only a very small part of what can be done. Therefore, if you have questions, ask them in the comments to this article. I will try to answer them.

This article discusses in detail the issues of using the Xcacls.exe program ...

This article details how to use Xcacls.exe (the Extended Change Access Control List tool) to view and change NTFS permissions for files and folders.
You can use Xcacls.exe to set all of the file system security options that are accessed from the command line in Explorer (for this purpose, Xcacls.exe displays and modifies the access control lists (ACLs) of files).
It is recommended to use Xcacls.exe for automatic Windows installations 2000 Professional or Windows 2000 Server. With its help, the initial permissions for the folders in which the files are located are set operating system... In the process of transfer software to servers and workstations Xcacls.exe provides one-step protection against user deletion of files and folders.
Xcacls.exe is included in the package Windows 2000 Resource Kit... The following file is available on the Microsoft Download Center:

Collapse this imageExpand this image

Xcacls.exe syntax

xcacls filename]]

where filename is the name of the file or folder to which the ACL or ACE is typically applied. Any standard wildcard characters can be used.
/ T Recursively view the current folder and all subfolders, assigning the specified access rights to all files and folders that satisfy the requirements.
/ E- edit the access control list (without replacing it). For example, after running the XCACLS test.dat / G Administrator: F command, only the administrator account has access to the Test.dat file. All previously applied access controls are canceled.
/ C- Xcacls.exe continues to run even after receiving an "Access Denied" message. If the parameter / C is not specified, the appearance of this message causes the program to stop.
/ G - user: permission; special_access Give the user access to a specific file or folder.

• The variable permission is used to assign the specified file access rights and to define a special file access mask for folders. The variable resolution takes the following values:
  • R- reading
  • C- change (write)
  • F- full access
  • P- change permissions (special access)
  • O- change of owner (special access)
  • X- launch (special access)
  • E- reading (special access)
  • W- recording (special access)
  • D- deletion (special access)
• The variable special_access (special access) is used only with folders; takes on the same values ​​as the variable resolution, and also has the following special meaning:
  • T- undefined value - assign an access control element to the directory without specifying the element that is used for files created in this folder. At least one access right must be specified. Text between the semicolon (;) and the T parameter is ignored. Notes.
    • The access options for files (for folders - special access to files and folders) are identical. For a detailed description of these parameters, see the documentation for Windows system 2000.
    • Other parameters (also assigned in Explorer) are subsets of all possible combinations of basic access rights. For this reason, there are no special folder permissions (eg LIST or READ).

/ R user Revoke all access rights for the specified user.
/ P user: permission; special_access- replace the access rights for the specified user. The variables "permission" and "special_access" are defined according to the rules described for the / G parameter. See a section of this article.
/ D user- Deny the user access to the file or folder.
/ Y- Cancel the display of a request to confirm the change in access rights. CACLS displays this prompt by default. For this reason, if the CACLS command is used as part of a batch file, its execution is interrupted until a response to the request is received. Parameter / Y used to suppress the prompt window when Xcacls.exe is used in batch mode.

Using Xcacls.exe to View Permissions

You can also use Xcacls.exe to view file and folder permissions. For example, at a command prompt, type xcacls C: \ winnt and press Enter. The program usually returns the following result.

C: \ WINNT BUILTIN \ Users: R BUILTIN \ Users: (OI) (CI) (IO) (special access :) GENERIC_READ GENERIC_EXECUTE BUILTIN \ Power Users: C BUILTIN \ Power Users: (OI) (CI) (IO) C BUILTIN \ Administrators: F BUILTIN \ Administrators: (OI) (CI) (IO) F NT AUTHORITY \ SYSTEM: F NT AUTHORITY \ SYSTEM: (OI) (CI) (IO) F BUILTIN \ Administrators: F CREATOR OWNER: (OI ) (CI) (IO) F

The ACL flags have the following meanings.

• IO: Inherit Only - This access control does not apply to the current object.
• CI: Container Inherit - This access control is inherited by lower-level containers.
• OI: Object Inherit - This ACE is inherited by lower-level files.
• NP: Non-Propagate — The lower-level object does not propagate an inherited ACE.

The letter at the end of each line indicates permission. For example:

• F- full access
• C- the change
• W- recording

Examples of using Xcacls.exe

Example 1

To replace the ACL for all files and folders in the current folder without browsing the subfolders and prompting you for confirmation, at a command prompt, type XCACLS *. * / G administrator: RW / Y and press ENTER.

Example 2

The access controls added in this example also inherit the access controls for new files that are created in this folder. After entering this command, the TestUser user gets the right to read, modify, run and delete all files that are created in this folder, but has only read and write permission for the folder itself. At a command prompt, type XCACLS *. * / G TestUser: RWED; RW / E and press ENTER.

Example 3

This example sets read and write permissions on a folder without creating an inheritable item for new files. For this reason, the files created in this folder are not assigned an access control for the TestUser user. An access control with read permissions is created for existing files. Type XCACLS *. * / G TestUser: R; RW / E at the command line and press Enter.

Instructions for Assigning NTFS Permissions

Consider the following when assigning NTFS permissions.

• NTFS permissions control access to files and folders.
• It is best to set permissions for groups rather than individual users.
• File permissions take precedence over folder permissions.
• Administrators and the owner of the object control the assignment of permissions.
• When changing folder permissions, be aware of the programs that are installed on the server. Programs create their own folders for which the parameter is set Carry over inherited permissions from parent to this object... Changing the permissions on the parent folder may cause program problems.

  A warning... Many folders and files receive permissions through inheritance. Therefore, changing the permissions for one folder can affect other objects.

This article ideologically continues the article. As it was said in it, after selecting users and (or) groups, you must specify the parameters for accessing them. You can do this by using the NTFS file system permissions, which are discussed in the following table.

File permissions

• Reading. You are allowed to read the file, as well as view its parameters, such as owner name, permissions, and additional properties.
• Recording. Allowed to overwrite the file, change its parameters, view the name of its owner and permissions.
• Reading and Execution. Read permission and right to run the executable application.
• The change. Allowed to modify and delete the file, as well as anything provided by the permissions Read and Execute, and Write.
• Full access.
• Full file access allowed. This means that all actions provided for by all of the above permissions are allowed. You can also take ownership of the file and change its permissions.

Folder permissions

• Reading. You are allowed to view subfolders and files, as well as their properties, such as owner name, permissions, and read-only attributes such as Read-only, Hidden, Archive, and System.
• Recording. It is allowed to create and place new files and subfolders inside the folder, as well as change the folder settings and view its properties, in particular the owner name and access permissions.
• List of folder contents. You are allowed to view the names of files and subfolders contained in the folder.
• Reading and Execution. Files in subfolders are allowed to be accessed even if there is no access to the folder itself. In addition, the same actions are allowed as for the Read and List folder contents permissions.
• The change. All actions for the Read and Read and Execute permissions are allowed, and the folder can be deleted.
• Full access. Full access to the folder is allowed. In other words, all actions provided for by all of the above permissions are allowed. Additionally, it is allowed to take ownership of the folder and change its permissions.
• Special Permissions. A set of additional permissions that differ from the standard ones.

The creator of the file is always considered to be its owner, who has the rights Full access, even if the owner account is not listed in the tab File security... In addition to the above file permissions, you can select two additional types of permissions.

• Change of owner... This type of permission allows the user to take ownership of the file. This permission type is assigned by default to the group Administrators.
• Change permissions... The user gets the ability to change the list of users and groups who have access to the file, as well as change the types of access permissions to the file.

Why in most cases does an organization need a server? Active Directory, RDS, print server and a bunch of small and large services. The most prominent role for all is perhaps the file server. People, unlike other roles, work with him most consciously. They remember in which folder what is, where the scans of documents are, where are their reports, where are the faxes, where is the shared folder in which everything is possible, where only one of the departments can access, where to another, and they don’t even know about some of them.

I also want to talk about access to network and local folders on the server.

Access to shared resources on the server is carried out, as everyone knows very well, via the SMB protocol already 3.0. Network access to folders can be restricted with SMB and NTFS permissions. SMB permissions only work when accessing a shared folder over the network and have no effect on the availability of a particular folder locally. NTFS permissions work both over the network and locally, providing a lot more flexibility in creating permissions. SMB and NTFS permissions do not work separately, but complement each other, according to the principle of the greatest restriction of rights.

In order to share a folder in Server 2012 in the SMB Share Cmdlets group, the New-SMBShare cmdlet appeared. Using this cmdlet as an example, we will see all the capabilities available when creating a shared folder, except for cluster configurations (this is a separate large topic).

Creating a new shared folder looks very simple:
net share homefolder = s: \ ivanivanov / grant: "admin", full / grant: "folderowner", change / grant: "manager", read / cache: programs / remark: "Ivanov" or
new-smbshare homefolder s: \ ivanivanov –cachingmode programs –fullaccess admin –changeaccess folderowner –readaccess manager –noaccess all –folderenumerationmode accessbased -description "Ivanov"

Understanding:

-name is the name of the shared folder on the network; it can be different from the name of the folder on the local computer. Has a limit of 80 characters, you cannot use the pipe and mailslot names.

Path is the path to the local folder to be shared. The path must be complete, from the root of the drive.

Cachingmode configures file autonomy in a shared folder.

What is an offline file?

An offline file is a copy of a file on the server. This copy is located on the local computer and allows you to work with the file without connecting to the server. When connected, the changes are synchronized. Synchronized in both directions: if you made changes in your offline file - the next time you connect, the file on the server will be changed; if someone made changes on the server, then your local copy will be changed. If changes have occurred in both files at once, we get a synchronization error and you will have to choose which version to save. For collaboration, I would not use this opportunity, but if for each user we make a ball and restrict access for others to reading, without the ability to write, we get the following buns:

• The work does not depend on the network - the switch may burn out, the server may reboot, the wire may break or the access point may turn off - the user works with his copy, not noticing that you have some kind of accident there, when the network connection is restored, his work goes to the server.
• The user can work anywhere: at the dacha, on the bus, on the plane - in those places where VPN connection is not available for some reason.
• Even if the user is using a VPN, but the connection is either very slow or constantly drops, it is easier to work with an offline copy and synchronize changes than trying to do something on the server.
• The user himself can choose what and when to synchronize, if given the opportunity.

It takes the following values:

• none - files are not available offline, access to files requires access to the server
• manual - users choose the files that will be available offline
• programs - everything in the folder is available offline (documents and programs (files with the extension * .exe, * .dll))
• documents - documents are available, there is no program
• branchcache - caching instead local computer user is hosted on BranchCache servers, users choose offline files themselves

-noaccess, -readaccess, -changeaccess, -fullaccess share permissions.

These permissions have one big advantage - they are very simple.

Noaccess secretary, steward - the secretary and the manager have nothing to do in the shared folders of the accounting department
-readaccess auditor - an auditor who checks the work of the accounting department can see the names of files and subfolders in a shared folder, open files for reading, and run programs.
-changeaccess accountant - accountants in their shared folder can create files and subfolders, modify existing files, delete files and subfolders
-fullaccess admin - fullaccess is readaccess + changeaccess plus the ability to change permissions.

When a shared folder is created, the most restrictive rule is automatically applied — the Everyone group is given read access.

These permissions apply only to users who access the shared folder over the network. When logging into the system locally, for example, in the case of a terminal server, both the secretary and the manager will see everything they want in the accounting department. This is fixed with NTFS permissions. SMB permissions apply to all files and folders on the Share. More fine tuning access rights are also handled by NTFS permissions.

Concurrentuserlimit Using this parameter, you can limit the maximum number of connections to the shared folder. In principle, it can also be used to restrict access to a folder, supplementing NTFS permissions, you just need to be sure of the required number of connections.

Description A description of the share as seen in Network Neighborhood. Description is a very good thing that many people neglect.

Encryptdata encryption

In SMB prior to 3.0, the only way to protect traffic from the file server to the client was with a VPN. How to implement it depended entirely on the preferences of the system administrator: SSL, PPTP, IPSEC tunnels, or something else. In Server 2012, encryption works out of the box, on a regular LAN or over untrusted networks, without requiring any special infrastructure solutions. It can be enabled for the entire server or for individual shared folders. The encryption algorithm in SMB 3.0 is AES-CCM, the hashing algorithm has become AES-CMAC instead of HMAC-SHA256. The good news is that SMB 3.0 supports hardware AES (AES-NI), the bad news is that Russia does not support AES-NI.

What is the threat of enabling encryption? The fact that only clients supporting SMB 3.0, that is Windows 8, will be able to work with encrypted shared folders. The reason, again, is the maximum allowable limitation of user rights. It is assumed that the administrator knows what he is doing and, if necessary, will give access to clients with a different version of SMB. But since SMB 3.0 uses new encryption and hashing algorithms, traffic from clients with a different version of SMB will not be encrypted, you need a VPN. The command set-smbserverconfiguration –rejectunencryptedaccess $ false will help to launch all clients to the file server with encryption enabled
In the default configuration (unencrypted traffic to encrypted shared folders is prohibited), when we try to access a client folder with SMB version lower than 3.0 on the client, we will receive an "Access error". On the server, an event 1003 will be added to the Microsoft-Windows-SmbServer / Operational log to find the IP address of the client trying to access.

SMB and EFS encryption are two different things, not related to each other, that is, it can be used on FAT and ReFS volumes.

Folderenumerationmode This is Access-Based Enumeration. With Access-Based Enumeration enabled, users who do not have access to a shared folder simply will not see it on the file server and there will be fewer questions as to why I don’t have access to this or that folder. The user sees his available folders and does not try to meddle in other people's business. The default is off.

• accessbased - enable
• unrestricted - turn off

-temporary This key creates a temporary shared folder that will no longer be accessible after the server is restarted. By default, permanent shared folders are created.

NTFS permissions

With the help of NTFS permissions, we can delimit rights in a folder in more detail. We can prevent a certain group from changing a certain file, leaving the ability to edit the entire main one; in the same folder, one user group may have edit rights on one file and cannot view other files edited by another user group, and vice versa. In short, NTFS permissions allow us to create a very flexible access system, the main thing is not to get confused in it yourself. In addition, NTFS permissions work both when accessing a folder over a network, in addition to shared permissions, and when accessing files and folders locally.

There are six basic permissions, which are a combination of 14 advanced permissions.

Basic permissions

Full access (fullcontrol)- full access to a folder or file, with the ability to change access rights and audit rules for folders and files

Modify- the right to read, modify, view the contents of a folder, delete folders / files and run executable files. Includes Read and Execute (readandexecute), Write (write) and Delete (delete).

Reading and Executing (readandexecute)- the right to open folders and files for reading, without the ability to write. It is also possible to run executable files.

List folder contents (listdirectory)- the right to view the contents of the folder

Read- the right to open folders and files for reading, without the ability to write. Includes Folder Contents / Reading Data (readdata), Reading Attributes (readattributes), Reading Additional Attributes (readextendedattributes) and Reading Permissions (readpermissions)

Write- the right to create folders and files, modify files. Includes File Creation / Data Writing (writedata), Folder Creation / Data Writing (appenddata), Writing Attributes (writeattributes) and Writing Extended Attributes (writeextendedattributes)

Additional permissions

I put only 1 of 14 permissions on the folder and watched what happened. In the real world, in most cases, basic permissions are enough, but I was interested in the behavior of folders and files with the most truncated rights.

Traverse folders / execute files (traverse)- the right to run and read files, regardless of folder access rights. The user will not have access to the folder (what is in the folder will remain a mystery), but the files in the folder will be available via a direct link (full, relative or UNC path). You can put on the folder Traverse folders, and on the file any other permissions that the user needs to work. The user will not be able to create and delete files in the folder.

Reading Attributes- the right to view the attributes (FileAttributes) of a folder or file.
You cannot view the contents of a folder or files or change any of the attributes.

Reading readextendedattributes- the right to view additional attributes of a folder or file.

The only thing I could find from the additional attributes is that they are used for backward compatibility with OS / 2 applications. (Windows Internals, Part 2: Covering Windows Server 2008 R2 and Windows 7). I don't know anything more about them.

Create files / write data (writedata)- gives the user the ability to create files in a folder to which he does not have access. You can copy files to a folder and create new files in the folder. You cannot view the contents of a folder, create new folders, or modify existing files. The user will not be able to change any file, even if he is the owner of this file - only create.

Create folders / append data (appenddata)- gives the user the ability to create subfolders in a folder and append data to the end of the file without modifying the existing content.

Examination

With the creation of subfolders, everything is clear: ni c: \ testperms \ testappend –itemtype directory will work as expected - it will create the testappend subfolder in the testperms folder inaccessible for the user to view. Let's try to add a line to the end of the file - we will emulate the maintenance of some kind of log. newevent >> c: \ testperms \ user.log Access denied.
Hmm ... Doesn't work in CMD. And if so. ac c: \ testperms \ user.log newevent ac: Access denied on path "C: \ testperms \ user.log".
And on the conveyor? "newevent" | out-file c: \ testperms \ user.log -append out-file: Access denied on path "C: \ testperms \ user.log".
And it doesn't work that way.

Beginning a black magic session: using the File class, the AppendText method. We get the log object.
$ log = :: appendtext ("c: \ testperms \ user.log") Exception when calling AppendText with "1" arguments: "Access denied on path" c: \ testperms \ user.log "."
I think that AppendAllText is no longer worth trying
$ log = :: appendalltext ("c: \ testperms \ user.log", "newevent") Exception when calling "AppendAllText" with "2" arguments: "Access denied on path" c: \ testperms \ user.log " . "
The point is, in principle, clear. Only the right to add data to the file is not enough for the above methods, they need to write to the file. But at the same time, we will give the opportunity to change the file, and not just add records, that is, we open the potential opportunity to destroy the entire contents of the file.

We need to revise the concept: let's not get the log object, but create a new one, in which we will set all the parameters of interest to us. We need something where we can explicitly specify the permissions. We need a FileStream, and more specifically, the FileStream Constructor (String, FileMode, FileSystemRights, FileShare, Int32, FileOptions) will help us. The following parameters are needed:

• File path - understandable
• How to open a file - open a file and find the end of the file
• File access rights - add data
• Access to other FileStream objects - not needed
• Buffer size - default 8 bytes
• Additional options - no

It turns out something like this:
$ log = new-object io.filestream ("c: \ testperms \ user.log", :: append, :: appenddata, :: none, 8, :: none)
Works! We have created a log object, we will try to write something there. The FileStream.Write method accepts input values ​​in bytes. We overtake the event that we want to write into bytes - the Encoding class, the GetEncoding method (we do not need any cracks at the output) and GetBytes (actually, the conversion)
$ event = "A new event has occurred." $ eventbytes = :: getencoding ("windows-1251"). getbytes ($ event)
FileStream.Write parameters:
What to write; where to start writing; the number of bytes to write
We write down:
$ log.write ($ eventbytes, 0, $ eventbytes.count)
Checking.
gc c: \ testperms \ user.log gc: Access denied on path "C: \ testperms \ user.log".
Everything is fine, the user does not have the rights to view what was written. Logging in as an administrator.
gc c: \ testperms \ user.log A new event has occurred.
Everything works.

The folder in which the file is located, in addition to the Create folders / add data permission, must also be granted the Content folder / Read data permission. The file is only enough to create folders / add data with disabled inheritance. It will not work to completely protect the user (and the user may also be an intruder) from files to which he should write something, but on the other hand, besides the list of files in the folder, the user will not see or be able to do anything.

The conclusion from this is simple: you won't be able to implement safe logging in batch files, PowerShell is saved by the ability to work with .NET objects.

Write Attributes- we allow the user to change the attributes of a file or folder. Everything seems to be simple. But just to answer the question: “Photos of my cats take up almost all the space on my profile and I have no place for business correspondence. I would like to compress the folder with cats, but they require administrator rights. You said that I have the right to change the attributes of folders. Is this an attribute? Why can't I change it? "

Yes, a user with write access to attributes can change almost all visible attributes of files and folders, except for the compression and encryption attributes. Technically, the user is given the right to execute the SetFileAttributes function. And file compression is performed by the DeviceIOControl function, which needs to be passed the FSCTL_SET_COMPRESSION parameter, and file compression is far from its only job. With this function, we can manage all devices and their resources in the system and, probably, giving the user this right to perform this function means making him an administrator.

With encryption, the story is similar: the EncryptFile function, which is exactly responsible for encryption, requires the user to have the rights Content folder / Read data, Create files / Write data, Read attributes, Write attributes and Synchronize to an object. Nothing will work without them.

Writing extended attributes (writextendedattributes)... Well these are the ones used for backward compatibility with OS / 2 applications, yeah. Well, and more recently, Trojans (ZeroAccess.C) have been added to the extended attributes of the C: \ Windows \ system32 \ services.exe file. Maybe you should turn them off at the highest level? I cannot give an answer to this question, theoretically - it may be worth it, practically in production - I have not tried it.

Removing subfolders and files. (deletesubdirectoriesandfiles) An interesting resolution that only applies to folders. The bottom line is to allow the user to delete subfolders and files in the parent folder without giving Delete permission.

Let's say there is a product catalog where users enter data. There is a parent folder Catalog, inside a subfolder in alphabetical order, from A to Z, inside them are some names. The names change every day, something is added, something is changed, something is outdated and outdated information needs to be removed. But it will not be very good if someone, by park or malicious intent, crashes the entire K directory, which is very possible if users have the Delete permission. If you take away the Delete right from users, then the administrator can safely change the work, because he will carry out requests to delete one or another name all day.

This is where Deleting subfolders and files comes in. Inheritance is disabled on all letters of the alphabet and users are given the Delete subfolders and files right. As a result, in the catalog folder, users will not be able to delete a single letter, but inside the letters they can delete anything they want.

Deleting (delete). Everything is simple here. Deletion is deletion. Doesn't work without the Read permission.

Read permissions gives the user the right to view the permissions on a folder or file. No permission - the user does not see the permission on the Security tab

Change permissions- allows the user to change permissions, in fact makes the user the administrator of the folder. It can be used, for example, to delegate authority to technical support. Without read permission, the permissions make no sense. Changing permissions does not mean changing the owner of the folder.

Takeownership- to begin with, who is the owner. The owner is the user who created the file or folder.

The peculiarity of the owner is that he has full access to the created folder, he can grant permissions to his created folder, but more importantly, no one can deprive the owner of the right to change permissions on his folder or file. If Vasya created a folder, gave Petya full access, and Petya entered and denied users access to the folder in general, and Vasya in particular, then Vasya can easily restore the status quo, since he is the owner of the folder. Petya will not be able to change the owner of the folder, even if he has the Change owner permission. Moreover, even Vasya cannot change the owner, despite the fact that he created the folder. The Change Ownership right applies only to the Domain Admins or Domain Admins group.

But if Petya created a file inside Vasya's folder and did not give Vasya access to it, then Vasya can only think and wonder what is so secret inside this file. Vasya will not be able to change the file's permissions, because Petya is the owner of the file. Also, Vasya will not be able to change the owner of the file - changing the owner of subcontainers and objects is also a privilege of the Administrators group, to which Vasya does not belong. Vasya's only option is to look at Petya's file inside his folder.

We manage

CMD uses the well-known icacls to manage permissions. In PowerShell, managing NTFS permissions looks like this:

Get the object to which we will set permissions
$ acl = get-acl c: \ testperms
Construct a rights string using the System.Security.AccessControl.FileSystemAccessRule class. We can set the following parameters:

• group / username - for whom we are doing ACL
• permission - ACE (takes the values ​​specified in the post)
• applies to - in the GUI, this is a dropdown list in additional security options. Actually only takes 3 values: none (only for this folder), containerinherit (applies to all subfolders), objectinherit (applies to all files). The values ​​can be combined.
• apply these permissions to objects and containers only inside this container (checkbox in the GUI) - also 3 values: none (unchecked), inheritonly (ACE applies only to the selected object type), nopropagateinherit (apply permissions only inside this container).
• rule - allow or deny

The default permissions line will look like this:
$ permission = “contoso.com \ admin”, ”fullcontrol”, ”containerinherit, objectinherit”, ”none”, ”allow”
Do new ACE with the above permissions
$ ace = new-object security.accesscontrol.filesystemaccessrule $ permission
And apply the newly created ACE to the object
$ acl.setaccessrule ($ ace) $ acl | set-acl c: \ testperms

We put it into practice

Armed with knowledge of SMB and NTFS permissions, by combining them, you can create access rules of absolutely any complexity. A few examples:

Type of	SMB permissions	NTFS permissions
Folder for everyone (Public)	Users - Read / Write	Users - Change
Black box. Users throw off confidential reports, suggestions, slander - the manual is read.	Users - Read / Write Manual - Read / Write	Users - Entry, applies to this folder only. It is assumed that writing a file to this folder is a one-way ticket, since there is no convenient way of editing without the right to View the contents of a folder of files stored in this folder (by the way, there is no convenient way for users to write to such a folder). And viewing violates privacy. Leadership - Change.
Applications	Users - Reading	Users - Read, Read and Execute, View folder contents. Naturally, some applications may require additional rights in order to function. But in the general case, for example, storing system utilities for diagnostics (the same SysInternals Suite) is quite enough.
User profiles	Each user - Read / write to his folder	Each user - Change to his folder.

Windows permissions are controversial. On the one hand, the basic resolutions are quite simple and cover 90% of cases. But when more fine tuning is required: different user groups, one folder, security requirements for shared folders, it can be quite difficult to deal with additional permissions, inheritance and owners.

I hope I haven't confused anyone further.

A granular and complex permission system is used to control user access to folders and files. The mechanism for controlling access to Windows objects is one of the most detailed among the known operating systems. For files and folders, there are at least 14 NTFS permissions that can be enabled or disabled - and checked. These permissions can be assigned to files or folders and to users or groups. In addition, you can designate the inheritance order for file or folder permissions and users or groups. It's easy to get lost in the maze of permissions. This article will discuss how folder and file permissions work and the most effective ways to use them.

Object Access Basics

The user never comes into direct contact with any Windows object. All access to objects is through programs (eg Windows Explorer, Microsoft Office) or processes. A program that accesses resources on behalf of a user performs a procedure called impersonation. A program that accesses a remote resource performs a procedure called delegation.

After a user is registered, the System Identifier (SID) and group SIDs are processed by the lsass.exe process, which generates the user's secure access token. Other information is also entered into the secure access token, including the rights (permissions) assigned to the user, the user's session ID (unique for each session), the permission mask with a detailed description of the type of access requested. The rights assigned to the user can be seen using the command

When a program accesses a protected resource on behalf of the user, the Windows security reference monitor asks the program for the user's secure access token. The Security Monitor then analyzes the token to determine the effective user permissions and allows or denies the user-requested operation. The effective resolutions are described in more detail below.

Share Permissions

Every protected Windows object — including files, folders, shares, printers, and registry keys — supports security permissions. Any Windows folder can be made public to allow remote access. Share permissions can be assigned to any folder and printer object in Windows, but permissions are applied only when the object is accessed over a network share. Folder Share permissions include Full Control, Change, and Read.

Security principals who have been assigned Full Control rights to an object can perform almost any operation on an object. They can delete, rename, copy, move and modify an object. A user with Full Control can change the Share permissions of an object and take ownership of the object (if he is not already the owner and does not have Take Ownership permission). This way, anyone with Full Control permission can revoke the permissions of others, including the administrator (although the administrator can always take back ownership and permissions). The ability to change permissions is a requirement of any discretionary access control (DAC) operating system, such as Windows.

In most cases, the main permission to access a resource required by regular users is Change. With the Change permission, the user can add, delete, modify, and rename any resources in the corresponding folder. Read permission allows you to view, copy, rename, and print an object. A user with Read permission can copy an object to another location in which he has Full Control permission.

NTFS permissions

If Windows uses the NTFS (not FAT) file system, then all files, folders, registry keys, and many other objects have NTFS permissions. NTFS permissions apply to both local and remote access to an object. To view and change the permissions of an NTFS file or folder, just right-click on the object, select Properties, and go to the Security tab.

Table 1 shows the 7 total NTFS permissions. The summary permissions are various combinations of the 14 more granular permissions shown in Table 2. You can view the granular permissions by opening the Advanced Security Settings dialog box for an object, clicking the Advanced button in the Security tab, and then clicking the Edit button in the Permissions tab. It is a good habit to become familiar with the granular permissions of an object (especially one that requires increased security), although it takes more effort. Summary permissions do not always accurately reflect the state of granular permissions. For example, I have seen the total Read permission when the user actually had Read & Execute permission.

Similar to Full Control Share permission, Full Control NTFS permission gives owners more options. Non-administrator users often have Full Control permission on their home directory and other files and folders. As noted, a holder of this level of rights can change the file's permissions and make himself the owner. Instead of giving users Full Control permission, you can only give them Modify permission. If the user is the owner of the file, then, if necessary, you can manually prevent him from changing permissions.

Technically, NTFS permissions are known as discretionary ACLs (DACLs). Audit permissions are known as system ACLs (SACLs). Most NTFS protected objects have both types of permissions.

Impact of Windows Trusts

By default, all Windows 2000 and later domains and forests have two-way trusts with all other domains in the forest. If a domain trusts another domain, then all users in the trusted domain have the same security permissions in the trusting domain as the Everyone group and Authenticated Users group of the trusting domain. In any domain, many permissions for these groups are assigned by default, and trusts implicitly provide broad rights that would not otherwise be granted. Keep in mind that unless the trust relationship is selective, any permissions granted to the Everyone and Authenticated Users groups are assigned to all other users in the forest.

Checking permissions from the command line

Administrators often use command line tools such as subinacl.exe, xacls.exe, and cacls.exe to check NTFS permissions. Subinacl is part of the Windows Server 2003 Resource Kit Tools. With Subinacl, you can view and change NTFS permissions for files, folders, objects, registry keys, and services. The most important feature of Subinacl is to copy the permissions of a user, group, or object and apply them to another user, group, or object in the same or a different domain. For example, moving a user from one domain to another on Windows creates a new user account; all pre-existing SIDs or permissions associated with the original user are revoked. By copying the permissions to the new user account using Subinacl, you can make them identical. Xcacls functions similarly to Subinacl and is included in the Windows 2000 Server Resource Kit.

The Cacls program is described in the Microsoft published article “Undocumented CACLS: Group Permissions Capabilities”. It is an older tool that has been included with Windows since the days of Windows NT. Cacls is not as useful as Subinacl or Xacls, but the utility is always available on Windows systems. You can use Cacls to view and modify files and permissions by user and group, but not create granular NTFS permissions. Currently, Cacls is limited to working with No Access, Read, Change, and Full Control permissions, which correspond to NTFS but not Share. In addition, the Read permission of Cacls corresponds to the Read & Execute permission of NTFS.

Inheritance

By default, all files, folders, and registry keys inherit permissions from the parent container. Inheritance can be enabled or disabled for individual files, folders, or registry keys, and for individual users or groups. As you can see in Figure 1, the Apply To box on the Permissions tab of the Advanced Security Settings dialog box indicates whether a particular permission is restricted by the current container, or whether it is propagated to subfolders and files. The administrator can assign permission (for individual users), which are inherited or not. In this example, the Everyone group has Read & Execute permission on the current folder, and this permission is not inherited.

If a file or folder inherits most of its permissions, but also has a set of explicitly set permissions, then the latter always take precedence over inherited rights. For example, you can grant a user Full Control-Deny permission on the root directory of a specific volume, and have all files and folders on the drive inherit those permissions. You can then assign an access right to any file or folder on the disk, which overrides the legacy Full Control-Deny mode.

Effective Permissions

Windows Protection Monitor determines effective user permissions (the actual permissions they actually have) based on several factors. As noted above, the protection monitor first collects information about the individual account user and all groups to which it belongs, and summarizes all permissions assigned to all user and group SIDs. If Deny and Allow permissions exist at the same level, Deny usually takes precedence. If Full Control-Deny is given priority, then the user usually does not have access to the object.

By default, when considering NTFS and Share permissions (the user connects to a resource over a network), the Security Monitor should collect all Share and NTFS permissions. As a result, effective user permissions are the set of permissions granted by both Share and NTFS permissions.

For example, the user might end up with Read and Change Share permissions, and Read and Modify NTFS permissions. Effective permissions are the most limited set of permissions. In this case, the permissions are almost identical. Read and Change / Modify are effective permissions. Many administrators mistakenly believe that Read only permissions are effective because of poor, oversimplified examples or outdated documentation.

The Advanced Security Settings dialog box for Windows XP and newer has an Effective Permissions tab (see Figure 2). Unfortunately, the Effective Permissions tab only reflects NTFS permissions. The impact of Share permissions, action-based groups that the user does not have membership of, and other factors such as Encrypting File System (EFS) are not considered. If EFS is enabled on a file or folder, then a user with the appropriate NTFS and Share permissions may be unable to access the object if they do not have EFS access to the folder or file.

• It is prudent to grant Full Control permissions to regular users. It is useful to assign them the Modify permission instead. In most cases, this approach provides users with all the permissions they need, without allowing them to change rights or take ownership of themselves.
• Work carefully with the Everyone group; it is better to use the Authenticated Users (or Users) group, or a special group with limited rights. An important omission of the Authenticated Users group is the lack of a Guest and an unauthenticated user.
• It is not uncommon for network administrators to be asked to enter guest accounts for third-party users (eg consultants, contractors, freelance programmers). But regular user rights are often redundant for the guest. Create and use a group that is heavily restricted by default (for example, Full Control-Deny permission for root directories), and then explicitly allow access only to files and folders required by this guest account. Explicitly assigned permissions are preferred because they give guest users the exact permissions they need to get them to work, but no more.
• Care should be taken when restricting the Everyone and Users groups, since administrators belong to these groups as well.
• In the case of trusts with other domains, it is useful to use one-way and selective trust to restrict the rights of users of the trusted domain.
• You should periodically audit NTFS and Share permissions to ensure that they are as limited as possible.

Using these guidelines and reference tables with a brief description of all permissions, you can safely go to the maze of the file system. The administrator can confidently assign permissions to files, folders, users and groups.

Table 1. Summary of NTFS Permissions

Permission	Action
	Provides viewing, copying, printing and renaming files, folders and objects. Prevents executable programs from running other than script files. Allows you to read object permissions, object attributes, and extended attributes (for example, the Archive bit, EFS). Lets you list the files and subfolders of a folder
	Read permissions, plus create and overwrite files and folders
List (Folders Only)	Allows you to view the names of files and subfolders within a folder
	Reading Permissions and Running Program Files
	Grants all permissions except the ability to assign ownership and assign permissions. Allows you to read, delete, modify and overwrite files and folders
	Provides complete management of folders and files, including the ability to assign permissions
Special Permissions	Allows you to create combinations of 14 more detailed resolutions that are not included in any of the other 6 total resolutions. This group includes the Synchronize permission

Table 2. Granular NTFS Permissions

Permission	Action
Traverse Folder / Execute File	Traverse Folder allows you to navigate folders to access other files and folders, even if the security principal does not have permissions on the transit folder. Applies to folders only. The Traverse Folder takes effect only if the security principal does not have Bypass traverse checking user permission (granted to the Everyone group by default). Execute File lets you run program files. Assigning Traverse Folder permission to a folder does not automatically set Execute File permissions to all files in the folder
List Folder / Read Data	Provides a view of the names of files and subfolders in a folder. The List Folder only affects the contents of the folder — it does not affect whether the folder to which the permission is assigned is listed. Read Data allows you to view, copy and print files
	The security principal sees the attributes of the object (for example, Read-only, System, Hidden)
Read Extended Attributes	The security principal sees extended object attributes (e.g. EFS, Compression)
Create Files / Write Data	Create Files allows you to create files inside a folder (applies to folders only). Write Data allows you to make changes to the file and overwrite existing content (applies to files only)
Create Folders / Append Data	Create Folders allows you to create folders within a folder (applies to folders only). Append Data lets you make changes to the end of the file, but not modify, delete, or overwrite existing data (applies to files only)
Write attributes	Determines whether the security principal can write or modify the standard attributes (for example, Read-only, System, Hidden) of files and folders. Does not affect the contents of files and folders, only their attributes.
Write Extended Attributes	Determines whether a security principal can write or modify extended attributes (eg, EFS, Compression) of files and folders. Does not affect the contents of files and folders, only their attributes
Delete Subfolders and Files	Allows you to delete subfolders and files even if Delete permission is not granted to the subfolder or file
	Allows you to delete a folder or file. If you do not have Delete permission on a file or folder, you can delete it if you have Delete Subfolders and Files permission on the parent folder
Read Permissions
Change permissions	Allows you to change the permissions (for example, Full Control, Read, Write) of a file or folder. Prevents modification of the file itself
	Determines who can own a file or folder. Owners can always have Full Control, and their permissions on a file or folder cannot be permanently revoked unless ownership is revoked.
	Administrators rarely use this permission. It is used for synchronization in multithreaded, multiprocessing programs and defines the interaction between several threads that access the same resource