A proof-of-concept demonstrating how SSSC can use a single Microsoft 365 tenant with a hierarchical admin model — enabling global governance from the root while giving each Sangat full, isolated control of its own members and resources.
SSSC is a global spiritual volunteer organization operating Sangats throughout the world. Managing Microsoft 365 for this kind of organization requires balancing three competing needs that would otherwise pull in opposite directions:
Global leadership must enforce baseline security policies — MFA, data residency, compliance — across all countries simultaneously without coordinating with each local admin.
Each National IT Coordinator should add/remove users, reset passwords, and assign licenses for their Sangat independently — without waiting on the global admin for routine tasks.
Volunteers in one country must not be able to see contact details of members in other countries, respecting local data protection laws and privacy regulations wherever each Sangat operates.
Microsoft Entra ID (formerly Azure Active Directory) is the identity backbone of Microsoft 365. Every user account, group membership, admin delegation, and conditional access policy flows through it. The specific feature that makes hierarchical, isolated country management possible within a single tenant is called Administrative Units (AUs). Everything in this architecture builds on that feature.
A common first instinct is to create a separate M365 tenant per country. This provides perfect isolation — but at enormous cost: licensing is multiplied, cross-country collaboration becomes very difficult, and the Global Admin loses centralized governance. Administrative Units achieve 95% of the isolation benefit inside a single tenant at a fraction of the complexity and cost.
This proof of concept validates the single-tenant AU approach before a full rollout, giving SSSC leadership confidence in the design prior to committing to production deployment.
The SSSC M365 proof-of-concept structure operates on three tiers. Policies and controls set at higher tiers cascade down automatically — country admins work within the boundaries established above them, but have full freedom within their own tier.
Seven interconnected components work together to deliver the full architecture:
Scope admin permissions to a country-specific subset of users. The primary isolation boundary between Sangats. A country admin can only see users inside their AU.
Global security policies (MFA, device compliance, block legacy auth) set at Tier 1. Automatically inherited by every user in every country — no action needed by country admins.
Auto-populate based on user attributes (e.g. Country = 'the member's country'). Used to target licenses, SharePoint permissions, and Teams membership — no manual list maintenance required.
Built-in roles like User Administrator are assigned to country admins, but scoped so they only affect their AU. The same role that would be global is limited to one country.
Controls what each user sees in Outlook's address book. Prevents cross-country contact lookup and email discovery. Each country has its own private Global Address List.
One intranet site per country. Permissions tied to the country's dynamic security group so only local members can access it. Global admin retains site collection admin rights.
Country-specific private Teams for local communication. A Global Org-Wide team for top-down announcements from SSSC leadership. Private teams are undiscoverable cross-country.
An Administrative Unit (AU) is a container inside Entra ID that holds a subset of users. When you assign an admin role scoped to an AU, that admin can only see and manage users inside that container. Users in other AUs are completely invisible to them — not just hidden, but absent from every admin view, search, and report.
SSSC has one AU per member country, each containing that country's members. Each country admin (e.g. [email protected]) is assigned the User Administrator role scoped to their AU only. When a country admin logs in to the Entra admin center, they see and manage only the members in their own country. Members in every other country's AU are completely absent from their view.
Not all Entra ID roles can be scoped to an AU. These are the most useful ones for SSSC's Sangat admins:
| Role Name | What the Country Admin Can Do Within Their AU |
|---|---|
| User Administrator | Create/edit/delete users, reset passwords, manage licenses, create groups. The primary role assigned to all country admins. |
| Helpdesk Administrator | Reset passwords and revoke sign-in sessions for non-admin users only. Lower-privilege option for tier-1 support volunteers. |
| License Administrator | Assign and remove Microsoft 365 licenses for users in their AU. No user creation or deletion rights. |
| Authentication Administrator | Reset MFA methods and manage self-service password reset for users in their AU. Useful for helping members who lose an MFA device. |
| Groups Administrator | Create, edit, and delete groups scoped to their AU. Allows country admins to manage local distribution lists and security groups. |
| AU Name | Country | Membership Rule | Country Admin |
|---|---|---|---|
| AU-[Country A] | Country A | Country attribute = "[Country A]" | [email protected] |
| AU-[Country B] | Country B | Country attribute = "[Country B]" | [email protected] |
| AU-[Country C] | Country C | Country attribute = "[Country C]" | [email protected] |
The entire dynamic group and ABP system depends on users having the correct Country attribute set in Entra ID. All country admins must set this field every time a new user is created. Use the exact spelling your dynamic group rules expect — spelling must be perfectly consistent for every user in a given country. Run a monthly audit to find users with a missing Country attribute: Get-MgUser -All | Where-Object {$_.Country -eq $null}
Conditional Access (CA) policies are evaluated every single time a user signs in to any Microsoft 365 service. They are configured exclusively by Global Admins and cannot be created, modified, or overridden by country admins. This is what makes the global root genuinely powerful — it can enforce security requirements on all members worldwide from a single location, and those requirements apply instantly to every new user added in any country.
| Policy Name | Applies To | Condition | Enforcement |
|---|---|---|---|
| CA-001-Require-MFA-All-Users | All users (excl. break-glass) | Any app, any location, any device | Require MFA · Sign-in frequency: 7 days |
| CA-002-Block-Legacy-Auth | All users | Exchange ActiveSync + Other clients (IMAP, POP, SMTP) | Block access — legacy protocols cannot satisfy MFA |
| CA-003-Admin-Strict-MFA | All *-Admins groups | Any app, any time | Require MFA · Re-authenticate every sign-in · No persistent session |
Before turning any CA policy fully ON, activate it in Report-only mode first. In this state, Entra evaluates the policy and logs which users would be affected — but doesn't enforce it yet. After reviewing the logs for 1–2 weeks and confirming no unexpected impacts, switch the policy to ON. This prevents accidental lockouts.
Without Address Book Policies, every user in the SSSC tenant can see every other user in Outlook's Global Address List — meaning a member in one country could search for and directly email any member in any other country. Address Book Policies (ABPs) solve this by giving each country its own private address book — members only see colleagues within their own Sangat.
Each Address Book Policy — one per member country — is built from four required components:
This pattern is repeated for every member country. Replace [Country] with the appropriate country name and ISO code for each Sangat.
| Policy | Address List | Global Address List | Offline Book | Applied To |
|---|---|---|---|---|
| ABP-[Country A] | AL-[Country A]-All | GAL-[Country A] | OAB-[Country A] | Mailboxes: CountryOrRegion = [ISO-A] |
| ABP-[Country B] | AL-[Country B]-All | GAL-[Country B] | OAB-[Country B] | Mailboxes: CountryOrRegion = [ISO-B] |
| ABP-[Country C] | AL-[Country C]-All | GAL-[Country C] | OAB-[Country C] | Mailboxes: CountryOrRegion = [ISO-C] |
ABPs apply at the Outlook/Exchange level only. A user who already knows another user's email address can still type it manually and send an email — ABPs only control what appears in the address book search and directory browse.
ABPs do not prevent Teams direct messages if users encounter each other through the Org-Wide Teams announcement channel.
Licensing requirement: ABPs require Exchange Online Plan 2, which is included in Microsoft 365 Business Premium, E3, and E5.
| Feature | Isolated by This Architecture? | Mechanism |
|---|---|---|
| Outlook address book (who you can browse/find) | ✅ Yes | Address Book Policies (ABP) |
| SharePoint site access | ✅ Yes | Dynamic security group permissions |
| Teams channels and membership | ✅ Yes | Private Teams + dynamic group membership |
| Entra admin view (what country admin can see) | ✅ Yes | Administrative Unit scoping |
| Emailing someone whose address you already know | ⚠️ No | ABPs don't block direct composition |
| Teams direct messages (to known contacts) | ⚠️ No | Teams DMs are not AU-scoped |
| Complete isolation (as strong as separate tenants) | ❌ No | Would require separate M365 tenants |