There is often the need to create a Microsoft Entra ID (formerly Azure AD) group based on a local registry key or another attribute to make more specific access decisions, to use this group for access rights to an application or many other use cases. In this blog post I will show you how to do this with the help of Endpoint Analytics and Azure Automation. In my blog I show you how to do this with the example of device manufacturer; of course we already have this info in Intune, but it is just an example of how this works. Of course you can also do this with anything else you can read out on a client.
Automatic assignment groups are useful when app deployment should stay consistent without manually creating a new Microsoft Entra group every time an Intune app is added. The pattern works best when group names, app names, and assignment intent follow the same convention.
In production tenants I recommend validating the group creation flow with one pilot application first. Check the created group, verify the Intune assignment, and document the naming rule before you let automation create groups for a larger application catalogue.
When creating a new app in the Intune admin center and not assigning it to AllUsers/AllDevices, this is always some work to create your own group for available/required and uninstall assignments for each app. You know I love automation. To save time and automate this work I will describe in this blog how you can create a runbook that takes this work completely over.
Synchronizing an Azure AD group with a kiosk configuration profile is mainly about keeping the assignment target reliable. The group should clearly describe the kiosk scenario, the device ownership model, and the configuration profile it belongs to.
Before using the approach in production, validate the group membership, profile assignment, and device check-in behavior on a small number of test devices. This makes it easier to separate assignment problems from kiosk shell or application configuration problems.
I have already described in a previous blog how to deploy a device as a kiosk device using Intune. This actually works really well. There is only one small thing that is really inconvenient. If a Microsoft Entra ID (formerly Azure AD) user or group is selected as the logon type (only specific users are allowed to log on to these devices), this policy must not only be assigned to a group, but the allowed users must also be defined in the profile. The option also allows you to add Microsoft Entra ID users and groups, and the SIDs of these objects are written to the local group, but Windows cannot resolve the Microsoft Entra ID groups (bug or feature?). The resolution of whether the user who is trying to log in is a member of one of the groups is done by Windows via Graph; when MFA is disabled, it works. But if MFA is enabled, Windows fails to get the token. In this blog I want to show you how you can easily work around this by syncing a Microsoft Entra ID group with this configuration profile.
