What Does Administrative unit Mean?
On This Page
Quick Definition
An Administrative unit is like a sub-department inside your company’s identity system. Instead of giving an admin control over all employees, you can give them control over only a specific group of people, like the Sales team or all users in a particular city. This helps you manage large organizations more safely and efficiently.
Commonly Confused With
An OU is an on-premises container used to group users, computers, or groups for applying Group Policy or delegating administrative control within an on-premises domain. An Administrative unit is a cloud-only container in Azure AD used specifically for delegating Azure AD role permissions. They serve a similar purpose (delegation) but in completely different environments, with different configuration tools and scopes.
You use OUs in on-premises AD to apply a specific password policy to the Finance department. You use an Administrative unit in Azure AD to give a helpdesk technician the ability to reset passwords for only the Finance users in the cloud.
A security group is used to grant access to resources like apps, SharePoint sites, or to assign licenses. It can have dynamic or assigned membership. An Administrative unit is not used for granting access to resources; it is used only to limit the scope of administrative roles. Also, adding a security group to an administrative unit does not bring the group's members with it – it adds only the group object itself.
You create a security group called 'Sales App Users' to give the Sales team access to the CRM app. You also create an Administrative unit called 'Sales Users' to allow a junior admin to manage the accounts of those same people.
Azure RBAC scopes are used to control permissions on Azure infrastructure resources like virtual machines, storage, and networking. Administrative units control permissions on Azure AD objects (users, groups, devices). They are fundamentally different systems – one is for identity, the other for resources.
To let someone create VMs only in the 'Europe' resource group, you assign them the 'Virtual Machine Contributor' role at that resource group scope (Azure RBAC). To let someone reset passwords only for European users, you create an Administrative unit containing those users and assign the 'Helpdesk Administrator' role scoped to that unit.
Must Know for Exams
Administrative units are a high-yield topic across multiple Microsoft exams. They appear most prominently in MS-102 (Microsoft 365 Administrator), AZ-104 (Azure Administrator), and SC-900 (Security, Compliance, and Identity Fundamentals).
For MS-102, the exam objective “Manage identity and access” includes delegating administration by using administrative units. You need to know how to create them, add members, and assign scoped roles. Expect scenario-based questions where you must decide whether to use an administrative unit or a different tool like a dynamic group or a custom role. The official Microsoft Learn module calls this a “best practice for delegated administration.”
For AZ-104, administrative units appear under “Manage identities and governance in Azure.” You must understand how to use them to delegate management of users and groups in a larger Azure AD tenant. The exam may ask you to choose between administrative units and Azure RBAC (role-based access control) for specific delegation scenarios. Remember: administrative units work for Azure AD roles, not for Azure resource management RBAC.
For SC-900, the exam is foundational, so questions are more conceptual. You might be asked to identify the purpose of administrative units or to choose the correct tool for delegating user management while following the principle of least privilege. The exam also tests your ability to distinguish administrative units from other identity concepts like organizational units in on-premises AD.
In all three exams, watch for questions that present a scenario with multiple regional offices. For example, a company with offices in New York, London, and Tokyo wants to give local IT staff the ability to reset passwords for users in their own office only. The correct answer is to create an administrative unit for each office, add the users from that office, and assign the Helpdesk Administrator role scoped to that unit. The trap answer might be to create a custom role, which would be more complex than needed.
Simple Meaning
Think of your company’s Microsoft Entra ID (formerly Azure AD) as one giant building with thousands of employees. If you gave every security guard a master key to every door, it would be very dangerous. A single mistake could let the wrong person into the CEO’s office. That is what happens when you assign an admin role to someone and they can change any user, any group, or any device in the entire directory.
Administrative units are like giving a security guard a key only to the floor they are responsible for. For example, you might have a junior IT person who needs to reset passwords for employees in the Marketing department only. Without an Administrative unit, you would have to give them a global role like “User Administrator,” which lets them reset passwords for everyone – including the CEO. With an Administrative unit, you can say: this person can reset passwords, but only for users who belong to the “Marketing” Administrative unit.
You can create Administrative units based on departments, geographic locations, projects, or any other logical grouping. Once the unit is created, you add members to it – users, groups, or devices – and then you assign Azure AD roles with a scope limited to that unit. The admin will see and manage only the objects inside their assigned Administrative unit. It is a way to practice the principle of least privilege, giving people exactly the access they need and nothing more.
Full Technical Definition
In Microsoft Entra ID, an Administrative unit is a directory-level resource that serves as a security boundary for role-based access control (RBAC). It enables the delegation of administrative permissions over a subset of objects without granting permissions over the entire tenant. This is especially important in large organizations with thousands of users, groups, and devices, where assigning global administrator roles would violate security best practices.
Administrative units are created using the Microsoft Entra admin center, Microsoft Graph API, or PowerShell. The object itself has a unique object ID, a display name, and a description. After creation, the unit is empty until you add members. Members can be users, groups, or devices. A single object can belong to multiple Administrative units, which provides flexible grouping.
Once the unit has members, you assign an Azure AD role, such as User Administrator, Helpdesk Administrator, or Groups Administrator, and scope that role to the Administrative unit. The admin then sees in their portals only the users, groups, or devices that are members of that unit. Their administrative actions – like resetting passwords, managing group memberships, or updating device settings – are restricted to those objects.
Behind the scenes, Microsoft Entra ID evaluates access using a combination of the user’s role assignment and the scope. The scope can be the entire directory, an administrative unit, or a specific object. When a scoped role is used, the system filters all directory queries to include only objects within the defined scope. This filtering happens at the API layer, so even if the admin tries to use Graph API directly, they will get an “access denied” error for objects outside their unit.
It is important to understand that Administrative units do not replace security groups or organizational units (OUs) in Active Directory Domain Services. They are logical containers exclusively for Azure AD role delegation. They do not affect group membership, device enrollment, or conditional access policies directly. However, they can be used in conjunction with dynamic groups and other tools to create a layered governance model.
Microsoft recommends Administrative units as a best practice for any tenant with more than a few hundred users. They are supported in Microsoft 365 (Azure AD Plan 1 and above), and they are a critical feature for exam scenarios in MS-102, AZ-104, and SC-900.
Real-Life Example
Imagine a large hospital with hundreds of doctors, nurses, and support staff. The hospital has an IT department that manages everyone’s computer accounts. The IT manager, Sarah, has two junior technicians: Tom and Lisa. Tom supports the Emergency Room (ER), and Lisa supports the Cardiology wing.
Without Administrative units, Sarah would have to give both Tom and Lisa the “Helpdesk Administrator” role for the entire hospital. This means Tom could accidentally reset the password of the Chief of Cardiology, or Lisa could change the email settings of an ER doctor. That would be a disaster.
To solve this, Sarah creates two Administrative units: “ER Staff” and “Cardiology Staff.” She adds all the doctors and nurses from the ER into the first unit, and all Cardiology staff into the second. Then she assigns Tom the Helpdesk Administrator role scoped to the “ER Staff” unit, and Lisa the same role scoped to the “Cardiology Staff” unit.
Now, when Tom logs into the admin portal, he sees only the 50 users in the ER. He cannot see or change any user in Cardiology. Similarly, Lisa sees only her 40 users. This is exactly how Administrative units work in Microsoft Entra ID. They let you delegate authority precisely, so each admin has the right level of access for their job, and nothing more.
Why This Term Matters
In modern IT environments, the principle of least privilege is not just a good idea – it is often a compliance requirement. Standards like ISO 27001, SOC 2, and NIST explicitly require that users be given only the minimum access needed to perform their work. Administrative units are a direct tool to achieve this in cloud identity management.
Without Administrative units, organizations are forced to either give too much power to too many people, or to create complex, hard-to-maintain custom roles. Both choices lead to risk. Overly broad access increases the blast radius of a compromised account. A single helpdesk technician with a global role could cause a ransomware outbreak by resetting passwords for high-privilege users. On the other hand, custom roles are difficult to set up and audit, often leading to misconfigurations.
Administrative units also simplify audits. When an auditor asks, “Who can reset passwords for the Finance department?” you can point to the specific Administrative unit and the role assignment. Without units, you would have to manually check every admin role across the entire tenant.
Administrative units help with organizational separation. If your company has multiple business units that should be isolated – for example, a parent company and a subsidiary sharing a Microsoft 365 tenant – you can use Administrative units to ensure that one unit’s admins cannot affect the other’s resources. This allows you to keep a single tenant for cost and collaboration reasons while maintaining strict access boundaries.
How It Appears in Exam Questions
Exam questions about administrative units fall into three main patterns: scenario-based delegation, configuration steps, and troubleshooting mismatched scope.
Scenario type: You are given a company with 10,000 users across 5 regions. Each region has a local IT team that needs to manage user accounts for their region only. You must decide which approach to use. The correct answer involves administrative units. Distractors include creating 5 Azure AD tenants, using on-premises AD organizational units, or giving each team the global User Administrator role.
Configuration type: You are asked to order the steps to delegate password reset for the Sales department to a new helpdesk employee. The steps include: 1) Create an administrative unit called “Sales Users,” 2) Add all Sales department users to the unit, 3) Assign the Helpdesk Administrator role to the employee, scoped to the newly created administrative unit. The exam may present these steps out of order and ask you to sequence them correctly.
Troubleshooting type: A junior admin complains that they cannot see a user they need to manage, even though they have a scoped role. The cause might be that the user was not added to the administrative unit, or that the administrative unit itself has no members. You must identify the missing step or misconfiguration.
Occasionally, questions test the difference between administrative units and Azure RBAC. For instance, “You need to delegate the ability to create virtual machines only in a specific resource group. Should you use an administrative unit?” The answer is no – administrative units are for Azure AD objects (users, groups, devices), not Azure resources like VMs. For Azure resources, you use Azure RBAC.
Finally, there are questions that test the relationship between administrative units and dynamic groups. For example, “You want members to be automatically added to an administrative unit based on their department attribute.” The answer is that administrative units do not support dynamic membership natively. You would need to use a dynamic group first and then add that group as a member of the administrative unit – but note that adding a group adds the group object itself, not its members. For direct user membership, you must add users individually or via PowerShell/Graph API automation.
Practise Administrative unit Questions
Test your understanding with exam-style practice questions.
Example Scenario
You work as an IT administrator for a medium-sized company called Contoso Ltd. The company has 1,200 employees in four main departments: Sales, Marketing, Engineering, and Human Resources. Each department has its own IT support person who should be able to reset passwords and manage user accounts for their department only.
Currently, all four support people have the global “User Administrator” role. This is a security risk because the Engineering support person could accidentally reset the password of the Sales VP. The CIO has asked you to fix this.
You decide to use Administrative units. You open the Microsoft Entra admin center and create four administrative units: “Sales Users,” “Marketing Users,” “Engineering Users,” and “HR Users.” Next, you need to populate these units with the correct users. You export all users and filter by department attribute. For example, all users with Department = “Sales” are added to the “Sales Users” administrative unit. You do this one by one, or use a PowerShell script to add them in bulk.
Once the units are ready, you remove the global “User Administrator” role from the four support people. Then, you assign each support person the “User Administrator” role again, but this time you scope the assignment to the corresponding administrative unit. For example, the Sales support person gets “User Administrator” scoped to “Sales Users.”
Now, when the Sales support person logs into the Microsoft 365 admin center, they see only the 300 users in the Sales department. They can reset passwords, manage licenses, and edit profile information for those users only. The Engineering support person sees only their 400 users. No one can touch users outside their department. The CIO is happy, and the company is more secure. This is a textbook use of Administrative units.
Common Mistakes
Thinking administrative units automatically add users based on group membership.
Administrative units do not support dynamic membership. You must manually add users, groups, or devices. Adding a security group to an administrative unit adds the group object, not the group's members. The members of the group are not included in the administrative unit's scope.
Either add users individually or use PowerShell or Microsoft Graph API to automate adding users based on attributes like department.
Confusing administrative units with Azure RBAC scopes.
Administrative units apply only to Azure AD roles (managing users, groups, and devices in Entra ID). Azure RBAC is for managing Azure resources like VMs, storage accounts, and resource groups. They are two separate systems.
Remember: Azure AD roles + administrative units = delegate user/group/device management. Azure RBAC = delegate Azure resource management.
Assigning a role with directory-wide scope and also scoped to an administrative unit, thinking it limits the role.
If you assign a role with directory-wide scope (like ‘All users’), the user has full access everywhere, regardless of any scoped assignments. The scoped assignment does not override the broader one.
Always remove any directory-wide role assignments before assigning a scoped role to the same admin. Use scoped assignments as the sole delegation method.
Assuming administrative units affect resource access like SharePoint sites or apps.
Administrative units only affect management of Azure AD objects. They do not control access to applications, SharePoint sites, or data. For data access, you need other tools like security groups, conditional access, or SharePoint permissions.
Use administrative units for delegated identity administration only. For resource access, use the appropriate authorization mechanism for that service.
Exam Trap — Don't Get Fooled
{"trap":"A question presents a scenario where a company needs to delegate password resets for users in a specific geographic region. The answer choices include: A) Create an administrative unit and add users from that region. B) Create a security group and assign the Helpdesk Administrator role to that group.
C) Use a dynamic group and assign the role. D) Create a new custom role with scoped permissions.","why_learners_choose_it":"Learners often choose B or C because they are familiar with security groups and dynamic groups from other contexts.
They think a group can directly grant the role, or that dynamic membership will automatically populate the scope. They may also choose D because they think custom roles are the solution for any non-global delegation.","how_to_avoid_it":"Understand that Azure AD roles cannot be assigned directly to security groups (except for a few specific roles like Groups Administrator, and even then, it is limited).
Dynamic groups cannot be used directly as a scope for role assignments. The only native way to restrict a role to a subset of users is by using an administrative unit. Custom roles can have scoped permissions but are more complex and still require an administrative unit or directory scope.
The simplest, correct, and exam-preferred method is option A."
Step-by-Step Breakdown
Plan groupings
Before creating any administrative unit, decide how you will group your users, groups, or devices. Common groupings include department, office location, project, or compliance boundary. This step is critical because re-organizing units later is cumbersome.
Create the Administrative unit
In the Microsoft Entra admin center, navigate to Identity > Roles & admins > Administrative units. Click 'Add' and provide a name (e.g., 'Sales Users') and an optional description. The unit is created empty.
Add members to the unit
Select the new unit and click 'Add member.' You can add users, groups, or devices. You must do this manually, or via PowerShell/Graph API. Bulk upload via CSV is supported only for users. Remember: adding a group adds the group object, not its members.
Assign a role scoped to the administrative unit
Go to Roles & admins, select the role you want to delegate (e.g., User Administrator), and click 'Add assignment.' Choose the user who will receive the role, set the scope to 'Administrative unit,' and select the specific unit you created.
Remove any wider role assignments
If the admin had any directory-wide role assignments, remove them now. Having both a directory-wide role and a scoped role makes the scoped role irrelevant – the admin would still have full access. This is a common exam mistake.
Verify the delegation
Sign in as the delegated admin and open the Microsoft 365 admin center or Entra admin center. Confirm that they see only the members of their unit. Attempt to manage an object outside the unit to verify the restriction works.
Practical Mini-Lesson
Administrative units are one of the most practical tools for identity governance in Microsoft 365 and Azure AD. As an IT professional, you will likely encounter a situation where you need to give administrative power to non-IT staff – for example, a department manager who needs to reset passwords for their team, or a regional IT person who needs to manage devices in their branch office.
Without administrative units, the only way to grant such a capability is to assign a global role. That would give that person access to every user, group, and device in the entire tenant. For a company with 5,000 users, even a small mistake by one delegated admin could cause a widespread outage or data exposure. Administrative units are the designed solution for this exact problem.
In practice, creating administrative units is only the beginning. The real work is in populating them correctly. Most organizations use PowerShell scripts or the Microsoft Graph API to automate adding users based on attributes like Department, OfficeLocation, or CustomAttribute. For example, you could run a script that loops through all users where Department equals 'Sales' and adds them to the 'Sales Users' administrative unit. This script can be run on a schedule to keep the unit up to date.
What can go wrong? The most common issue is forgetting to remove the previous global role. A technician might be assigned Helpdesk Administrator scoped to 'Marketing Users,' but if they still have a global 'User Administrator' assignment from before, they will still be able to see and manage all users. Always audit existing role assignments when you implement scoped delegation.
Another issue is that administrative units do not support dynamic membership directly. If a user changes departments, you must manually update their membership in the administrative unit – otherwise, they might remain in the wrong unit, giving the wrong admin access to them. Some organizations use Azure Automation runbooks to handle this.
Finally, remember that administrative units are for Azure AD only. If you need to delegate management of Exchange Online mailboxes or SharePoint sites, you need to use the separate admin roles in those workloads (like Exchange Admin role). Administrative units do not cascade into those systems.
Memory Tip
Think: AU = Admin Unit = A tiny universe of users. It limits admin power to a small universe, not the whole galaxy.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
Frequently Asked Questions
Can I assign the same role scoped to multiple administrative units to one person?
Yes. A user can have the same Azure AD role assigned multiple times, each scoped to a different administrative unit. This effectively gives them access to the combined membership of all those units.
Do administrative units support nested units?
No. Administrative units are flat containers. You cannot have a parent unit containing child units. All units are independent and exist at the same level.
Can I add a device to an administrative unit?
Yes. Administrative units support devices as members. This allows you to delegate device management (like BitLocker recovery or device settings) to a specific team, scoped to only certain devices.
What happens to an admin's access if the administrative unit is deleted?
If the administrative unit is deleted while an admin has a role scoped to it, the role assignment becomes invalid. The admin will lose access to manage any objects because the scope no longer exists. It is best practice to remove or reassign role assignments before deleting the unit.
Are administrative units available in all Azure AD editions?
Administrative units are available in Azure AD Plan 1 and above, which includes Microsoft 365 Business Premium and Enterprise plans. They are not available in Azure AD Free.
Can I use dynamic groups to automatically populate an administrative unit?
Not directly. Administrative units do not support dynamic membership rules. However, you can use a dynamic group to collect users based on attributes, and then use PowerShell or Graph API to periodically add those users to the administrative unit.
Summary
Administrative units are a foundational concept in Microsoft identity and governance. They allow you to delegate administrative permissions over a subset of users, groups, or devices, rather than the entire Azure AD tenant. This directly supports the principle of least privilege, reduces security risk, and simplifies compliance auditing.
For learners pursuing certifications like MS-102, AZ-104, or SC-900, understanding administrative units is essential. You will encounter scenario-based questions that require you to choose between this and other delegation methods, and configuration questions that test your ability to set them up correctly. The most common exam traps involve confusing administrative units with security groups, dynamic groups, or Azure RBAC scopes.
In the real world, administrative units are used by organizations of all sizes to empower local IT teams, departmental managers, and support staff while maintaining tight security boundaries. They are not a replacement for other tools like security groups or organizational units, but they fill a specific and critical role in cloud identity management.
The ultimate takeaway: if you need to give someone admin power over a specific group of people without giving them the keys to the whole kingdom, administrative units are the right tool for the job.