Azure AD identity governance — Part 3 — Govern the resource lifecycle

The blog series

Part 1 — The basics

Part 2 — Govern identity lifecycle

Part 3 — Govern resource lifecycle

Part 4 — Govern Azure AD B2B

Part 5 — Govern access lifecycle

Part 6 — Reach back to on-premises

Govern resource lifecycle

As already in the last part of this blog series, we are currently still looking at standard functions. As a short refresher, in this part we would like to deal with the following topics.

• What resources are there in my environment?
• Where do these resources come from and who is allowed to create them?
• Who is responsible for these resources?

We will find that these requirements cannot yet be covered in their entirety with standard functions, but let’s take a look at them first. In the first part of the blog series I already named a list of possible resources, now I want to focus on the features for Azure AD resources. However, other resources should not be neglected.

Limit security group creation

Azure AD offers the possibility to allow normal users to create security groups, but this is disabled by default. Usually we don not want to allow normal users to do this.

This setting can be found in the Azure Portal under Azure Active Directory -> Groups -> General

If we still enable this setting, normal users can create Azure AD groups in multiple places, the usual place would be the Groups application accessible through the access panel. Access to the Groups application can also be completely withdrawn, the setting can be seen on the first screenshot above.

Users can also use the Azure AD management portal to which they have default access. However, access can be restricted via Azure Portal -> Azure Active Directory -> User settings -> Administration portal.

Limit Office 365 group creation

At the location already mentioned above, a setting for Office 365 Groups is also available. This setting is also disabled by default, but once there are enough controls in place to prevent groups from orphaning, this setting can be enabled. Many companies would like to see an approval workflow for the creation, in which case the setting would have to remain disabled, we’ll take a look at this in one of the following blog articles.

Important, there is more to Office 365 Groups. Not only can these groups be created in many applications, e.g. Outlook, but the setting also affects other applications, so the setting also limits who can create Microsoft Teams, since there is an Office 365 group behind it. However, the setting in the Azure AD Portal does not affect the other locations in Office 365, Teams client and other portals. To have an effect on all portals, the setting must be set using PowerShell.

Item for the Govern resource lifecycle, beyond the basics: Approval workflows

Limit application creation

By default, users can add applications which support password single-sign to their Access Panel. This can be restricted via Azure Portal -> Azure Active Directory -> Enterprise applications -> User settings.

From an administrative point of view, there is an Azure AD role for application management.

Owner

An essential part of the resources as well as access lifecycle is the owner. By default, the creator is the first owner of Azure AD Groups. Whether additional owners can be added by the owner can be defined in each case.

Unfortunately, the standard options already stop here, so we will take a look at this topic in a later blog article. For example, what do we do if the owner leaves the company?

Item for the Govern resource lifecycle, beyond the basics: Owner management

Group naming policy

Azure AD provides the ability to define a naming convention for Office 365 groups that will be evaluated when groups are created. This feature allows the configuration of:

• A group prefix
• A group suffix
• Blocked words

I won’t go into the details of the feature as there is an excellent documentation including screenshots from the user’s point of view.

At the time of writing this blog article, I also noticed that the feature is now available in the Azure portal, which was previously only available via PowerShell. Azure Portal -> Azure Active Directory -> Groups -> Naming policy (Preview).

Expiration policy

Finally, I would like to draw your attention to the Expiration Policy for Office 365 Groups. This allows Office 365 to expire after X days, the owner is notified in advance and must extend the group, otherwise it will be deleted.

Azure Portal -> Azure Active Directory -> Groups -> Expiration.

In the settings options you can see that we can enable expiration for all or dedicated groups. Unfortunately, the dedicated groups have to be named explicitly, so we’ll have another blog article about how to configure this setting in an automation. Background, Project-related groups should usually expire, but this may not apply to other group types.

Item for the Govern resource lifecycle, beyond the basics: Granular expiration as part of resource automation

Additional information

Surely there is much more to say about this topic. The Office 365 Group Governance documentation offers a very good overview.