Mixed inherited and unique permissions on sub-sites

Question

Background

In our SharePoint Online tenancy, we have a site structure like this:

                    Projects (Site-Collection)
                        │
        ┌───────────────┴┬───────────────┐
        │                │               │
Alpha-Project       Beta-Project        ...
 (SubSite)           (SubSite)        (SubSites)

Where, we have a site-collection for all our projects with a sub-site for each of the projects. We also have security groups in our AD for each of the project teams and management.

Requirement

We need to allow all employees to be able to view all sites. However, only the project team should be able to manage their own respective sites. Also, we need the management to be able to contribute to all project sites along with the parent "projects" site-collection.

What I did

1. For the view permissions, I added the pre-existing "Everyone except external users" principal to the "Projects" site-collection group "Projects Visitors". I had the understanding that with this all users would be able to view everything.
2. Next, I added the "Management" AD group to the "Projects" site-collection group "Projects Members". I had the understanding that this will allow all management people to be able to contribute to all sites.
3. Then, for each project sub-site, I broke the inheritance by clicking "Stop Inheritance" on the sub-sites. I had the understanding that this will allow me to provide unique permissions on each of the sub-sites.
   • While breaking the inheritance, (on the same page when asked), I created project sub-site group only for "Project Members". This I did by selecting new group for the existing inherited "Projects Members". This group was named "Alpha-Project Members" for the first sub-site. Ditto for other sub-sites. I had the understanding that only the "Members" group needs to be unique and the other two groups (Owners and Visitors) would inherit from the "Projects" site-collection.
   • Next, I added the "Alpha-Project-Team" AD group to the "Alpha-Project" sub-site. Same for other individual project sub-sites. I had the understanding that now, only the individual project team members would have contribute permissions on their own project sub-sites; whereas the management would be able to contribute to any site by virtue of inherited "Projects Members" group, along with all employees be able to view all sites by way of inherited "Projects Visitors" group.

How the permissions look like

          ┌─ Projects Members   ─ Management AD Group
Projects ─┼─ Projects Visitors  ─ Everyone except external users
    │     └─ Projects Owners    ─ Admins AD Group
    │   
    │                  ┌─ Alpha-Project Members     ─ Alpha-Project-Team AD Group  (Inheritance broken here)
    ├─  Alpha-Project ─┼─ Projects Members          ─ Management AD Group
    │                  ├─ Projects Visitors         ─ Everyone except external users
    │                  └─ Projects Owners           ─ Admins AD Group 
    │                   
    │   
    │                  ┌─ Beta-Project Members      ─ Beata-Project-Team AD Group  (Inheritance broken here)
    └─  Beta-Project  ─┼─ Projects Members          ─ Management AD Group
                       ├─ Projects Visitors         ─ Everyone except external users
                       └─ Projects Owners           ─ Admins AD Group 

Problem(s)

1. However, after having done this I found out that employees are able to view the parent "Projects" site-collection but getting an access-denied on individual project sub-sites.
2. Also, the individual project team members were also unable to get access to the individual project sites.
   • Even if I add "Alpha-Project-Team" AD group to the "Projects Visitors" SharePoint group on the parent "Projects" site-collection, they get access-denied on their "Alpha-Project" sub-site. Ditto with other project sub-sites.
   • However, if I add "Alpha-Project-Team" AD group to the "Projects Visitors" SharePoint group on the parent "Projects" site-collection, then they get access to their own "Alpha-Project" sub-site. Not only this, then they get access to and contribute permissions on all project sites.

Question(s)

I am just unable to grok this permissions conundrum! Where has my understanding gone wrong? How to set these permissions up correctly so that I meet the requirements mentioned above?

^Update

^{After being convinced by @Eric that my understanding was correct and no problems with the way I set up the permissions, I went ahead and opened a ticket. After a lot of time digging around, it was suspected that the custom page layout which was being referenced from the parent site-collection could not get published and was stuck at being unpublished. This caused the access denied to users with read permissions. Users with contribute permissions at parent site-collection were unaffected. Another 5-10 minutes and the problem was resolved. The page layout got successfully published and access was restored.}

Answer 1

Your setup looks correct and should behave like you are imagining.

It has been our experience that using AD groups sourced from on premises AD can take upwards of 72 hours for the permissions to actually fully propagate from Azure AD to all services in Office 365.

This has been a particular pain point for a few of our sites where automated processes in other systems update AD group membership, user is notified they are added to an AD group, but don't have access to the SharePoint Online resources.

I would say, wait and give it time and see if it resolves itself. If it does not, then you'll want to open a case with Microsoft in your Office 365 Admin portal (or have someone do it if you aren't a global administrator).

Answer 2

Have seen a bug in SP Online where when breaking sub site inheritance the security groups are not properly stapled to the sub site. Fortunately it's an easy fix by navigating to the security setup page and just clicking OK: /_layouts/15/permsetup.aspx.

WRT Previous advice to continue to wait - DON'T - it's overly risky. If you've been through the O365 support process you would know it can take a very long time to get to resolution! This has only occurred on my tenants during service interruptions. You want your tenant prioritized for repair. When setup properly this idea of a 72 hour wait is lunacy.

Open a support ticket ASAP - you pay for it! You've already "wasted" 72 hours and your users will start getting frustrated soon. It'll take that long just to get to a quality chat with MS support.

If this is infact a bug you need to report it and get MS to start working on the fix / work on your alternative vectors. Last major bug I found in search took 3 months to repair.

You will get a better answer from 2nd level MS support than from anyone here. Phrase it as a business interruption and have Sr. officers emails on the ticket to have it escalated quickly. Best of luck!