Enable app password creation when MFA is enforced using Azure Conditional Access
I'm actually implementing this for a customer and this one small thing has caused a BIG hold up.
I find it very odd that MFA being enabled from 2 different places would have a different effect. If MFA is enabled directly on a user in the Azure Classic Portal then, the app password creation option is presented during the MFA setup process. If MFA is enabled using Conditional Access policies in the new Azure Portal then, the app password creation option is not presented at all. Both are implementing the same function essentially but the latter blocks the apps that don't support ADAL completely. Even though one could argue that this is a condition based access where we want MFA when a particular resource is being accessed. Well, the point is that even if we're enabling it for the user in the classic portal, that is still the goal. We want MFA! So, I don't see why you would give the option to create app passwords only for one of them and not the other.
We are reviewing the option to use App Password with MFA enforced by Conditional Access. We strongly recommend using modern authentication, if possible, which removes the need for App Passwords.
Tony Brisciani commented
Wow. Another half-assed needlessly confusing and complicated mess from Microsoft. Would be wonderful if one day MS learned to make their products actually user friendly.
Can confirm that this 3 year old request has not been implemented.
1. If Conditional Access is used to enable MFA, App Passwords are not supported. This is official Microsoft language.
2. App Passwords can still be used with the legacy AAD "Enforce MFA" portal per-user. However, enforcing MFA overrides CA Policy, and you are unable to add that user to any conditional access policy that observes MFA.
Microsoft's position is to tell developers to update applications to use modern authentication. However, there are dozens of very large vendors who do not yet support modern authentication on their desktop applications.
The failure of Microsoft to fuse this broken feature, and instead, trying to shift blame to developers has put us in a state where we cannot effectively secure our users via MFA. Microsoft pushes security, while forcing insecurity through their complacency. It's very disappointing.
I figured out how to solve the issue where certain users could not create app passwords because that option was missing from their addition security features screen in their Office 365 account.
You just have to visit Office Admin, then Active Users. Don't select a user. On the top select Multi-factor authentication. A new web page tab will open displaying the MFA status per user. For the user which cannot create app passwords you will see Enabled as the status. You must click that user and then select Enforce. When a user is set to Enabled but not enforced this issue will occur, even though MFA is technically active. But unless you set it to enforced that user will not be able to create app passwords. Wow, that took me a long time to figure out.
I am still having this issue but only for a few users. Wow, how frustrating. I gave directions in another comment but I still cannot get it working for a couple of users. For those I had no choice but to disable MFA for the time being. I can use a very tight CA policy for those users though and (get this!) force MFA in the CA policy for high risk logins. LOL Please fix this ASAP.
Flaherty, Jason commented
I was banging my head against a wall trying to figure out this problem as well. Our symptom was that as soon as we enabled MFA using CA, our remote users who use Outlook started hollering that they could no longer access Outlook because the credential window kept popping up and would not accept their credentials. And of course most of them are executives.
I went down this path of app passwords, but it actually turned out to be a Modern Auth issue. Our Microsoft consultant at Core BTS, Nelson Paret, figured out the solution. In short, older O365 tenants have Modern Auth disabled by default. There is no way to see this in the GUI and nothing in the Sign-ins screen indicates that's where the problem lies. You need to use PowerShell to determine the Modern Auth setting and then again to toggle it to On if it is not already. In the meantime, you can always use the 'Exlcude' option under users in your CA policy to open up people who need to access their MS apps immediately. Here's the detailed explanation from Nelson:
"I have one question. Was your current O365 tenant created prior to August 1st, 2017? If so, its possible that Modern Auth is not turned on, and this will create the types of problems you are describing.
Please connect to EXO Powershell using the following commands after launching the Windows Powershell console as an Admin:
Set-ExecutionPolicy RemoteSigned -force
Set-ExecutionPolicy Unrestricted -force
$LiveCred = Get-Credential
Install-Module -Name MSOnline –Credential $livecred
Connect-MSOLservice –Credential $livecred
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Once you have connected through the PS console, run the following command:
Get-OrganizationConfig | Format-Table Name,OAuth* -Auto
If the setting is “False” this is the source of all your problems.
You would need to run the following command to enable it, but please make sure you run the command above first, as we need to verify the setting:
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
The TechNet article describing the process is below:
Enable or disable modern authentication for Outlook in Exchange Online"
I figured out a solution! I am not sure if these are the exact steps I did. But the root cause was previously having a conditional access policy applied to that user.
-Make sure the CA policy for MFA is not enabled. Mine was the Legacy rule, "Baseline policy: Require MFA for admins (Preview)"
-Disable the MFA for that user in the Office 365 Admin.
-Create a new CA policy in Azure AD. Have it grant access and require MFA, and only apply just to that user.
-Go back to the Office 365 MFA admin and enable then disable the MFA requirement for that user a few times. I did it four times. Leave with it disabled.
-Return to Azure and remove that user from the CA policy requiring MFA. Leave it enabled but just not applied to any users.
-Return to Office 365 admin and enable MFA for that user.
-Initiate a screen sharing session with that user. Have them log into their MFA set up screen.
https://aka.ms/MFASetup They will then see and be able to create a new app password.
This took me a month to figure out, and my exact steps may not have been exactly as I said above. Hopefully the whole community can figure out the best way.
This is extremely frustrating. I had one user assigned to a CA policy requiring MFA. Then I later disabled that policy. Now they cannot create an APP password. Wow, what a mess. This user is now locked out of key company systems unless I disable MFA, which I am reluctant to do because of constant attack against their IMAP login (which is needed for one legacy system we must use for the time being).
Microsoft has made it so activesync doesn't work with conditional defaults (with modern authentication) or security defaults. [activesync requires app passwords, app passwords aren't compatible with conditional access). Am I to conclude that they just want to kill activesync? I'd prefer not to use a closed source application to access my email.
What a dissapointment when I ran into this issue.
I wanted to switch to Conditional Access for MFA, but just noticed that we can't create app passwords then.
Very weird logic by Microsoft...
Marc Rodieck commented
This is very frustrating, has anybody found a way around this? So basically if you have a conditional access policy enforcing MFA, you cannot use app passwords?
Jake Ives commented
It is frustrating that it is currently not possible to generate an app password for an account when MFA has been enforced via a Conditional Access Policy.
We want to be able to enforce MFA under certain conditions but not others and also want new users to be able to use Skype. Currently this is not possible as using Conditional Access for MFA does not present app passwords to users on registration. Seems like a huge gap.
Oscar Öhrling commented
Baseline policy: Require MFA for admins (preview)
Baseline policy: End user protection (preview)
We have enabled these policies, but need to use app-password :(
Thank You, all the hours I spent going through every item in Azure and O365 and thinking I missed something is now known as time wasted, though not my fault??
Customer has new employee that must have iOS resident email app.
For MFA and Email on iOS,
Intune Company Portal on the App Store + Outlook app work perfect
Tom Turpin commented
I have tested with not enabling the MFA policy for both Modern authentication clients and Exchange ActiveSync clients. I have found that Android clients can add the account.
For Apple devices though, I had to approve Apple as an Enterprise application to get it working. This process meant getting the URL for the username entry on an Apple device into a PC so that I could alter the URL to enable an Admin to Approve it as an Enterprise Application in Azure.
Instructions are here: https://bit.ly/2F66Wa7
Long URL is:
Tom Turpin commented
Still unsolved. I have a client with 5,000 licenses, and cannot create app passwords due when using the conditional MFA Policy.
I guess one could exempt Android from MFA and create conditional access policy that requires the device marked as compliant and then require strict config polices in Intune instead of poking a hole in MFA security with a static app password that doesn't follow password rotation policies... #tradeoffs
Application passwords should probably be available independent of Microsoft's MFA. For example if you use DUO MFA via conditional access, there seems to be no way to allow a user to create application passwords without enrolling them in two different MFA methods.
Greg Lamb commented
Considering Skype for Business requires an App Password it's pretty lame that we can't use conditional access policy. If I exclude Skype that creates a hole
Anuj Rana commented
You can now block legacy clients using conditional access. Clients using Active sync, IMAP, POP, SMTP etc can be blocked using CAP on Portal.azure.com