Access Control

Security is based on two fundamental concepts: authentication and authorization. Access control is the model for implementing authorization. Once a user account has been authenticated, the type of access granted to an object is determined by the permissions that are attached to the object and, sometimes, by the User rights that are assigned to the user.

  • For tips about access control, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.


Best practices

Permissions

  • Assign permissions to groups rather than to users.

    • Because it is inefficient to maintain user accounts directly, assigning permissions on a user basis should be the exception.

  • Set permission to be inheritable to child objects.
  • Assign Full control, if appropriate, rather than individual permissions.
  • Deny should be used for these special cases.
    • Use Deny permissions to exclude a subset of a group which has Allowed permissions.
    • Use Deny to exclude one special permission when you have already granted full control to a user or group.

User rights

  • Assign rights as high in the container tree as possible. By doing this, you gain the greatest breadth of effect with the least effort. The rights you establish should be adequate for the majority of the security principals.
  • Apply inheritance to propagate rights through the tree. You can quickly and effectively apply access control settings to all children or a subtree of a parent object.
  • Administrators should use an account with restrictive permissions to perform routine, nonadministrative tasks, and use an account with broader permissions only when performing specific administrative tasks. To accomplish this without logging off and back on, log on with a regular user account and use the Runas command to run the tools that require the broader permissions.

Related Topics


How to...

  • Set, view, change, or remove file and folder permissions
  • Set, view, change, or remove special permissions for files and folders
  • Take ownership of a file or folder
  • View effective permissions on a file or folder


Set, view, change, or remove file and folder permissions

Microsoft Windows graphic

To set, view, change, or remove file and folder permissions

  1. Open Windows Explorer, and then locate the file or folder for which you want to set permissions.
  2. Right-click the file or folder, click Properties, and then click the Security tab.
  3. Do one of the following:
    • To set permissions for a group or user that does not appear in the Group or user names box, click Add. Type the name of the group or user you want to set permissions for and then click OK.
    • To change or remove permissions from an existing group or user, click the name of the group or user.
  4. Do one of the following:
    • To allow or deny a permission, in the Permissions for User or Group box, select the Allow or Deny check box.
    • To remove the group or user from the Group or user names box, click Remove.

Important

  • If you are not joined to a domain and want to view the Security tab, see To display the Security tab.

Notes

  • XOX
  • In Windows XP Professional, the Everyone group no longer includes Anonymous Logon.
  • You can set file and folder permissions only on drives formatted to use NTFS.
  • To change permissions, you must be the owner or have been granted permission to do so by the owner.
  • Groups or users granted Full Control for a folder can delete files and subfolders within that folder regardless of the permissions protecting the files and subfolders.
  • If the check boxes under Permissions for user or group are shaded or if the Remove button is unavailable, then the file or folder has inherited permissions from the parent folder. For more information on how inheritance affects files and folders, see Related Topics.
  • When adding a new user or group, by default, this user or group will have Read & Execute, List Folder Contents, and Read permissions.

For more information about permissions on other objects, see Permissions.


Set, view, change, or remove special permissions for files and folders

Microsoft Windows graphic

To set, view, change, or remove special permissions for files and folders

  1. Open Windows Explorer, and then locate the file or folder for which you want to set special permissions.
  2. Right-click the file or folder, click Properties, and then click the Security tab.
  3. Click Advanced, and then do one of the following:
    4. To | Do this
Set special permissions for an additional group or user | Click Add. In Name, type the name of the user or group, and then click OK.
View or change special permissions for an existing group or user | Click the name of the group or user and then click Edit.
Remove an existing group or user and its special permissions | Click the name of the group or user and then click Remove. If the Remove button is unavailable, clear the Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here check box, click Remove, and skip the next two steps.
  4. In the Permissions box, select or clear the appropriate Allow or Deny check box.
  5. In Apply onto, select the folders or subfolders you would like these permissions to be applied to.
  6. To configure security so that the subfolders and files will not inherit these permissions, clear the Apply these permissions to objects and/or containers within this container only check box.
  7. Click OK and then, in Advanced Security Settings for FolderName, click OK.

Caution

  • If you select the Replace permission entries on all child objects with entries shown here that apply to child objects. Include these with entries explicitly defined here check box, then all subfolders and files will have all their permission entries reset to be identical with the parent object. Once you have clicked Apply or OK, you cannot undo this operation by clearing the check box.

