An identity administrator often inherits a tenant in which too many people can change too many objects. The difficult work is not finding a role with a convenient name; it is deciding which administrative action is necessary, which population it may affect, and how that authority will be explained and revoked later. The Microsoft SC-300 identity-management domain explicitly includes built-in and custom Microsoft Entra roles, administrative units, effective permissions, groups, device registration, and tenant settings.
Consider a university with an independent help desk in each faculty. Faculty staff should reset passwords for their own students without becoming tenant-wide administrators. Separately, central IT needs to administer domains, directory settings, Conditional Access policy, and emergency access. Designing these two boundaries as one broad administrator role would hide an important distinction between delegated routine work and platform-wide control.
Start with the operation, not the job title
Write down the verb and the target before assigning access. “Reset credentials for enrolled students,” “update group membership,” “manage enterprise application settings,” and “assign privileged roles” are not interchangeable privileges. A person called an identity engineer may need only a few of them; a help-desk contractor with a narrow title should not automatically receive a broadly capable directory role.
Microsoft Entra built-in roles map common administrative functions. Custom roles may suit a controlled set of resource actions when an appropriate built-in role is too broad, subject to the actions and scopes the platform actually supports. A custom role is not a magic way to restrict every tenant setting. Check the permissions available for the resource type and the supported assignment scope before promising a delegation design to a business unit.
For a sensitive change, document who requests it, who approves it, who performs it, and where the resulting audit event will be reviewed. That separation is particularly important for granting directory roles, editing group ownership, or changing authentication methods. A role assignment that is technically minimal but never expires or receives review can still create a durable exposure.
Use administrative units for scope, not confidentiality
Adding a group object to an AU does not silently put every group member into that AU. A help-desk role scoped to the AU might manage the group without being allowed to reset passwords for member users who are not themselves members of the AU. Keep restricted-management AUs separate from ordinary AU scoping; the former adds special object modification protections and different operational constraints.
An administrative unit (AU) groups users, groups or devices for scoping supported directory-role administration; it is not a confidentiality boundary and does not extend to every tenant-wide setting. It is useful for a regional service desk or decentralized campus IT team: assign the appropriate role at the AU rather than the tenant where the supported role can be scoped. The official administrative unit behavior is explicit that AUs constrain management permissions; they are not intended to hide directory data from every person outside the unit.
Membership is important. Adding a group to an AU brings the group object into the delegated management scope, not automatically every user inside the group. If a help-desk administrator also needs to change individual member properties, the users require their own appropriate AU membership and role permissions. This detail frequently causes “the role exists but the action is denied” troubleshooting.
AUs do not nest, and a user may belong to multiple AUs. Geographic divisions may overlap with functions such as a shared engineering team; therefore document how a person is placed in and removed from each boundary. If a delegated admin has another tenant-wide role, the broader assignment may still authorize actions outside the AU. Evaluate the person’s effective privileges across all assignments, not one attractive scoped record.
Give groups and devices their own operating model
Groups often become the practical entitlement boundary for enterprise applications, licensing, and collaboration. Before delegating membership management, decide which groups permit self-service joins, which need a business owner, and which represent elevated or regulated access. A change to a harmless mailing list is not equivalent to adding a member to an application group with production data access.
Device identities introduce different states: registration, join, and hybrid join are related but not identical. A policy might require a compliant managed device to reach sensitive resources, while a help desk needs limited capabilities to troubleshoot registration problems. Assigning a directory role should not be confused with granting local operating-system administrator rights on an endpoint.
Custom security attributes can classify identities for policy and reporting, but those attributes require deliberate administration and appropriate roles. Attribute labels such as employee type or data-sensitivity handling can be consequential: incorrect values can change automated access decisions. Treat their schema, update process, and audits as governed configuration rather than convenient free-text metadata.
Walk through effective permissions for a real delegation
Suppose a faculty help-desk operator can update users in the Business AU but cannot reset a particular student’s authentication methods. Work backward: is the student object in the AU, is the operator’s assigned role allowed to perform that particular action, is the action protected by an additional privileged-account rule, and is another policy restricting the operation? Merely seeing a role assignment in the portal does not prove every administrative operation should succeed.
Test with a representative ordinary user, a high-privilege account, a group managed by the department, and a device object. Record expected allowed and denied operations. Do not test by performing irreversible or risky resets on real users; use controlled identities in a nonproduction tenant or approved test population. A least-privilege design is persuasive when the denied operations are demonstrated as clearly as the allowed ones.
The next layer is tenant-wide governance. Role assignment history, administrator sign-ins, group-ownership changes, and privileged membership should be reviewed together. A small scope does not protect a tenant if the delegated account is compromised and routinely permitted to reset the authentication credentials of many high-impact users.
Protect platform administration separately
Routine scoped administration should coexist with a much smaller set of tenant-wide privileged roles. The people who can change Conditional Access, application consent, or privileged role assignments need higher authentication assurance and just-in-time activation where appropriate. Privileged access design with Microsoft Entra PIM provides useful context on controlling time-limited elevation and protecting the administrative path itself.
Break-glass accounts are distinct from the ordinary delegation model. They exist for resilience if normal authentication or policy configuration prevents administrators from entering the tenant. They should be monitored, documented, and tested without being used as convenient all-purpose support accounts. Removing them because they are inactive would defeat their purpose.
Licensing is another design input. Administrative-unit creation and delegation have different licensing implications, and rules for dynamic administrative-unit membership may have additional requirements. Validate the current licensing of the actual tenant before finalizing a proposal; an architecture should not assume a premium feature merely because its screen appears in a training image.
Plan a controlled tenant configuration change
A delegated role project often reveals that tenant settings have been changed informally for years. Before changing a company branding setting, domain, user consent option or default group creation rule, identify every user experience and service that depends on it. A globally visible tenant property can affect thousands of users even when the individual change seems small. Treat the configuration item as a product with an owner, approved expected state and rollback note.
For example, restricting who can create Microsoft 365 groups could reduce uncontrolled collaboration sprawl, but it may interrupt departments that use self-service workspaces as an operational necessity. Assess current group ownership, automation and collaboration processes before applying the restriction. Define a replacement request flow that is fast enough to be used; otherwise the apparent security improvement produces workarounds and extra support tickets.
Directory licenses require a similar distinction between assignment and permission. Assigning a premium license does not itself grant a user administrative authority, while delegating a role does not ensure every premium feature is available for that user or tenant. When license assignment is automated by group, review membership changes, exclusion logic and failure reports. Misconfigured group-based licensing can create an application outage without any obvious authentication error.
For device settings, determine whether users may register or join devices, whether restrictions depend on enrollment policy and whether the endpoint team has a separate management platform. Microsoft Entra device registration and Intune device compliance are linked operationally but are not the same record. A delegated admin changing a cloud device identity may not be authorized to alter the endpoint’s actual security configuration.
Make every change testable: capture before/after values, a controlled impacted user, a negative test for someone outside the intended scope and an observation window. Review the audit event, help-desk symptoms and policy results after deployment. The more sensitive the setting, the more important it is to preserve an independent recovery path and avoid using the same administrator credentials for change approval and execution.
Keep boundaries current as the organization changes
A delegated boundary degrades when students graduate, departments merge, contractors rotate, or a security team takes over a shared application. Use an authoritative personnel or organizational source to drive membership where reliable, and explicitly handle exceptions that cannot be automated. Owners should review whether the resources in an AU still correspond to the responsibility described by the associated role.
Record the design as a compact entitlement register: principal, role, scope, business justification, approver, activation method, expected review, and removal trigger. Reconcile the register with live Entra role assignments and audit logs. The purpose is not to collect paperwork; it is to make an unexpected right explainable and removable before an incident.
Tenant roles, administrative units, group ownership, and device identity are connected parts of one model. A sound result gives regional teams enough authority to resolve common requests promptly while preventing a local task from quietly turning into tenant-wide control. That operational precision is more useful than memorizing a long list of role names without understanding their reach.