Many Exchange administrators are familiar with the Get-ADPermission cmdlet. In the contrary to the Get-MailboxPermission cmdlet, the Get-ADPermission cmdlet retrieves Active Directory permissions for an object, instead of permission in Exchange itself. For instance, the Get-ADPermission cmdlet will reveal e.g. Send-As permissions whereas the Get-MailboxPermission cmdlet will tell you e.g. who has Full Access permissions on the mailbox.
If you need to do a quick search for Send-As permissions, and for a limited set of mailboxes, you will find that using the Get-ADPermission cmdlet is pretty simple and straightforward:
[sourcecode language=”powershell”]Get-ADPermission <mailbox> | ?{$_.ExtendedRight -like "*Send-As*"}[/sourcecode]
If you are dealing with a large number of mailboxes (e.g. several thousands of mailboxes), using the Get-ADPermission cmdlet can be quite limiting. During recent testing, I noticed the command took anywere from 2-8 seconds per mailbox to complete. In this particular scenario, I was helping a customer to move user accounts from their (old) account forest into the new resource forest.
As part of the process, we would enumerate all mailbox permissions (including Send-As), and check if any of them were assigned to a user account in the account forest. However, because the source environment has tens of thousands mailboxes, the Get-ADPermission approach was not feasible.
Normally, querying AD is not a problem. If you’ve ever written an LDAP query, you probably noticed that most of them complete within several seconds –depending on the result set size, of course. But either way, talking directly to AD should be a lot faster. As such, and given that Send-As permission are assigned to the user account in AD, I figured that using the Get-ACL cmdlet would be best suited.
The first particularity to keep in mind is that, for easy processing, you should change your current location in PowerShell to Active Directory:
[sourcecode language=”powershell”]Import-Module ActiveDirectory
Set-Location AD:[/sourcecode]
Next, you can e.g. run the following command to get the ACL for an object. Notice how I’m using the distinguishedName of the object. Although there are other ways to quickly get the DN for an object, I referred to using the Get-Mailbox cmdlet, because I had to run it earlier in the script anyway:
[sourcecode language=”powershell”]$mbx = Get-Mailbox <mailbox>
(Get-ACL $mbx.distinguishedName).Access
ActiveDirectoryRights : ExtendedRight
InheritanceType : None
ObjectType : ab721a53-1e2f-11d0-9819-00aa0040529b
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : EXCHANGELAB\Everyone
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
ActiveDirectoryRights : ExtendedRight
InheritanceType : None
ObjectType : ab721a54-1e2f-11d0-9819-00aa0040529b
InheritedObjectType : 00000000-0000-0000-0000-000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : EXCHANGELAB\UserA
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
ActiveDirectoryRights : WriteProperty
InheritanceType : All
ObjectType : 934de926-b09e-11d2-aa06-00c04f8eedd8
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : EXCHANGELAB\Exchange Servers
IsInherited : False
InheritanceFlags : ContainerInherit
PropagationFlags : None[/sourcecode]
The result of the cmdlet will look similar to what you see above. For brevity purposes, I’ve omitted some of the results. Nonethelss, it should give you a good picture of what to expect.
As you can see from the results, there’s a LOT of entries on each object. Because I was solely interested in the Send-As permission, I decided to filter the results based on the ActiveDirectoryRights attribute. Given that Send-As is an ExtendedRight, I used the following:
[sourcecode language=”powershell”]$mbx = Get-Mailbox <mailbox>
(Get-ACL $mbx.distinguishedName).Access | ?{$_.ActiveDirectoryRights -eq "ExtendedRight"}
ActiveDirectoryRights : ExtendedRight
InheritanceType : None
ObjectType : ab721a53-1e2f-11d0-9819-00aa0040529b
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : EXCHANGELAB\Everyone
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
ActiveDirectoryRights : ExtendedRight
InheritanceType : None
ObjectType : ab721a54-1e2f-11d0-9819-00aa0040529b
InheritedObjectType : 00000000-0000-0000-0000-000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : EXCHANGELAB\UserA
IsInherited : False
InheritanceFlags : None
PropagationFlags : None[/sourcecode]
So far, so good. However, none of the entries mentioned “Send-As” anywhere. As it turns out, the objectType attribute contains a GUID which refers to the actual permission. AD stores information about Extended Rights in the configuration partition, in a container unsurprisingly called “Extended-Rights”. Using ADSIEdit, you can navigate to the Send-As Extended Right, and look for the rightsGuid attribute. I’ve checked in various labs and environments, and the Guid always turns out to be ab721a54-1e2f-11d0-9819-00aa0040529b.
Now that we have this information, it is very easy to filter the results from the Get-ACL cmdlet:
[sourcecode language=”powershell”]$mbx = Get-Mailbox <mailbox>
Get-ACL $mbx.distinguishedName | ?{($_.ActiveDirectoryRights -eq "ExtendedRight") -and ($_.objectType -eq "ab721a54-1e2f-11d0-9819-00aa0040529b")}
ActiveDirectoryRights : ExtendedRight
InheritanceType : None
ObjectType : ab721a54-1e2f-11d0-9819-00aa0040529b
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : EXCHANGELAB\UserA
IsInherited : False
InheritanceFlags : None
PropagationFlags : None[/sourcecode]
While benchmarking this approach, we were able to return results for approximately 1-5 mailboxes per second. Quite an improvement over before!
The one caveat is that Get-ACL does not return the same result set (in terms of what attributes are shown) as the Get-ADPermission cmdlet. If all you care about it the permission itself, or if you already have all the other information for the mailbox (e.g. because you previously ran Get-Mailbox), than the speedy approach using Get-ACL might just offer all you need.
You must log in to post a comment.