When we talk about Active Directory groups, we are usually talking about two kinds of groups: Distribution Groups and Security Groups. Managing distribution lists and security groups is a mission-critical task for just about any IT organization.
Active Directory distribution groups work with your email client to define who is included on group messages, while security groups are used to control access to resources. Those could be hardware, SharePoint sites, applications, folders, or a host of other uses.
Simple so far, right? Distribution groups are for emailing people, and security groups provide access. Black and white. Cut and dried.
Or maybe not… Let’s go through them briefly to understand the types better.
The Two Types of Active Directory Groups
Distribution Groups
Distribution groups are designed to combine users together so that you can send e-mails (via Microsoft Exchange Server) collectively to a group rather than individually to each user in the group. Active Directory Distribution groups are designed to be used for e-mail specifically and cannot be granted Windows permissions.
Objects in Active Directory that can have permissions granted to them are known as a security principal. For example, users are an example of a security principal because a user can be granted rights. Security groups, as discussed below, are also security principals. Distribution groups are not security principals, however, because rights cannot be granted to a distribution group. Why? Because the Active Directory schema does not give distribution groups this ability.
The terms “distribution groups” and “distribution lists” tend to be used interchangeably, particularly if you work with Microsoft Exchange Server administrators. Don’t let this trip you up!
Read: Scopes of Active Directory Groups
Security Groups
Used with care, Active Directory Security Groups provide an efficient way to assign access to resources on your network. Using security groups, you can
- Assign User Rights. User rights are assigned to active directory security groups to determine what members of that group can do within the scope of a domain (or forest). User rights are automatically assigned to built-in security groups at the time Active Directory is installed to help administrators define a person’s administrative role in the domain.
- Assign Permissions to Resources. Permissions are assigned to the security groups in the active directory for a shared resource. This is different from user rights because user rights apply across an entire domain versus permissions that are directed to a specific entity. Permissions determine who can access the resource and the level of access, such as Full Control or Read-only. Some permissions that are given domain objects are automatically assigned to allow various levels of access to built-in security groups, such as the Account Operators group or the Domain Admins group.
Read: Mail Enabled an Active Directory Security Group or Not?
Mail-Enabled Security Groups
A mail-enabled security group serves a dual purpose in an organization.
- It can be used to send and receive email messages.
- It can be used to grant access rights and permissions to network resources, such as files and shares.
Using a Security Group as a Distribution List
Set the Security Group Scope to Universal
By default, most security groups have a global scope. To mail-enable them, you must first change the scope to universal, as Microsoft Exchange only supports universal as a group scope.
Mail-Enable a Security Group
Open Exchange Management Shell on the Exchange Server and run the following cmdlet:
Type (Enable-DistributionGroup -Identity “Marketing”)
Here, replace the group name with the name of your security group. If the group name contains a space, use double quotes.
To reverse this, use the following cmdlet:
Disable-DistributionGroup -Identity “group name”
Create a Mail-Enabled Security Group
You can create a mail-enabled security group using Exchange Administration Center (EAC), as shown below.
However, you cannot mail-enable an existing security group using EAC; for that you have to use Exchange Management Shell.
The mail-enabled security group’s name, display name, group type, and primary SMTP address will appear in the resulting display.
The group is ready to receive an email. To view your group in EAC, go to Recipients > Groups.
This group is identical to other distribution groups in terms of its attributes.
Characteristics of Mail Enabled Security Groups
Granting Access to Resources:
Mail enabled security groups are used for granting access to resources such as SharePoint and emailing notifications to users.
Function Same as Security Groups:
They function the same as regular security groups, except that they cannot be dynamically managed through Azure Active Directory and cannot contain devices.
Ability to Send Mail:
It includes the ability to send mail to all the members of the group.
Can be Added to Team:
Mail-enabled security groups can be added to a team.
A Discussion on Mail-Enable Security Groups
QUESTION: So should you use a mail-enabled security group for email or create a distribution list instead?
Here are some questions that we have tried to answer this important question.
- Why should I mail-enable a security group instead of just using a distribution group?Network security cannot be controlled by distribution groups. There are instances when we need to alert users of an outage or, if concurrent usage licensing, send them a request to quit the program so that another user can access it. By mail-enabling security groups, we don’t have to maintain separate distribution lists for sending emails.
- When I run the following cmdlet:“Enable-DistributionGroup”I get the message, “The group you wish to mail-enabled is not a universal group. Mail can only be enabled for universal groups.”
What does this mean and how can I resolve the issue?Because Microsoft supports the universal scope for mail enabling a group, make sure you set this scope for your mail-enabled security groups in Exchange Server 2007 and later releases. Remember that groups with global scope cannot be mail-enabled. - I understand what security groups and distribution groups in Active Directory are used for. However, I am not convinced that a security group should be mail-enabled. What is the purpose of distribution groups in Active Directory if security groups must be used for both security and email distribution?A security group is stored in the Kerberos token of the user (or computer), allowing you to allocate rights based on group membership. The Kerberos token, on the other hand, has a maximum capacity limit, and if the user belongs to many groups, strange things will happen. Logging in a user account that is a member of more than 1,010 groups on Windows Server-based devices may fail, according to Microsoft. The user may receive an error message such as: HTTP 400 – Bad Request (Request Header Too Long) after authenticating. The user may also have difficulty accessing resources, and his or her Group Policy settings may not be up to date. Logon could also fail completely, with an error message such as: The user’s security context gathered too many security IDs during a logon attempt. Please try again or contact your system administrator for assistance. A “token bloat” is the term used to describe this issue. Distribution groups are not included to the Kerberos token (which is why you cannot grant/deny permissions based on distribution groups), preventing the user’s token from becoming too large.To summarize, use security groups wisely since you do not want to exceed the maximum number of groups per user.
- Originally created as security groups, I had some groups with email addresses. Someone converted them to distribution groups.The question is, does a security group that was converted to a distribution group lose its original SID? I want to convert some of the groups back to security groups, but I am not sure if the groups would regain ACL permissions.Even after a security group is changed to a distribution group, the security rights for that group are stored on the object. So, there’s a chance you’ll be fortunate. When you convert a distribution list back to a security group, it should have the same scope the security group originally had. Any changes will almost certainly result in the creation of a new SID. More research is needed on this subject. I just tried it out and discovered a few things. It’s possible that this will only operate in native mode.
- When you create a group, it is assigned a SID.
- The SID of a security group that is converted to a distribution group stays in the directory.
- The SID does not change when the group scope is changed.
- The security settings are very much visible on an object that was assigned to a security group, even when that security group is converted to a distribution group.
This, I believe, is to prevent the loss of security settings if an administrator decides to change their mind. While I would not rely on this behavior, as security ACLs persist on objects even if the original item is deleted, it would seem reasonable that the distribution group would retain the SID of the original security group.
When a user logs on, their security access token does not include distribution groups. This is because, while these distribution groups may be given SIDs, permissions cannot be assigned to them. And even if permissions were previously assigned, they would be ignored. When you revert the distribution group back to a security group, (supposedly) all previous security settings would be applicable again.
- We employ security groups to grant access to files, folders, and shares across our network. The Helpdesk is responsible for creating groups and adding/removing members. Our Heat system receives all requests. We’re able to document everything in this way.Some folks recommend using distribution lists and creating security groups out of them. It’s as simple as ticking a box to change a DL into a security group. What are the advantages and disadvantages of using a distribution list as a security group, especially if you’re working with sensitive information?Because distribution groups are not secure; they cannot be included in discretionary access control lists (DACLs).Whether it’s a security group or a distribution list, group owners can manage group memberships. They just need to know how they can accomplish it with ADUC (Active Directory Users and Computers), Windows Address Book, or a scripting tool (most are only aware of Outlook as a method).Ask yourself this question: is the group’s owner also the manager of the resource for which you want to change the distribution group to a security group?If you had an ACL (Access Control List) for the network share, you could convert a distribution group whose membership would be appropriate for it to a security group and apply the ACL to it. However, you may not want to do so since the manager of a distribution list with the ability to edit its members may not be the best person to oversee who has access to the share.For example, any user in an organization (such as a department manager) can be the owner of a distribution list. But when you convert this DL to a security group and assign permissions to multiple resources (such as files, shares, computers, and printers), the owner becomes irrelevant because the helpdesk or administrators can manage security groups better than a DL owner.When possible, we keep our security groups and distribution lists separate, but there are situations when they overlap naturally. In those circumstances, we normally take away the group owner’s ability to change the membership of the group (they can call the helpdesk if they need a change). You should never mail-enable a security group, as it would allow the owner to easily manage group membership through Outlook. And it’s not a good practice to allow managers to change security group memberships.
- We would like to create an Exchange distribution group (formed with New-DistributionGroup with closed joining and departing) to reach out to multiple teams quickly. Adding members directly works great, as those members receive the emails sent to the distribution group. However, when we add those teams’ security groups as members of the distribution group, they do not receive emails sent to the distribution group. Although these security groups do not have email capabilities, each individual user object within a security group does have a mailbox.Is there a way to ensure that security groups nested as DL members also receive emails sent to the DL? Is it because the distribution group has universal scope whilst the security groups have global as scope? I am aware that the reverse does not work.This does not appear to be doable. There is no direct evidence that states this; instead, there are a number of posts on the subject. For nested membership, Exchange relies on group expansion logic, which means that all groups along the chain must be mail-enabled. It is not a constraint imposed by AD. On a distribution group, running Get-ADGroupMember -Recursive works properly. It’s an Exchange constraint that only considers group members who have access to email. As a result, layering mail-enabled groups is possible. I have not tested whether simply populating a group’s e-mail address field is sufficient.
- Will the permissions assigned to an AD security group cascade to the members of a distribution group nested within that security group, or do I need to convert the distribution group to a mail-enabled security group in order to nest that distribution group within a security group?The situation is that another team has given me a security group to utilize to issue permissions to their team; however, users still don’t have permissions after issuing permissions to that security group. Looking at the security group’s membership, it appears to be a distribution group containing their people. I am assuming that’s why it’s not working, but I wanted to double-check.Distribution groups are not security principals and hence cannot propagate security permissions to their members. You’ll almost certainly require a mail-enabled security group. Instead of nesting, I would propose that you simply mail-enable the security group. You cannot add public folders to a security group. If this is for public folders, forget it; they must, as far as I am aware, be distribution groups. As a result, in some circumstances, duplicate groups are required (when one group is used to prevent users from accessing files and another is a distribution group).
- When allowing full access and Send As rights on a shared mailbox, I need to know how a mail-enabled security group differs from a security group.Allowing full access with an AD security group won’t allow Outlook to auto map the mailbox. I read that converting the security group to a mail-enabled security group would work, so I did that using the following cmdlet in Exchange Management Shell:Enable-DistributionGroup -Identity “group name”I used the following cmdlet for permissions:“Add-MailboxPermission -Identity “Shared Mailbox Name” -User “Groupname” -AccessRights FullAccess -InheritanceType All -AutoMapping $true”I thought that the mailbox would be auto mapped in Outlook as a result of this. But now I’m a little perplexed about this “mail enabled security group,” which appears in EMC/EAC under groups (as opposed to the security groups we regularly use in AD) and has its own email addresses. What is the purpose of a mail-enabled security group, given that it has its own addresses, and how would this appear to members?Mail-enabled security groups can be used to disseminate messages and provide access permissions to Exchange and Active Directory resources. In the Exchange Admin Center (EAC) or Exchange Management Shell, you may create, modify, and remove mail-enabled security groups.A distribution group is an Active Directory mail-enabled group object that can only be used to send messages to a certain group of people. A mail-enabled security group is a universal security group in Active Directory that may be used to disseminate emails as well as assign access permissions to AD objects.
Risks of Mail-Enabled Security Groups
As you know, as each user object collects more and more SIDs they are going to experience decreased performance due to token bloat. Their logins will be slower, and at more than 1015 tokens, they will be unable to log in entirely.
Of course, this makes it even more important that you have some sort of lifecycle on your security groups. Pretty much any security group should be monitored to make sure that the resource it protects still exists and the membership is current, but it becomes even more critical if every group is a security group!
Read: How to expire Active Directory Security Groups
So, what is right for you? Carefully monitored security groups or a mix of distribution and security groups?
Must Read Resource: Verdict on Mail Enable Security Group or Not
All-in-One Security Solution
When Active Directory Groups becomes too significant a burden to bear, it’s time to upgrade your life with GroupID. Join companies like Disney, Nike, Splunk, Hershey’s, FedEx, American Red Cross, The Federal Reserve, Cedar Sinai Hospital, and the Center for Autism, who all rely on GroupID to keep their systems up to date and secure. Get started with GroupID today with a Free Trial, and see how much more you could be doing with your Active Directory Groups while improving productivity.
Learn more about GroupID here.
Jonathan Blackwell
View ProfileSince 2012, Jonathan Blackwell, an engineer and innovator, has provided engineering leadership that has put GroupID at the forefront of group and user management for Active Directory and Azure AD environments. His experience in development, marketing, and sales allows Jonathan to fully understand the Identity market and how buyers think.