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.
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.
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.
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 ResetPassword*, 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: