Hero Banner

Multi-Factor Authentication (MFA)

Learn and ask questions on how to implement MFA

Reply
Visitor 1

Legacy Protocol

Hi, according to the documentation for CSP security requirement

https://docs.microsoft.com/en-us/partner-center/partner-security-requirements

all the legacy protocol IMAP, SMTP, POP3 are essentially "blocked", meaning we cannot use IMAP and App password? 

Many MSPs out there are using ConnectWise, Autotask etc. as ticketing system. Does that mean we have to use a different tenant or something?

 

61 REPLIES 61
Visitor 1

You and other documentation keep saying "exclude users from baseline policy". The only way to do this seems to be to make a new policy by guessing what's in the "baseline" one. How are we supposed to know we got this right?

 

BTW: Of couse you say this "of course it is not recommended to make every user a global admin" but it's not what you're actually doing.

 

(Edit: silly typo)

Microsoft

@msjunk9 : You got it right when all you made sure that for all users MFA is enabled & enforced via any of the available methods. You don't need to configure your own policies exactly like the baseline policies - for conditional access policies you just need to make sure that you enable MFA as control.

 

There are multiple options for the "right" design, e.g.

UserA is not targeted by conditional access policies, but MFA is enabled directly in the user configuration

UserB is targetd by conditional access rule 1 - where MFA is enabled as control

UserC is targeted by conditional access rule 2 - where MFA is enabled and the condition is added that access may only happen from certain location.

 

The "MFA for Admins" baseline policy is basically a conditional access policy where only users with adminsitrative roles are targeted, under conditions all cloud apps/services are chosen and MFA is enabled as only control.

The end user protection baseline policy does actually use Identity Protection features - but enabling Identity Protection is not mandatory for CSP Partners, only that user goas through MFA is. So if you want to build your own policy targeting end users just make sure that you enable MFA as control in the policy and let it apply to all apps. You can additionally define Identity Protection risk policies when you have AzureAD Premium Plan2, but this is not required.

 

 

Level 1 Contributor

Does your statement for the exception of risk based MFA also when you require MFA except when using when using AADJ+/AADJ devices for all users?

Microsoft

@RobinVermeirsch : I'm not sure I understand the question - how are the risk based MFA policies related to AADJ devices?

AADJ devices should not be excluded from MFA requirements however. On those devices the user might not see the MFA prompt since those devices might already contain a MFA claim

So you would still enforce MFA as control in a conditional access policy for users accessing the services from these devices, you can however require a Hybrid joined device as additional control.

Level 2 Contributor

i have disabled the 2 baseline policies and enabled MFA for all users. All users have Azure Premium Plan 1.

But I don't see the app-password capabilities in https://myprofile.microsoft.com or https://mysignins.microsoft.com on the service accounts. App Password is not available

 

Any hints ??

Level 1 Contributor


@Morten_Knudsen wrote:

i have disabled the 2 baseline policies and enabled MFA for all users. All users have Azure Premium Plan 1.

But I don't see the app-password capabilities in https://myprofile.microsoft.com or https://mysignins.microsoft.com on the service accounts. App Password is not available

 

Any hints ??


You need to enable MFA via the Azure Dashboard -> Users -> Multi-Factor Authentication.  Then the option will appear.

Level 2 Contributor

I solved it by 'require register MFA' on the user, then it was possible. Thanx

Level 2 Contributor

@JanoschUlmer 

 

In addition, does the above app password scenario allow partners to remain in compliance with the CSP requirements?

 

Leif

Influencer

I, too, am struggling with getting specific scenarios approved.  It would be great if there were a consistent FAQ around scenarios.  If we knew where those were (and what is/is not in compliance) we could help spread the word in the Partner Community.

 

I am returning from Inspire and 3 out of 5 partners that I spoke with were totally unaware of the scope of this requirement.  Most partners just assumed they could turn on MFA for their Partner Center users and meet the requirement.  

 

Few understood that it had implications for all users (such as Guest Accounts or non-Partner Center users).

 

We received this notice from one of our line of business application vendors that doesn't support modern auth and is a technical blocker.  While the enforcement date isn't clear, it's pretty clear that we are responsible for meeting this requirement by 1 August.  Vendors aren't helping the case with spreading incorrect information.  Capture.PNG

