Caroline Sosebee is a Senior Software Engineer at ThreeWill. She has 30+ years of software development experience and a broad scope of general IT knowledge. At ThreeWill she has a proven track record of quality consultative and software development skills, focusing on the design and implementation of SharePoint solutions, both on-premises and in the Microsoft 365 cloud.
Introduction
We recently had a client who was ready to streamline the security of their SharePoint Online site and change it from ‘Everyone’ access to groups of people with more specific access. Our recommendation to them was to use Azure AD groups so that the groups would be global and could be both centrally managed and used across site collections.
As we moved ahead with it, they had the groups added with the appropriate members. We then granted SharePoint permissions to the new AD groups by adding them into the appropriate SharePoint groups and removing the reference to ‘Everyone but external users’.
The Problem
At first all seemed to work ok but as the week progressed, random problems started cropping up that we couldn’t explain, the biggest one revolving around search results. One of their users (and others, we later found out), who had full read access to the root site and all subsites, would only get back results from his OneDrive library and from the separate training documents site (which is open to Everyone). Yet he could easily navigate to and access all the document libraries in all the sites.
Thus began my long search on all sorts of things SharePoint search related, trying to figure out what was going on. For some reason, I finally decided to go look at the AD groups themselves with the thought that since roles are assigned to users, maybe the same thing might need to be done for groups. This was a bust of course, but being fairly new to administrating SharePoint Online, I was game for checking all sorts of things I didn’t know about.
Microsoft 365 Groups vs Azure AD Security Groups
Luckily this random check ultimately ended up pointing me to the real problem. It turns out these two new groups were setup as Microsoft 365 Groups instead of security groups. At the time, I didn’t know anything about Microsoft 365 Groups but didn’t really think this could be the problem. I decided to do a little research anyway into what that meant. One of the definitions I found was:
Microsoft 365 Groups is a service that enables teams to come together and get work done by establishing a single team identity (managed in Azure Active Directory) and a single set of permissions across Microsoft 365 apps including Outlook, SharePoint, OneNote, Skype for Business, Planner, Power BI, and Dynamics CRM.
So SharePoint was mentioned in that list of Microsoft 365 apps, right? How could the group type be the problem then? We needed access to SharePoint and it says it does that. What it doesn’t tell you is that it’s mostly referring to access to the team site that is created, specifically for that group, when the group is first created. It does not mean that it will be very usable by other sites.
After more searching and finding very little, I decided it was time to do some of my own testing. First I had a test user added to the Microsoft 365 Group currently in use. After giving the cloud some time to process this change, I signed in and ran a search or two. What I got back was very similar to the user mentioned above. I got little or no results back, even though I had access to everything in the site.
I then created a new Azure AD Security group, added the same test user to it and then granted it the same permissions in the SharePoint site as the Microsoft 365 Group had. After waiting a decent time so I was sure the security change was processed by search, I signed back in and found that the behavior was now entirely different. With the test user as a member of my new security group, I got back tons of results, just as expected. To further verify, I then removed the user from my test security group, waited a bit, ran a search and found I was back to square one. This was pretty solid evidence that the Microsoft 365 Group was the culprit.
The Solution
Our end solution was to create new Azure AD Security groups, add the correct members, grant them the same access as had been granted to the Microsoft 365 Groups and then remove the access for the Microsoft 365 Groups. This seems to have corrected all the problems the users were experiencing.
I still don’t know a lot about Microsoft 365 Groups and haven’t had time to research much further, but I do like the below snippet (found here) that very succinctly describes each group and what it does.
I’m sure that Microsoft 365 Groups have a place in the Microsoft world, but it is definitely not a replacement for AD security groups.
As a quick recap, here are the areas that were impacted (at least on this particular site) by using a Microsoft 365 Group instead of a security group:
- Search – would not return results from the site
- Starting a workflow – if a user in an O365 group kicked off a workflow, the workflow got hung up with an ‘Access Denied’ error before it ever got far enough along to send out custom errors.
- Site access – Various users had problems accessing the site, even though they were in the correct group. Was a very random thing as it worked for some and for others, it didn’t.
I hope this helps save someone sometime in the future!
More blog posts about Microsoft 365 Groups:
10 Comments
Joseph Boland
Thanks for the insightful account of the consequential differences between AD Microsoft 365 Groups and AD security groups. I don't understand, however, your statement that you removed the Microsoft 365 Groups. Wouldn't doing so break O365 Groups functionality even if equivalent security groups existed?
Caroline Sosebee
Hi, Joseph ... thanks for the comment and sorry for the delayed reply! Your comment ended up in spam so I'm just seeing it. :( When I said removing the Microsoft 365 Groups, I didn't actually remove them from the AD but removed the previously granted access for these groups to the SharePoint site. The groups are still out in AD and still have their site associated with them. I should have specified that a little more clearly. thanks for calling that out - I'll get it updated to be a little clearer. Have a great day!
Mark Burland
Microsoft royally blasted themselves in the foot by using the word "Groups" for O365 Groups. I get why they called it that, but did they consider the confusion it would cause, not to mention the problems with Googling (sorry, Binging) anything Groups related? Then they went and did it again with Teams!!!
Caroline Sosebee
Agreed!!
Greg
1000% agreed, I just spent hours hitting my head on the wall trying to add computers to an Microsoft 365 groups so that I can manage them in Intune and although the confirmation reads "Successfully added" that's a lie and no computers get added to the O365 Group, so I created a Security group instead and all works on the first try
Anthony E
This was a phenomenal post, thank you for the information! I look forward to learning more along your journey! However, I wonder if anyone else is still experiencing this now that some time has gone by. I'd also be curious if Microsoft know about this issue. Anyways, thanks again!
John Colvin
This article saved me from wasting an immense amount of time. God bless you, Caroline.
Sanjay Gohil
Great article. I went through the same process myself over the past few weeks. This article describes the problem very well. Now I have the laborious task to changing 60+ active sites for Azure AD Security Group managed access.
Javier
Very interesting, thank you. I was confused by the same kind of groups in O365
marcelo sauaf
so... if one needs that a group of users both sharing a certain team site ou outlook group mailbox AND access other sites as well, would need TWO groups (a security and a ms365) with exact same members... that's a big burden huh...