'Microsoft App Access Panel' and Conditional Access with SSPR combined registration bug
Currently, enabling self-service password reset (SSPR) registration enforcement causes the app 'Microsoft App Access Panel' to be added to the login flow of users who have SSPR enabled. This app is not able to be excluded from Conditional Access (CA) polices and is caught by 'All cloud apps', which breaks secure zero-trust scenarios and CA policy configurations. Best way to demonstrate this is through examples... ----Example 1---- Environment: CA Policy 1 - 'All cloud apps' requiring hybrid/compliant device, but excluding [App] (for all non-guest accounts) CA Policy 2 - [App] requiring MFA only (for contractor accounts, etc) CA Policy 3 - [App] requiring hybrid/compliant device (for internal accounts, etc) SSPR registration enforcement (Password reset > Registration) - set to 'Yes' MFA registration enforcement (Security > Authentication Methods > Registration campaign) - set to 'Enabled' Scenario: A new user requires access to web [App] on an unenrolled device and is assigned an account that falls under CA Policy 1 and 2, however [App] is excluded from 1 and shouldn't apply to this login. When accessing [App] for the first time, users must register SSPR/MFA. They see the below message, click 'Next' and are directed tohttps://accounts.activedirectory.windowsazure.com/passwordreset/register.aspx: Then they see this screen, which will block the login and try to get the user to download the Company Portal app: While behind the scenes, the login to [App] is being blocked by 'Microsoft App Access Panel' because it is seemingly added to the login flow and caught in CA Policy 1 in Req 2/3: CA Policy 1 shows as not applied on Req 1, CA Policy 2 shows as successful for Req 1/2/3 and CA Policy 3 shows as not applied for Req 1/2/3. Creating a CA policy for the 'Register security information' user action has no effect on this scenario and also shows as not applied on all the related sign-in logs. ----Example 2---- Environment: Same as above, but SSPR registration enforcement - set to 'No' Scenario: Same as above, but when accessing the [App] for the first time, they see the below message instead, click 'Next' and are directed to https://accounts.activedirectory.windowsazure.com/proofup.aspx: Then they are directed to the combined SSPR/MFA registration experience successfully: The 'Microsoft App Access Panel' doesn't show in the sign-in logs and the sign-in is successful after registration. From the two examples, it seems to be a bug with the SSPR registration enforcement and the combined registration experience. ----Workarounds---- 1 - Prevent using 'All cloud apps' with device based CA policies (difficult, requires redesigning/thinking/testing policies, could introduce new gaps, etc) 2 - Turn off SSPR registration enforcement and turn on MFA registration enforcement like in example 2 (easy, but only enforces MS MFA App registration, doesn't seem to re-trigger registration if the MS MFA App is removed, no other methods are supported for registration, and doesn't remind users to update) 3 - Disable SSPR entirely for affected users (medium depending on available security groups, and doesn't allow for affected users to use SSPR) ----Related links---- Be able to exclude Microsoft App Access Panel from Conditional Access · Community (azure.com) Support conditional access for MyApps.microsoft.com · Community (azure.com) Conditional Access Policies, Guest Access and the "Microsoft Invitation Acceptance Portal" - Microsoft Community Hub MS, please either: 1 - Allow 'Microsoft App Access Panel' to be added to CA policies so it can be excluded 2 - Prevent 'Microsoft App Access Panel' from showing up in the CA login flow when SSPR registration enforcement is enabledPasswordless app notification not pushing into iOS notifications (app must be opened manually)
When switching to passwordless authentication, the Microsoft authenticator app does not generate a push notification in the iOS notification center. When I open the Microsoft authenticator app, the number matching prompt is displayed, so the sign-in works as expected, but I don't get a push notification from the app. The strange thing is, when I disable the passwordless method, and fallback to password + push notification with number matching, then the Microsoft authenticator generates the push notification in the iOS notification center. How could I troubleshoot that issue?
OTP Code via SMS from non microsoft number
Hi Microsoft Team, Good day! For a few weeks now, many people around me have been receiving their OTP code for MFA via SMS often from unknown senders (non-Microsoft phone number). The sender of the SMS doesn't use an official Microsoft phone number and "Microsoft" is not displayed as the sender. I would like to request assistance on how to verify that these numbers are legitimately from Microsoft. 41 79 998 76 61 and 4915758307532. Many thanks for your help. Kind regards, Rosine
Enable MFA for external idetnities in MS Entra
Hi all, I am planning to enable MFA for guest accounts and external identities using Conditional Access in MS Entra. I am however wondering how I can select what Authentication methods can they use - or what would be the default behaviour. Currently, I am still using legacy MFA for internal users. I will migrate MFA to MS Entra later this year however, not sure how this is working when enabling MFA for external users. As I do use legacy MFA, my setting in " Authentication methods > Policies" have MS Authenticator set to NO. Now, do I need to switch MS Authenticator to YES if I want guests to use that app? And if I enable it, how do I assign it to External identities only? I do not see that kind of option there at all... I can assign it to all, for example, but I am not yet ready to migrate internal users as well... Would be happy to get some clarification on this. Thank youDouble entries in userCertificate avoids Hybrid Join
Hey guys, I have an interesting situation at a customer. He utilizes a third party MFA provider while being on a federation. That means new computers never will have a registered state. For users it is mandatory that theirs clients have fulfilled the Hybrid Join to use M365 apps, what can be a real pain. So the Automatic-Device-Join task has to create the userCertificate on the OnPremises computer object, before it can be synchronized to Entra. Here comes the issue. In some cases we see that some computers will create two userCertificate entries. This situation will lead to an inconstistent Hybrid Join. I already tried to remove one of the certificates, but for me it is impossible to recognize which is the right one. Only solution for me was to remove both entries under userCertificate and let the Automatic-Device-Join task create a new one. Afterwards the Hybrid Join will work. I want to understand, which process or scenario might create the double userCertificate entries?
Phishing resistant MFA options for Entra ID Guest users
What are the phishing resistant MFA options for Entra ID B2B guest users who authenticate from an IDP that is not configured for inbound cross tenant trust? From our testing, there does not appear to be any way to use fido2/passwordless/certificate-based authentication with the guest account on the resource tenant. The following links appear to indicate that this is not supported. Overview of custom authentication strengths and advanced options for FIDO2 security keys and certificate-based authentication in Microsoft Entra ID - Microsoft Entra ID | Microsoft Learn Microsoft Entra passwordless sign-in - Microsoft Entra ID | Microsoft Learn When we enable MFA requirements in conditional access policy for Guest users, the only option that seems to work is MS Authenticator which the user can enroll for on our tenant. Would switching the account from a B2B guest to an internal Guest allow something like CBA to function or is the only real option to enable cross tenant trust and force the user to enable MFA on the account in their home IDP?Microsoft seems to be obliging its 0365 customers to use the Microsoft MFA from October 15, 2024
https://workingtogether.fun/2024/08/27/microsoft-semble-obliger-ses-clients-0365-dutiliser-le-mfa-microsoft-a-compter-du-15-octobre-2025/ If you’re a Tenant Office 365 administrator, you must have received this kind of message warning you that MFA activation for all users will be mandatory from October 15, 2024 or, if you’ve postponed it, from March 15, 2025. This MFa will be required for all users needing to access the following resources (the Azure portal, Microsoft Entra admin center, and Intune admin center) Personally, I’m in favor of this for obvious security reasons. However, activating MFA for all users implicitly means asking them to use either their personal email addresses, or to install an authentication application (Microsoft Authenticator or Google Authenticator) on their phone (business or personal), or even to enter their phone number (business or personal) to receive the SMS. This obviously requires a bit of communication and education to get everyone on board. On the other hand, it poses another problem for organizations that have chosen not to use Microsoft’s MFA solution. What will happen on March 15, 2025 for those organizations that have activated MFA via a third-party solution Microsoft had already automatically pushed conditional access rules that could be deactivated, Will these rules be automatically activated on March 15, 2025? Will the use of Microsoft MFA become mandatory to the detriment of other solutions? All this information is not provided in the message you received.Some users repeatedly prompted for MFA
All our devices are Intune joined. MFA turned on with a conditional access policy: Grant Access to: Require multifactor authentication; Session only configured Sign in frequency: x days. When majority users sign in apps without any issue, and only required to re authenticated with MFA after the defined x days. We have a small group of users are asked to MFA every time they opens a new app. Intune indicates these users' computers "Compliant". However, Entra - Monitoring - Signin logs shows: The same monitoring for other users, Authentication Details are "previously satisfied'. For these users, even they are working on the same app on a desktop, they are still returned with "Mobile app notification" and therefore are asked to MFA: DSREGCMD /status returns some different Diagnostic Dataresults to other devices without MFA issues:Last HostName Update : NONE. ********************************************************************* +----------------------------------------------------------------------+ | Device State | +----------------------------------------------------------------------+ AzureAdJoined : YES EnterpriseJoined : NO DomainJoined : NO Virtual Desktop : NOT SET Device Name : [COMPUTER_NAME] +----------------------------------------------------------------------+ | Device Details | +----------------------------------------------------------------------+ DeviceId : [COMPUTER_ID] Thumbprint : [COMPUTER_THUMBPRINT] DeviceCertificateValidity : [ 2023-08-05 04:25:23.000 UTC -- 2033-08-05 04:55:23.000 UTC ] KeyContainerId : [COMPUTER_KEYCONTAINERID] KeyProvider : Microsoft Platform Crypto Provider TpmProtected : YES DeviceAuthStatus : SUCCESS +----------------------------------------------------------------------+ | Tenant Details | +----------------------------------------------------------------------+ TenantName : [TENANTNAME] ... ... ... +----------------------------------------------------------------------+ | User State | +----------------------------------------------------------------------+ NgcSet : NO WorkplaceJoined : NO WamDefaultSet : YES WamDefaultAuthority : organizations WamDefaultId : https://login.microsoft.com WamDefaultGUID : [...] (AzureAd) +----------------------------------------------------------------------+ | SSO State | +----------------------------------------------------------------------+ AzureAdPrt : YES AzureAdPrtUpdateTime : 2024-09-03 23:32:02.000 UTC AzureAdPrtExpiryTime : 2024-09-17 23:32:01.000 UTC AzureAdPrtAuthority : [...] EnterprisePrt : NO EnterprisePrtAuthority : OnPremTgt : NO CloudTgt : YES KerbTopLevelNames : .windows.net,.windows.net:1433,.windows.net:3342,.azure.net,.azure.net:1433,.azure.net:3342 +----------------------------------------------------------------------+ | Diagnostic Data | +----------------------------------------------------------------------+ AadRecoveryEnabled : NO Executing Account Name : AzureAD\[USERNAME], [USEREMAILADDRESS] KeySignTest : PASSED DisplayNameUpdated : Managed by MDM OsVersionUpdated : Managed by MDM HostNameUpdated : YES Last HostName Update : NONE +----------------------------------------------------------------------+ | IE Proxy Config for Current User | +----------------------------------------------------------------------+ Auto Detect Settings : YES Auto-Configuration URL : Proxy Server List : Proxy Bypass List : +----------------------------------------------------------------------+ | WinHttp Default Proxy Config | +----------------------------------------------------------------------+ Access Type : DIRECT +----------------------------------------------------------------------+ | Ngc Prerequisite Check | +----------------------------------------------------------------------+ IsDeviceJoined : YES IsUserAzureAD : YES PolicyEnabled : NO PostLogonEnabled : YES DeviceEligible : YES SessionIsNotRemote : YES CertEnrollment : none PreReqResult : WillNotProvision ************************************************************************** Can someone help here and shade some light on the issue.
Entra External ID (External Tenant) employee login question
Hello, We are creating an app for our customers. We have created an External ID Tenant for our customers to live in. We have set everything up and things are working as expected for the customers. I am struggling with the right settings for our employees to log in and manage/administrate inside the application. They currently have to MFA in twice when logging into this app using the same page that our customers use to log in. I have added these users as guests in the External ID tenant so that they can use the same credentials as our Work-Force tenant. This works, but as I said, they MFA in twice. Once for our Work-Force tenant, and once for the External ID tenant. I do have a conditional access policy set up to force MFA on anyone who has admin access to the External ID tenant, but when logging into our application, you have to MFA in EVERY time. When logging into Azure, it's very different. I seems to cache that I'm logged in, and/or cache that I've previously passed MFA and doesn't require it again. I have multiple questions: How can I stop having 2 MFA prompts every time an employee/admin logs into our application and keep things secure. I assume I could disable MFA on external guest accounts to get rid of one MFA prompt. My concern is that there is a way to directly log into the External ID tenant and bypass our Work-Force tenant which requires the MFA. Is there a way to disable MFA from my Work-Force tenant when logging into the app registered in the External ID tenant? Why is the app not operating like Azure Authentication. Shouldn't it keep my session open just like Azure does unless I log out or time out? Why does it not remember that I've previously satisfied MFA from my location. Is this something a developer needs to look at? I'm open to other suggestions as well to accomplish this. We are trying to avoid our tech support staff and other admins from having to MFA in twice when they access the admin section of this application.Entra ID Join for Windows Workgroup PCs without MFA
Hello, I am in the process of joining Windows workgroup PCs to Entra ID by manually adding work/school accounts. One of the mandatory requirements is that the account used must have administrative rights. Additionally, I've noticed that the system prompts for Multi-Factor Authentication (MFA) setup if it's not already configured for the account. Is there a way to disable the MFA requirement for user accounts during the manual Entra ID joining process? Any guidance you can provide would be greatly appreciated. Thanks
