Your Property IT Team Doesn't Need Admin Rights to the Whole Portfolio

Key takeaways

• Most hotel groups run one Microsoft 365 tenant across properties they own, properties they contract out, and properties run by outside management companies. The identity platform is shared; the operating reality is not.
• Granting a property or an outside operator a tenant-wide admin role gives them reach across every other property in the portfolio. Withholding it means every seasonal onboarding and every front-desk password reset becomes a corporate ticket.
• Microsoft Entra ID Administrative Units resolve this. A role can be scoped to a container of specific users, groups, and devices, so permissions apply only to the members of that unit and not to tenant-wide settings.
• The container is the easy part. What makes the boundary hold is the group architecture beneath it, least-privilege role design inside it, tested proof it cannot be crossed, and a documented way to revoke it.

---

Download the full whitepaper (PDF)

The question every multi-property group eventually asks

"Can we let the property handle its own password resets and device enrollments?"

It sounds like a small request. It is not, because of how Microsoft Entra ID assigns administrative roles by default. Microsoft is direct about the mechanic: if a role is assigned to a user who is not scoped to an administrative unit, the scope of that role is the entire tenant (Microsoft Learn).

So when a hotel group grants Helpdesk Administrator to the IT staff at one resort — or to the third-party management company running it — that grant does not stop at the resort. It reaches every identity, every device, and every group in the tenant. Including the other properties. Including corporate. Including the ownership group.

Most groups discover this and pull back to the other extreme: nobody at the property gets anything. Then a workstation drops off the domain during check-in, the seasonal ramp adds forty people in two weeks, and property operations starts solving the problem the way property operations always does — shared accounts, a local admin credential passed around on a sticky note, devices joined by whoever happened to be logged in.

Neither position is acceptable. Both are avoidable.

What an Administrative Unit actually does

An Administrative Unit is a Microsoft Entra resource that acts as a container for other Entra resources. It can hold users, groups, and devices, and nothing else (Microsoft Learn).

The value is in the scoping. Entra roles can be assigned with a scope limited to an Administrative Unit, and when they are, the permissions apply only when managing members of that unit. They do not apply to tenant-wide settings or configurations. Microsoft's own example: a Groups Administrator scoped to an Administrative Unit can manage groups that are members of that unit, cannot manage other groups in the tenant, and cannot manage tenant-level settings such as group expiration or naming policies (Microsoft Learn).

For a hotel group, that translates cleanly. One Administrative Unit per property. Property staff and devices inside it. Delegated roles scoped to it. Property IT works at property tempo inside the fence and cannot reach past it.

There is no specific limit on the number of Administrative Units in a tenant, so one-unit-per-property scales with the portfolio (Microsoft Learn).

The trap that breaks most first attempts

Here is the single most common mistake, and it is worth stating plainly because it silently produces a delegation that does not work.

Adding a group to an Administrative Unit brings the group object into scope. It does not bring the group's members into scope.

Microsoft spells out the consequence. A User Administrator scoped to an Administrative Unit that contains a group can manage the group's name and the group's membership. That same administrator cannot manage the user properties of individual members, cannot manage their authentication methods, and cannot reset their passwords — unless those users are added directly as members of the Administrative Unit (Microsoft Learn).

So a team that builds a property Administrative Unit, drops the property's security group into it, and hands the property a Helpdesk role will find that the property still cannot reset a single password. The users have to be in the unit directly.

Protecting the properties from each other — and everyone from the helpdesk

For sensitive object sets, Entra offers restricted management Administrative Units. In one of these, only administrators with an explicit assignment at that unit's scope can change the Entra properties of the contained objects. A Global Administrator cannot modify them unless the Global Administrator explicitly assigns themselves a role scoped to that unit — and that self-assignment is an auditable event (Microsoft Learn).

Microsoft names protecting C-level executive accounts and their devices from Helpdesk Administrators as a primary use case (Microsoft Learn). In hospitality, the equivalent is the ownership group, the asset managers, and corporate leadership sitting in the same tenant as property helpdesk staff.

Restricted management is powerful, and it has real constraints that have to be designed for rather than discovered:

Object type	Regular AU	Restricted management AU
Users	Yes	Yes
Devices	Yes	Yes
Security groups	Yes	Yes
Microsoft 365 groups	Yes	No
Mail-enabled security groups	Yes	No
Distribution groups	Yes	No

Source: Microsoft Learn

Restriction also stops at the Entra boundary. Modifying Exchange mailbox and email settings, applying Intune policy to a contained device, changing SharePoint site ownership, adding contained objects to other groups, and assigning licenses all remain permitted for administrators outside the unit's scope (Microsoft Learn).

And Microsoft warns directly that placing objects in a restricted management Administrative Unit severely restricts who can make changes, which can cause existing workflows to break (Microsoft Learn). Workflow impact analysis is a design step, not an afterthought.

