Access control lists, by default, inherit rules from parent container objects. Access rule protection blocks the propagation of rules from a parent object.

Rule protection can be enabled for the access ACL using the SetAccessRuleProtection method or for the audit ACL using the SetAuditRuleProtection method.

Setting rule protection has the same effect as disabling inheritance in the GUI.

Each of the methods expects two arguments. The first argument, isProtected, dictates whether or not the list should be protected. The second argument, preserveInheritance, dictates what should be done with existing inherited entries. Inherited entries can either be copied or discarded.

In the following example, access rule protection is enabled (inheritance is disabled) and the previously inherited rules are copied into the ACL:

$acl = Get-Acl C:TempACL2 
$acl.SetAccessRuleProtection($true, $true) 
Set-Acl C:TempACL2 -AclObject $acl  

Copied rules will only appear on the ACL (as explicit rules) after Set-Acl has been run.

If access rule protection is subsequently re-enabled, copied rules are not removed. The resulting ACL will contain both inherited and explicit versions of each of the rules. Inheritance can be re-enabled as follows:

$acl = Get-Acl C:TempACL2 
$acl.SetAccessRuleProtection($false, $false) 
Set-Acl C:TempACL2 -AclObject $acl 

The access control list will have doubled in length:

PS> Get-Acl 2 |
>>     Select-Object -ExpandProperty Access | 
>>     Select-Object FileSystemRights, IdentityReference, IsInherited

FileSystemRights               IdentityReference                   IsInherited
----------------               -----------------                   -----------
-536805376                     NT AUTHORITYAuthenticated Users    False
Modify, Synchronize            NT AUTHORITYAuthenticated Users    False
FullControl                    NT AUTHORITYSYSTEM                 False
268435456                      NT AUTHORITYSYSTEM                 False
268435456                      BUILTINAdministrators              False
FullControl                    BUILTINAdministrators              False
ReadAndExecute, Synchronize    BUILTINUsers                       False
FullControl                    BUILTINAdministrators              True
268435456                      BUILTINAdministrators              True
FullControl                    NT AUTHORITYSYSTEM                 True
268435456                      NT AUTHORITYSYSTEM                 True
ReadAndExecute, Synchronize    BUILTINUsers                       True
Modify, Synchronize            NT AUTHORITYAuthenticated Users    True
-536805376                     NT AUTHORITYAuthenticated Users    True 

Discarding access rules will result in an empty ACL:

$acl = Get-Acl C:TempACL3 
$acl.SetAccessRuleProtection($true, $false) 
Set-Acl C:TempACL3 -AclObject $acl 

Once this operation completes, any attempt to access the directory will result in access being denied:

PS> Get-ChildItem C:TempACL3
Get-ChildItem : Access to the path 'C:TempACL3' is denied.
At line:1 char:1
+ Get-ChildItem C:TempACL3
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : PermissionDenied: (C:TempACL3:String) [Get-ChildItem], UnauthorizedAccessException
    + FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand 

Access to the folder can be restored provided the current user has the SeSecurityPrivilege privilege, granted to users with administrative privileges (run as administrator). Re-enabling inheritance is the simplest way to do this, although we might have taken the opportunity to add rules:

$acl = Get-Acl C:TempACL3 
$acl.SetAccessRuleProtection($false, $false) 
Set-Acl C:TempACL3 -AclObject $acl 

In the previous example, the second argument for SetAccessRuleProtection, preserveInheritance, is set to false. This value has no impact; it only dictates behavior when access rule protection is enabled.

This loss of access does not apply when using the SetAuditRuleProtection method, as it does not describe who or what can access an object.