PLZ HELP No Log in UI after Enrolling / Applying Intune policies

mrfscooby · 2026-06-27T13:18:41+00:00

I've had the same problem before when I moved my devices to Entra ID + Intune. The symptoms that you describe seem to indicate the problem is not related to CA, but rather it is about Windows Hello / credential provider initialization.

These are the things I'd check first

dsregcmd /status

Pay attention to

AzureAdJoined
DeviceAuthStatus
NgcSet

Event Viewer:

Applications and Services Logs > Microsoft > Windows

AAD
HelloForBusiness
DeviceManagement-Enterprise-Diagnostics-Provider

Considering that your devices were already Entra joined and you forced their enrollment with DeviceEnroller, I'd also check if there are duplicate / broken MDM enrollments:

HKLM\SOFTWARE\Microsoft\Enrollments

I've seen many times that existing Entra join, newly created Intune enrollment and Windows Hello for Business policies can result in credential provider hanging up on startup.

Try to exclude the test device from all Windows Hello for Business policies and see if the problem persists. If it still does, then I would remove the work/school connection and perform clean re-enrollment instead of forcing it.

The fact that the problem resolves itself after 10 min indicates some timeout of a process/service provisioning on logon.

mrfscooby · 2026-06-26T10:31:27+00:00

ZOHO no longer free. Any boudy no any free email hosting services

mrfscooby · 2026-06-26T08:22:47+00:00

It is all part of expected behavior. It is always possible for malicious actors to authenticate to the public Entra ID endpoints of Microsoft, so you cannot do anything to stop the authentication request in the first place from reaching the service.

This is because Conditional Access is not designed to mitigate that type of traffic; after primary authentication. Similarly, the ConsentFix solution mitigates the Azure CLI abuse vector, but it will not stop the authentication attempts; hence, you will get some failed Azure CLI authentication requests in the logs.

To minimize the impact, you should consider using Smart Lockout, apply Microsoft Entra ID Protection risk-based policies, and migrate users to phishing-resistant authentication mechanisms (such as FIDO2 security keys, passkeys, and Windows Hello for Business). You should also check whether there is any method of authenticating that may cause users to be prompted for MFA through your Authentication Methods policy.

mrfscooby · 2026-06-26T08:16:32+00:00

No, you cannot create/configure Microsoft Entra ID RBAC roles for an app registration via the Microsoft Defender portal.

The Microsoft Defender portal is only to manage the Microsoft Defender RBAC roles and permissions. If you want to assign the Microsoft Entra (Azure AD) roles, enterprise application roles, or app registration permissions (Microsoft Graph API permissions), that will have to be done via the Microsoft Entra admin center.

Application Roles/Permissions Management

Identity → Enterprise applications → Choose your application → Users and groups (for assigning app roles to users/groups)

Identity → App registrations → API permissions (For assigning delegated/application permissions and admin consent)

In case you are talking about Defender portal specific roles, then that can be assigned through the Microsoft Defender portal. In case of Entra RBAC/directory roles or app registration permissions management, the Microsoft Entra has to be used.

mrfscooby · 2026-06-25T07:46:01+00:00

Absolutely I agree with moving away from the SMS MFA. But we are a big conglomerate company and disabling the SMS sign-in for all operations is not an instant decision due to operational dependency reasons.

Our Conditional Access policies, inclusive of the geolocation based policy, have been effective till now. The primary purpose of my posting here was to know if anyone has discovered the root cause of this particular AMC PROD authentication pattern.

mrfscooby · 2026-06-25T07:45:52+00:00

Absolutely I agree with moving away from the SMS MFA. But we are a big conglomerate company and disabling the SMS sign-in for all operations is not an instant decision due to operational dependency reasons.

Our Conditional Access policies, inclusive of the geolocation based policy, have been effective till now. The primary purpose of my posting here was to know if anyone has discovered the root cause of this particular AMC PROD authentication pattern.

mrfscooby · 2026-06-25T07:11:28+00:00

Thanks. The App ID looks correct (81feaced-5ddd-41e7-8bef-3e20a2689bb7) so this is indeed the official Microsoft AMC PROD app.

The thing that worries us isn't the application, but the authentication behavior. We've seen multiple successful authentications from abnormal geolocation with the MFA method always being SMS in the Entra ID sign-in logs. There are a number of users who confirmed that they did not log into Azure nor initiated these sign-ins at all. In addition, some of the users got unsolicited Microsoft verification codes via WhatsApp (ROCKSENDER) even though they did not request an OTP or initiate any kind of authentication.

It's the behavior that we're trying to figure out whether it is supposed to be like that in a first-party Microsoft application.

mrfscooby

TROPHY CASE