Fido2 key and their issues using them on Android
First, do Android support using Fido2 keys on Android? Yes, it does support both using bluetooth, NFC and USB authentication. For reference: https://developers.google.com/identity/fido/android/native-apps But does it mean that it is straight forward to use it in a enterprise environment without hiccups? No, the support lacks many features that both Windows and iOS has supported for long time. If I buy a modern Fido2 with OTP support, will it work straight out of the box for using the USB? No, you need to disable the OTP support first. Here is how you can do that from yubikey manager, this works for Yubikey. Other vendors might have something similar. But for Fido2 keys without OTP support, it should work out of the box for USB-C, like Google titan. Why this happens, dont know. Can we use NFC for Entra ID authentication like we can on Windows and iOS? No. Android does not currently support CTAP2 for NFC, only for USB-C input. CTAP1 (FIDO U2F) supports certificate based authentication, but CTAP supports user verification with PIN and biometrics. Entra ID requires UV (user verification) before accepting login. As far as I know, there is also support for bluetooth. But I dont have any fido2 keys that support bluetooth yet. So why does this matter? With Android you can have shared devices with secure login for multiple users with a single log in for all supported apps, auto log off and many other possibilities. https://learn.microsoft.com/en-us/entra/identity-platform/msal-shared-devices Other sources/discussions: https://www.reddit.com/r/yubikey/comments/1oncuh2/whats_the_point_of_nfc_on_android/ https://www.reddit.com/r/yubikey/comments/13tlzoc/fido2_inconsistent_across_windowsandroid/ https://fidoalliance.org/specifications/Widgets on COPE - MS Intune
Hey, Unfortunately there are no settings and/or no chance configure Widgets on COPE in MS Intune. There is specific setting in Intune restrictions config profile to allow/disallow Widgets for BYOD method. Is this problem tied only MS Intune or is this something for Google? Majority of our 10k fleet enrolled as COPE and it's a big gap not having widgets available for Work Apps. Thanks Jarmo
SCEP Certificate Fails with Multiple Root CAs on COPE/COBO (Works on BYOD)
Hi everyone, We're running into a certificate issue with our Android Enterprise deployment and hoping someone here has encountered something similar or can point us in the right direction. We're using Microsoft Intune as our MDM solution with COPE and COBO enrolled devices. This affects all Android devices regardless of manufacturer, including Google Pixel devices running Android 16 with the latest security patch. The devices use SCEP certificates for Wi-Fi authentication. In early September, we rolled out new Root CAs via Intune. These new Root CAs are used for creating SCEP profiles for Wi-Fi authentication. The devices now have both the old, still valid Root CA and the new Root CA installed. The problem occurs when a device tries to obtain a new SCEP certificate issued by the new Root CA. In this case, the Android device attempts to verify the certificate chain using the old Root CA, which fails because the certificate was issued by the new Root CA. As soon as the old Root CA is removed from the device via MDM, the certificate verification works as expected. Interestingly, the entire process works without any problems on Android devices with personal enrollment (BYOD). We've tested creating a new SCEP profile, but unfortunately that didn't help. Only removing the old Root CA solved the problem. The issue now also occurs with BYOD devices as well. Has anyone dealt with a similar situation during a Root CA migration on Android Enterprise devices? We're trying to understand why COPE and COBO devices behave differently than BYOD devices in this scenario, and whether there's a configuration we're missing that would allow both Root CAs to coexist properly during our transition period. Thanks in advance for any help you can provide.
Intune - Swapping Managed Google Play Account with Devices enrolled in Device Administrator and AOSP
Hi All, My Intune environment is connected with an old-school gmail.com account - i access the managed store page by going to https://play.google.com/work to approved apps / etc. - This was an old solution that saw little to no use. We're now looking at requiring Intune enrollment on our android devices and it'll get a ton of use once we do that. I'd like to upgrade my account to an Android Enterprise account, but it looks like to do that I'll need to disconnect the Managed Google Play account from Intune. My understanding is that I will need to un-enroll all my android devices from the tenant before doing that. For personally owned devices with work profiles, that's not a problem - we only have 3 PoC users that I can unenroll. The only other two enrollment options we use are Device Administrator (For Yealink teams phones...) and AOSP (For.. newer.. Yealink teams phones). Will disconnecting Managed Google Play affect the enrollment of Device Administrator or AOSP? Thanks!Issues Intune and okta enrollment
Hi all, I could use some help or guidance from someone who has experience with using Okta as IDP and Intune as MDM. The problem: When going trough enrollment (COPE), the Intune login page shows up. When entering the email, it forwards to Okta as it should. But after verifying with Okta, you should get back to a Microsoft confirmation but instead it shows a page not found error. It used to work, nothing has changed as far as we know and the issue is present on devices ranging from Android 13 to 15, different brands but mostly Samsung. Apple and Windows enrollment work as expected, no issues there. I can't find any related logging details in Intune and lack the knowledge of Okta (will add a support ticket there as well). So i'm kind of lost as to what is happening. Where do I need to look for the return URL for example? There are multiple Azure enterprise apps but i'm not sure which one to check and don't want to mess to much with this. Thanks!
ANDROID 15: Problem with unlock code expiry in COPE mode
Hello, Our users' Samsung smartphones are enrolled in Intune in COPE mode. We have a configuration profile that requires a device unlock code with an expiration time. We haven't configured a code for the work profile, so the One Lock setting is enabled by default. In Android 15, following the expiration of the unlock code, the user is now required to change the unlock code. However, once they do so, when they launch an app in the work profile, the smartphone also asks them to change the work profile code. I don't understand why the smartphone is asking to change the work profile code when the One Lock setting is enabled. Is anyone else having the same problem? Benjamin
Android Enterprise work profile does not support wearOS yet
Hi, We recently moved to android enterprise with work profile (using Intune) for all of our android users. And we just found out that with android enterprise with work profile does not support wearOS yet so that our users cannot add their corporate email account (O365) to the outlook app on their samsung watch or pixel watch. we tried to contact microsoft about this and microsoft said that this is not up to Microsoft but it is up to Google Android whether they would like to support wearOS for work profile. Can Google confirm if they would like to provide some support for work profile in the future for wearOS as well? I know that any development of newly feature in android system are fully confidential but it would be good for android end users to know if Google has a plan to support this in the future or not.
Tenant has been unbound from Google Play console (Intune)
Hey @Community, we have a strange issue with out MDM (Intune) - It seems like, the link between Intune and Google has broken. Trying to enroll new devices are failing with "Invalid code". Trying to add new applications via "Managed Google Play" fails also with the message "Tenant has been unbound from Google Play console". Intune-Support says, that we need to contact Google, but there is no option for creating a case. So we decided to write you here (and hopefully you can help us ;) ). We still have the access to the used Google-Account.
