Important change released for Guest Configuration audit policies

Welcome to the Governance and Management blog!

Summary

An important change has been released to policies in category Guest Configuration. The policy format has been updated to address customer feedback, to simplify the experience of auditing settings inside machines. Existing policies that were assigned prior to this release will continue to display accurate results and will not be deleted in the near future. For new policy assignments, only the updated definitions are available. The old policies are no longer available for new assignment from the Azure portal.

IMPORTANT

This change also addresses an issue reported by customers where user assigned managed service identities are replaced by system assigned managed service identities. If you are experiencing this issue, please follow the steps in this article to switch to the updated definitions.

In the new experience, a single initiative handles all prerequisite requirements. Once the prerequisites are completed, Audit policies may be added/removed without needing to run remediation tasks.

Switching to the new experience requires assigning the new definitions.

TL/DR Engineering perspective on the change

Here is a full post-mortem on the change and why we have made it.

Background

Guest Configuration policies operate together with the Microsoft.GuestConfiguration resource provider (RP). The role of the RP is to map scenarios to machines. In the example below, the RP stores a “guest configuration assignment” that audits for groups/accounts that should not be members of the Administrators group.

"guestConfiguration": {
            "name": "AdministratorsGroupMembersToExclude",
            "version": "1.*",
            "contentUri": "https://oaasguestconfigeus2s1.blob.core.windows.net/builtinconfig/AdministratorsGroupMembersToExclude/AdministratorsGroupMembersToExclude_1.0.0.0.zip",
            "contentHash": "4D4AC73EE559B4B4C52BF123E6BE62A6901BC3E24750A238C32759DB366E433D",
            "contentType": null,
            "assignmentType": null,
            "configurationParameter": [
                {
                    "name": "[LocalGroup]AdministratorsGroup;MembersToExclude",
                    "value": "foobar"
                }
            ],
            "configurationProtectedParameter": [],
            "configurationSetting": null
        }

The Azure resource must be created when an Azure Policy is assigned for guest configuration scenarios. The information provided by the resource makes the scenario visible in the Azure Resource Manager API, which is how Azure Policy evaluates the results returned by the agent.

For the last two years, guest configuration policies have followed a pattern where each scenario included an initiative containing two definitions. Each definition played an important role:

• A Deploy If Not Exists definition that created the guest configuration assignment, and ensured the extension is installed for the machine and the machine has a system assigned managed identity.
• An Audit If Not Exists definition that would examine the results returned by the agent in ARM to make the compliance state available in the Azure Policy experience.

Challenge

The consequence of this design was that when the definitions were assigned to a scope with existing machines, a remediation task needed to be run for the guest configuration assignments to be created. Customer feedback told us that the notion of remediating an audit policy did not sound logical and was too confusing for a “day 0” experience.

Resolution

We have now launched a new policy experience for guest configuration definitions. Effective now, only the Audit If Not Exists definition is required. Customers will not need to assign Deploy If Not Exists definitions per scenario, and will not need to assign an initiative per scenario.

You can see the definitions in the Azure Portal by filtering to Category = Guest Configuration.

To handle creation of the guest configuration assignment resource, we have implemented an automation solution in our service. When Azure Policy performs a GET request to determine machine compliance, the automation will create the resource and return a state of Pending. Once the agent has performed the audit and calculated the compliance state, the service will write Compliant or NonCompliant as the state of the scenario per machine. This PUT activity triggers Azure Policy to evaluate the resource again, which means the state of the resource in Azure Policy will always be current with the latest compliance state of the machine (within 30 minutes).

IMPORTANT

To start using the new definitions you must create a new Policy assignment.

We took our time in releasing this change because we thoroughly investigated every possibility for migrating existing assignments to the new model. In every design proposal we were able to find edge cases where parameter values could be at risk. To ensure the highest degree of reliability, the only possibility is to release new policies and mark the existing policies as deprecated.

< EDIT - ADDITIONAL STEP - 11/23/2020 >

In addition to deleting the policy assignment, we have found that some customers also needed to directly delete the Guest Assignments created by the Deploy If Not Exists Policy. The catch we found is that the new automation will not override Guest Assignments previously created by Policy, as a safe guard. However, many customers wished to change the parameter values for the Azure Policy assignment when they made the switch to the new definitions, and this created a mis-match between the old Guest Assignment and the new results they expected. An enhancement that is scheduled to be deployed in December will also address this issue, but in the meantime you can correct the problem by deleting the old Guest Assignment using Az PowerShell and the new Audit If Not Exists definition will replace it with a new Guest Assignment that has the new expected parameter values.

For Guest Assignments on Azure VM's:

Remove-AzResource -ResourceId '/subscriptions/yoursubscriptionid/resourceGroups/yourresourcegroupname/providers/Microsoft.Compute/virtualMachines/yourVMName/providers/Microsoft.GuestConfiguration/guestConfigurationAssignments/yourGuestAssignmentName' -Verbose -apiversion "2018-11-20" -Debug

Or for Arc machines:

Remove-AzResource -ResourceId '/subscriptions/yoursubscriptionid/resourceGroups/yourresourcegroupname/providers/Microsoft.HybridCompute/machines/yourMachineName/providers/Microsoft.GuestConfiguration/guestConfigurationAssignments/yourGuestAssignmentName' -Verbose -apiversion "2018-11-20" -Debug

If you are managing 100's or 1000's of machines, you will want to do a ForEach loop to remove the Guest Assignment resource for each of the machines in scope.

Existing definitions appearing as ‘Deprecated’

All existing guest configuration definitions will appear with the text "[Deprecated]" added to the beginning of the display name. This does not mean they have been deleted, or that they will be deleted near term. The only change is that they are not visible in the Azure Portal for new assignments. Where they are used for existing assignments, they will continue to function as they have in the past and they will show accurate results.

There is no date and time when customers using the previous Initiative/Deploy/Audit policy combinations must change to the new policies. However, we would encourage everyone to switch to the new policies as soon as they are able. The new experience is simplified, easier to use, and all future updates will only be made to the new policies.

When you would like to enjoy the new experience, you can assign the new policies. Having the “old” policies and “new” policies both assigned to the same or overlapping scopes is fine as long as they use the same parameter values.

Only one set of prerequisite definitions

To simplify handling all prerequisite requirements to perform an audit inside the machine, we now have an initiative named Deploy prerequisites to enable Guest Configuration policies on virtual machines. This initiative combines 4 definitions:

• Create a system assigned managed identity for machines with no identity
• Create a system assigned managed identity for machines with an existing user assigned managed identity
• Deploy the ‘AzurePolicyforWindows’ extension to Windows machines
• Deploy the ‘AzurePolicyforLinux’ extension to Linux machines

These policies will deploy requirements to new machines automatically and make remediation tasks available for existing machines. Once machines have been remediated for prerequisites, you do not need to run additional remediation tasks as you assign more audit policies.

Thank you

I know this change is inconvenient since it requires making a manual change. We have done our best to lessen the impact of the change, with intention to bring you the best experience possible. Thank you for your patience and I look forward to hearing your feedback.

To provide feedback or engage in discussion about guest configuration, I would suggest the following options.

• Feature requests for Azure Policy: User Voice

• Discussion about the Azure Governance platform including guest configuration: Governance Community Hub

• Discussion about DSC custom resource development for guest configuration: DSC channel in PowerShell community Slack*

* You are also welcome to direct-message me here with questions or feedback about guest configuration

Thank you!

Michael Greene

Principal Program Manager

Azure management services