But the output is a bit messy, and what we really want to see is the security principal for a given Access Control Entry (ACE) and it’s permission, so we can modify the statement slightly above to pare down the listing, like this: What we’re doing here is calling the Get-ACL cmdlet on the distinguished name of the Marketing OU, and asking it to return just the “Access” property, which is what holds the security descriptor for that OU.
This returns the full Access Control List for the Marketing OU. (Get-Acl “OU=Marketing, DC=cpandl,DC=com”).Access Let’s say we want to find out the current ACL on the Marketing OU. Now that we are “in AD” we can use Get-ACL and Set-ACL to manage security on OUs. This changes our default drive to our current AD domain. How can I do that? Type the following into PowerShell to get into the AD PS Provider: Let’s say I want to get the current permissions on my Marketing OU. They work equally well on AD as PS Provider, so let’s see how that works. What we can do, is take advantage of the AD “PS Provider” that comes with the PowerShell module, along with some existing cmdlets called Get-ACL and Set-ACL, which are ordinarily used for getting and setting file system security. Interestingly, there are no direct cmdlets in the Active Directory PowerShell module that Microsoft provides that allow you to get and set ACLs on AD objects. These rights can be conveyed using a number of different methods, including the “Delegation of Control” wizard in AD Users and Computers, modifying the Access Control List (ACL) of the OU directly, or using a command-line utility like dsacls.exe.
The ability to add objects to an OU, or to modify those objects within the OU, is often controlled at the OU level.
Let’s start by looking at how we can keep an eye on delegation of Organizational Units (OUs).
0 kommentar(er)
