How the "Baseline policy: End user protection" will effect SMTP devices/printers

[alorenzen]

Since enabling the Baseline policy: End user protection will hit all users, how does one comply with MFA yet still allow printers to send scans as attachments over SMTP? We are a partner manager with access to the partner center portal. I understand that we can create a new policy that excludes a user (the printer) but from my understanding the requirement is to get all users in our org to comply, including the printer.

[idwilliams]

Hi @alorenzen,

When you enable any of the baseline policies legacy authentication will be blocked. So, this means protocols like IMAP, POP3, and SMTP that do not support modern authentication will be impacted. We are currently investigating whether or not app passwords will work with the baseline policies. Once we have a firm answer on this we will let you know.  

[dferrell]

Will the baseline policy override any previous conditional access policies? With a seperate CA will app passwords continue to work there?

[JanoschUlmer]

It is not directly an override, all CA policies are equal 🙂

However - when user authenticates all rules/controls in all policies that are applicable to the user need to be fulfilled - in effect a kind of merge of all policies.

So if you have a CA policy that e.g. requires access from a managed device, and you also enable the baseline policy for MFA, user both needs a managed device and MFA. 

Also, if existing CA policies make an exception for some users, the baseline policy will still apply to all users, respectively all admins.

When you enable the "require MultiFactor-Authentication" control in any conditional access policy, legacy auth will be blocked.

App passwords are only an option if you enable MFA on a per-user basis (From Azure AD user management), not with conditional access-enforced MFA. However, we currently can not confirm that app passwords can be even used as alternative, this is still in discussion and depends on how the technical enforcement will be implemented. We will update you as soon as we can.

[dferrell]

Thank you for that information. I did have a few followup questions based on this scenario. Now taking into account that all CA policy is equal to an extent.

if i remove the trusted networks from my conditional access, this is going to make all users MFA anytime all the time. If the baseline user is asking to only MFA on risky sign on and i have EMS e3 licensing, how can i match my conditional access polcies to mirror the baseline CA that is in preview? I have a per user deployment and i like the idea of automatic registration within 14 days. This was not available at the EMS e3 level.

If it is not possible then how will that react to the other conditional access policy if enabled, will the baseline override and take default? Are there any best practices or suggestions you may have  if conditional access should be dropped in favor of the Baseline user policy or can they both be used? The concern is that one CA policy will require MFA on every log in, the baseline will only require risky sign in to MFA. Can these be mixed?

[JanoschUlmer]

For the building a policy similar to end user protection policy you would need to use Azure Identity Protection features, e.g. https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-sign-in-risk-policy -  this requires a P2 plan however.  Also this sign-in risk policy does not allow to set a 14 days grace period, this behavior is afaik  limited to the baseline policy.

---

@dferrell wrote:

If it is not possible then how will that react to the other conditional access policy if enabled, will the baseline override and take default? Are there any best practices or suggestions you may have  if conditional access should be dropped in favor of the Baseline user policy or can they both be used? The concern is that one CA policy will require MFA on every log in, the baseline will only require risky sign in to MFA. Can these be mixed?

---

The baseline will not override, both rules will be processed. So in this example MFA will be required to fulfill the requirements of the conditional access policy - even if baseline policy does not demand MFA (yet). So they can be mixed.

The best practice is to use the baseline policy when you don't have AAD premium licenses. If you have AAD Premium, if you need more flexibility on how to respond to the MFA prompt (e.g. also have the option to use phone or SMS) and/or if you do want to add further controls, like requiring a managed or compliant device etc. use conditional access instead.

[dferrell]

Thank you for the information, can you clarify outside of other mobile options what other flexibility options can be used with conditional access, as in exceptions or app passwords?

Thank you,

Derrick Ferrell
Microsoft Cloud Engineer
MCSA Office 365

***Disclaimer***

The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please call us (collect) immediately at 412-279-8700 and ask to speak to the message sender, in addition destroy any copies of this information.

All Lines Technology

[JanoschUlmer]

@dferrell : Conditional access gives the option to use several other conditions, and additional controls.

You can e.g. say "If accessed from our internal network MFA is fine, but when external we also require the device to be compliant". Or "We require MFA for everything, but when Sharepoint/OneDrive is accessed from mobile devices we additionally only allow managed apps".

Also there are custom controls which allows to use 3rd party MFA (Still trying to confirm this will also work for the Partner Center security requirements - it should, but I wanted to double check)

App passwords are not an option when using conditional access, app passwords can only be used when enabling MFA on a per user basis (and we also can not confirm that it will be sufficient for the security requirements - depends on how technical enforcement will be implemented).

[simonharvey]

> App passwords are not an option when using conditional access, app passwords can only be used when enabling MFA on a per user basis (and we also can not confirm that it will be sufficient for the security requirements - depends on how technical enforcement will be implemented).

Am I the only one a little irritated at the fact that MS has sent a whole host of scary messages and emails threatening dire outcomes if we don't comply with their arbitrary security demands but then actually can't tell us what "compliance" would actually look like 3 weeks out?

I've spent the past two hours trying to figure out whether we are already compliant, not at all compliant or somewhere in between and am still none the wiser.

Whoever is in charge of the partner program over there has straight up lost their mind recently

Simon

