This topic contains 4 replies, has 3 voices, and was last updated by
September 12, 2017 at 4:07 pm #79417
I have created custom attributes in the AD schama and set the confidentiality bit for specific ones. I then created groups in AD and granted permissions to read those confidential attributes based upon the group membership. I set these permissions at the OU level where I place all of my users and set the inheritance flag. I used DSACLS to perform this.
I now want to run a report on the OU to view the exact permissions that have been set. Using get-acl "$ou_DN" | select -expandproperty access | select identityreference,activedirectoryright gives me some information but not specifically what I am looking for.
For instance: I create the attribute hrSomeAttribute. I then grant group "HR" controlaccess right to the hrSomeAttribute on the employees OU, set inheritance and set the confidentiality bit. Only the Domain Admins and HR group can view the values for a user for the hrSomeAttribute. it is hidden from all others.
When I run get-acl "AD:ou=employees,dc=domain,dc=com" | select -ExpandProperty access | select identityreference,activedirectoryrights, I cannot get the specific information I am looking for. I want to see that HR is granted CA access to hrSomeAttribute. I have more custom attributes with permission similar to this at the same OU level. I have other groups that are allowed to view confidential information. i need to run the report so that I can know that permissions have net been changed on sensitive information.
Is there a powershell way to do this?
September 12, 2017 at 4:09 pm #79420KeymasterPoints: 1Rank: Member
No, in that there are no specific commands to do this. You'd probably have to get into the underlying .NET bits. If not make LDAP calls. You could wrap a function around all that for ease of use, but you'll have to get into the nitty gritty yourself.
September 12, 2017 at 4:28 pm #79424
Thanks Don. been wracking my brain trying to figure this one out. I am not the best with .net but I can figure it out with enough research now that I know I need to go that route. BTW: looking forward to hearing you at Ignite this year.
September 13, 2017 at 12:26 am #79457ParticipantPoints: 0Rank: Member
If you don't mind using a third party module, you can try the PowerShellAccessControl module. The source is here (there's a build script that should work w/o Visual Studio), and a compiled version is here.
You'd want to use Get-PacAccessControlEntry:
# You should be able to provide the dn as the path: Get-PacAccessControlEntry 'ou=OuName,dc=site,dc=com' # Or you can use AD module commands to get objects: Get-ADObject 'FilterOrIdHere' | Get-PacAccessControlEntry
The optional parameters to Get-PacAccessControlEntry act as filters, and you can stack them up. For AD objects, you can use the -ObjectAceType and the -InheritedObjectAceType parameters to filter on ACEs that grant access to specific properties, property sets, extended rights, validated writes, and classes (-InheritedObjectAceType would only work with classes since it controls what types of objects an ACE applies to). They take wildcards, and they default to showing ACEs that grant the filtered rights, even if they're not explicit. For example, if you look for the reset password extended right, you'd use -ObjectAceType *Reset*Password*, and an ACE granting 'All Extended Rights' or 'Full Control' w/o an object ace type would also be included. If you are only looking for ACEs that grant a specific right via an object ace type or inherited object ace type, you can use the -Specific switch.
That was a lot of info in w/o good examples (I don't have access to a domain joined system right now, which is why I used wildcards for the reset password right), so please let me know if you have any questions. I'll try to put a couple of examples that *should* work below, but they haven't been tested:
Get-ADOrganizationalUnit blah | Get-PacAccessControlEntry -Principal User1Filter, Blah* -ObjectAceType *PropertyNameHere* Get-ADOrganizationalUnit blah | Get-PacAccessControlEntry -Principal User1Filter, Blah* -ObjectAceType *PropertyNameHere* -InheritedObjectAceType user Get-ADOrganizationalUnit blah | Get-PacAccessControlEntry -Principal User1Filter, Blah* -ObjectAceType *PropertyNameHere* -InheritedObjectAceType user -Specific Get-ADOrganizationalUnit blah | Get-PacAccessControlEntry -ObjectAceType *PropertyNameHere* -InheritedObjectAceType user -ActiveDirectoryRights WriteProperty
September 13, 2017 at 2:14 pm #79553
I will take this for a test spin in my dev environment. I will let you know how it worked for my situation.
The topic ‘View permissions for schema objects at the OU level’ is closed to new replies.