I’ve written before about how an Office 365 Group or Team always includes a site collection, one that relies on the underlying Group membership for security boundaries. But, what does that look like under the hood? Here are some screenshots with commentary, from a quick dive I took with one of my co-workers.
First, let’s take a look at what the Group looks like where it lives – in Azure Active Directory.
Note the GUID, which is the Object ID, ending in 726f85a.
Now let’s take a look in SharePoint Online’s Site Settings for the Group Site Collection. Where’s the Members link? Site Collection Administrators?
Your first reaction as a traditional SharePoint admin might be, “Oh no, I have no idea how to look at membership and administration!” But then, you come to your senses and look up some familiar paths.
For example, if you go to /_layouts/15/user.aspx, you’ll see the familiar Users page.
Then, if you click on any of those standard SharePoint groups, you’ll see who’s in them.
Go a little further, and you’ll come full circle back to the 365 Group. See that GUID for the Account? Look familiar?
Next, If you go to /_layouts/15/mngsiteadmin.aspx to look for Site Collection Administrators, you’ll see that not only is Malcolm Singer an SCA, but so are both the Team Members and Team Owners of the underlying Group.
In fact, if you drill in to either owners or members, you can see that the GUID for the Group is used to define the account. What’s odd is that the same GUID is used for both the Team Owners and Team Members, presumably because both are part of the same Group. SharePoint is populating both SharePoint groups with information contained in the same object.
It’s clear that Microsoft is not completely re-inventing the SharePoint wheel, though they are bringing new technologies into play, particularly Groups. Understanding how Groups work is one step, but another important step is understanding how Groups interface with SharePoint.