This solution uses Ansible to deploy WUfB reports infrastructure for partitioning data and securing access using Azure RBAC. As an administrator you can define one or more scopes to indicate that records for a given Azure AD group of devices should be exported from the tenant workspace to a scoped workspace that can be secured using Azure RBAC.
The ansible folder of the project contains an Ansible playbook which, after configuration, can deploy the necessary infrastructure to your Azure tenant.
At the high-level, this includes the following resources:
- Azure resources
- Resource group to contain resources generated by the automation
- Azure Function triggered on an interval to perform periodic data export
- Log Analytics resources
- Log Analytics workspace for each scope
- Azure Monitor resources
- Data collection endpoint ingesting data
- Data collection rule for each scoped workspace to direct data routing
All access groups will use the same Azure Monitor Workbook. WUfB reports has been updated to provide a drop-down workspace chooser.
The user or service principal running the automation to deploy infrastructure should be an Azure subscription Owner to ensure necessary providers and resources can be enabled automatically.
- Aggregated delivery optimization status is not computed. Aggregated status is tenant-wide in the primary workspace and therefore scoped workspaces would need to compute the aggregate for their device set separately. The Azure Function doesn't yet perform that process.
- No support for nested Azure AD groups. Only direct group members are considered at present. Nested support could be added by modifying the Azure Function.
- The solution assumes a single subscription and target resource group. This may or may not be relevant for your tenant. Tenants that need greater control can extend the solution by modifying the Ansible project.
Before running the deployment, you must tailor the configuration to your tenant by copying ansible/host_vars/localhost.example to ansible/host_vars/localhost and then editing the values in the file.
---
# 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"| Parameter | Description |
|---|---|
| tenant_id | The GUID for your tenant. |
| subscription_id | The GUID for the subscription that resources will be created in. |
| scopes | This is a dictionary of the scopes you want to be created. 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 that data will be exported from. |
| primary_workspace_resource_group | The resource group containing the primary workspace. |
| target_resource_location | The Azure location or region to store created resources. |
| Parameter | Description |
|---|---|
| target_resource_group | The resource group to contain created resources. |
| target_resource_prefix | The resource prefix for all created resources. |
| function_app_storage_account_name | The globally unique name of the storage account for the function app. A portion of the tenant ID is also used to facilitate uniqueness. |
| function_app_max_days_to_sync | The maximum number of days to sync back in time when the function is executed. Values greater than 48 hours overwrite the TimeGenerated field at the target which could result in unusable data. |
| ansible_python_interpreter | Path to the Python interpreter to use when running Ansible. |
To install Ansible, see Ansible installation.
After Ansible is installed, ensure all requirements of the Azure Collection have been installed.
ansible-galaxy collection install azure.azcollection
pip install -r ~/.ansible/collections/ansible_collections/azure/azcollection/requirements-azure.txtIf you installed Ansible core, you will need to install the following additional collections:
Install the latest version of Node.js.
Install the Azure CLI.
Install the Azure Functions Core Tools.
npm i -g azure-functions-core-tools@4 --unsafe-perm truebrew tap azure/functions
brew install azure-functions-core-tools@4- For authentication with Azure you can pass parameters, set environment variables, use a profile stored in ~/.azure/credentials, or log in before you run your tasks or playbook with
az login. - Authentication is also possible using a service principal or Active Directory user.
- To authenticate via service principal, pass subscription_id, client_id, secret and tenant or set environment variables AZURE_SUBSCRIPTION_ID, AZURE_CLIENT_ID, AZURE_SECRET and AZURE_TENANT.
- To authenticate via Active Directory user, pass ad_user and password, or set AZURE_AD_USER and AZURE_PASSWORD in the environment.
- Alternatively, credentials can be stored in
~/.azure/credentials. This is an ini file containing a[default]section and the following keys: subscription_id, client_id, secret and tenant or subscription_id, ad_user and password. It is also possible to add additional profiles. Specify the profile by passing profile or setting AZURE_PROFILE in the environment.
See Authenticating with Azure for more information.
From the ansible folder, the following command will run the playbook to initiate deployment of infrastructure. You must have previously logged into Azure and also configured values for your tenant, including the target scopes, by modifying the localhost configuration file.
ansible-playbook -i inventory site.ymlSome organizations may wish to deploy the infrastructure in separate steps according to access role. Therefore, certain project tasks have been tagged, and Ansible allows for skipping or running a playbook with matching tags. The following commands can be used to run steps for each role individually.
After authenticating with a user that has Azure subscription Owner permissions, the following command will create necessary resources but will skip the Microsoft Graph authorization step which requires a different role.
ansible-playbook -i inventory site.yml --skip-tags "function_app_authorize_graph" After authenticating with a user that has Privileged Role Administrator or Global Administrator Azure AD roles, the following command will authorize the Azure Function to call the Microsoft Graph for enumerating device group membership.
You will need to replace <objectId> which you can obtain from the Azure Portal for the wufb-scope-connector Function App under its Function App > Settings > Identity > Object (principal) ID property.
ansible-playbook -i inventory site.yml --tags "function_app_authorize_graph" --extra-vars '{"scope_connector_identity":{"principalId": "<objectId>"}}'After the solution has been deployed, the Azure Function must be triggered once to export data from the primary workspace to the scoped workspaces.
Once the Log Analytics workspaces have data, users will be able to open the WUfB reports workbook to see data scoped to their access.
The planned experience is to provide a drop-down allowing users to change the active workspace used by the workbook by selecting from a list of available subscriptions and their workspaces.
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct.
For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines.
Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.
Any use of third-party trademarks or logos are subject to those third-party's policies.