Important

  • If you are not joined to a domain and want to view the Security tab, see To display the Security tab.

Notes

  • XOX
  • The Everyone group no longer includes the Anonymous Logon permission.
  • If you select the Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here check box, then this file or folder will inherit permission entries from the parent object.
  • You can set permissions only on drives formatted to use NTFS.
  • If the check boxes under Permissions are shaded, the permissions are inherited from the parent folder.
  • To change permissions, you must be the owner or have been granted permission to do so by the owner.
  • Groups or users that have been granted Full Control for a folder can delete files and subfolders within that folder, regardless of the permissions protecting the files and subfolders.

For more information about permissions on other objects, see Permissions.


Take ownership of a file or folder

Microsoft Windows graphic

To take ownership of a file or folder

  1. Open Windows Explorer, and then locate the file or folder you want to take ownership of.
  2. Right-click the file or folder, click Properties, and then click the Security tab.
  3. Click Advanced, and then click the Owner tab.
  4. In the Change owner to box, click the new owner.
  5. (Optional) To change the owner of all subcontainers and objects within the tree, select the Replace owner on subcontainers and objects check box.

Notes

  • XOX
  • If you are not joined to a domain and want to view the Security tab, see To display the Security tab.
  • You can transfer ownership in two ways:
    • The current owner can grant the Take ownership permission to others, allowing those users to take ownership at any time.
    • An administrator can take ownership of any file on the computer. However, the administrator cannot transfer ownership to others. This restriction keeps the administrator accountable.
  • In Windows XP Professional, the Everyone group no longer includes the Anonymous Logon group.


View effective permissions for files and folders

Microsoft Windows graphic

To view effective permissions on files and folders.

  1. Open Windows Explorer, and then locate the file or folder for which you would like to view effective permissions.
  2. Right-click the file or folder, click Properties, and then click the Security tab.
  3. Click Advanced, and then click the Effective Permissions tab.
  4. Click the Select button.
  5. In Name, enter the name of a user or group and then click OK. The selected check boxes indicate the effective permissions of the user or group for that file or folder.

Notes

  • XOX
  • If you are not joined to a domain and want to view the Security tab, see To display the Security tab.
  • The Everyone group will always be included as long as the selected user or group is not a member of the Anonymous Logon. In Windows XP Professional, the Everyone group no longer includes Anonymous Logon.
  • The calculation does not take these Security Identifiers into account: Anonymous Logon, Authenticated Users, Batch, Creator Group, Creator Owner, Dialup, Enterprise Domain Controllers, Everyone, Network, Proxy, Restricted, Self, Service, System, and Terminal Server User. An example would be if a user were to access a file remotely.
  • The Effective Permissions tab shows information that is calculated from the existing permissions entries. Therefore, the information displayed on that page is read-only and does not support changing a user's permissions by selecting or clearing permission check boxes.
  • Permissions are set only on drives formatted to use NTFS.


Concepts

This section provides general background information about Access Control:

  • Access Control overview
  • Understanding Access Control
  • Using Access Control


Access control overview

Access control is the process of authorizing users, groups, and computers to access objects on the network. Key concepts that make up access control are:

Permissions

Permissions define the type of access granted to a user or group for an object or object property. For example, the Finance group can be granted Read and Write permissions for the file payroll.dat.

Permissions are applied to any secured objects such as files, Active directory objects, or registry objects. Permissions can be granted to any user, group, or computer. It is a good practice to assign to groups.

You can assign permissions for objects to:

  • Groups, users, and special identities in the domain.
  • Groups and users in that domain and any trusted domains.
  • Local groups and users on the computer where the object resides.

The permissions attached to an object depend on the type of object. For example, the permissions that can be attached to a file are different from those that can be attached to a registry key. Some permissions, however, are common to most types of objects. These common permissions are:

  • Read permissions
  • Modify permissions
  • Change owner
  • Delete

When you set up permissions, you specify the level of access for groups and users. For example, you can let one user read the contents of a file, let another user make changes to the file, and prevent all other users from accessing the file. You can set similar permissions on printers so that certain users can configure the printer and other users can only print from it.

