Ensuring policy compliance with Autopilot
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 blog covers a key use case for our Office 365 management tool Autopilot. If you want to find out more about what the solution does – you can find an overview here.
Policy Compliance: A real-world example
Using Autopilot’s configuration policies, you can apply changes to user objects based off of where they exist in a virtual organizational unit (vOU) structure created in the product.
For example, let’s say you have a vOU for your legal department. You want all users in that department to be enabled for multi-factor authentication (MFA). In Autopilot, you can simply create a configuration policy to enable MFA for the users in that vOU. Here’s how you do it:
First, you select the legal department vOU.
Next, you enable MFA.
Now, whenever you add a user to the legal department vOU, the configuration policy causes MFA to be enabled for that user. Take a look:
This is great. But, what happens if someone makes a change to that user outside of Autopilot and the vOU is no longer in compliance with the policy?
Making changes to users outside of Autopilot
After you created that configuration policy, it’s possible someone might use native tools to disable MFA. Will that leave gaps in your compliance with the policy? Let’s find out.
First, let’s disable MFA in Azure Active Directory (AAD):
Now, my user is not in compliance with the Autopilot configuration policy.
What happens next?
Since this was a change to the user object in AAD, Autopilot receives a webhook notification from the Graph API that the user has been updated. Each time the product receives that notification it will run a job to check to see what changes were made. That job can be seen labeled as “1” in the audit log (shown below).
From there, the configuration policy understands that the user is not in compliance. Autopilot automatically sets the MFA back to enabled, as seen in the audit log (above) as “2”. Since Autopilot just set back the MFA for that user, a change notification will again be sent by the Graph API, “3” shown in the audit log above. Finally, since a change was detected on that user’s MFA, Autopilot then queries the user to ensure MFA is enabled, and the user is in compliance with the configuration policy, “4” in the audit log above.
Compliance made easy
As you can see, Autopilot configuration policies help you ensure…
- Objects are compliant.
- Policies are enforced.
This is true even if external changes are made.
Does this sound like it might make your job easier? Or keep your organization protected and compliant? Learn more about Autopilot here.