Unexpected Results Occur If You Set File Security by Using Either Group Policy or Security Templates

If you try to set file system permissions by using either Group Policy or security templates on files and folders that have Microsoft Windows NT 4.0-style Access Control Lists (ACLs), you may experience unexpected results. Specifically, you may modify the folder's permissions if the folders are not explicitly set to be configured. The file or folder that is affected inherits permissions when it was not configured to do so. As a result, the affected folder may have more relaxed access permissions.

This problem may occur if you are using a security template in which two or more ACLs are being set that are hierarchically under each other, and when one of the following conditions is true:

• You are using a volume that has been remotely accessed by a Windows NT 4.0 client computer.
• You are using a freshly formatted volume.
• You are using a volume that has been migrated from Windows NT 4.0.
• You are using a volume on which Cacls.exe has been used to set permissions.

This problem occurs because the security configuration engine does not correctly interpret Windows NT 4.0-style ACLs as being protected from inheritance.

To work around this problem, use any of the workarounds that are described in this section.

Workaround 1: Modify the Security Template to Protect Folders That May Be Affected

You can use Group Policy or security templates to configure files or folders so that they are protected from having their permissions replaced. To do so, click Do not allow permissions on this file or folder to be replaced when you set file system permissions.

In the scenario that is described in the Summary section, if you protect C:\Data\Private, inherited permissions are not applied to the folder after the policy is applied. The security template includes the following entries: If you click Do not allow permissions on this file or folder to be replaced, you also prevent any folders under C:\Data\Private from being affected.

NOTE: You cannot use wildcard characters (*) to specify multiple folders.

Workaround 2: Use Multiple Templates to Apply File System Security

The problem that is described in the "Summary" section only occurs when file system security is set at multiple levels in the same folder hierarchy in the same template. Therefore, if you create templates that only affect the file system at the same level in the hierarchy, you can prevent the problem from occurring.

For example, Template 1 applies permissions to C:\Data and Template 2 applies permissions to C:\Data\Public. In this scenario, you can apply the templates individually in any order. If you do so, C:\Data\Private is not affected.

Template 1 Settings: Template 2 Settings:

Workaround 3: Overwrite All of the Permissions

If you want all subfolders to be controlled only by using inherited permissions that are delivered by templates or Group Policy, you can use Overwrite mode. To overwrite all permissions, click Replace existing permissions on all sub folders and files with inheritable permissions in the Template Security Policy Setting dialog box that appears when you configure restricted groups.

For example, if you use the C:\Apps folder to provide an installation point for programs, you may want to make sure that all users have only read access to that folder and to the subfolders that contain the programs. In this scenario, you can use Overwrite mode. If you use the Overwrite mode, any Windows NT 4.0-style ACLs are converted to Windows 2000-style ACLs.

Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.

The version of the NTFS file system in Windows 2000 uses the inheritance functionality and inheritable permissions. In Windows 2000, a file or folder can have both explicit and inherited permissions. By default, the permissions are inherited from the containers that are higher in the folder heirarchy unless these permissions are blocked.

The permissions on files or folders can be represented by a string language known as Security Descriptor Definition Language (SDDL). The following list describes some of the strings that define inheritance behavior:

• "P" SDDL_PROTECTED: This string means that inheritance from containers that are higher in the folder heirarchy is blocked.
• "AR" SDDL_AUTO_INHERIT_REQ: This string means that child objects inherit permissions from this object.
• "AI" SDDL_AUTO_INHERITED: This string means inheritance is allowed, assuming that "P" is not also set.

A folder on NTFS that is formatted under Windows 2000 that has inheritance blocked typically has the P flag and the AI flag set, for example: Conversely, if you set an ACL by using the Cacls utility or the Xcacls utility, the ACL does not include the P flag or the AI flag. Therefore, inheritance does not affect an object that is configured in this way.

Sample Problem Scenario

The following folder hierarchy exists on a volume:

• C:\Data
• C:\Data\Public
• C:\Data\Private

The following permissions are set:

• C:\Data:D:PAI(A;OICI;FA;;;WD): Everyone Full Control, Block Inheritance
• C:\Data\Public:D:AI(A;OICIID;FA;;;WD): Everyone Full Control, Inherited
• C:\Data\Private:D:(A;OIIO;FA;;;BA)(A;CI;FA;;;BA): Builtin Administrators Full Control

You use the following command to set the permissions on C:\Data\Private: To reproduce the problem, use Group Policy to configure the following file system restrictions:

• C:\Data: Everyone Full Control, Users Read, Block Inheritance
• C:\Data\Public: Guest Read, Inheritance Enabled

After you apply the policy, the following permissions occur:

• C:\Data:D:PAI(A;OICI;FA;;;WD)(A;OICI;0x1200a9;;;BU)
• C:\Data\Public:D:AI(A;OICI;FA;;;WD)(A;OICI;0x1200a9;;;BG)(A;OICIID;FA;;;WD)(A;OICIID;0x1200a9;;;BU)
• C:\Data\Private:D:AI(A;OIIO;FA;;;BA)(A;CI;FA;;;BA)(A;OICIID;FA;;;WD)(A;OICIID;0x1200a9;;;BU)

After you perform this procedure, the AI flag is now set on C:\Data\Private. As a result, Everyone (WD) Full control permissions and Users (BU) Read permission are inherited.