Azure AD Gets on the Group Expiration Bandwagon
I recently wrote about the need for group expiration as part of a comprehensive lifecycle approach to group management. It’s a necessary step, given the life of group objects in any of the directories you manage won’t last forever. The only exceptions, generally, lie around built-in administrative-type groups.
Microsoft recently released an update to Microsoft 365 (and Office 365) groups in Azure AD where they now include an expiration policy. It’s definitely not group lifecycle management. But it does provide value to organizations wishing to maintain security aligned with the current needs of the business.
Below are some of the features of Azure AD’s new group expiration functionality. I’ve provided some commentary on their application (or lack thereof) to group lifecycle management.
- Roles – GOOD – This new policy comes with two roles: an admin role (who can manage policies), and a user role (who can renew and restore groups they own). This option empowers users to self-service group renewals and simplifies group attestation.
- Groups to be Expired – BAD – This is implemented as a per-policy (and not per-group) setting. M365 currently only supports a single group expiration policy that can be applied to multiple groups. This significantly limits organizations from using this policy. Good group lifecycle management dictates that every group have an expiration (as a way of forcing attestation). Making every group conform to a single expiration setting is a non-starter.
- Group Lifetime – OK – You can specify that group expiration occur any number of days desired above 31 days. This flexibility is needed to conform the management of the group with its necessity within the organization. For example, if its a project-based group, the lifetime should coincide with the intended end date of the project. Because only a single policy is allowed, this setting is not flexible enough to meet specific organizational needs.
- Owner Notification – OK – By default, group owners are sent emails at 30, 15, and 1 day before group expiration. Should there be no assigned owner, a backup email address can be specified. What’s needed is workflow to define who should be notified if the owner doesn’t respond. The reason is group deletions impact user productivity. A user going on maternity leave shouldn’t be the reason users can’t work. On the plus side, though, this feature alone moves organizations to think about the necessity for group owners – a key step towards group lifecycle management.
- Group Renewal – GOOD – Owners (or the backup email address) are sent the group expiration/renewal email complete with a “Renew Group” button in the email. Pressing it allows them to review the group in question and renew from within the Azure AD Amin Center. This is how simple user-based group attestation needs to be.
- Group Expiration – OK – When an M365 group expires, it’s deleted from Azure AD. It can be restored within 30 days of deletion. I’d rather see the group be accessible to the owner in an “expired” state, but given that would require some major changes to group objects within Azure AD, this is an acceptable start.
- Access to Expiration Functionality – OK – Microsoft limits the availability of its’ group expiration functionality. Only those organizations with “Azure AD Premium licenses for all members of the groups to which the expiration policy is applied”. That means the policy won’t apply if a group has members with a mix of Azure AD licenses. Additionally, as previously mentioned, this also only applies specifically to M365 groups within Azure AD.
Group Expiration: A Step in the Right Direction
Microsoft’s addition of this functionality gives credence to the necessity for organizations to be thinking about group lifecycle management (GLM). GLM improves the security of the organization by ensuring only proper permissions, members, and groups are in place to meet the current business needs. Doing even this one part of GLM within Azure AD works toward the goal of having your on-prem and web-based directories being completely up to date.
What’s missing is this same ability across all your directories, where the expiration of just one group resonates throughout every directory used by your enterprise. Expanding GLM functions is also needed beyond just group attestation. This should include attestation of group members, as well as permissions assigned. Even so, this one policy may very well be the catalyst necessary to help organizations recognize the need for attestation as a part of an overall group lifecycle management strategy.
Evaluating Your Own Groups
Before even considering a group lifecycle implementation, it is a good idea to understand the relative health of the groups you already have. We recommend that you get a full health check up using the Imanami Health Meter, a free tool that evaluates key directory metrics and provides guidance on how to get the most from your directory. Go here to get started.