Security Info blocked by conditional access
Hello, We have a conditional access policy in place where a specific group can only access Microsoft 365 (deny all apps, except Office 365). The moment a user clicks on Security Info in My Account, the user is blocked by this policy. I cant find a way to exclude the app "My Signins" (AppId 19db86c3-b2b9-44cc-b339-36da233a3be2). Since MFA is forced for this group, they can't change their authenticator app registration. Is there a solution for this? Initial MFA setup works by the way. UPDATE jan 23, 2025: I contacted Microsoft support and this was their answer (in short): " MySignin is a very sensitive resource that is not available in the picker and cannot be excluded in the conditional access policy. Also, the application is calling Microsoft Graph. I understand that this is not the information you are looking to hear at this time, I would have loved to help but the application cannot be excluded from the policy. "Announcing mandatory multifactor authentication for the Microsoft 365 admin center
Reposting from the Microsoft 365 Blog what was originally published on November 11, 2024. Microsoft is committed to continuously enhancing security for all our users and customer organizations. One of the pillars of the Microsoft Secure Future Initiative is to protect identities and secrets, and multifactor authentication (MFA) is a proven approach to substantially reduce the risk of unauthorized access to user accounts. Starting February 3rd, 2025, Microsoft will begin requiring MFA for all user accounts accessing the Microsoft 365 admin center. This requirement will be rolled out in phases at the tenant level. You will receive a message through the Microsoft 365 admin center Message center approximately 30 days before your tenant is eligible for enforcement. Recommended actions Global admins: To set up MFA in your organization now, visit the MFA setup guide at aka.ms/MFAWizard or refer to Set up multifactor authentication for Microsoft 365 Users accessing the Microsoft 365 admin center: Check your verification methods and add one if needed by going to aka.ms/mfasetup. What is multifactor authentication and why is it important? Multi-factor authentication (MFA) is a security feature that requires you to provide two or more pieces of evidence to prove your identity when you sign in to an online service. These pieces of evidence can be something you know (such as a password or a PIN), something you have (such as a phone or a security key), or something you are (such as a fingerprint or a face scan). MFA adds an extra layer of protection to your account and your data, reducing the risk of unauthorized access even if your password is compromised. MFA is especially important for the Microsoft 365 admin center, where you can manage your organization's settings, users, licenses, subscriptions and more. Research by Microsoft shows that MFA leads to a 99.22% reduction in risk of account compromise. MFA will help you: Prevent unauthorized access to your Microsoft 365 admin accounts and the sensitive accounts, data, and resources that you manage Enhance your reputation and trust among your customers, partners, and stakeholders, who expect you to safeguard their data and privacy Help you reduce the risk of data breaches, identity theft, phishing, ransomware, and other cyberattacks that can compromise your business and your data Thank you for your cooperation and commitment to creating a more secure future We appreciate your understanding and your support as we implement this important security measure. We know that using MFA may require some adjustments, and we believe that the benefits greatly outweigh the efforts. We are confident that MFA will help you enhance your data security and your peace of mind, and we are here to help you with any issues or feedback that you may have along the way. FAQ - Microsoft 365 admin center - Mandatory MFA MFA Readiness and Verification What if I need more time to prepare for this requirement? We understand that some customers may need additional time to prepare for this MFA requirement. Therefore, Microsoft will allow extensions for customers with complex environments or technical barriers. Global Administrators can go to the Azure portal to postpone the start date of enforcement. A few important notes on requesting postponement: Global Administrators must have elevated access before postponing the start date of MFA enforcement on this page. For multi-tenant organizations, Global Administrators must perform this action for every tenant for which they would like to postpone the start date of enforcement. Extension requests will extend the enforcement for the Microsoft 365 admin center as well as the Azure portal, Microsoft Entra admin center, and the Microsoft Intune admin center. If you have already submitted a request for an extension in the Azure portal, the extension will apply to the Microsoft 365 admin center. If you need assistance with postponing your MFA enforcement date, contact support. How do I know if I am ready for MFA as an admin user accessing the Microsoft 365 admin center? If you have enrolled in MFA and have added a verification method, you will be able to satisfy the requirement. Go to aka.ms/mfasetup, review your verification methods and add one if needed. How do I know if this requirement impacts my organization? Microsoft will be rolling out this requirement to all users accessing the Microsoft 365 admin center. You will receive a message center post approximately 30 days before your tenant is eligible for enforcement. If your organization has already set up a qualifying MFA policy for your admin users or for all users in your organization, and users accessing the Microsoft 365 admin center have registered for MFA and added a verification method, then no further action is required at this time. As a Microsoft 365 administrator, how do I know if my organization has an MFA policy applied to Microsoft 365 admin center sign-in? If your Microsoft 365 tenant was created on or after October 22, 2019, Security defaults may already be enabled in your organization. To check if security defaults are enabled, sign in to the Microsoft Entra admin center as at least a Security Administrator. Navigate to Identity > Overview > Properties and view Security defaults. If security defaults are enabled, you will see "Your organization is currently using security defaults." next to a green check mark, and you are already meeting the requirement. If your organization is using Conditional Access policies in Microsoft Entra and you already have a conditional access policy through which users sign in to the Microsoft 365 admin center with MFA, then you are already meeting the requirement. While Security defaults and Conditional Access are recommended approaches for setting up your MFA policies, some organizations set MFA policies on a per-user basis. You can also check per-user MFA settings to review and enable each user account with MFA. What if I don't add an MFA verification method before this mandatory MFA requirement is applied for my tenant? Will I be locked out of my account? Will I still be able to access the Microsoft 365 admin center? No, you will not be locked out of your account. Yes, you will still be able to access the Microsoft 365 admin center. If you have not added an MFA verification method by the time the MFA requirement was enforced for your tenant, you will be prompted to register MFA for your account and add a verification method when you attempt to access the Microsoft 365 admin center. If a user is locked out, there may be another reason. Follow the guidance on Account has been locked - Microsoft Support. For further assistance with account lock-out, contact support. MFA Policies and Requirements Can I opt out of this requirement? No. This security measure is important to the safety and security of Microsoft 365 customer organizations and users. Increasingly, MFA is an industry standard baseline security requirement. Does this requirement impact all Microsoft 365 users? No. The mandatory MFA requirement for the Microsoft 365 admin center only impacts users accessing the Microsoft 365 admin center at this time. While MFA is not currently required for general Microsoft 365 services, Microsoft recommends that all Microsoft 365 users use MFA to safeguard user accounts and your organization. Does this requirement impact Microsoft Graph PowerShell or API? No. This requirement does not impact the use of Microsoft Graph PowerShell or API at this time. Does this requirement apply to emergency access accounts? Emergency access accounts (also known as break glass accounts) are privileged accounts not assigned to a specific user and intended to mitigate the risk of accidental account lockout. If your organization has set up emergency access accounts, note that these accounts are also required to sign in with MFA once enforcement begins. We recommend updating emergency access accounts to use passkey (FIDO2) or configure certificate-based authentication for MFA. Both of these methods satisfy the MFA requirement. Third-party Identity Providers Our organization uses a third-party identity provider (IdP) for MFA. Will this satisfy the requirement? Yes. Use of external MFA solutions will meet the requirement through external authentication methods in Microsoft Entra ID. If your MFA provider is integrated directly with this federated IdP, the federated IdP must be configured to send an MFA claim. Will third-party IdPs through the legacy Conditional Access custom controls preview satisfy the requirement? No. As you may know, in 2020, Microsoft provided a preview of Conditional Access custom controls to enable the use of third-party MFA providers with Azure Active Directory. This approach to third-party MFA was found to be too limited and has been replaced by external authentication methods in Microsoft Entra ID. Implementation and Support I'm part of a small organization with only a few admin users that need to access the Microsoft 365 admin center. What's the easiest way for me to satisfy this requirement with minimal disruption to our users? Admin users should simply go to aka.ms/mfasetup and add a verification method such as Microsoft Authenticator. Once the Microsoft 365 admin center MFA requirement is rolled out to your tenant, admin users will be prompted to sign in with MFA using the method your admins have added. How do I turn on security defaults? You may use the steps outlined in the documentation to turn on security defaults here: Security defaults in Microsoft Entra ID - Microsoft Entra | Microsoft Learn How do I require MFA through Conditional Access in Microsoft Entra? You may use the steps outlined in the documentation to create a Conditional Access policy which requires MFA here: Require MFA for all users with Conditional Access - Microsoft Entra ID | Microsoft Learn. I am part of an organization with multiple Microsoft 365 tenants. Will Microsoft 365 admin center MFA enforcement roll out to all our tenants at the same time? Not necessarily. The MFA requirement will roll out in phases at the tenant level starting February 3rd, 2025. For organizations with multiple Microsoft 365 tenants, MFA for Microsoft 365 admin center sign-in may be enforced for your tenants at different times. We recommend you apply MFA across all your Microsoft 365 tenants as soon as possible. I need help. Who can I contact? We are committed to helping you through this important security measure now and into the future. If you need assistance, contact support.
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 Data results 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."sign-in frequency" every time not working as expected and described.
We have several PIM managed groups in an Entra ID tenant. Members are added as eligible. For the activation of the memberships an Authentication Context is created which is linked to a conditional access policy. The conditional access policy requires MFA with phishing resistant authentication factors, and "sign in frequency" is set to "every time". When activating membership authentication is required. When activating membership to another group (>5min in between activations) one would expect to request an authentication prompt, as described in Microsoft documentation. In Firefox this works as expected, In Edge and Chrome there is no re-authentication required every time, and sometimes even not for the first activation, not even in an in-private session. The device is not joined to this tenant, and the account used to log on is different from the one used to logon to the Entra ID portal. This is a test tenant with only those CA rules configured, no other policies or rules are in place. Anyone experiencing the same, or knowing the cause?
'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 to https://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 enabledHow to Recover a Global admin account without MFA
Hi Community I have created a Global admin account in a tenant, unfortunately I had to reset my mobile device, and the MFA codes / setup are gone. I know the password for the account though, without being able to access MFA, I'm not able to login anymore. I have no other admin accounts / Privileged accounts setup. Is there any way to recover from this situation?
Can we enroll MFA to the users through POSTMAN
Hi Team, I am learning about MS Entra and planning to replace OneLogin with SSO. I can find all the API details of user enrollment in OneLogin, but I am struggling to get all the details to manage MFA enrollment for MS EntraID. I appreciate your valuable and kind support on this.MFA on RDP (with AD, RDG, NPS)
Hi, everyone. In the company where I work we have an AD domain and RDP servers (MP) that some employees access from outside via RDG. We have already installed ADFS and NPS but I am still not clear which products and which license levels are necessary to enable 2FA on RDP via RDG. Does anyone have a clearer idea than me? Thanks
