mcollera / accesscontroldsc Goto Github PK

Change code in NTFLAccessEntry.psm1 file:
Proposed Solution:- to make the resource compatible with PowerShell core. We should replace the GetAccessControl method calls with ‘Get-Acl’ cmdlet
existing: $currentAcl = $fileSystemItem.GetAccessControl('Access')
new: $currentAcl = Get-ACL $fileSystemItem

In the following scenario, if a user specifies "SYSTEM" to have "FullControl" with "ContainerInherit" as the "InheritanceFlags", "None" as the "PropagationFlags" and "Allow" as the "AccessControlType", the resource will create an access rule accordingly and add it to the current ACL. However, when the resource detects a similar ACE, such as "SYSTEM/FullControl/None/None/Allow", it will add this to the "ToBeRemoved" access rules variable. The method that is used to remove the access rule is not absolute, meaning that it will remove any rule that matches the IdentityReference and Access Mask.
Removes access rules that contain the same security identifier and access mask as the specified access rule from the Discretionary Access Control List (DACL) associated with this CommonObjectSecurity object.
https://docs.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.commonobjectsecurity.removeaccessrule?view=netframework-4.5.1
The rule in the screenshot outlined in red is the targeted rule to be removed, however, when the "RemoveAccessRule" is called, with the supplied rule, it removes "FullControl" from the "SYSTEM" Principal. The "ContainerInherit/InheritOnly" will grant "SYSTEM" "FullControl" access, through inheritance to any child objects, but not the parent where this ACE/ACL is defined.

I will be submitting a PR to address this by calling RemoveAccessRuleSpecific instead:
https://docs.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.commonobjectsecurity.removeaccessrulespecific?view=netframework-4.5.1

Describe the bug

When NTFSAccessEntry is used and a string that contains wildcards is used to address permissions to a given path, the resource fails to reach the desired state.

To Reproduce

Generate a configuration where the path statements contains wildcards, such as .*.*
Attempt to apply the configuration to a system, the permissions will not apply correctly.

Expected behavior

Successfully apply permissions to multiple files when wildcards are used in a given path.

When permissions are assigned to the registry, multiple code paths can be used. When querying/maintaining ACLs/ACEs with .NET, any ACEs defined with the COM code path will not translate correctly. This is why one would observe a value of -2147483648 (Generic Read) and 268435456 (Full Control) for RegistryRights with some ACEs. Any principal other than APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES is handled correctly. However, there's a workaround that has to be performed when manipulating access rules with the formerly mentioned principal. The workaround involves creating a new access rule with the SID for ALL APPLICATION PACKAGES then performing an action to the ACL, whether it's a remove or add. This workaround is not viable since the translated RegistryRights in these cases aren't valid RegistryRights enumerations. Code will have to be developed to handle removing these ACEs when the scenario is encountered.
This will require additional code than what was addressed for Issue #37

Started new resource in fork, see pull request #28

AccessControlDSC v1.4.0.0 is throwing error while trying to set permission to a folder for the group "ALL APPLICATION PACKAGES" and "ALL RESTRICTED APPLICATION PACKAGES"

Below is the error message

Exception calling "AddAccessRule" with "1" argument(s): "Some or all identity references could not be translated."
+ CategoryInfo : NotSpecified: (:) [], CimException
+ FullyQualifiedErrorId : IdentityNotMappedException
+ PSComputerName : localhost

The PowerShell DSC resource '[NTFSAccessEntry]Test' with SourceInfo
'C:\Temp\Hardening_IIS_DSC\Dependencies\AccessControlDSC\1.4.0.0\Examples\NtfsAccessEntry_example -
Copy.ps1::6::9::NTFSAccessEntry' threw one or more non-terminating errors while running the Set-TargetResource
functionality. These errors are logged to the ETW channel called Microsoft-Windows-DSC/Operational. Refer to this
channel for more details.
+ CategoryInfo : InvalidOperation: (:) [], CimException
+ FullyQualifiedErrorId : NonTerminatingErrorFromProvider
+ PSComputerName : localhost

The SendConfigurationApply function did not succeed.
+ CategoryInfo : NotSpecified: (root/Microsoft/...gurationManager:String) [], CimException
+ FullyQualifiedErrorId : MI RESULT 1
+ PSComputerName : localhost

