To understand the difference between Group Policy and Azure Policy, we need to start with the architecture differences regarding how devices are seen in a Windows Server domain versus in Microsoft Azure.
Traditional Group Policy architecture is based on Users and Computers being objects in Active Directory, which both authenticate with the Domain. With the Cloud, this architecture is split somewhat.
- User accounts live and are managed in Azure Active Directory (though other services such as Office 365 surface service-specific user settings).
- Computers (Servers) are a virtual machine resource in Azure, or are visible to Azure via Azure Arc. Previously this was also accomplished by various agents and extensions.
- Computers (PCs) are visible to Azure when they are Azure AD Registered, Azure AD Joined or Hybrid Azure AD Joined. For more information on the differences, visit https://docs.microsoft.com/azure/active-directory/devices/overview?WT.mc_id=itopstalk-blog-socuff
These connection methods to Azure AD allow for:
- The devices to support access to Microsoft Cloud resources (Azure, Office 365 etc) via a personal (Azure AD registered only) or organizational Azure AD account. This includes supporting single sign-on.
- Device-based conditional access policies, allowing actions to be applied (eg require or don't require MFA) and access to be granted or denied, based on whether the requested device is known to Azure AD or not.
- Management of devices via Microsoft Endpoint Manager and Microsoft 365 Business.
So while you'll see Device Identities inside Azure Active Directory, the device settings that you can configure here are limited, and do not reflect the full set of workstation Group Policy settings you will find in Active Directory. For more information, visit https://docs.microsoft.com/azure/active-directory/devices/device-management-azure-portal?WT.mc_id=it... Many traditional device settings are instead managed via the Microsoft Endpoint Manager products.
Azure Policy, however, includes:
- Settings for Azure subscriptions.
- Settings for Azure resources.
- Settings for "in-guest configuration" (for example, the Windows Server operating system inside a virtual machine). And with Azure Arc, that now easily includes Windows Servers on-premises and in other Cloud providers.
This means that:
- There are some things Azure Policy can do, that Group Policy can't do - like enforce that certain Azure virtual machine SKUs can't be created, or audit that a Windows Server virtual machine is enrolled in the Azure Security Centre for monitoring.
- There are some things that both Group Policy and Azure Policy can do - like enforce password length settings inside a Windows Server virtual machine (in Azure, or via Azure Arc to non-Azure Server VMs).
- There are some things that Group Policy can do, that Azure Policy can't - like enforcing a screen saver or desktop wallpaper on a Windows 10 PC.
Azure Policy is enforced by the Azure Resource Manager when an action occurs or a setting is queried, against a resource that ARM has access to. Group Policy is applied on login or policy refresh, when the user or device authenticates with the Active Directory domain.
Why would you use Azure Policy to do something that Group Policy can enforce?
If you're moving to use Azure Policy as your single point of administration for your Windows Servers, regardless of whether they're in Azure or not.
If you are using Azure Policy as your compliance dashboard to show in one place which resources are not compliant, across your hybrid infrastructure. (note: here Group Policy could still enforce the setting, but you'll define an Azure Policy to check that particular setting anyway, so it may not make sense to have to manage this in two places).
The next important point is that Azure Policies are assigned to all the things inside the policy "scope" - that is, a management group, a subscription or a resource group. You can exclude things from that scope - for example, apply the Policy to a management group of subscriptions, but exclude particular subscriptions or apply the Policy to a resource group and exclude particular resources. You cannot apply an Azure Policy to individual resources.
Policies can also have different effects, depending on if you want to add a setting (append), change a setting (modify), audit if something does or does not exist, deploy something if it does not exist, or deny something. This gives you a broad range of flexibility, from outright blocking the creation of or changes to some types of resources, to having visibility of configuration drift on the compliance dashboard, allowing you to then address each instance manually. For more information on policy effects and the order they are evaluated in, visit:
https://docs.microsoft.com/azure/governance/policy/concepts/effects?WT.mc_id=itopstalk-blog-socuff
So what would you use Azure Policy for?
That's a pretty long list! Most Azure services have inbuilt Azure policies you can turn on today, including policies for the settings inside virtual machines. Here are some examples:
- Require disk encryption
- Audit virtual machines without disaster recovery configured
- Audit virtual machines that contain expiring certificates within the specified number of days
- Audit virtual machines that do not match Azure security baseline settings
- Audit virtual machines that have not restarted with the specified number of days
- Audit Linux VMs that have accounts without passwords
- Audit virtual machines that don't have the specified application installed
- Require automatic OS image patching on virtual machine scale sets
- Allow locations (Azure regions)
- Allow/not allow resource types
- Allow disk SKUs or virtual machines SKUs
- Audit usage of custom role based access control rules
- Enable Azure Monitor
- Enforce resource tagging (tag name and/or value)
- Enforce naming pattern consistency
Regulartory compliance:
IRS1075, UK NHS, SWIFT CSP-CSCF, PCI, Canada Federal PBMM, ISO 27001, NIST SP 800-53 R4, FedRAMP controls (and that list is growing!). These policy initiatives and their associated policy definitions are available in Preview inside the Azure portal.
And if there isn't an in-built Azure Policy that meets your needs, you can create your own custom policies or check out the Azure Policy GitHub repo: https://github.com/Azure/azure-policy
So when would you still use Group Policy?
That's a call your organization needs to make based on how you are managing your infrastructure and how far along you are embracing cloud tools. For desktop settings, your device fleet may not be fully managed by Microsoft Endpoint Manager, so Group Policy is still supported in Windows Server 2019.
The hardest approach is to say "this is what we currently do - how do we do it in the Cloud?" Instead, you need to take a look at the capabilities of both Azure Policy and Microsoft Endpoint Manager and say "what's the best approach, using these new capabilities, to meet my organizational requirements for managing my infrastructure now and into the future?". Sometimes a fresh pair of eyes instead of a direct translation, can lead to the best results.
To learn more:
Create and manage Azure Policy: https://docs.microsoft.com/azure/governance/policy/tutorials/create-and-manage?WT.mc_id=itopstalk-bl...
Create a custom policy definition: https://docs.microsoft.com/azure/governance/policy/tutorials/create-custom-policy-definition?WT.mc_i...
Azure Policy modules on Microsoft Learn: https://docs.microsoft.com/learn/browse/?products=azure-policy&WT.mc_id=itopstalk-blog-socuff
