SOLVED

Site Collection Admin in Modern Team Sites

MVP

About a week ago I noticed that Modern Team Sites no longer had the abilty to add SharePoint or Azure Active Directory Groups to be a part of the members, visitors, and owners SharePoint groups.  In fact SharePoint groups had disapeared. 

 

I just noticed tonight that there is no longer a way on a site to set the site collection admins for that site.  Is there any documentation about what's happening with Modern Team Sites in terms of permissions and authentication.  This seems to be an area that will impact how people think about governance and site structure but i haven't seen a real explanation of whats happening or how the team is thinking about this working.

 

Any guidance would be really appreciated as this is the biggest non-cosmetic change from modern team sites that i've seen so far.

dave

34 Replies

IMHO this is one of the missing / not well explained points of modern team sites...I'm not aware of that documentation because I think is not ready yet. By the way, those options are there (hidden, but you can manage to get to them :-)). @Sean Squires I would also be interested in your advice about how to govern security in moder team sites

You can set site collection admins for a modern team site (a.k.a. Group team site) at

https://<tenant.sharepoint.com>/sites/<sitename>/_layouts/15/mngsiteadmin.aspx

or by powershell.

You're right that they are currently these, but i hate to rely on things that have been intentionally hidden from the UX.  Even stranger, when i look at who the site collection admins are, it's the group associated with the team site.  This seems really strange having all members of the group by site collection admins seems weird if site collection admins are still a thing.

 

@Jeremy Mazner have any idea what's happening with Modern team site permissions?  We really would love to be ready as a community before these GA so governance, adoption, and information architecture guidance can be adjust as a part of our readyness strategy.

My client noticed the same thing last week when I was demonstrating this to them. Unfortunately, I did not have an answer, and like you was not able to find one. Microsoft's unwillingness to delay code releases until documentation is ready continues to be a major frustration to me and many others.

If SharePoint team sites aren't going to support using azure active directory groups or site collection administrators that feels like something that should be communicated very clearly with some context around what the strategy is moving forward.  Really hoping this doesn't GA in its current state as I don't know how one could roll these out as is.

Agree with all comments here.   If you are going to give us a sharepoint site, then GIVE us a sharepoint site, not a neutered excuse for a sharepoint site.  

 

I think the pendulum has swung too far on trying to protect end users from themselves.


@Salvatore Biscari wrote:

You can set site collection admins for a modern team site (a.k.a. Group team site) at

https://<tenant.sharepoint.com>/sites/<sitename>/_layouts/15/mngsiteadmin.aspx

or by powershell.


Note that only the Group Owner can do this. Even an Office 365 Global Admin gets access denied on this!

Understand the current state that this is possible in this one narrow window of a group owner going to an undocumented url and it still happens to work.  I'd really like to understand from MS what the plan is here and where this is going.  Feels like we're trying to reverse engineer current state instead of understand the intent.

@Chris McNulty can you get someone to provide us some insight?

@Kevin Crossman

I have not tried it, but I think that a GA can use the powershell method... Have you tried it?

 

@David Feldman

The powershell method is documented, however...

@David Feldman

On the same vein, modern team site permissions can be accessed at

https://<tenant>.sharepoint.com/sites/<sitename>/_layouts/15/user.aspx

You can access almost every administrative page that is part of "classic" sites in modern sites just typing the adminitrative page url :)

Hi all, sorry for the confusion.  let me try to tackle everything here:


1) documentation -- happy to help fill in gaps where docs are flat out missing, or edit for clarity where we have docs that are insufficient.  If you think docs are missing: post what you searched for and failed to find docs that matched your expectations.  If you think docs need updating, post the URL and leave a comment on the page about what you'd like to see.

 

2) to Dave's original observations: "About a week ago I noticed that Modern Team Sites no longer had the abilty to add SharePoint or Azure Active Directory Groups to be a part of the members, visitors, and owners SharePoint groups.  In fact SharePoint groups had disapeared" and "I just noticed tonight that there is no longer a way on a site to set the site collection admins for that site": I'm not aware of anything that would have changed in the past week, and in my test tenant I am not seeing any issues -- I went to user.aspx, saw all the default SP groups there, and added a non-mail-enabled SG from AAD to the Members group.  There's discussion further in the thread where people are posting the specific URLs to admin pages and it sounds like they are working for you too...so on the particular comment of "something changed", let me know what specifically worked last week that isn't working now -- URL of the page you're going to, what you're trying to do, what error you get.

 