There is a ceiling worth knowing: a tenant can have a maximum of 100 restricted management Administrative Units, and any single Entra resource can be a member of no more than 30 Administrative Units (Microsoft Learn).

Least privilege is a design decision, not a checkbox

In Intras Cloud Services (ICS) delivery work enabling per-property administration for hotel groups, one of the most consequential decisions is to reject a built-in role.

Delegated property staff need to manage users. The obvious answer is the built-in User Administrator role, scoped to the property's Administrative Unit. But that role carries license-assignment capability — and an outside team operating a property typically has neither a business need nor the commercial authority to assign licenses the hotel group pays for.

So instead of accepting the built-in role, ICS builds a custom property user-management role that omits license assignment and assigns that at the Administrative Unit scope. Entra supports this: any custom role can be assigned with Administrative Unit scope as long as its permissions include at least one permission relevant to users, groups, or devices (Microsoft Learn).

That is the pattern worth carrying: for every capability the property genuinely needs, find the narrowest role that provides it. Where no built-in role is narrow enough, build one.

Devices are the other half of the problem

Identity delegation without device governance produces a fenced property full of unmanaged endpoints.

ICS designs the property boundary to a cloud-native target posture — no on-premises Active Directory dependency, no hybrid join, no directory sync for property objects, no legacy authentication path — and enforces it: documented the Entra-only device requirement, configured Entra device settings to enforce the approved join policy, blocked hybrid join for the property device group, and validated by test that only cloud-native Entra join succeeded.

For a resort, a cloud-native posture means no domain controller to patch, no domain controller to lose in a power or water event, no site-to-site dependency for authentication, and one less class of legacy authentication exposure sitting on the property network.

Alongside that, ICS defines which specific accounts and groups are authorized to join devices for the property, builds a device registration approval workflow with SLA targets at each step, and publishes a device-join Standard Operating Procedure written for property IT — prerequisites, steps, troubleshooting, escalation.

What actually makes the boundary hold

The Administrative Unit is available to any tenant with the right licensing. Very few delegation models fail because the container was hard to create. They fail for four other reasons.

No group architecture. Administrative Units consume object structure; they do not create it. ICS designs and secures approval for the group naming and type convention before any Administrative Unit work begins — a client prefix on every group, distinct markers for each group type, location codes per property, and department codes for hospitality functions. Without that, nobody can tell six months later which group governs what.

No test evidence. A boundary you have not tried to cross is an assumption. ICS runs test scenarios per delegated role confirming that property staff can manage objects inside the unit and cannot access or modify objects outside it, and documents the result. No delegation goes live before those tests pass.

No register. Every AU-scoped assignment should be recorded with the assignee, the business justification, and the approval date. That register is what makes periodic access review possible — and it is what makes offboarding an outside operator a checklist instead of an investigation. In hospitality, where management agreements change, that matters more than it does in most industries.

No way to take it back. Delegation without a documented revocation path is an unmanaged risk. ICS produces a step-by-step Administrative Unit disable and role-revocation procedure, held separately from the operating model so it is not confused with routine change.

What it costs in licensing

Worth checking before you design:

Requirement	License
Each AU administrator holding directory roles over the unit's scope	Microsoft Entra ID P1
Each AU member	Microsoft Entra ID Free
Creating Administrative Units	Microsoft Entra ID Free
Each AU member where dynamic membership rules are used for the unit	Microsoft Entra ID P1
Each user with a custom role assignment	Microsoft Entra ID P1
PIM eligibility, time-bound assignment, activation controls	Microsoft Entra ID P2 with PIM

Sources: Microsoft Entra ID licensing, Assign roles with AU scope

Creating Administrative Units and assigning roles over them requires the Privileged Role Administrator role (Microsoft Learn).

The organizational dependency nobody plans for

One honest note from delivery. The biggest schedule risk on this work is usually not technical. It is getting the third-party management company to engage and define what its staff actually needed to do.

Per-property delegation cannot be designed unilaterally by corporate IT. Someone at the property or the management company has to be named, accountable, and available to work through the role model. If that person does not exist, the project stalls in design regardless of how clean the architecture is. Designate them before design starts, and treat it as a condition of delivery.

The question to take to your next IT review

Not "can we delegate to the properties." You can.

Ask instead:

• If we granted a property admin role today, what else in the tenant would that reach?
• Can we produce a current list of every administrative right held by every property and outside operator, with the justification for each?
• If a management agreement ended tomorrow, is revoking that access a documented procedure or a discovery exercise?
• Have we ever tested that a property administrator cannot reach another property's objects?

If the answers are uncomfortable, the fix is well-understood, supported by the platform you already own, and does not require a new product.

---

Next step: ICS Enterprise Services delivers Governed Property Enablement — a fixed-fee engagement covering property boundary design, group architecture, least-privilege role delegation, device-join governance, boundary testing, and the co-management operating model. Contact ICS to schedule a Governed Property Enablement Readiness Discussion — or download the full whitepaper (PDF) to share with your team.