Hero Banner

Multi-Factor Authentication (MFA)

Learn and ask questions on how to implement MFA

Reply
vishal2suryan
Visitor 1

Exclude Service Account from MFA and EUP Baseline Policy

  • How do exclude Service Accounts from Baseline policy?
  • Our Azure AD is integrated with office 365.
    • One of the O365 Email account is configured in Printer for scanning as a Service account – Will this get affected due to MFA policy? How do we avoid getting affected?
    • We use one of the O365 Email accounts with SMTP details as a service account in one of our internal application and an external application to receive application activity notification. Will this get affected? If yes then how do we exclude this account from MFA?
8 REPLIES 8
JanoschUlmer
Microsoft

Baseline policies do not allow for exclusions anymore.

You need to create your own conditional access policies if you want to target different account with individual policies - generally it is not allowed to generally exclude user accounts from MFA. This also requires AzureAD Premium Plan1.

 

For the printer and the 2nd scenrio you mentioned  - this sounds like a scenario where an app password can be used. In order to use app passwords, you will enable MFA directly on the affected accounts, then log in to e.g. myapps.microsoft.com using this account one time to complete registration and to set an app password.

Be sure to not also target an conditional access policy to this account.

Kind regards,
Janosch
Get consultations form Technical Presales & Deployment services team via https://aka.ms/technicalservices
JoshK
Level 1 Contributor

@JanoschUlmer This Microsoft article indicates that changing the individual user state for MFA "requires users to perform two-step verification every time they sign in and overrides Conditional Access policies."  

 

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates

 

Does that mean that per user MFA setup also overides the baseline conditional access policies?

 

Does that mean that if we setup a single service account user state to enable MFA at the user level, setup an app password for that user (which enforces MFA for non-browser/all apps), and then enabled both baseline policies globally, would the user level MFA override the baseline policy and allow this service account user to continue to use the app password to access the service?

 

Does per-user MFA state trigger first and then bypass all conditional access policies (and the baseline policies) so they are not acted upon for that user, even though the usery may fall under the scope of that CA policy?

 

The goal would be to enforce MFA for the individual service account at the user level, use an app password for it to authenticate, use the baseline policy for all other users globally, and not have to setup a custom Conditional access policy to target specific users and not target the service account.

 

Ultimately, we are looking for security with MFA for all users and simplicity so we can keep these policies working securely in the future, but still accommodate Connectwise which requires an app password for Managed Service Providers to use it.

 

Thanks,

Josh

 

JanoschUlmer
Microsoft

@JoshK I was now able to test it - and you can enable the baseline policies, then enable MFA per user for an account and create app passwords. App passwords will then "bypass" the conditional access/baseline policy MFA enforcement.

And so you would only need an AzureAD P1 or Office 365 E1/E3 license for the user account which is using the app password (you don't need to assign it).

Added screenshot of how this looks like in AzureAD sign in reportsMFA app password.png

 

Kind regards,
Janosch
Get consultations form Technical Presales & Deployment services team via https://aka.ms/technicalservices
JoshK
Level 1 Contributor

Thank you @JanoschUlmer for testing this.  That is great news and looks very promising.  This method could be very helpful for partners that want to use the benefits of the baseline policies to improve security for every user, but also need an app password for a special service account like Connectwise sync. 

 

We plan to try moving to this method since it seems less error prone that just enabling MFA on every account.  Hopefully it will allow our service account to connect through protocols like EWS, SMTP, and IMAP and allow some Android users to use an app password with Activesync on the native mail client.  Hopefully we will not see any unintended consequences from this change to baseline policies.

 

Could a Break the Glass account be established for a special Global Admin user by using the app password for emergency access to the portal?

 

Do you know if implemening both baseline policies and adding an app password for a few service account users will meet the upcoming technical validation requirements?  Is that team checking for that scenario?

 

Thanks,

Josh

JanoschUlmer
Microsoft

@JoshK : App passwords will only work for non-browser apps, so the admin can not use it for emergency access. They will also not work for access via Powershell.

 

Since app passwords were confirmed to be working once technical enforcement starts, also baseline policies + app passwords will work, this has been checked.

 

Kind regards,
Janosch
Get consultations form Technical Presales & Deployment services team via https://aka.ms/technicalservices
CraigCollings
Visitor 1

Microsoft reccommendation regarding emergency "break-glass" acounts is to exclude them from CA and baseline policies (see the extract below).  How is this achieved?  I cannot see how to exclude an account from the baseline policy.

Am I interperting this correctly, that emergency accounts should not use MFA?  Or should use a different MFA (i.e. TOTP token).  

 

I welcome any clarification.

 

regards

Craig

 

"Exclude at least one account from phone-based multi-factor authentication

To reduce the risk of an attack resulting from a compromised password, Azure AD recommends that you require multi-factor authentication for all individual users. This group includes administrators and all others (for example, financial officers) whose compromised account would have a significant impact.

However, at least one of your emergency access accounts should not have the same multi-factor authentication mechanism as your other non-emergency accounts. This includes third-party multi-factor authentication solutions. If you have a Conditional Access policy to require multi-factor authentication for every administrator for Azure AD and other connected software as a service (SaaS) apps, you should exclude emergency access accounts from this requirement, and configure a different mechanism instead. Additionally, you should make sure the accounts do not have a per-user multi-factor authentication policy.

Exclude at least one account from Conditional Access policies

During an emergency, you do not want a policy to potentially block your access to fix an issue. At least one emergency access account should be excluded from all Conditional Access policies. If you have enabled a baseline policy, you should exclude your emergency access accounts."

JanoschUlmer
Microsoft

@CraigCollings : As mentioned in the guidance for emergency accounts it is recommended that at least one admin is not using the same MFA method, so the options you have are using a 3rd party MFA service for some accounts and/or  using different MFA verification methods. Both of these options are not possible using the baseline policies though, you need AAD Premium to configure user-scoped conditional access policies (where some users are forced to use Azure MFA, and others 3rd party MFA via custom controls) - or to configure other verification options like phone/sms or OATH token devices..

This is also confirmed in the FAQ on the security requirements: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements-faq#how-do-i-configure-an-emergency-access-break-glass-account 

 

 

Kind regards,
Janosch
Get consultations form Technical Presales & Deployment services team via https://aka.ms/technicalservices
JanoschUlmer
Microsoft

@JoshK : Honestly, need to test it again myself (because I myself saw some conflicting info on this). I should get this done in the coming days and then I can confirm if this is true.

Kind regards,
Janosch
Get consultations form Technical Presales & Deployment services team via https://aka.ms/technicalservices