3) on how group-connected team site permissions work by default: I tried to cover this at my Ignite talk, around 46:00 mark at https://channel9.msdn.com/Events/Ignite/2016/BRK2038.  The recap is: Site Collection Ownership is linked to ownership of the associated O365 Group. In pseudo-code, SPSite.Owner == Group.Owner.  When you go to mngsiteadmin.aspx we have a display bug that renders the group name but doesn't make it clear it's the group owners. I will log that for engineering to fix. You can see under the covers by looking at the REST endpoint for your site, eg: https://contoso2016g.sharepoint.com/sites/ProjectTahoe/_api/site/owner.  You should see a claim like "<d:LoginName>c:0o.c|federateddirectoryclaimprovider|09d2ba12-c4ad-4428-82d2-eb5f4efe9ebb_o</d:LoginName>".  You'll see the same via PowerShell, eg: "Get-SPOSite https://contoso2016g.sharepoint.com/sites/ProjectTahoe | ft Owner" returns "09d2ba12-c4ad-4428-82d2-eb5f4efe9ebb_o" . The GUID is the identity of the group, the "_o" postfix indicates this is the claim given to Owners of that group.  Of course this is not something we ever want any user or admin to have to look at it, but just wanted you to be able to see under the covers that we are actually setting this correctly.  The members of the site default to the members of the group, again in pseudo-code SPWeb.AssociatedMembersGroup.Users == Group.Members.  If it's a public group, we put the "Everyone except external users" claim in there as well.  You can see that in REST as well, https://contoso2016g.sharepoint.com/sites/ProjectTahoe/_api/web/AssociatedMemberGroup/Users.

 

4) on Brent's comment "GIVE us a sharepoint site, not a neutered excuse for a sharepoint site."  That is absolutely the goal.  I described above the defaults for group-connected sites.  We have only one limitation on that site right now, which is that you cannot delete the group owner claim from the site collection admin list -- the whole point of a group-connected site is that the group provides the governance for the site, so removing group owners doesn't make sense.  Beyond that, we do hide the user.aspx page from site settings to encourage users to manage access via O365 group membership, rather than mucking with SharePoint groups, again for better governance, and we will be adding some new modern UI to make it easier for end users to view and manage O365 group membership directly from the site...but user.aspx is still there and still works.  We may over time add additional limitations to avoid getting into cases where group members don't have access to the site...but generally, yes, we are giving you a full site and trying very hard to avoid a case where you say "oh this site isn't good enough, I have to go create a _real_ site to use with this group"

 

5) to Kevin's comment "Even an Office 365 Global Admin gets access denied" to mngsiteadmin.aspx: this is how SharePoint Online has always worked.  O365 Global Admins are not granted any rights to any SharePoint content or management by default.  If an admin needs access to a site, they must use powershell (Set-SPOSite -Owner) to explicitly add themselves to the Site Collection Administrators for that site.  Without taking this audited/traceable action, even global admins don't have special powers or access.

 

okay, hope that helps, thanks for the feedback, and let's get documentation gaps patched up for sure.

Thank you very much, Jeremy.

Among other considerations, my takeover is that using hidden pages, directly accessing them by their URL, is definitely a legitimate and supported operation. Am I correct?

@Juan Carlos González Martín

BTW, in his awesome post, Jeremy has answered also to an old question that, if you remember it, we have discussed in the good old days of the Yammer network: why in the SCAs page have we listed the Group name itself?

Jeremy answer is: it is a display bug, and the Group name actually stands for the Group Owners!

Ey Salvatore, what a good times did we have in the wonderfull Office 365 Network :-)....as always, you are right!

Thanks Juan! I always remember with a little nostalgia those wonderful times!

If you use the hidden UX to delete the AssociatedMemberGroup, our sharing dialog will stop showing the simple "edit" permission, all O365 Group Members will loose access, and other group experiences like modern attachments from mail won't work -- the product is not designed to support operating correctly without AssociatedMemberGroup. And there are other things you can do in user.aspx that will end up changing site behavior in a way that isn't obvious to users -- for example you can share the site to an additional security group for broader access, but when your users look at the doc library or list UX, they will still see it say "Private Group" and will still see a count of members in the associated O365 Group, and they will have no idea that the site is actually available to this whole other SG.  That's no different than how we've always approached SharePoint team sites, the difference with our modern UX and O365 groups is that we are doing more and more work to hide the paths that are most likely to cause pain like this.  People who are taking the time to read this thread will, I believe, understand this implications and make the right tradeoffs for their particular circumstances, but that is different from saying that everything you can do on the page is "supported" as in "will work really well with the default experiences the SharePoint team designed".  Make sense?

Thanks Jeremy

 

>If an admin needs access to a site, they must use powershell (Set-SPOSite -Owner) to explicitly add

>themselves to the Site Collection Administrators for that site

 

This right now is at least the same as the fact that the same O365 Global Admin can't see the Group's Site Collection in the SP Admin panel (where, if he could see the site collection he could add additional SCAs).

 

But, per my above use case, if the site collection is visible to a Global Admin then that Global Admin can edit the Site Collection Admins. I would expect this to continue to be the case...   PowerShell is better than nothing, that's for sure, but isn't really a solution for many of us Service Owners.

 

Hopefully updating the SP Admin UI ito include Group sites is coming soon.

1 best response

Accepted Solutions
best response confirmed by David Feldman (MVP)
Solution

I agree with the sentiment, which is why all of our modern UX guides users down safe paths.  But as you can see from this thread, we also have a community of people who depend on being able to do some advanced, custom configuration, and don't want to leave them in the lurch.  We believe that we've struck a good balance here, where unlike the past 10 years we avoid users accidentally stumbling into trouble, but empowering the experts who to get their job done.  I hear your feedback that you think we need to go further, but I know if we completely block it we'll have a lot of feedback saying we went too far.

View solution in original post