Did you know: SID strings and Exchange permissions

OK, let’s start with some definitions. SID stands for Security Identifier and its purpose is to uniquely identify a security principal (trustee), such as a group or user. In the security descriptor definition language (SDDL), there are several well-known SIDs, for example the Everyone group, which can be identified by the SID S-1-1-0. Apart from the standard string representation of a SID (which always uses the format S-R-I-S), for well-known SIDs we can use the SID string constants listed in this article. SID strings are basically two letter trustee shorthand notations, for example the Everyone group can be denoted with the WD SID string.

Turns out, you can actually use SID strings to specify the trustee for some permissions related operations in Exchange. This was news to me, as none of the TechNet articles mentions the fact (and they do list a rather extensive number of ways you can designate a trustee, see for example the description of the User parameter here). As it usually happens, I run into this discovery by chance. I was preparing an example for a forum reply, with the idea to illustrate the possibility to grant SendAs permission to a group object, so I used by “DG” group within the PowerShell cmdlet:

PS C:\> Add-RecipientPermission shared -AccessRights SendAs -Trustee DG

Identity                            Trustee                             AccessControlType                   AccessRights                        Inherited
--------                            -------                             -----------------                   ------------                        ---------
shared                              EURPRD03\Domain Guests              Allow                               {SendAs}                            False

Yes, I do have a distribution group named “DG”, I’m simple like that :). Note the highlighted part however. While I was expecting to simply see the “DG” group added, instead the “Domain Guests” well-known SID appeared. After few dumb looks I realized what has happened – if you go back to the SID strings article above, you will notice that the two letter “DG” notation corresponds to the “Domain Groups” SID!

Now, as I mentioned earlier, I discovered this because of the lucky coincidence that my poorly named Distribution group matched one of the SID strings. Once I noticed this however, I was quickly able to verify that any other SID string will also to the trick. For example, I can add Domain Admins, Enterprise Admins, and so on:

PS C:\> Get-RecipientPermission shared

Identity                            Trustee                             AccessControlType                   AccessRights                        Inherited
--------                            -------                             -----------------                   ------------                        ---------
shared                              NT AUTHORITY\SELF                   Allow                               {SendAs}                            False
shared                              EURPRD03\Domain Admins              Allow                               {SendAs}                            False
shared                              EURPRD03\Domain Guests             Allow                               {SendAs}                            False
shared                              EURPRD03\Enterprise Admins        Allow                               {SendAs}                            False

Overall, it seems to work with every trustee shorthand notation (SID strings) recognized by the SDDL format. Apart from Recipient permissions, we can also grant Mailbox Permission, for example:

PS C:\> Add-MailboxPermission shared -User WD -AccessRights FullAccess

Identity             User                 AccessRights                                                                                                            IsInherited Deny
--------             ----                 ------------                                                                                                            ----------- ----
shared               Everyone         {FullAccess}                                                                                                            False       False

In all fairness, using SID strings with the above cmdlets doesn’t bring anything new to the table. Each of these security principals, such as “Domain admins” or “NT AUTHORITY\SELF” or “Everyone” can be added simply by typing its name as the value for the Trustee/User parameter. On the other hand, Mailbox folder permissions, public folder permissions or role assignments cmdlets do not seem to recognize the SID strings format, just as they don’t recognize the actual security principals behind “Domain admins”.

Support for the SID strings format however can cause small nuisances for people like me, which tend to use simple names for their recipient objects. If we go back to the beginning or the article and the example with the now famous “DG” group, we can see that SID strings took precedence over the group name. So if we have conflict between the object name and some SID string, we would need to use a different identifier for said object, such as email address or UPN. Otherwise the result will not be what we expect. And there’s always the possibility of simply missing the actual trustee that got added in the cmdlet output, thus causing some minor headaches with seemingly not-working permissions.

This entry was posted in Exchange Online, Office 365, PowerShell. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *