A user can only create 250 groups

By Anatoly Mironov

A non-admin user can create no more than 250 resources in Azure AD. That is one of the many Azure AD service limits and restrictions. A “resource” can be an app registration, an Office 365 Group etc. But I would like to discuss Groups more in detail.

Imagine the following scenario: Your organization has disabled Office 365 Group Creation. Only IT can create new groups. A service account has been set up for creation of team sites. The application permissions are “binary”, either everything or nothing: Group.ReadWrite.All. This service account will hit the limit very soon.

To prove that, I have created a small script that creates 251 groups.

By the way, just for clarification, when create a new group, that will also create a SharePoint site.

Please don’t try this with your real account in production. The 251st request will fail:

Directory_QuotaExceeded

The directory object quota limit for the Principal has been exceeded. Please ask your ad
ministrator to increase the quota limit or delete objects to reduce the used quota.

Even if you remove, it will take time to get free slots in this limit:

Deleted Azure AD resources that are no longer available to restore count toward this quota at a value of one-quarter for 30 days.

There is not much to do about it. For App Registrations you can create and assign a custom role. But for groups there is no custom roles available.

Exceptions

It might be obvious, but still:

Admins

Admins do not have this limit. But not all “admin roles” are really admins. Those roles are excepted:

  • Global Admin
  • SharePoint Admin
  • …

Those roles are not excepted:

  • Message Center Reader
  • …

I don’t have time to try every admin role, but I suppose only admins that can change global configuration, are excepted, not the reader ones.

Communication Sites

Since communication sites do not have an Office 365 Group behind the scenes, a non-admin user will still be able to create such sites even after the limit is hit.

Workarounds and Solutions

Since my scenario for creating groups with a service account does not work, we need to seek workarounds and solutions.

Do not restrict Group Creation

That is the best one. If users can create groups/sites by themselves, then none of this would be a problem. But still, in my scenario, there is a business requirement to control the creation of groups.

Application Permissions Group.ReadWrite.All

That is exactly the opposite of my scenario. This gives that application full access to all groups and files (!). This means, that application can access all Group-Connected SharePoint Sites as well.

Microsoft creates permissions for groups

If we also had “groups” permissions for custom roles, then we could do the same way as with app registrations. Today (2019-10-25), there are only permissions for applications.

Microsoft creates new permission Group.Create.All

If there were a permission for only creating groups, that would solve the problem.

What we have today

There is a similar role: User.Invite.All, it allows only invitations, not editing All Users.

Microsoft allows exceptions per user

If there were a switch for the 250-limit per user, that would also solve the problem.

Granting the service account admin rights

Granting SharePoint Admin would solve the problem, but at what price? That is safer than Application Permissions Group.ReadWrite.All, since you need to actively add this account to the groups in order to read all the files, but this is still less secure than just a non-admin account.

Having multiple service accounts

If we had account 1..100 and we used every account 250 times. Theoretically it should work, but it is a cumbersome process. You need to keep track of how many groups an account as created, or having the right error handling. How should the password be kept safely. Should the accounts be removed when they have reached the 250 limit?

Group Creation Microservice

To overcome the limits and the ungranularity in the built-in permissions in Office 365, one way to solve it would be a tiny, but a dedicated, and secured service for creation of groups (and sites). It would still need the “hefty” Group.ReadWrite.All Application Permissions, but making it do the only thing and do it right, would mitigate the risks.

It could be a simple Azure Function that few have access to. That could be just a couple of lines of code.