Concept and mechanism
Identity administration requires knowing the object, operation, and scope. An administrative unit delegates certain functions over a set of users, groups, or devices. Including a group brings the group object into scope; it does not automatically include every member object. This explains why an administrator can manage group membership but cannot reset a group member’s password. Units limit management and do not themselves remove default directory-read permissions. They are not separate tenants. Before promising isolation, describe exactly which operations should be allowed, denied, or visible and confirm the appropriate mechanism.
Guided application
In a fictional project for support teams across countries, build a matrix of administrators, resources, and tasks. Confirm licensing: inspected guidance requires P1 for administrators holding unit-scoped roles; static members can use Free, while dynamic membership has separate requirements. Do not confuse creating a unit with exercising all its capabilities. The same discipline applies to group-based licenses: configuration does not prove success for each person. Inspect errors and confirm delivery before closing the request. For devices, retain the distinction between registered, joined, and hybrid joined. A report switching labels can drive an incorrect access decision. Record identifiers and observed state with a date so RUN knows what was actually delivered.
Group in the unit: group management can be permitted while password reset for a member outside the unit remains out of scope.
Common pitfalls
Group as all its members; unit as tenant; configuration as delivery; label as actual state.
Related topics: Hybrid identity and partners · Methods and emergency access · Conditional Access and risk
Verify actual objects and permissions within task scope.
Reference: Administrative units · SC-300 objectives effective 2026-04-27; product documentation reviewed 2026-10-01; 2026-10-28 English update compared separately