The main purpose of the article is to clarify some terms and concept that relate to the “group” object and to demonstrate the efficiency that we can
achieve when managing permissions by using a group instead of assigning permission directly to a specific user.
Reduce the number of permission tasks
Despite the fact, that providing permission to a specific user considers as the simple task, the disadvantage of this option is that in time, the management of a large amount of users becomes hard and messy.
The use of “group” enable us to define a “logic wrapper” for users who need permission to other user’s resources (mailbox, mailbox folder, etc.). The permissions are assigned to the group and the users who are a member in the group inherit the permission that was assigned to the group.
When we need to assign a permission or remove permission to a specific user. We will just need to add the user to the specific group or remove the user form the specific group.
To demonstrate to the advantages of using a group for assigning permissions, let’s use the following example: the Help Desk team members are: Suzan, John, bob and Isabel. We need to assign this user a permission to access the calendar of the following users: David and Alice. In case that we want to assign each of the members on the helpdesk team the required permission, we will need to implement eight different tasks.
Assign permission to Suzan (Help desk team member) on David and Alice (two separate operations) to the assignment of the required permission for the rest of the three members will end up by implementing an additional six permissions tasks.
The second option (the preferred option) is to assign the required permission to a group. The first step is to create the group, add the required members to the group and the last step is to assign the group the required permission for accessing David and Alice’s calendar.
In this way, we will need to “execute” the permission task only once verses the former scenario that was implemented by eight individual permission tasks.
In case that you are not fully convinced we can think of scenarios in which we need to assign calendar permission to Help desk team member to 300 users ( you can try to do the mathematics, if you want a claw, the number of the permission task will be 4 X 300 = 1200).
Another scenario could be: Suzan (one of the Help Desk team members) is leaving the Help Desk team. In case that we use the option of: assigning permission to an individual user, we will need to look and find all the users that Suzan has permission to the calendar or mailbox, and starts to remove this permission user by the user.
Security Group versus Distribution group
The main difference between Security Group versus Distribution group is that we can use a security group for assigning permissions. We cannot use a distribution group for assigning permission. In other words: Distribution groups are not security-enabled, which means that they cannot be listed in discretionary access control lists (DACLs).
The next question could be: I know that we use distribution group for sending mail to each of the members of the distribution group (be specifying the distribution group name is a recipient) but can use a security group also as a distributing group? And the answer is: yes!
To make a security group function as a “distribution group” all we need to do is assigns an email address to the security group. When we assign an email address to a security group, the group is described as: Mail enabled security group (other used term is Security Distribution Group).
When users create a new mail item and use the GAL (global address list) for selecting there is no unique sign that distinguishing a Mail enabled security group from a standard distribution group.
Implicit verse explicit permissions
Important terms that we should be familiar with is: Implicit and explicit permissions. The term implicit permissions describe a scenario in which we provide a permission implicitly to a specific object such as a “user object.” For example: when we assign John access permission to Suzan’s calendar, we use implicit permissions.
When we assign permission to a group, we also use an implicit permission. The group members are assigned with implicit permissions.
We use the term “Implicit permissions” because the fact the group member inherits their permission from the group that they belong to. For example: we assign a Full access permission to Alice’s mailbox to a group named: Help Desk John and Suzan that are a member’s in the Help Desk group. Because of that John and Suzan have also Full Access permission to Alice’s mailbox.
The dynamic nature of the group
We have mentioned the advantages of assigning a permission to a group instead of assigning permission to a specific user, but I would like to add additional emphasis the ability of the group to answer the need for managing permission in a dynamic environment.
When we assign permission to a Security group, all the group members automatically inherit the permission that was assigned to the group.
In the following diagram, we can see that each of the Help Desk group members, have Full access permissions to David’s mailbox (the concept of Implicit permissions).
In case that one of the Help Desk members is leaving the team, all we need to do is remove the team member (Bob in our example) from the Help Desk group instead of accessing David’s mailbox and manually remove Bob’s permissions.
Bob was replaced by a new Help Desk team member named: Isabel. To be able to provide Isabel the required permission for managing other user mailboxes (David’s mailbox in our example) all we need to do is just add Isabel to the Help Desk group. Isabel will inherit the access permission that was assigned to the Help Desk group.
Another important concept that we should be familiar with is the: Group nesting. The Group nesting concept describes a scenario in which a group is a member in other groups (A group can contain “user object” or “Group object”). The concept of inheritance or implicit permissions is implemented in the same way for a group.
To demonstrate the concept of Group nesting let’s use the following scenario: in the company’s headquarters, we create a security group named: HQ Help Desk. We want to enable Help Desk member of the New York site to have access permission to David’s mailbox. The New York site help desk member has a group named: NY Help Desk.
To accomplish this task, we can implement the option of: Group nesting. All we need to do is add the NY Help Desk as a member in the HQ Help Desk.
The outcome is that now Isabel and Jeff have also access permission to David’s mailbox.
The use of Group nesting is a powerful option, and we can implement many levels of “nesting.” Although we can implement a complicated structure of Group nesting, the best practice is not to over use the nesting option because the advantage could become a disadvantage when we create a complicated structure of nesting. Using too many levels of nesting prevents us from getting a clear view of the permission structure.
Converting a Distribution group to a Security group
In case that you have been convinced that is better to use security group for assigning permission (or as a “distribution group”) the obvious questions could be: how can I convert existing distribution group to a Security group? The answer is that at the current time, there is no option to convert the type of the group.
Additionally, there is no menu or interface that can enable us to copy group member form existing group to a “New security group.” I have found some workaround for this issue by using a PowerShell command that copies existing member form one group (distribution group) into a new group that was create as a security group.
$DestinationGroup = “Help-Desk-NEW”
Get-DistributionGroupMember -Identity $SourceGrpoup |
$DestinationGroup -Member $($_.Alias)
The solution is to plan ahead for the required permission infrastructure, create the required security group and find a way to copy the group member’s form existing distribution group into the new security group that has been created.
Another scenario could be when there is an implementation of Directory synchronization (DirSync application). In that case the solution is simpler because the On-Premises Active directory enable us to convert and existing distribution group into a security group. We will need to convert the required distribution group into a security group and the update will be replicated to the Office 365 Active Directory (AD Azure).
Creating a new Security group
The task of: Creating a new Security group in Exchange Online is very simple. In the Exchange Online management interface on the top menu bar choose the group menu and choose the add icon.
In the following screenshot we can see the available option for the group type.
To create a mail enabled security group, choose the option of: Security group.
Find information about the group type
In case that you want to get information about the “type” (security or distribution) of a group in the Exchange Online management interface on the top menu bar choose the groups menu.
In the GROUP TYPE column you can see information about the group type.
We really want to know what you think about the article