If you need to change the permissions on an individual object, you can simply start the appropriate tool and change the properties for that object. For example, to change the permissions on a file, you can run Windows Explorer, right-click the file name, and click Properties. In the Security tab, you can change permissions on the file. For more information, see Permissions.

Ownership of objects

An owner is assigned to an object when that object is created. By default, the owner is the creator of the object. No matter what permissions are set on an object, the owner of the object can always change the permissions on an object. For more information, see Ownership.

Inheritance of permissions

Inheritance allows administrators to easily assign and manage permissions. This feature automatically causes objects within a container to inherit all the inheritable permissions of that container. For example, the files within a folder, when created, inherit the permissions of the folder.

Object auditing

You can audit users' access to objects. You can then view these security-related events in the security log with the Event Viewer. For more information, see Auditing.


Understanding access control

This section covers:

  • Permissions and security descriptors
  • Explicit vs. inherited permissions
  • Ownership
  • Effective permissions
  • How inheritance affects file and folder permissions
  • Security identifiers
  • User rights


Permissions and security descriptors

Every container and object on the network has a set of access control information attached to it. Known as a security descriptor, this information controls the type of access allowed to users and groups. The security descriptor is automatically created along with the container or object that is created. A typical example of an object with a security descriptor is a file.

Permissions are defined within an object's security descriptor. Permissions are associated with, or assigned to, specific users and groups. For example, for the file Temp.dat, the Administrator group might be assigned Read, Write, and Delete permissions, while the Operator group might be assigned Read and Write permissions only.

Each assignment of permissions to a user or group is known as a permission entry, or access control entry (ACE). The entire set of permission entries in a security descriptor is known as a permission set. Thus, for the file Temp.dat, the permission set includes two permission entries: one for the Administrator group and one for the Operator group.


Explicit vs. inherited permissions

There are two types of permissions: explicit permissions and inherited permissions.

Explicit permissions are those that are set by default when the object is created, by user action.

Inherited permissions are those that are propagated to an object from a parent object. Inherited permissions ease the task of managing permissions and ensure consistency of permissions among all objects within a given container.

By default, objects within a container inherit the permissions from that container when the objects are created. For example, when you create a folder called MyFolder, all subfolders and files created within MyFolder automatically inherit the permissions from that folder. Therefore, MyFolder has explicit permissions, while all subfolders and files within it have inherited permissions.

For more information on inherited permissions, see How inheritance affects file and folder permissions.


Ownership

Every object has an owner, whether in an NTFS volume or Active Directory. The owner controls how permissions are set on the object and to whom permissions are granted.

Ownership can be taken by:

  • An administrator. By default, the Administrators group is given the Take ownership of files or other objects user right.
  • Anyone or any group who has the Take ownership permission on the object in question.

When an object is created, the person creating the object automatically becomes its owner. Administrators create and own most objects in Active Directory and on network servers when installing programs on the server. Users create and own data files in their home directories and some data files on network servers.

Ownership can be transferred in the following ways:

  • The current owner can grant the Take ownership permission to another user, allowing that user to take ownership at any time. The user must actually take ownership to complete the transfer.
  • An administrator can take ownership.

Although an administrator can take ownership, the administrator cannot transfer ownership to others. This restriction keeps administrators accountable for their actions.


Effective permissions

If you would like to find out what permissions a user or group has on an object, you can use Effective Permissions. Effective Permissions is a tool that calculates the permissions that are granted to the specified user or group.

The Effective Permissions calculation takes the permissions in effect from group membership into account, as well as any permissions inherited from the parent object. It will look up all domain and local groups that the user or group is a member of in its calculation.

The calculation does not take these Security Identifiers into account: the Anonymous Logon, Authenticated Users, Batch, Creator Group, Creator Owner, Dialup, Enterprise Domain Controllers, Interactive, Network, Proxy, Restricted, Self, Service, System, and Terminal Server User. An example would be if a user were to access a file remotely.

The effective permissions that are granted to a user or group are indicated by a check mark.

The Everyone group will always be included as long as the selected user or group is not a member of the Anonymous Logon group. In Windows XP Professional, the Everyone group no longer includes Anonymous Logon.

For more information, see To view effective permissions on files and folders.


How inheritance affects file and folder permissions

