Technical Review: OUs and configuring Authorization policies
This article refers to our former reporting, security, and management products. We have now integrated these products into Nova, an all-new Office 365 management platform. Find out more
This is an excerpt from an independent review of Autopilot by Microsoft MVP Dominik Hoefling. We will be releasing sections on the blog over the coming weeks, but if you would like to read the entire review, you can download it here.
(Virtual) Organizational Units are the heart of a proven delegated administration tool. OUs are well-known for most administrators out there. The logical structure is the same as you’ll find in your on-premises Active Directory.
With Autopilot, you can create tenant groups and Organizational Units. Tenant groups are a top-level Organizational Unit that can contain multiple tenants, as you can see in the following figure:
Figure 4: Tenant Groups
Figure 4 shows how two different Office 365 tenants are grouped to one tenant group and their underlying OU structure:
- GrJo and AuSm: Tenant group of two Office 365 tenants
- GregTenant1: Display name of the first tenant (GrJo)
- US: Organizational Unit within the first tenant (GrJo)
- West Coast: sub-level OU of the US OU
- onmicrosoft.com: Display name of the second tenant (AuSm)
- EMEA: Organizational Unit within the second tenant (AuSm)
You can design your tenant and OU structure in the way that best suits you. For example, you can design a completely new structure for your Office 365 tenants and admins, or you can also synchronize your on-premises Active Directory OU structure with the on-premises sync agent provided with Autopilot. If you have a well designed on-premises OU construction, it makes sense to synchronize it because most customers have a lot of (nested) OUs.
Autopilot allows you to manage and configure policies. It comes with two kinds of policies:
- Authorization Policies: used for both admin role permissions and delegated admin role permissions. Authorization Polices can be assigned to tenant groups, Organizational Units, and administrators.
- Configuration Policies: used for automated bulk-processing tasks, like updating user attributes, adding and removing Azure AD licenses, enabling MFA, etc. Configuration Policies can be assigned to tenant groups, Organizational Units, and administrators.
All details of every action and event will be captured and saved in its audit log so you can see exactly who made each change and when. More details on the audit log will be covered in the section “Audit Log”.
An important task for initial set up and ongoing management is configuring delegated admin permissions for either a user, a tenant group, or Organizational Unit so that delegated admins can perform their daily administrative tasks within Autopilot. Users can initiate management tasks and the internal policy engine of Autopilot determines if the user has the correct permissions to perform that action on the target user. Bulk actions can be applied to a set of users, or to an entire Organizational Unit.
As an admin, you can configure Authorization Policies for nearly every needed task. For example, the policy “QTPS2-Germany-UserManagement-Restricted” is assigned to the OU ‘Germany’ within the tenant group QTPS2.
Figure 5: Authorization Policy Configuration
Administrators can have the ability to configure Authorization Policy templates as well. Templates can be used for similar roles for different OUs or tenant groups, like help desk admins. The Default user policy setting will apply to all users in a tenant. The Self-service configuration allows the users to do actions in the container where the policy is applied. You can also apply the Is template setting if you would like to configure similar Authorization Policies for different containers.
The Assignment configuration lets you configure where the policy should be assigned to:
- Organizational Units
- Single users
- Members of a security group
Configure Authorization Policy Actions
The most important part of this process is assigning specific rights to your delegated admins. Referred to as “actions”, these are specific permissions that you would like to assign to your Authorization Policy. I filtered the list of actions based on the “mailbox” keyword to see all relevant mailbox configuration settings that can be assigned to your policy.
Figure 6: Mailbox Authorization Policy Actions
These actions are daily administrative tasks like create, set, change, disable, and delete parameters:
- Mailbox permissions
- Distribution Group
- Office 365 Group
- Out of office
- Shared Mailbox
In addition to this, there are Groups and Teams cmdlets like “Update Group” and “Add New Channel To Team”. As Autopilot was GA in the middle of 2018, there will be more features and actions constantly added in the future.
This delegated administration is a big win for organizations with multiple service desk or help desk departments. Not to mention, this feature enables each administrator to only to see and manage users they are allowed to. This kind of delegation is not possible within Azure and Office 365 today, nor with Role Based Access Control (RBAC).
Configure Authorization Policy Properties
To add to the granular management of the tool, you can configure which Active Directory property your delegated admins are allowed to read and edit.
Figure 7: Configure read and edit rights on AD property
In the third and final installment of this blog series, Dominik will be looking at creating Configuration policies, reviewing, scheduling, and tracking jobs, and using the audit log. If you would like to read the entire review now, you can download it below.