The shift to the cloud has many organizations focused on the productivity features available in a given cloud suite. And M365 is no exception. There’s a long list of applications in M365 – a list that’s continually growing. But, Using M365 isn’t just about productivity; it’s also about security and control for IT. And, like most environments, the use of group accounts serve as the basis for much of the functionality available.
In this 2nd blog in a three-part series, we’re taking a look at cloud-based office suites and how each provides enterprises an ability to establish and maintain control of the environment, but do so as part of a larger cloud-based strategy that includes, in today’s case, M365, as part of the mix. As in my last blog, my goal here is to highlight what’s possible with groups within M365 at a high level, and then cover what’s missing for Enterprise organizations.
Managing Groups in M365
As you probably already know, groups in M365 are actually hosted within an instance of Azure Active Directory (AAD), so when you’re making changes from within an M365 console of some kind (more on that later), you’re actually making changes to AAD. Groups are vital to M365, and can be found throughout all of its service offerings, including:
| Outlook | Calendar | Skype | Dynamics CRM | Delve | Planner |
| OneDrive | SharePoint | Yammer | Microsoft Teams | StaffHub | PowerBI |
Like Google Workspace, M365 uses groups for three purposes: security, communication, and collaboration. The first two are the same as you’ve come to expect with on-prem AD – security groups provide access to applications and data across M365, while distribution groups are used within Exchange Online to disseminate email to the appropriate mailboxes.
The last purpose – collaboration – focuses on the need for M365 users to work together through calendars, OneNote notebooks, OneDrive files, etc. It may sound a lot like both Team Site and Yammer, because there is a degree of overlap that exists (a problem common with companies that acquire new technology). Microsoft will be rectifying this over time.
Management is accomplished from a number of interfaces: the M365 admin center, PowerShell, and Outlook all provide varying group management functionality. The first two are methods of choice for IT for the creation and on-going management of groups, while the third is used by users who wish to manage their own distribution groups from within Outlook.
Microsoft continues to update this important feature set to align group functionality more and more with collaborative efforts. For example, guest access allows users can nominate members that are users outside the organization, so that external users can participate in online collaboration with internal users.
Where M365 Groups Miss the Mark:
- The Directory is very M365-Centric – like most online suites, Microsoft is focusing on building an online ecosystem where entire companies live and accomplish every task. Since many enterprise organizations leverage M365 as just one of many online applications from many vendors, it makes sense that you have some kind of system of record (e.g. an HR database) that guarantees accuracy of the user data, with an ability to sync that into AAD (likely via first syncing with on-prem AD and then into AAD for many of you). M365 groups do not replicate, synchronize, or otherwise get represented in an on-premise directory for use with other traditional applications. Nor can they be leveraged for security when you want the simplicity of managing both access to physical resources and communication at the same time.
- Growing at a Rapid Pace – Microsoft has always had a love for acquisition. New products plugged into their existing products to add revenue has been a model of theirs for over 20 years. But, as M365 grows, the ability to maintain a consistent level of ability to manage groups centrally for the entirety of M365 will become more and more a challenge over time.
- No Real Automation – you can script something with PowerShell, but, the reality is that with so much contextual data in AAD about a given user, there’s little reason automated group management. Companies will frequently find the need to build dynamic membership on more than one source of data (directory attributes and database queries for example). Forget about leveraging attributes that were added as part of your extended schema without some heavy lifting. Also, if you want to delegate any of this work to smaller IT departments, you just can’t get there without granting access that no O365 admin really wants to give up.
- Little around Lifecycle Management – I’ve already mentioned the need for ownership and review in my last blog, and M365 is no exception. Attestation without enforcement is an empty statement. An administrator needs to assign more than one owner to ensure that groups do not outlive their purpose with policies in place to auto-promote additional owners to be a primary owner when they leave the organization.
- Temporary Membership – Frequently, group owners need to be able to loop in other employees to work on a time constrained task. Getting them involved is pretty easy through delegated membership management but without some closed loop policy in place as to the length of time they should be members , perpetual membership is the likely outcome. Without some sort of temporary join and temporary leave, these groups can quickly include people in something they should long have been removed from.
Keeping M365 in Line
Microsoft has done a tremendous job in building out an environment that enhances both user productivity and IT administrative ability. But as the M365 ecosystem grows with each new application and service, IT is going to need a more central way to manage both all of M365 and the many other cloud-based applications. While Microsoft thinks they’re the center of the universe (and, for many, they are), you need to be certain you can manage M365 as just one cog in your enterprise application wheel.
To learn more about how you can automate the centralized synchronization, configuration, delegation, and management of groups on-prem and in the cloud, Contact us
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.