Android 15 - CredentialProviderPolicy not surfaced by Intune
I have been having an issue with Android 15 devices. We use Authenticator as our password autofill provider. As soon as a device is updated from Android 14 to Android 15, the password autofill provider is no longer set and the setting to change it is 'blocked by work policy.' I have already tried removing all policies that apply to the devices (device config and device compliance policies) and factory resetting them. Simply having them enrolled as corporate owned fully managed devices causes this to happen. I raised the issue in the Android Enterprise community blog. A link to that is included below. Someone on that thread found that there is a policy in Android 14/15 called the credentialproviderpolicy. When that policy is blocked or unconfigured, this behavior happens. I cannot find anywhere in Intune where I can set this policy. It seems that it is allowed by default when managing Android 14 with Intune, but not set or blocked when the device switches to Android 15. Is there any way to specifically set a policy that is not reflected in the Intune UI? This is a blocker for being able to move more phones to Android 15. Link to Android Enterprise thread: https://www.androidenterprise.community/t5/admin-discussions/android-15-cannot-set-default-password-app/m-p/8827#M2105 Thanks, Tom
SSID connection using intune pushed profile kept prompting manual login
Hi, anyone encountered an issue where users connecting to an SSID with 802.1X authentication using an Intune-pushed Wi-Fi profile (with credential caching enabled) are still being prompted to enter their credentials manually? However, it works fine by configuring the network connection protocol manually. Thank you.Which Entra account are you supposed to use to connect to a managed Google Play account?
At Connect Intune account to managed Google Play account - Microsoft Intune | Microsoft Learn, it says: We recommend using the Microsoft Entra account you're signed into to create the Google Admin account. So I used my Entra account to set it up. Now, though, when I look at the Managed Google Play item in Intune under Devices > Android > Enrollment, it has my email address under "Linked account". Was I supposed to create a shared Entra account to make this connection? What happens when I leave the org?
Platform SSO "Page not found" on macOS Tahoe 26.4 — Company Portal 5.2602
Environment: macOS Tahoe 26.4 Company Portal 5.2602.0 (latest as of April 2026) Microsoft Intune — Automated Device Enrollment (ADE) Platform SSO with Secure Enclave (UserSecureEnclaveKey) SSO Extension: com.microsoft.CompanyPortalMac.ssoextension / Team ID: UBF8T346G9 URLs configured: https://login.microsoftonline.com, https://login.microsoft.com, https://sts.windows.net Device: MacBook Pro 14" (Apple Silicon), supervised, ADE-enrolled Issue: During Platform SSO registration, after the user authenticates successfully in the SSO registration prompt, Company Portal crashes with a "Page not found" error. The registration never completes — no WPJ certificate is created, no SSO registration key is stored in the Secure Enclave. Console logs show: CompanyPortalMac: URL(filePath:) API misuse — usingass old file path API which does not support security scoped bookmarks The error occurs specifically at the token exchange step after authentication, suggesting the Company Portal binary is calling a deprecated macOS file URL API that Tahoe 26.4 now enforces more strictly. What we tried: Full wipe and re-enrollment via ADE Removing and reinstalling Company Portal via Intune Different user accounts Verified SSO extension profile is correctly applied (confirmed via profiles show -type configuration) Verified network connectivity to Microsoft identity endpoints Tested on a clean macOS Tahoe 26.4 install — same result Expected behavior: Platform SSO registration completes, WPJ certificate is created, and SSO token is cached for seamless authentication. Actual behavior: "Page not found" after authentication in the SSO registration flow. Console shows the URL(filePath:) API misuse warning. Registration fails silently — no error surfaced to the user beyond the page not found screen. Question: Is this a known bug in Company Portal 5.2602 with macOS Tahoe 26.4? Is there a newer build or hotfix addressing the URL(filePath:) deprecation? Any workaround available? Tags: Platform SSO, macOS, Company Portal, ADE, IntuneHybrid Azure AD joined device not enrolling into Intune
Issue A Windows device successfully registers in Entra ID (Hybrid Azure AD join) but never enrolls into Intune. Result: Device appears in Entra ID Device does not appear in Intune Intune Management Extension is not installed Device remains SCCM‑only (co‑management never starts) Log (CoManagementHandler.log): EnrollmentUrl = (null) Device is not MDM enrolled yet. All workloads are managed by SCCM. Environment Windows 10/11 Hybrid Azure AD Join On‑prem AD + MECM (Cloud Attach / Co‑management enabled) Microsoft 365 E3 (Intune license assigned) Device on corporate trusted network What I’ve done Verified Azure AD join and MDM URL Confirmed MDM user scope = All Verified Intune enrollment restrictions allow Windows Verified user has Intune license Identified Conditional Access policy targeting “Register or join devices” Updated that CA policy to Exclude → Microsoft Intune Enrollment Waited for replication and retried enrollment (deviceenroller.exe /c /AutoEnrollMDM) Question Despite excluding Microsoft Intune Enrollment, the device still does not enroll into Intune.Windows Autopilot Hybrid Join failing with OOBE error 80004005
Hello everyone, We’re facing a consistent issue with Windows Autopilot user‑driven Microsoft Entra hybrid join where devices are provisioned using a Hybrid Join Autopilot profile, but Hybrid Join does not complete. Setup (High level) Windows Autopilot (user‑driven) Autopilot profile: Microsoft Entra hybrid joined Only one Autopilot profile Domain Join profile configured (domain + OU) Entra Connect: Hybrid Join + device writeback enabled Intune Connector for Active Directory installed and healthy MDM auto‑enrollment enabled Issue During Autopilot OOBE, the device frequently shows: “Something went wrong” Error code: 80004005 Despite this, Autopilot continues and completes. Resulting Device State After provisioning: Device appears in Entra ID as Microsoft Entra joined (not Hybrid) Device is enrolled into Intune and shows compliant Device‑scoped Intune MDM policies do not apply dsregcmd confirms Hybrid Join never completed Understanding So Far From correlating the OOBE error, dsregcmd output, and final device state: Hybrid Join starts but fails mid‑process Windows does not roll back provisioning Device falls back to Entra ID Join Join type is finalized for that run Resetting without fixing the root cause repeats the behavior This explains why devices look healthy but are not Hybrid Joined and why device‑based policies don’t reflect. Questions Is 80004005 during Autopilot OOBE a known indicator of Hybrid Join / Offline Domain Join failure? Is fallback from Hybrid Join → Entra ID Join expected when Hybrid Join prerequisites fail? Once a device ends up Entra joined, is wipe + reprovision the only supported recovery after fixing the root cause? Public Wi‑Fi / offsite scenario: Has anyone successfully completed Hybrid Autopilot using pre‑logon VPN / device tunnel (Always On VPN, GlobalProtect, AnyConnect, etc.) to provide DC line‑of‑sight? Which logs are most useful to confirm the exact failure point (ODJ, dsreg, Intune Connector, ESP)? Thanks in advance for any insights or field experience.
Intune enroll on redhat 10 KDE
**intune-portal 1.2603.31 fails to authenticate on RHEL 10 KDE Plasma — Misconfiguration(0) in gtk4/actions.rs** **Environment** - OS: Red Hat Enterprise Linux 10 - Desktop: KDE Plasma (Wayland, XDG_SESSION_DESKTOP=plasma) - intune-portal: 1.2603.31-1.el10.x86_64 - microsoft-identity-broker: 3.0.1-1.el10.x86_64 - xdg-desktop-portal-kde: 6.4.5-1.el10_1.x86_64 - webkitgtk6.0: 2.50.4-2.el10_1.x86_64 **Summary** The Intune portal fails to complete authentication on KDE Plasma. The same machine, same user account, and same tenant works correctly under GNOME on the same RHEL 10 install. The only difference between the working and non-working sessions is XDG_SESSION_DESKTOP (gnome vs plasma). **Error** The portal throws the following Rust error when attempting to start a login: ``` [intune-portal/src/gtk4/actions.rs:103:29] e = Error { context: "Starting a new login", source: Misconfiguration( 0, ), } ``` The OneAuth logs show: - `No accounts found in the OneAuth account store` - `Auth params authority is empty` - `MATS device telemetry disabled` This results in a [4kv4v] error in the Microsoft auth window with Code: 0. **Additional findings during investigation** 1. On RHEL 10, the KDE portal service is named `plasma-xdg-desktop-portal-kde.service` rather than the expected `xdg-desktop-portal-kde.service`. This means it is not auto-discovered without explicitly starting it, which is a secondary issue. 2. Overriding `XDG_SESSION_DESKTOP=gnome` at launch does not resolve the Misconfiguration(0) error, suggesting the portal reads the session desktop variable at startup rather than at auth time. 3. The auth flow reaches the broker, the broker starts MSAL, but the portal fails to pass authority parameters, so the login flow never presents a credential prompt to the user. **Steps to reproduce** 1. Install intune-portal 1.2603.31 on RHEL 10 2. Log into a KDE Plasma Wayland session 3. Launch intune-portal and attempt to sign in 4. Observe Misconfiguration(0) error — no login prompt is shown 5. Log out, log into GNOME on the same machine 6. Launch intune-portal — authentication completes successfully **Expected behaviour** Authentication should work on KDE Plasma in the same way it does on GNOME. **Workaround** None found. Using GNOME is the only current option on this machine.
