In a recent conversation with a GroupID customer, we were made aware that they don’t allow mail-enabled Active Directory security groups. Another customer in the same meeting wished to disable the ability of mail-enabling security groups altogether.
So, it left us wondering why IT Administrators are hesitant to mail enabling security groups? Before digging down into why they are reluctant, Let’s discuss first when we would want to mail enable Active Directory security groups.
Table Of Contents
Use Cases to Mail-Enable Security Groups
-
Giving Permission to a Specific Printer
You are using a security group to permit the use of a specific printer, and it’s broken…the best way to tell the users of that printer is to email everyone who has permission to use it.
-
Giving Access to a Particular Folder
You are giving access to a particular folder to members of a project team with a security group…if you want to email everyone on that team with information on what goes in that folder, it’s easy for you to email the security group.
-
Notifying Changes in SharePoint Resource to Members
If you own a SharePoint resource and manage access with a security group and want everyone to know about the great changes you have made to that resource…. hey, email the mail-enabled security group!
In short, any time you are controlling access to a system, folder, file, etc., and you need to communicate about that access, it’s easy to do.
Reasons to Not Mail-Enable Security Groups
In analyzing why IT is reluctant to mail enable active directory security groups, we came across the following technical limitation:
-
Exchange 2007: Only Universal Groups can be Mail-Enabled
One technical limitation started with Exchange 2007 that only Universal security groups can be mail-enabled. This must have to do with losing email for incorrectly scoped groups. Whenever Exchange 2000/2003 receives a mail sent to a mail-enabled group, Exchange will query a global catalog to find out who the members are of that group. Sometimes mail would be stuck in the Categorizer, in most cases because the Global Catalog cannot supply the members list of a domain local/global group created in another domain.
A universal group would solve this problem, but Microsoft encourages global security groups unless you don’t have trust between the domains. So, to mail enable that security group, you are going outside of recommended practice by using a universal group. Hence, IT Admins reluctance to mail-enabling security groups.
Final Verdict
However, it is essential to note that business uses would appear to outweigh the technical limitations. What am I missing? The two customers referenced above have MASSIVE infrastructures, so maybe it’s just that keeping their groups scoped correctly is more important than letting users email a security group. However, there has to be more, right?
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.
I’m interested in what people come up with here as well. It’s not a clear cut case but one thing to consider is that you may need Distribution lists that are NOT security groups even if there are things for which a security group already exists. Distribution lists may need to be broader than just a particular security group (though perhaps you could always just add your mail enabled security group(s) plus any individuals to an additional distribution list then?). However often times companies want some members to have direct management of distribution lists and obviously that’s not a good… Read more »
Hi Ed, A couple corrections and comments on your article: – Microsoft requires Universal Distribution groups, not Security groups, in Exchange 2007. Security groups are still optional – You can only assign permissions across domains with a trust, and once the trust exists, you can use any group scope (Global, Domain Local, and Universal) in your design. My thoughts on the matter: Universal security group usage in the Windows 2000 era resulted in higher replication costs, as every time group membership changed, the entire list was replicated to every global catalog in the forest. Imagine a group with thousands of… Read more »
I have run into this exact thing. We have scientific instruments which access is limited by group membership. If the staff that support the instrument want to communicate with the users they can email the security group. However we have had to make these all universal groups (we have a forest with 5 trees) because of the very issue you mentioned about not being able to enumerate the membership of security groups that are not universal
If you use a universal security group to give “full access permissions” in the console, if you also want the group to be able to “send on behalf of” (not ‘send as’), then you would still need to add them as a ‘Delegate’ in Outlook under ToolsOptionsDelegates. The problem then arises that you can’t add a group as a delegate unless it is a mail-enabled group. So that’s another reason for doing that. (this is regarding Exchange 2007)