jrngsg , App filters are different, you need to create them in addition to what you already have for devices.
Ramya_Chitrakar , here are results of my investigation for app filters:
- Intune admin center provides the wrong selection for filter rules for iOS. app.deviceManagementType can only have values of "Unmanaged" or "MDM", but what it offers from the dropdown is "Unmanaged" and "Managed". If you go with what is offered for "Managed", you are going to be lost. Manually editing and overruling the GUI to use "MDM" instead does the trick.
- Intune admin center is broken to offer selections of "Unmanaged" and "Managed" when editing App Protection Policies. It is greyed out and none can be selected. That makes editing of APP a problem and even more if you follow the suggestion from this article to change to filters instead of using the Device Type restriction of the policy itself (at least, if you hadn't resolved the problem from no.1 just yet). If you had lost the Device Type restriction for whatever reason, the only way to get this back into place is using Microsoft Graph API. That worked fine for us here but is not the level of quality you expect when such new function goes live and is even rolled out in waves (who does the testing, like nobody?).
I was also hoping to get more properties to filter App Protection Policies for specific groups of managed devices. For example, I need to be able to distinguish between User-Enrolled iOS devices and Supervised iOS devices to assign different App Protection Policies. I still can't do this with the new app filters, making them unimportant for me to use. For managed devices, it should be possible for app filters to also rely on information from the device enrollment (e.g. device.enrollmentProfileName, device.deviceOwnership). I understand that this information is not available for unmanaged devices for obvious reasons, but when a device is known to be managed, this information is available in Intune already.
Additions about Apple Account Driven User Enrollment (Just-In-Time Enrollment)
- When enrolling a device using Apple Account Driven User Enrollment, the enrollment profile name is no longer stored to the device object and left empty.
That means that existing policies who rely on that data (e.g. when using filters with device.enrollmentProfileName) will not be assigned to the new device. That is very annoying for compliance policies in particular if you want granular control (like not a compliance policy for all Personal devices, but be more selective how they came into the system). - UX is not as good as with Company Portal, it actually requires 3 logins instead of 2 with Company Portal. The promise of one single sign-in for the UX is not kept yet.
The initial authentication is okay to receive the initial PRT / login credentials. However, these credentials are not accepted when the Managed Apple ID wants to login with their federated account, ending up with another login prompt. It least, CA is not happy to fulfill MFA at this point so it asks again for validation.
It seems that the PRT that the Setup Assistant / Settings app receives is also not forwarded to the Authenticator app (yet). As a result, after the enrollment, the Authenticator app is empty and the accounts needs to be added manually, including authentication.
Apples documentation about Account Driven User Enrollment states that the MDM can define one single app to be provisioned right during and/or after the enrollment. I suppose it receives the access token for further processing and that this app shall be the Microsoft Authenticator app. However, by assigning the Microsoft Authenticator app as just any other app in Intune, this requirement from Apple is not fulfilled and will not provide the experience we expect.
Last, but not least: There is currently no good solution when the Authenticator app switches between personal and business context. That means by unenrolling the device, the Microsoft Authenticator app suddenly gets removed from the device (even though I had configure it differently in the Intune portal, but that settings seems to be overruled internally). This potentially leaves the user with no authentication methods and s/he has to call Service Desk for assisting with the recovery. Not good!
In case the user had installed the Authenticator app before (or it wasn't pulled after unenrolling the device, as one would assume), this app is not transferred to the business context during user enrollment. The user is not prompted to confirm the transfer and the Authenticator app just stays in user context. That might be okay but again, I wonder how this would work with what Apple has in their design for the MDM to designate a single broker app during the enrollment process.
I know this is a Public Preview and it is in Development. Still, kind of sad there was no information about the missing pieces.
Microsoft