Multi-factor authentication is the current solution to the problem of inadequate information security in today’s world of user names and passwords. When you have enabled multi-factor authentication in Microsoft Azure and Office 365, you might need app passwords to allow for certain access to not disrupt the business.
The situation
As an organization, you use Microsoft Azure Active Directory (Azure AD). Your colleagues access data and functionality through Azure AD-integrated applications, services and systems. Your organization uses the default settings in Azure AD.
You have enabled multi-factor authentication through either:
- Security Defaults
- Conditional Access
A colleague needs to access functionality and/or data through an outdated application or needs a service to communicate with your data using a privileged account in a situation that requires multi-factor authentication by your information security policies.
(in the latter case, as an Azure AD admin you create and optionally synchronize an account with least privileges as the service account)
The colleague cannot log in using modern authentication, is not prompted for multi-factor authentication, and as a result, is unable to gain access to the functionality or data.
You do not want to make an exception to the policies, so you allow the colleague to use one or more app passwords.
You instruct the user to create an app password. He or she performs the following steps:
- He or she opens a web browser on her system and navigates to https://myaccount.microsoft.com/security-info.
- He or she signs in using the credentials for the account.
- He or she performs multi-factor authentication to gain access to multi-factor authentication management mode as part of the MyProfile / MyAccount experience.
- He or she clicks on the UPDATE INFO > link on the Security info tile.
The link leads to the Security info page. - He or she presses the + Add method button.
The Add a method modal screen appears. - He or she opens the drop-down list of available methods.
The issue
The drop-down list for Add a method doesn’t offer to create an App password.
The cause
The colleague cannot create an App password, because multi-factor authentication is required through Conditional Access or Security Defaults
The solution
To be able to create an App password, the account needs to be configured with the per-account multi-factor authentication requirement.
Note:
For accounts that are used as daily accounts for colleagues, configuring per-account multi-factor authentication results in a painful experience, as these settings override Conditional Access policies and Security Defaults and require multi-factor authentication for every sign-in with the account, unless remember multi-factor authentication is enabled. For these purposes, another solution is recommended; either create a separate service account or migrate to an app(lication) that the user can use with modern authentication.
Follow the below steps to enable per-user multi-factor authentication for an account:
- Open a browser and navigate to the Azure AD Portal.
- Sign in with an account that has the Global administrator or Privileged Authentication administrator role assigned.
- In the left navigation pane, click Azure Active Directory.
- In Azure Active Directory’s navigation pane, click on Security.
- In the Security navigation pane, click on MFA.
- In the Multi-Factor Authentication | Getting started main pane click the Additional cloud-based MFA settings link.
A new browser tab or window opens with the multi-factor authentication page.
On the Service settings tab you should see that the option to Allow users to create app passwords to sign in to non-browser apps is enabled by default. - Click the Users tab.
On the Users tab, you should see a list of user objects within the Azure AD tenant. - Search the user object, or select it from the list of users.
- In the area to the right of the users list, you should see the following links for the user object:
- Enable
- Manage user settings
- Click the Enable link.
- In the About enabling multi-factor auth modal window, click the enable multi-factor auth button.
- In the Updates successful modal screen, click the close button.
- The value in the MULTI_FACTOR AUTH STATUS column for the user object should now show Enabled.
- In the area to the right of the users list, a new link appears: Enforce.
- Click Enforce.
- In the About non-browser applications modal, click the enforce multi-factor auth button.
- In the Updates successful modal screen, click the close button.
The value in the MULTI_FACTOR AUTH STATUS column for the
user object should now show Enforced. - Sign out and ask the colleague to try and create an App password again.
After a few minutes, the colleague should be able to create an App password in multi-factor authentication management mode as part of the MyProfile / MyAccount experience.
Note:
After the app password is set, the per-account multi-factor authentication requirement can be removed by clicking the Disable link in the are to the right of the users list in the multi-factor authentication portal.
Concluding
Fumbling around in legacy portals to change legacy settings for legacy applications is quite the experience. I hope the whole ordeal left you with the bittersweet aftertaste of ‘Let’s not do this again’.
Thanks Sander – This might have helped us!
great!
This has just saved my skin and my sanity – thank you so much!
Thanks for the article. How does this affect all the other users? Are they still under the "security defaults" for MFA? I did not realize you could mix and match. I thought when you turned on security defaults the old conditional MFA settings had to be disabled.
Hi Mike,
Indeed, Security Defaults and Conditional Access are mutually exclusive.
The settings in the legacy PhoneFactor portal, however, can be used in conjunction with both.
Thanks for the article.
I followed the steps above with a new tenant that had security defaults enabled by default. I'm still unable to use the app password. I'm seeing authentication errors e.g. using send-message using powershell to relay through M365 I receive 5.7.57 Client not authenticated to send mail.
Could this be somehow related to legacy auth being disabled across the org with security defaults?
In Microsoft's article on security defaults, it mentions that 'App passwords are only available in per-user MFA with legacy authentication scenarios only if enabled by administrators'. It lists this under 'Conditional Access' not security defaults.
Thoughts?
Indeed, with Security Defaults on, the IMAP, POP and SMTP AUTH protocols are disabled.
I want this to work. And it seems like it should. With security defaults enabled *AND* MFA enforced on a user, I get the ability to create an App Password. However, it just doesn't seem to auth for IMAP/SMTP in Mail.app or Thunderbird. Maybe I need to wait an hour for something to propagate?
With Security Defaults on, IMAP, POP and SMTP AUTH are disabled.
Hi Sander,
In my tenant I have a Conditional Access policy for MFA that include one group with some users.
So now I have to enable App passwords for some of these users. Can I enbale app passwords even they are already in that group? Thanks.
Yes, you can.
As long as the legacy PhoneFactor portal is available, you can set the status for the users that require an app password to 'enable' (per user). As long as the setting in the legacy portal allows creating app passwords too, they can create app passwords.
Hi Sander,
I have an AD tenant that is configured to use a Conditional Access policy at a group level.
Now, I need to enable app password for some users that are already in a group that uses Conditional Access. Is that possible without modifying the CA policy? Thanks.
Yes, you can.
As long as the legacy PhoneFactor portal is available, you can set the status for the users that require an app password to 'enable' (per user). As long as the setting in the legacy portal allows creating app passwords too, they can create app passwords.
As app passwords satisfy the MFA requirement, you don't have to modify the CA policy to make exceptions.
Hi Sander,
thanks for the quick answer, i appreciate it !
What do you mean when you talk about the PhoneFactor portal ? Is that another portal ? Or is the portal where i can set the app password ? Thank you and have a good day.
Hi John,
My apologies for the confusion.
The PhoneFactor portal is the website you access when you click the Additional cloud-based MFA settings link, after you've navigated to Azure Active Directory, Security and then MFA in the Azure Portal.
This portal has been around since the early days of Azure MFA Server (Microsoft's product based on the PhoneFactor technology, acquired in 2012). It looks and feels legacy when compared to the Azure portal, hence my name for it.
Hi Sander,
Thanks, I got it!
Great website, keep it going 😉
Hi Sander,
After have spend the last 4 days to figure this out, I was so pleased to see you guide, as I was sure this was exactly what was looking for. I have done all the above, and can still not make this work.
One question,where do I chech this?:"the IMAP, POP and SMTP AUTH protocols are disabled".
The IMAP4, POP3 and SMTP protocols can be disabled in three different ways:
Great helpful article…Im trying to get a stupid legacy app to send out emails (it just stopped the other day) and Im wondering is there anyway with security defaults on that I can allow smtp email out from just one account?I can turn off multifactor for that account if needsbe..?
thanks
Hi Gary,
Not with Security Defaults on, unfortunately.
With Conditional Access you can create a separate Conditional Access policy for this type of accounts and limit them to the location (egress IP address) where it is used/hosted. Then, you would excerpt the accounts from the policy that requires multi-factor authentication.
Great work!!! I could not find this information anywhere else. Thanks for documenting clearly.
Is it possible to use Application Password for web access?
Hi Francisco,
App passwords can only be used when the authentication is against Azure AD. When your Remote Desktop Web Access implementation, your WiFi sign-in or your VPN connection is based on RADIUS authentication, then Active Directory performs the authentication and app passwords won't work.
This is regardless of the multi-factor authentication used. You can use Azure MFA with RADIUS authentication and it won't work. On the other hand you could use a third party multi-factor authentication with Azure AD and it will work. It's the authentication provider that has to support them and only AUre AD supports its own app passwords.
We are trying to allow our invoicing software to send invoices via email directly.
I have enabled MFA for the account we want to use through office365 security, but do not have a subscription which allows access to Conditional Access.
I'm still not seeing "Add App Password" as an option when adding authentication options…
Thank you Sander!
This is the only post I have found (and I have been looking for days), which mentions that 'Enforce' needs to be clicked for 'app password' to become an authentication method option.
Unfortunately, the generated password still doesn't authenticate my Mac mail client. Have you had experience with Mac mail client?
Mac mail client works when using autodiscover option. But with this setting an annoying notification keeps coming up after some time 'Exchange Password Required', which prevents rx/tx mail. The way to fix the issue is to delete/add Exchange in the Mac mail client, or log into outlook.com, but the fix is only temporary. I was told by Apple and Microsoft Support to use the 'app password' option, but the connection continues to fail. Any thoughts are greatly appreciated.
I just read the pop up again after clicking on Enforce multi-factor auth and the second sentence puzzles me. Does this mean, because my user account is an admin account, that I cannot use an app password, even though it is an auth method option, after clicking Enforce?
Warning
About non-browser applications
After multi-factor auth is enforced, users will need to create app passwords to use non-browser applications such as Outlook or Lync.
For security reasons app passwords are not available to admins, who will be able to sign in only with the browser.
enforce multi-factor auth or cancel
Hi Jutta,
Microsoft discourages the use of App Passwords, as they were only meant as a convenience measure a couple of years ago.
Please use modern authentication (with multi-factor authentication prompts) to authenticate in your mail app(s). If your mail app does not support it, upgrade it to a version that does, or to another mail app that does (for instance, Outlook). Alternatively, use Outlook on the Web.
Typically, mail apps will remember the multi-factor authentication status for 90 days, unless:
Please note that Microsoft intends to block legacy authentication per October 1, 2022.
Please note that Microsoft eventually intends to decommission the PhoneFactor portal.
Hi Sander,
I have the same question as Jutta.
There is no way to get app-passwords to work for an admin account, despite the fact it is possible to create app-passwords for an admin account?
I have MFA active with Conditional Access and i have a WAN Ip in the Exclude list
It works great, at the office no one need to use MFA but outside the office people need to use MFA!
Now some users need "App Password", and yeah I can enforced it from the MFA pages, but this wil overrule the CA exclude list
How can I make MFA app password without overruling the CA exclude list?
The legacy PhoneFactor portal, where you allow App Passwords and enforce multi-factor authentication on a per-user basis, also offers the option of configuring IPv4 address ranges to exempt from MFA. These are labeled 'Skip multi-factor authentication for requests from following range of IP address subnets'. These ranges apply to the per-user MFA requirements, too.
It may be a little bit confusing because internal IPv4 ranges are provided as examples. Use public ranges there, as you would in your Conditional Access Named Locations.
Note:
When using the IP ranges in the legacy PhoneFactor portal ánd Conditional Access named location, the burden doubles to manage trusted locations.
Note:
IP ranges in the legacy PhoneFactor portal only support IPv4 ranges, where Conditional Access Named Locations support both IPv4 and IPv6 ranges.