When using the WriteProperty AD right, how do I specify an individual property such as msDS-AllowedToActOnBehalfOfOtherIdentity ?

Thank you!

I think the NTFSAccessEntry resource should have the option to explicitly set the inheritance for permissions instead of only disabling it when trying to remove an inherited permission.

I would like to add a DSC resource that can manage file and most audit rules on files, and if it makes sense, registry keys also

RegistryAccessEntry resource does not resolve out of box SID used in permissions on HKLM:\SOFTWARE and HKLM:\SYSTEM starting in Server 2019 and Windows 10 (1809+), including Server 2022 and Windows 11.

Applying DSC configuration to set permissions on HKLM:\SOFTWARE with "force" param removes this SID, which is problematic. Attempting to add this SID to the DSC resource causes an error, as it can not resolve to a friendly name, which is by design with capability SIDs.

SID: S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681

This is a capability SID and should not be removed from the permissions of HKLM:\SOFTWARE or \SYSTEM:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/sids-not-resolve-into-friendly-names#cause

Is your feature request related to a problem? Please describe.

Yes, there are instances where ObjectType is needed with an Audit Rule, the current implementation of ActiveDirectoryAuditRuleEntry does not allow for these scenarios.

Describe the solution you'd like

The resource should have ObjectType parameter for this scenario.

An exception occurs in Test on both NTFS and Registry resources when ACLRules first addition is only a single object and not an array. Subsequent additions throw an exception because there is no add method on PSObjects. Fix is to instantiate ACLRules as an array at the beginning of the function.

Describe the bug

When Force and ForcePrincipal parameters are set to false and Inheritance/Propagation Flags are not equal to the currently defined ACE, the Test-TargetResource function will return $false for "InDesiredState". Because of this issue, the Set-TargetResource Function is run unnecessarily, as well as the configuration is never compliant/in desired state.

To Reproduce

1. On the target machine, modify an NTFS permission rule outside of the default setting and/or outside what the current configuration specifies. Furthermore, a principal can be defined via a configuration to have 1 set as the InheritanceFlags, but the actual ACE for the specific principal is 3, when this scenario occurs, the Test-TargetResource will return false and the Set runs. When the Set-TargetResource function runs, it sets the ACE to 1, however, since the principal already has 3, it has more than what is needed so nothing technically happens.
2. Create a Member Server configuration and apply it to a target machine.
3. When you run the configuration over and over again, note that it's never in the desired state, even though the Set-TargetResource function is executed.

Expected behavior

The Set-TargetResource should not run in this scenario since the specified rule is already applied via an ACE granting common Inheritance/Propagation Flags.

If a configuration requires the "ALL APPLICATION PACKAGES" IdentityReference to be added to a registry ACL, the resource doesn't gracefully handle this scenario. The code in this resource converts the user input string to an NTAccount, which creates the Fully Qualified version of this principal, then creates an access rule with the converted Identity. When the access rule is added to the current ACL, this error occurs:
Exception calling "AddAccessRule" with "1" argument(s): "Some or all identity references could not be translated."
There is code, however, in this resource to handle successful removal of an identity for this scenario, but isn't handled when adding to the ACL.
This is a known win32 API bug according to Yanbing, see the following link:
PowerShell/Win32-OpenSSH#750
To workaround this issue, one of two things must occur, the short name can be provided to the access rule or the SID equivalent. I will be submitting a PR for this issue momentarily with the latter workaround as the fix.

Describe the bug

The NTFSAccessControlEntry Resource will complete remove Audit Rules defined for a given path. Furthermore, there's also a bug that will not successfully set the defined permissions if the Local Service is the current owner. Both these bugs are addressed with the same code fix.

To Reproduce

1. Create a member server 2012 R2 configuration.
2. On a newly installed OS, modify the Application.evtx permissions.
3. When the Set-TargetResource runs, it will throw an error.
4. If audit rules are defined on any path where Set-TargetResource runs, those audit rules are completely removed.

Expected behavior

Apply a configuration without throwing an error or wiping any pre-defined audit rules for a given path.

Screenshots