Exchange 2010 SP1 made a change to limit the ability to make changes to universal security groups (USGs) via the Exchange Management Console (EMC), which meant that administrators were no longer able to use EMC to amend USG membership, a side-effect of the introduction of support for a split permissions model. The problem was subsequently addressed in KB2487852 and administrators could once again use EMC to modify USG membership.

Exchange 2013 replaces EMC with the browser-based Exchange Administration Center (EAC), which builds off the Exchange Control Panel (ECP) used by Exchange 2010 for some administrative purposes and to set user options in Outlook Web App (OWA). Like many transitions, the switchover from EMC to EAC was bumpy in places. EAC has steadily improved as Microsoft has released cumulative updates, and it seems that some recent updates in Exchange 2013 CU6 have improved the ability to assign the ability to work with USGs to users who are not administrators.

As I documented in “Microsoft Exchange 2013 Inside Out: Mailbox and High Availability” (page 284-5), Exchange 2013 RTM would only allow users to create USGs through OWA if they were a member of the all-powerful Organization Management RBAC role group. Users who were members of the Recipient Management role group could create USGs through EAC, but a disconnection existed in the ability of the two role groups to interact with USGs through OWA and EAC.

Prompted by a recent question from a reader, I went back to look at the current situation as implemented in Exchange 2013 CU6 and found some improvements. The scenario that many are interested in involving giving permissions to help desk personnel to manage USGs without having to include those users in the Organization Management role group.

To test what can be done today, I created a role group called Help Desk Level 2 and assigned it the kind of management roles that I think you’d expect to find given to people who provide second-level support. The set of roles included the Security Group Creation and Membership role. As you’ll recall, an RBAC role is composed of a set of cmdlets and parameters that can be executed by users who are assigned the role through their membership of a role group.

By the way, if you’re at Exchange Connections in Las Vegas next week, be sure to check out the session on “Role Based Access Control and You” given by Bharghav Shukla (2:45pm on Wednesday). It’s just one of the in-depth technical sessions given by independent experts that you’ll get at Connections.

I then added some users to the role group. The next time the users log in and authenticate to Exchange, the RBAC evaluation that is part of this process will detect their membership of the Help Desk Level 2 role group and assign them the roles covered by the group. In effect, all of the cmdlets and parameters defined for each of the roles will then be available to the users. This is what happens when you start an EMS session with Exchange 2013 or Exchange Online and you see the message saying that command information is being got for the remote (PowerShell) session and that a certain number of commands have been loaded. Each one of those commands is described in a role assigned to the user.

An EMS session reports as it loads commands

The next step was to log into OWA using one of the user accounts that held the Security Group Creation and Membership role. OWA and EAC share the same “slab-based” user interface, which means that user interface components are only loaded if the user has the permission to interact with an object. For example, if your user does not hold the permission to work with public folders, you won’t see the public folders UI through EAC.

Through OWA options, I was able to create and edit USGs. The important caveat here is that you can only edit USGs if your account is listed as a group owner, presumably because USGs hold security principals that might be used to protect confidential information and you don’t want to create the potential for that information to be compromised by a change made by someone other than a group owner. The same behavior now extends across both EAC and OWA. It would be good if this fact was clearly called out in the TechNet article that documents the Security Group Creation and Management role as I can see how confusion might arise when a user who holds the role attempts to edit the membership of a USG that they don’t own.

However, there is a workaround. The Update-DistributionGroupMember cmdlet is used to update group membership of both USGs and (normal) mail-enabled groups. This cmdlet supports a BypassSecurityGroupManagerCheck switch that allows any user who holds the Security Group Creation and Management role through membership of a role group like Recipient Management to update the membership of a USG without being a group manager. Thus, it is possible to use this workaround in a scenario where you want to allow administrators to update USGs without having to add every administrator to the ownership of every group.

EAC command logging reveals how it runs Update-DistributionGroupMember

As can be verified with command logging, EAC never passes the BypassSecurityGroupManagerCheck switch when it calls the Update-DistributionGroupMember cmdlet. This is to ensure that the same behaviour exists across EAC and OWA, which is a good thing. It’s also good that some of the restrictions that existed in older versions of Exchange 2013 have now been addressed!

Follow Tony @12Knocksinna