ADObjectPermissionEntry: access denied when running under non domain administrator account

[JasonN3]

Details of the scenario you tried and the problem that is occurring

When you use ADObjectPermissionEntry, it requires DomainAdmin in order to run. This was reported in #314 but closed due to a lack of response. Based on the powershell code I am using as a temporary replacement, it does seem like the solution @JoshuaJSwain suggested should work.

Verbose logs showing the problem

TBC

Suggested solution to the issue

The DSC configuration that is used to reproduce the issue (as detailed as possible)

Invoke-DscResource `
    -ModuleName ActiveDirectoryDsc `
    -Name ADObjectPermissionEntry `
    -Method Set `
    -Property @{
    Ensure                             = "Present"
    ObjectType                         = '00000000-0000-0000-0000-000000000000'
    InheritedObjectType                = '00000000-0000-0000-0000-000000000000'
    Path                               = $ObjectDN
    IdentityReference                  = "${DOMAIN}${ACCOUNT}"
    ActiveDirectoryRights              = @("GenericRead")
    AccessControlType                  = "Allow"
    ActiveDirectorySecurityInheritance = "None" 
}

The operating system the target node is running

TBC

Version and build of PowerShell the target node is running

TBC

Version of the DSC module that was used

TBC

[JasonN3]

I'm unable to work on a PR this week, but afterwards I will work on a PR.

[X-Guardian]

Hi @J4yD4n, you've just copied and pasted the issue description from #314. Please edit this and instead detail the actual Dsc config you are using where you see the problem, along with the verbose logs that are generated from it. Thanks.

[JasonN3]

There's really nothing useful to add to his report. I could maybe update the version numbers and the suggested solution, but right now the solution is in PR #576. Otherwise it is the exact same issue. How to repeat in existing code:

1. Create a user account and only grant it access to a specific OU or object
2. Attempt to change permissions using Set-TargetResource <- This will fail

[X-Guardian]

@J4yD4n, the module is not designed to be used in this way. It is designed to be called through either the DSC LCM or Invoke-DscResource. Please provide DSC that demonstrates the issue, not direct calls to the module functions.

[JasonN3]

Invoke-DscResource -ModuleName ActiveDirectoryDsc -Name ADObjectPermissionEntry -Method Set -Property @{Ensure = "Present"; ObjectType = '00000000-0000-0000-0000-000000000000'; InheritedObjectType = '00000000-0000-0000-0000-000000000000'; Path = $ObjectDN; IdentityReference = "${DOMAIN}\${ACCOUNT}"; ActiveDirectoryRights = @("GenericRead"); AccessControlType = "Allow"; ActiveDirectorySecurityInheritance = "None" }

[X-Guardian]

I've updated the initial issue text with the code you supplied, formatted to make it readable. Please update it with the additional info marked as TBC on the issue from your execution of the DSC.

I also don't see you specifying PsDscRunAsCredential, so how are you intending this resource to be run by a non admin account?

[JasonN3]

Using Set-ACL even in a standard powershell script doesn't work. It still requires more permissions than it should, so PSDscRunAsCredential won't help the original code. However, it may negate the need for the Credential parameter. If I do that though, it would be inconsistent with the rest of the resources (ADComputer, ADGroup, ADManagedServiceAccount, ADUser, possibly more). It's up to you on whether I should keep the Credential parameter I just added in or remove the Credential parameter on all of the resources in order to keep consistency.

[johlju]

@J4yD4n The parameter Credential in other resource is a legacy thing for PowerShell 4.0 that did not have PsDscRunAsCredential. Since this module is no longer supported on PS4.0 we could remove that parameter from all resources since we should use PsDscRunAsCredential to change the user context from the default SYSTEM. 🤔

[JasonN3]

I did a test with PsDscCredential before updating the merge request and it somehow worked even though it shouldn't have. Sorry for the waste of time. If someone else comes across this problem, make sure PsDscCredential is set. Even though Set-Acl will fail in powershell windows. Dsc gets around that somehow. Make sure PsDscCredential is set.