After you set permissions on a parent folder, new files and subfolders that are created in the folder inherit these permissions. If you do not want them to inherit permissions, select This folder only in Apply onto when you set up special permissions for the parent folder. In cases where you want to prevent only certain files or subfolders from inheriting permissions, right-click the file or subfolder, click Properties, click the Security tab, click Advanced, and then clear the Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here. check box.

If the check boxes appear shaded, the file or folder has inherited permissions from the parent folder. There are three ways to make changes to inherited permissions:

  • Make the changes to the parent folder, and then the file or folder will inherit these permissions.
  • Select the opposite permission (Allow or Deny) to override the inherited permission.
  • Clear the Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here. check box. You can then make changes to the permissions or remove the user or group from the permissions list. However, the file or folder will no longer inherit permissions from the parent folder.

In most cases, Deny overrides Allow unless a folder is inheriting conflicting settings from different parents. In that case, the setting inherited from the parent closest to the object in the subtree will have precedence.

Only inheritable permissions are inherited by child objects. When setting permissions on the parent object, you can decide whether folders or subfolders can inherit them with Apply onto. For more information, see Selecting where to apply permissions.

You can always find out what permissions a user or group has on an object with effective permissions.


Security identifiers

Security identifiers (SIDs) are numeric values that identify a user or group. For each access control entry (ACE), there exists a SID that identifies the user or group for whom access is allowed, denied, or audited.

Well-known security identifiers (special identities)

Well-known SID | Description
Anonymous Logon (S-1-5-7) | A user who has connected to the computer without supplying a user name and password.
Authenticated Users (S-1-5-11) | Includes all users and computers whose identities have been authenticated. Authenticated Users does not include Guest even if the Guest account has a password.
Batch (S-1-5-3) | Includes all users who have logged on through a batch queue facility such as task scheduler jobs.
Creator Owner (S-1-3-0) | A placeholder in an inheritable access control entry (ACE). When the ACE is inherited, the system replaces this SID with the SID for the object's current owner.
Creator Group (S-1-3-1) | A placeholder in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID for the primary group of the object's current owner.
Dialup (S-1-5-1) | Includes all users who are logged on to the system through a dial-up connection.
Everyone (S-1-1-0) | On computers running Windows XP Professional, Everyone includes Authenticated Users and Guest. On computers running earlier versions of the operating system, Everyone includes Authenticated Users and Guest plus Anonymous Logon. For more information, see Differences in default security settings.
Interactive (S-1-5-4) | Includes all users logging on locally or through a Remote Desktop connection.
Local System (S-1-5-18) | A service account that is used by the operating system.
Network (S-1-5-2) | Includes all users who are logged on through a network connection. Access tokens for interactive users do not contain the Network SID.
Self (or Principal Self) (S-1-5-10) | A placeholder in an ACE on a user, group, or computer object in Active Directory. When you grant permissions to Principal Self, you grant them to the security principal represented by the object. During an access check, the operating system replaces the SID for Principal Self with the SID for the security principal represented by the object.
Service (S-1-5-6) | A group that includes all security principals that have logged on as a service. Membership is controlled by the operating system.
Terminal Server Users (S-1-5-13) | Includes all users who have logged on to a Terminal Services server that is in Terminal Services version 4.0 application compatibility mode.

For more information on the Administrators (S-1-5-32-544), Power Users (S-1-5-32-547), Backup operators (S-1-5-32-551), and Users (S-1-5-32-545) groups, see Default security settings.