Level 5 Contributor

@sreedwilson: Microsoft has two different dates for the Partner Security Requirements.

- A contractual Effective Date: August 1, 2019
- A technical Enforcement Date: TBD
Influencer

@cjmod Yes, I am aware that there is a contractual deadline (1 Aug) and technical enforcement (TBD) - I was sharing that others are confused as to the difference and are spreading misinformation to the partner community.  Sorry if I wasn't clear on that.

 

For partners who aren't engaged in this community they will definitely be confused.

Level 2 Contributor

We have an account in our tenant, that we use for scan-to-email on our printer.  Is there a way to exclude this account from the End-user protection baseline policy?

Community Manager

Hi All!

 

Please refer & subscribe to this related thread for more information: https://www.microsoftpartnercommunity.com/t5/Multi-Factor-Authentication-MFA/How-the-quot-Baseline-policy-End-user-protection-quot-will/m-p/10975#M45

 

especially this post : 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.  

 

Hope this helps,

Andra

Visitor 1

We're in the same boat but according to their documentation there are no exlusions.  We've been using App Passwords up to this point, which is a subset of MFA but if SMTP is going out the door then we doubt that will still work.

 

Might have to set up a Gmail or other service for these MFPs.

Visitor 1


@kbyrd78 wrote:

We have an account in our tenant, that we use for scan-to-email on our printer.  Is there a way to exclude this account from the End-user protection baseline policy?


We are also in the same situation.  The webinar said "more information to come in the coming weeks", but the deadline is 8/1 which is less than a month away.  Any ideas?



 

Level 4 Contributor


@kbyrd78 wrote:

We have an account in our tenant, that we use for scan-to-email on our printer.  Is there a way to exclude this account from the End-user protection baseline policy?


We are in the same situation. Our service account does not have any administrative rights and people do not email it sensitive information.

Visitor 1

Hi,

 

I am facing the same issue has any found a resolution for this. I won't be able to create a seperate tenant as they will  need the same domain to function correctly and all our licensing with partner benifits are curently tied to the tenant requiring MFA.

 

Would placing a forward to a mailbox on a new tenant that does not have mfa and account have only the exchange online license work when pointing connectwise to the new tenant. only issue I can see would be the automatic job replies from connectwise would all go to the old account

 

Moderator

Hi @kaingworth

 

We are working with the Azure AD team, to confirm that app passwords can be utilized with the partner security requirements. Once we have a confirmation on this additional guidance will be shared that will hopefully address the concern you have raised. 

Microsoft

Can you provide more details on how those ticketing systems are integrated in/connected to the CSP tenant?

 

Legacy protocols blocked means that if a solution integrated in the CSP tenant's AzureAD, like Exchange Online, authentication to this service (with AzureAD) can only happen with MFA. So access to Exchange Online would only work with modern auth, like Outlook App, not email apps that access via Exchange via IMAP. So if the ticketing system accesses Exchange Online mailbox via IMAP emails, and Exchange Online is in the tenant used for CSP, then yes, it would be blocked and the only solution would be to use Exchange Online in a different tenant. 

Level 2 Contributor

ConnectWise uses IMAP accounts to convert emails into support tickets.  It also has a function that uses Exchange Web Services to sync calendar appointments between ConnectWise and Exchange.

 

Both of these integrations use account/password for authentication.

 

I asked this in another topic but would App Passwords meet the MFA requirement?  I can enable MFA on an integration account and create an App Password that bypasses the MFA prompt.  It's built into the service so does that mean it's OK?

Microsoft

So I guess Connectwise is accessing a mailbox in Exchange Online via IMAP to get those emails it will convert?

This will not work - even if no basic authentication is used for web services, there would be a MFA prompt whenever authentication is happing. Connectwise would need to implement the secure app model to use access tokens to access Exchange via API (e.g. https://docs.microsoft.com/en-us/previous-versions/office/office-365-api/api/version-2.0/mail-rest-operations#use-the-mail-rest-api)

 

App Passwords will also not work, they do only work for legacy authentication protocols, which are blocked.