Disable approval popup in MS Authenticator app
Hi, I have a tenant with MFA setup on all accounts and most people have used the Microsoft Authenticator app. Unfortunately someone was silly enough to press approve on their phone when they weren't getting prompted on their PC, and let a hacker in who knew their password. We're trying to educate them better but still I'd like to remove the feature where the they get that popup in the MS Auth app, and make them have to get a code from the app only so they can't accidentally let a hacker in. Can I do this by powershell somehow? I have 50+ users in this tenant and other tenants I may want to change too so not viable to ask them all to setup their MFA again a different way. Running powershell reports shows they all have two MFA methods of PhoneAppNotification and PhoneAppOTP and so I assume I just need to remove PhoneAppNotification. I found a script in the below thread to switch the default, but I assume that means a hacker could still try the other method and make their app do a approval popup, I want it removed. https://techcommunity.microsoft.com/t5/azure-active-directory-identity/powershell-cmdlets-for-mfa-settings/m-p/157678/thread-id/132 $m1=New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod $m1.IsDefault = $true $m1.MethodType="PhoneAppNotification" $m2=New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod $m2.IsDefault = $false $m2.MethodType="PhoneAppOTP" $m=@($m1,$m2) set-msoluser -Userprincipalname "UPN" -StrongAuthenticationMethods $m Thanks
2FA Authentication via Microsoft Authenticator or a Similar App on Windows 10
Hi, everyone, I hope you all are enjoying your day so far; I would love your help (please indicate which forum to post to if this is not the right place): I just recently got a new laptop, and I need to get an authenticator program working on my computer that resembles Microsoft Authenticator since obviously Microsoft hasn't released the application for Windows 10 on PC. Furthermore, I have many accounts in Microsoft Authenticator on my phone; would there be any way to easily migrate these accounts to a trustworthy app on the laptop? Thank you very much for any help that you can provide ☺️
'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---- https://feedback.azure.com/d365community/idea/d5253b08-d076-ed11-a81b-000d3adb7ffd https://feedback.azure.com/d365community/idea/1365df89-c625-ec11-b6e6-000d3a4f0789 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 enabledUse OTP Hardware token as a 2nd Authentication method
Dear Reader, In this post, I wrote about setting up a hardware OTP token if you don't currently have any of those tokens. I hope this helps you decide whether to migrate to this solution or not, in your production environment. An OTP hardware token is a physical device that is used to generate one-time password (OTP) codes for authenticating users to Azure services. These tokens are often used in combination with Azure Active Directory, which is a cloud-based identity and access management service. When a user attempts to log in to an Azure service, they will enter their username and password, and then use the hardware token to generate an OTP code. This code is then entered into the login screen to complete the authentication process. The process for activating an OTP hardware token may vary depending on the specific token and the system in which it will be used. Here is a general outline of the steps that may be involved: Install the hardware token: Follow the manufacturer's instructions to install the hardware token on your device. Register the hardware token: To use the hardware token, you will need to register it with the system or service that you will be using it with. This may involve creating an account or linking the hardware token to an existing account. Activate the hardware token: Once the hardware token is installed and registered, you will need to activate it. This may involve entering a code that was provided with the hardware token or completing some other activation process. Set up your hardware token: After the hardware token is activated, you may need to set up additional security measures, such as a PIN code, to use the hardware token. Use the hardware token: Once the hardware token is set up and activated, you can use it to generate OTPs when logging in to your account or accessing sensitive information. Again, the exact steps for activating an OTP hardware token may vary depending on the specific token and system you are using. Be sure to follow the manufacturer's instructions carefully to ensure that the hardware token is properly activated. In my situation, I'm going to use the TOTP Toolset from https://www.token2.com/ to emulate the Hardware Token. It is suitable for practicing the whole process before buying or configuring OTP hardware tokens in productive Infrastructure. About "Seed in base32" (We are generating this file to activate our OTP Hardware Token before using it) In the context of OTP hardware tokens, a seed in base32 is a string of characters that is used to generate one-time passwords (OTPs). The seed is typically provided by the manufacturer of the hardware token and is used to initialize the token's internal state. Base32 is a notation for encoding arbitrary byte data using a restricted set of symbols that can be conveniently used by humans and processed by computers. It is often used to represent data, such as seeds, in a compact and easy-to-read format. To generate an OTP using a seed in base32, the hardware token uses an algorithm to generate a unique password based on the current time and the seed. The OTP is typically valid for a short period, after which a new OTP must be generated. To use a seed in base32 with a hardware token, you will typically need to enter the seed into the token or provide it to the system or service that you are using the token with. The exact process for doing this will depend on the specific hardware token and system you are using. Seed in base32 format looks like: upn,serial number,secret key,timeinterval,manufacturer,model email address removed for privacy reasons,2300000000002,ABXYZ_VALUE_IN_BASE32,30,Token2,miniOTP-1 After generating the file in ".csv" format we should upload it to Azure Active Directory. Upload the ".csv" file to Azure Active Directory. After uploading we need to activate Hardware OTP Token. It is time to write the OTP on the Hardware Token. In our Situation, it is a TOTP Toolset-generated Code. After successfully activating you will get the notification. IMPORTANT!!! In Microsoft Azure Active Directory (Azure AD), legacy multifactor authentication (MFA) and self-service password reset (SSPR) policies are being deprecated and replaced with modern alternatives. Legacy MFA policies refer to older methods of implementing multifactor authentication in Azure AD, such as phone calls, SMS, and mobile app verification. These methods are being replaced with Azure MFA, which provides a more secure and scalable solution for implementing multifactor authentication. Legacy SSPR policies refer to older methods of allowing users to reset their passwords in Azure AD, such as using security questions or requiring the assistance of an administrator. These methods are being replaced with Azure AD Passwordless, which allows users to reset their passwords using techniques such as email, phone, or the Microsoft Authenticator app. Azure AD is deprecating these legacy policies to provide users with more secure and convenient authentication and password management solutions. It is recommended to migrate to the modern alternatives as soon as possible to ensure your Azure AD environment's continued security and functionality. Please check which authentication method you are using for users in your Tenant.?! The next step is to create a Conditional Access Policy: Checking the end user for authentication. After typing the username and password it will need a one-time OTP as a 2nd authentication method. Remember! We can use a Hardware OTP only for a 2nd authentication method. It doesn't support passwordless. As before mentioned we are typing here the TOTP Toolset-generated Code. Limitations Please also read the full documentation provided by the OTP hardware token vendor and from Microsoft before going to the configuration steps. I'm excited to publish this post and can't wait to hear what you think. I'd love to hear your feedback Farhad Khankishiyev MA/MCP/MCA/ISO27001 Auditor Azure Active Directory (AAD) Microsoft Authenticator Microsoft 365 Conditional Access
Excessive MFA prompts for a specific user
One specific user in my tenant is prompted for MFA multiples times/day. Our conditional access policies specify that a user must re-authenticate every 90 days with MFA. All other users do not get prompted daily without a new risk factor like new device/unknown IP address. I have tried the following: Re-registered authentication methods and revoked previous multifactor auth sessions. Enabled Multifactor Authentication in Security Defaults for this user (Rather than conditional access) Exempted this user from the standard CA policy, and created a new one. None of these steps have helped. Microsoft support was no help. Some other information: This user uses 1 to 2 IP addresses throughout the week. (Home and office) This user is using the same devices every day. We have replaced the devices and issue persists. There are at least 1, up to 5 prompts daily. No other users are experiencing this issue, and MFA behaves as expected. Azure Identity Protection lists the risk for this user as none. Zero risk detections within the last 90 days. Any suggestions are appreciated.Report suspicious activity (Preview)
Allows users to report suspicious activities if they receive an authentication request that they did not initiate. This control is available when using the Microsoft Authenticator app and voice calls. Reporting suspicious activity will set the user's risk to high. If the user is subject to risk-based Conditional Access policies, they may be blocked.
Issues with user accessing external tenant and not receiving MFA notifications
I have a user that has been invited to access some Sharepoint content in an external O365 tenant. When this user attempts to access the external content he is prompted for MFA, which he is set up for in his home tenant, however, he does not receive any push notification in Microsoft Authenticator. He has tried alternative MFA options (only OTP code is offered) and enters the OTP code from Microsoft Authenticator - but this is never accepted ("code is wrong") and so he cannot access the content in the external tenant. We have Security Defaults enabled in our tenant and this user uses MFA flawlessly to access content in our tenant - i.e. push notifications work to the Microsoft Authenticator app and he does not have any issue logging in. I have revoked his MFA sessions and forced him to re-register for MFA, i.e setting up Microsoft Authenticator and other methods again, but this does not help and he is still blocked accessing this external content. The login to the external tenant is logged on our side as this: User type: Guest Cross tenant access type: B2B collaboration Application: Office 365 SharePoint Online Sign-in error code: 500121 Failure reason: Authentication failed during strong authentication request. Additional Details: The user didn't complete the MFA prompt. They may have decided not to authenticate, timed out while doing other work, or has an issue with their authentication setup. Searching for 500121, I have found other discussions with the same issue but no solution for it: https://techcommunity.microsoft.com/t5/sharepoint/mfa-error-external-user-accessing-sharepoint/m-p/3197780#M57672 https://techcommunity.microsoft.com/t5/microsoft-teams/teams-mfa-not-working-for-specific-user-as-guest-in-external/m-p/2371725 Given that MFA works flawlessly on our side, is the issue the responsibility of the external tenant? I.e. it is they that are requiring MFA for guest users, therefore the issue lies with them somehow? Any pearls of wisdom here... it's pretty frustrating. EDIT: another user in our tenant has now been sent the link to the external Sharepoint content and this user is able to access it without any issue. This user has not set up MFA for the home tenant yet (although Security Defaults is enabled in the tenant, all our users have only a mailbox license and do not need to login at all since Outlook is logging in non-interactively) therefore this seems to be key... it seems like the MFA requirement is not being requested by the external tenant, since this user can access the content without being prompted for it at all... The plot thickens...Difference between "Microsoft Authenticator" and "Authenticator app" in Security Info
When I visit Security info (https://mysignins.microsoft.com/security-info), I see two different sign-in methods, "Microsoft Authenticator" and "Authenticator app". I have added my Microsoft work account only in one authenticator app (Microsoft Authenticator) on one device. What is the difference between those methods? This is how my account looks on the Microsoft Authenticator side:
