Since launching Windows Update for Business reports, you've asked for richer control over your data. We're excited to announce the preview of more flexible data routing and access controls, as well as new regions for data storage. Make it easier to monitor update compliance by routing data for Azure AD device groups to different Log Analytics workspaces and securing them using Azure role-based access control (RBAC). Let's see how!
When you enable Windows Update for Business reports, all data for all devices in your tenant is routed to a single Log Analytics workspace. That begins when you do one of the following:
But what if you have a subset of your tenant devices that you want to periodically report on or that you want to control access to?
You need a way to separate those devices into their own workspace and then optionally apply different access controls to each.
Note: You might already know that in Azure role-based access control (RBAC), resource access is controlled by creating a role assignment, which consists of 3 elements:
This means that given a group of users (security principal), you can secure their access to a workspace (scope) by assigning the built-in Log Analytics Reader role or equivalent custom role (role definition). |
Using our Ansible solution on GitHub, currently in preview, you can route data for various device groups to different Log Analytics workspaces and then grant different report readers access to each. Traditionally, you could use the Azure portal to do this, but we've automated it for you!
Let's jump right into increasing your control over who can see which device data while enabling report owners to focus on only what's important to their area of responsibility.
How can you route data from the tenant's primary workspace into separate secured workspaces for each access control scope? You'll do so by routing data for Azure AD device groups to different Log Analytics workspaces. Let's walk through the following seven steps from defining scopes to using the Ansible solution to deploy infrastructure for populating the Windows Update for Business reports.
The first step is to define the list of scopes you need by creating Azure AD groups. Let's look at some examples where we divide the tenant into two distinct operational scopes: Contoso and Fabrikam.
Once you know how you want to partition devices within your tenant into scopes, use the Azure portal to create security groups containing these devices.
You can learn more at Manage Active Directory groups and group membership.
Note: Nested groups are not currently supported, but the source code to the Ansible solution is provided should you want to extend with this capability. |
We'll be using automation to group resources, partition data to different workspaces, and control access across these resources.
All the created workspaces will be added under a single Windows Update for Business reports resource group, and we must be careful to ensure that users are only granted read access to the specific workspace matching their authorized scope. Use the Azure portal to create this resource group, or one will be created for you automatically when you run the deployment solution using Ansible.
Azure resource tags are used to mark workspaces for data routing, so you wouldn't want unauthorized users to modify these. When assigning access to a workspace directly or through inheritance from the resource group or subscription, common roles and permissions may be too permissive. To mitigate this, here are our recommendations for access control within the target resource group:
You can learn more about how to Manage access to Log Analytics workspaces and about permissions required to manage tags in the Use tags guide.
At this point, you're ready to download and use the Ansible solution on GitHub to deploy the necessary infrastructure to your tenant for data partitioning.
After cloning or downloading the repository, follow the instructions in the README on your control node or workstation to:
Before running the deployment, you must tailor the configuration to your tenant by copying ansible/host_vars/localhost.example to ansible/host_vars/localhost.
---
# Required configuration
## Tenant info
tenant_id: <guid>
subscription_id: <guid>
## Define access scopes and associated Azure AD group (identified by objectId)
scopes:
contoso:
azure_ad_group_id: <guid>
fabrikam:
azure_ad_group_id: <guid>
## Properties for the primary workspace to be used as input for data transformations
primary_workspace_name: <name>
primary_workspace_resource_group: <resource_group>
## All resources will be deployed to this location (e.g. westus2)
target_resource_location: <location>
# Optional configuration
## All resources will be created under this group
target_resource_group: wufb-reports-access-control
## All resources will use this prefix and will be suffixed by the
## playbook with a resource type or scope.
target_resource_prefix: wufb-reports-
## Storage account for function app
function_app_storage_account_name: wufbreportsscopes
## Maximum number of days to sync.
## Not currently recommended to increase beyond 2 because LA overwrites TimeGenerated if > 48 hours.
function_app_max_days_to_sync: 2
# Python 3.11 has breaking changes to the `inspect`` module. Use 3.10 for now.
ansible_python_interpreter: "/usr/local/bin/python3.10"
Then edit the values in the file. In particular, you'll want to update the following required parameters.
Parameter |
Description |
tenant_id |
The GUID for your tenant. |
subscription_id |
The GUID for the subscription in which resources will be created. |
scopes |
This is a dictionary of the scopes you want to create. Each named scope is associated with the directory ID of an Azure AD group containing a list of devices included within the scope. Nested groups are not currently supported. |
primary_workspace_name |
This is the primary workspace containing all data for the tenant from which that data will be exported. |
primary_workspace_resource_group |
The resource group containing the primary workspace. |
target_resource_location |
The Azure location or region to store created resources. |
After configuration, you're ready to use the Ansible solution to automate the deployment of infrastructure to Azure. Here's how:
ansible-playbook -i inventory site.yml
After the solution has been deployed, the Azure Function must be triggered once to export data from the primary workspace to the scoped workspaces. This should happen automatically, but you can also trigger it manually through the Azure Portal if needed.
Once the Log Analytics workspaces have data, users will be able to open the Windows Update for Business reports workbook to see data scoped to their access. Each scoped workspace can be selected using the drop-down menu at the top of the report page, as illustrated next.
Since this feature is in preview, you'll need to use the preview URL for the Windows Update for Business reports workbook. From the preview workbook list, scroll to the bottom and locate Windows Update for Business reports. You're done!
Now you have more power to partition and control access to your data with Windows Update for Business reports, as well as to host it in an expanded set of regions.
Check out our discussion board post for more details on the architecture, pricing structure, and some current limitations of this solution.
If you have any feedback or questions regarding the Ansible solution on GitHub, please feel free to open project issues for support or reach out through our other Windows Update for Business reports support options.
Continue the conversation. Find best practices. Bookmark the Windows Tech Community and follow us @MSWindowsITPro on Twitter. Looking for support? Visit Windows on Microsoft Q&A.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.