[JanoschUlmer]

Short update on this: It was confirmed that App Passwords can be used for scenarios where legacy protocols are used. Be sure to review the app password considerations

@simonharvey : For now, for August 1st, it is important to focus on the contractual compliance - so that MFA is enabled for every user account in the tenant as stated in the program guide. So in order to determine if you are compliant you only need to check if you have fulfilled the terms in program guide.

I agree that it is unfortunate that not all technical details are clear yet, the technical enforcement of these requirements will not happen right away on August 1 though. We are working on something to easier identify if your implementation is also technically working (=compliant) once technical enforcement will start, but there is no ETA for this yet.

[dferrell]

Based on this information and on other threads that i have seen. Please confirm if my understanding is correct here. We can continue to use CA for the user based accounts. For the service accounts, i can enable them on a per user basis and leave them out of conditional access policies so they can use app passwords to be compliant?

Also, since we cannot enable MFA for External accounts (Guest accounts) will CA cover those accounts as well?

Can you confirm?

[JanoschUlmer]

@dferrell Your understanding is correct. 

Reg. guest users - custom conditional access policies can also target guest users (last time I check there was a choice for "all guest users" as preview - but also by excluding all "internal users" guest users could be targeted specifically in the CA rule)

[brentmo]

I enabled the "Baseline policy: End User Protection (Preview)" because of mandatory requirement for our company. Now I have a couple of users that get "Update your password" after they click "Approved" from the Microsoft Authenticator. We have one-way syncing because of Azure AD Connect setup. I have changed the password on local AD and it synced to Office 365, but we still get the "Update your password" message and cannot proceed.

Thanks, Brent

[JanoschUlmer]

That sounds like it was detected that the user credentials were leaked - so account is compromised and the policy triggered a password reset. If self-service password reset was not enabled, the admin needs to reset password - as you already did - and then unblock the user manually: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-baseline-protect-end-users#recovering-compromised-accounts 

[JohnF]

You say you're blocking accounts automatically as part of these baseline policies based on certain situation ("Users with leaked credentials are blocked from signing in until a password reset."). Is that alertable via email (Cloud App security rule or something) so we're aware when this occurs?

It was unknown on a prior partner call, and still unanswered on the last one.

Thanks

[brentmo]

FYI: The user was not blocked to sign in. I could not find the setting that prompts for password reset, so I had to setup "Password write-back" via the Azure AD Connect. Lucky for me we have the Azure Actve Directory Premium P1 licenses. Now the user can change their passwords.

[JanoschUlmer]

@JohnF : Afaik there is no specific event in AzureAD activity logs for this - this would allow to configure an alert rule. Not 100% sure about this though, di dnot yet have time to test.

If AAD Premium P1 is available in the tenant, the admin can configure notification emails in Azure Identity Protection: https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/notifications 

[ictineo]

Has anyone a solution yet? App passwords are not working while the baseline policy is enabled. Many platforms, scanners, portals are still using SMTP. I understand the inproved baseline policy is required for partners. (GDPR), but 'the rest of the world' has not phased out SMTP yet.

[JanoschUlmer]

@ictineo: Have you enabled the specific user account where you want to use app passwords also for MFA? So MFA user state set to enabled in the classic MFA admin portal (Access via AzureAD portal --> Users) and user has done initial MFA registration? The last time I tested it it worked well to use app passwords when baseline policies were enabled, AzureAD signin reports even showed specifically that MFA requirement was fulfilled because app password was used.

[JeremyTBradshaw]

Hello @idwilliams ,

I believe the answer is "Yes" to this, but can you please confirm if you have a firm answer yet on whether App Passwords will work with the Baseline policy "End user protection"?

Thanks,

Jeremy

[JanoschUlmer]

@JeremyTBradshaw : Yes, if the user account is enabled for MFA additionally, the user can use app passwords for some non-browser applications if the "end user protection" baseline policy is enabled (and "Block legacy authentication" baseline policy is disabled).

However, since the baseline policies are deprecated and will be removed on Feb. 29, the new solution "AzureAD Security defaults" will block App Passwords, since it is planned that it will block all legacy authentication.

[JeremyTBradshaw]

@JanoschUlmer thanks for the concise answer and clear distinction about how legacy authentication is involved and how Security Defaults will behave.

On a side note, I noticed Azure AD Sign-Ins is only available in AAD Premium P1 and above. It would be nice if this was available to Azure AD Free customers so they can know if they have any clients using legacy auth., before they flip the switch on Security Defaults. I know the Sign-Ins data is available because individuals can see their own through My Sign-Ins. So it's something I've asked for on uservoice. It's kind of mean trick the way it is now.

[JanoschUlmer]

Good feedback, I agree with you that it would be great not to require Premium to check the sign-in logs.

BTW - the data is available without Premium licenses in the Graph beta version. And this is why this powershell does give the sign-in data even without AAD premium, it uses Graph Beta:

https://docs.microsoft.com/en-us/powershell/module/partnercenter/get-partnerusersigninactivity?view=partnercenterps-3.0

Mybe there is even some way to filter for legacy auth, have not tried.

[JeremyTBradshaw]

@JanoschUlmer Fantastic! I was hoping to find something like that. This is real and great value add for partners supporting their customers.