For more information, see Well-Known Security Identifiers at the Microsoft Resource Kits Web site.(http://www.microsoft.com/)


Using access control

This section covers:

  • Permissions
  • Permissions for files and folders
  • Selecting where to apply permissions
  • Changing inherited permissions


Permissions

Each type of object is controlled by an object manager. There is a different object manager for each type of object. The object types, their object managers, and the tools you use to manage these objects are as follows:

Object Type | Permission Descriptions | Procedures
Files and folders | File and folder permissions | To set, view, change, or remove permissions for files and folders or To set, view, change, or remove special permissions for files and folders
Shares | Shared folder permissions | To add a user or group to a shared resource
Registry keys | Maintain registry security | To add users or groups to the permissions list
Services | Services permissions | Local computer security for file system, registry, and system services
Printer | Printer permissions | To set or remove permissions for a printer
Terminal Services Connections | Permissions on Connections or Controlling connection access | To manage connection access
Group Policy object | To filter the scope of Group Policy according to security group membership or Default permissions | To set permissions for managing Group Policy
WMI object | To authorize WMI users and set permissions | To authorize WMI users and set permissions


Special permissions for files and folders

Microsoft Windows graphic

Permissions for files and folders

Folder permissions include Full Control, Modify, Read & Execute, List Folder Contents, Read, and Write. Each of these permissions consists of a logical group of special permissions which are listed and defined below.

Permission | Description
Traverse Folder/Execute File | For folders: Traverse Folder allows or denies moving through folders to reach other files or folders, even if the user has no permissions for the traversed folders (applies to folders only). Traverse folder takes effect only when the group or user is not granted the Bypass traverse checking user right in the Group Policy snap-in. (By default, the Everyone group is given the Bypass traverse checking user right.) For files: Execute File allows or denies running program files (applies to files only). Setting the Traverse Folder permission on a folder does not automatically set the Execute File permission on all files within that folder.
List Folder/Read Data | List Folder allows or denies viewing file names and subfolder names within the folder. List Folder only affects the contents of that folder and does not affect whether the folder you are setting the permission on will be listed. Applies to folders only. Read Data allows or denies viewing data in files (applies to files only).
Read Attributes | Allows or denies viewing the attributes of a file or folder, such as read-only and hidden. Attributes are defined by NTFS.
Read Extended Attributes | Allows or denies viewing the extended attributes of a file or folder. Extended attributes are defined by programs and may vary by program.
Create Files/Write Data | Create Files allows or denies creating files within the folder (applies to folders only). Write Data allows or denies making changes to the file and overwriting existing content (applies to files only).
Create Folders/Append Data | Create Folders allows or denies creating folders within the folder (applies to folders only). Append Data allows or denies making changes to the end of the file but not changing, deleting, or overwriting existing data (applies to files only).
Write Attributes | Allows or denies changing the attributes of a file or folder, such as read-only or hidden. Attributes are defined by NTFS. The Write Attributes permission does not imply creating or deleting files or folders, it only includes the permission to make changes to the attributes of a file or folder. In order to allow (or deny) create or delete operations, see Create Files/Write Data, Create Folders/Append Data, Delete Subfolders and Files, and Delete.
Write Extended Attributes | Allows or denies changing the extended attributes of a file or folder. Extended attributes are defined by programs and may vary by program. The Write Extended Attributes permission does not imply creating or deleting files or folders, it only includes the permission to make changes to the attributes of a file or folder. In order to allow (or deny) create or delete operations, see Create Files/Write Data, Create Folders/Append Data, Delete Subfolders and Files, and Delete.
Delete Subfolders and Files | Allows or denies deleting subfolders and files, even if the Delete permission has not been granted on the subfolder or file. (applies to folders)
Delete | Allows or denies deleting the file or folder. If you don't have Delete permission on a file or folder, you can still delete it if you have been granted Delete Subfolders and Files on the parent folder.
Read Permissions | Allows or denies reading permissions of the file or folder, such as Full Control, Read, and Write.
Change Permissions | Allows or denies changing permissions of the file or folder, such as Full Control, Read, and Write.
Take Ownership | Allows or denies taking ownership of the file or folder. The owner of a file or folder can always change permissions on it, regardless of any existing permissions that protect the file or folder.
Synchronize | Allows or denies different threads to wait on the handle for the file or folder and synchronize with another thread that may signal it. This permission applies only to multithreaded, multiprocess programs.


Selecting where to apply permissions

When you set advanced permissions on files and folders, you can use Permission Entry for File or Folder Name to set which folders or subfolders will inherit permissions. In this dialog box, Apply onto lists the locations where you can apply permissions. How these permissions are applied depends on whether you select the Apply these permissions to objects and/or containers within this container only check box. By default, this check box is cleared.

For more information, see How inheritance affects file and folder permissions.

When the Apply these permissions to objects and/or containers within this container only check box is cleared

Apply onto | Applies permissions to current folder | Applies permissions to subfolders in current folder | Applies permissions to files in current folder | Applies permissions to all subsequent subfolders | Applies permissions to files in all subsequent subfolders
This folder only | x |  |  |  |
The folder, subfolders and files | x | x | x | x | x
This folder and subfolders | x | x |  | x |
This folder and files | x |  | x |  | x
Subfolders and files only |  | x | x | x | x
Subfolders only |  | x |  | x |
Files only |  |  | x |  | x

When the Apply these permissions to objects and/or containers within this container only check box is selected

Apply onto | Applies permissions to current folder | Applies permissions to subfolders in current folder | Applies permissions to files in current folder | Applies permissions to all subsequent subfolders | Applies permissions to files in all subsequent subfolders
This folder only | x |  |  |  |
The folder, subfolders and files | x | x | x |  |
This folder and subfolders | x | x |  |  |
This folder and files | x |  | x |  |
Subfolders and files only |  | x | x |  |
Subfolders only |  | x |  |  |
Files only |  |  | x |  |


Changing inherited permissions

If the check boxes are shaded when you view the permissions of an object, the object has inherited permissions from the parent object. There are three ways to make changes to inherited permissions:

  • Make the changes to the parent object, and then the object will inherit these permissions.
  • Select the opposite permission (Allow or Deny) to override the inherited permission.
  • Clear the Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here. check box. Then, you can make changes to the permissions or remove users or groups from the Permissions list. However, the object will no longer inherit permissions from the parent object.

On the Advanced page, in Permission entries the Apply To column lists what folders or subfolders a permission is applied to. The Inherited From column lists where the permssions have been inherited from.

If the Special Permissions entry in Permissions for user or group is shaded, it does not imply that this permission has been inherited. This means that a special permission has been selected. For more information, see To set, view, change, or remove special permissions for files and folders.


File and Folder permissions

Special Permissions | Full Control | Modify | Read & Execute | List Folder Contents(folders only) | Read | Write
Traverse Folder/Execute File | x | x | x | x |  |
List Folder/Read Data | x | x | x | x | x |
Read Attributes | x | x | x | x | x |
Read Extended Attributes | x | x | x | x | x |
Create Files/Write Data | x | x |  |  |  | x
Create Folders/Append Data | x | x |  |  |  | x
Write Attributes | x | x |  |  |  | x
Write Extended Attributes | x | x |  |  |  | x
Delete Subfolders and Files | x |  |  |  |  |
Delete | x | x |  |  |  |
Read Permissions | x | x | x | x | x | x
Change Permissions | x |  |  |  |  |
Take Ownership | x |  |  |  |  |
Synchronize | x | x | x | x | x | x

Important

  • Groups or users granted Full Control on a folder can delete any files in that folder regardless of the permissions protecting the file.

Notes

  • Although List Folder Contents and Read & Execute appear to have the same special permissions, these permissions are inherited differently. List Folder Contents is inherited by folders but not files, and it should only appear when you view folder permissions. Read & Execute is inherited by both files and folders and is always present when you view file or folder permissions.
  • For information on setting permissions and descriptions of each special permission, see Related Topics.
  • In Windows XP Professional the EVERYONE group no longer includes the ANONYMOUS LOGON group.


Display the Security tab

Microsoft Windows graphic

To display the Security tab

  1. Open Folder Options in Control Panel.
      2. XOX
  2. On the View tab, under Advanced settings, clear Use simple file sharing [Recommended].


Permissions on a file server

One possible scenario for working with permissions is when you must assign permissions for the files on a file server. For example, suppose you need to set file permissions on a server used by a small department. The file server includes an applications folder, home folders for each of the department's users, a public folder where users can share files, and a drop folder where users can file confidential reports that only the group manager can read.

Applications folder. In this folder, make all executable programs read-only to all users, to prevent viruses and Trojan horses. You can also grant Change permission to members of the Administrators group, so that administrators can grant themselves Write permission when it is time to update a program.

If none of your programs needs to write any files (such as initialization files) in their own folders, you should also set all of the folders containing programs to read-only.

Home folders. In these folders, give each user Full Control over his or her own folder, and do not give anyone permissions for any other folder.

Public folder. In this folder, you can give all users Change permission. Change permission is more appropriate than Full Control, because Full Control also allows users to set permissions for the public folder and take ownership of it.

Drop folder. To create a drop folder, grant the Users or Everyone built-in groups Add permission for the folder, and grant Change permission to the manager who is to read the files in the folder.

Give access to local system folders or subfolders only to Administrators or Server Operators.