Question regarding MFA compliance

[fmartel]

Hello Microsoft Support,

1. What happens the 1st august, can you explain the in dept process that confirm that a partner tenant is in compliance, is it a job that verify the default base line or it check that ALL users if they are MFA enabled?
2. If the user is MFA enabled and we add MFA trusted IP of our office, would it be considered compliant?
3. Does disabled admins account (for emergency purposes or rare use occasions) will make us non compliant if they are not MFA enabled?
4. What about Exchange Online PowerShell module (Hybrid EXO module). Will you fix the Delegated parameter to make the MFA work in delegated access? Right now, the only way to manage another Exchange Online tenant command line parameter is by providing an admin account with a license which is time consuming.
5. Is there a tool, or a script that you can provide us to confirm that our tenant will be compliant the 1st august?

Thank you for your support!

[kevinwilso05]

According to the FAQ, every authentication attempt will have to be met with an MFA challenge, so that would mean that you couldn't add a trusted location and bypass MFA through that. Microsoft says that enabling the enduser and admin baseline policies would suffice though. The conflict there is that the end user policy only requires the MFA challenge for risky sign ons. Which one is it? Do you have to have an MFA challenge each time, or is the baseline enduser policy which bypasses MFA except for risky signins enough?

[daokeefe]

@kevinwilso05, trusted locations or other whitelisting solutions available in Azure AD P1/P2 or 3rd party MFA solutions do not fulfill the MFA requirements.  Enabling the admin and end-user baseline protection policies does fulfill the MFA requirements.  I understand the confusion regarding the conflict between the requirement for each sign on to receive a challenge and the risk-based nature of the end-user baseline protection policy.  While today end-users only need to complete an MFA challenge based on risk with the baseline protection policy, in the future, end-users may be prompted to complete an MFA challenge for every sign on, regardless of risk.

[kevinwilso05]

If that's the case where the baseline end-user protection policy is compliant, and location based conditional access is not, then the FAQ is wrong. By definition then, if you use the baseline policy, you are using conditional access to circumvent the MFA challenge. If these requirements are really about making the enviornment secure, I'd actually argue that location based conditonal access is actually way more strict than the baseline policy. It's way less likely that you're going to have a risky sign-in from inside your own network, so to play it on the safe side, you force the MFA challenge for every sign-in thats not coming from your intranet. It looks like Microsoft hasn't fully figured out what they want for this yet, but even your last sentence contradicted itself. When you said that "While today end-users only need to complete an MFA challenge based on risk with the baseline protection policy, in the future, end-users may be prompted to complete an MFA challenge for every sign on, regardless of risk.", you admitted that the MFA challenge every time is definitely a step up security-wise than the baseline policy. If today end-users only need to complete an MFA challenge based on risk, then why does the FAQ and article say differently? And then saying "in the future, end-users may be prompted to complete an MFA challenge for every sign on, regardless of risk." The way you said it sounds like it hasn't been determined if Microsoft will make it a requirement to have an MFA challenge every time, and may be implemented in the future, yet the FAQ for these security requirements says that you have to have the MFA challenge everytime. There is just constant going back and fourth even in Microsofts published articles which is making this a confusing mess. 

[JanoschUlmer]

@kevinwilso05 Thank you for the feedback and sorry for the confusion caused.

We need to differentiate between the contract and technical enforcement. Indeed it would be great if the end user baseline policies would already work like they should, for various reasons the technical change in the policy was not implemented before the annoucement on security requirements was published.

The contract (CSP Program Guide) does explicitely call out baseline policies as one way being compliant. The FAQ is still correct in its guidance that no exclusions can be configured - because once technical enforcement starts authentication will not be successful if no MFA has been done. And before this technical enforcement will start, the baseline policy will incorporate this required change to trigger MFA every time.

[Gavwoods]

We have enabled the end-user policy yesterday and my understanding was that user accounts in the tenant would be enforced for MFA. This was no problem as all users (accounts on our domain) were MFA anyway.

However, since we enabled it yesterday we have noticed that, if we had shared a OneNote with a client, the client (logging in as, for example bob.smith@clientdomain.com) has an entry in our Azure AD of type guest and source External Active Directory. When they tried to access the shared OneNote this morning they were requested to configure MFA as if they were our staff members even though they have MFA enabled for their Azure AD account on their own tenant.

Can you advise if this is expected behaviour?

I can't see how this makes any sense and it has the feel of a bug in the policy implementation as the whole idea behind centralised active directories is that it allows you to assume that the identity has been confirmed by the source AzureAD. Once they have authenticated to their own Azure AD that should be sufficient.

Has anyone else come across this at all and are there any workarounds or fixes.

Many thanks in advance.

[assofohdz]

This is by design. Users must configure MFA per tenant (because each tenant may have configured it differently with different methods etc.)

Authentication to their own tenant has nothing to do with authentication to your tenant. The guest user in your tenant is the key here.

[47Minutes]

Good afternoon,

I recently joined the partner program as an indirect reseller partnered with Sherweb.  I have just three paid clients for which I am managing Office 365.

My confusion comes as to whether these security requirements apply to my client's tenant/users or if it is my company's tenant, of which, I am the only user/account.

[Jinseng]

These requirements to enable MFA are for your company's tenant that you use to connect to the CSP portals.  It's highly suggested that you encourage your clients to enable MFA, but that is not this requirment.

[BerndS]

Hello all together,

yes, there are problems with the Admin policy, but it seems there are some workarounds.

What nobody yet mentioned is the second policy:

All our users must be enabled for MFA through this policy, but only "dangerous" tasks will need MFA.

But enabling this policy requires, that our users all have mobile devices.

There is a policy in our company, that users are not allowed to use personal smartphones in the office!

Only technicians have smart phones.

So how will I use MFA?

Thans for replies,

Bernd Schneider

[JanoschUlmer]

Both baseline policies only enable the option to use Microsoft Authenticator app. 

If you enable Azure MFA via your own conditional access policies (Azure AD Premium Plan1 required), then you also got the option to use phone or SMS as verification method.

If you use ADFS or another STS solution for authentication, you can integrate 3rd party MFA solutions on-premises with ADFS/STS - and use any method provided by this 3rd party solution.

If you use conditional access with custom controls to integrate a 3rd party solution for MFA (Does also require AzureAD Premium Plan1), then you can use any method provided by the 3rd party (Note: I'm still seeking out for official confirmation that custom controls will work to fulfill the security requirements and what technical requirements need to be fulfilled by the 3rd party control)

[Yoshi]

Hi,

Could you confirm this scenario please?

Program guide for Cloud Solution Provider partners says

"The requirement to enable a multifactor authentication service may be fulfilled by either

(i) Company’s enablement of both the “Baseline policy: Require MFA for admins” and the “Baseline policy: End user protection” in the “Azure Portal”for all users;

(ii) Company’s purchase of a Microsoft offer that includes a multi-factor authentication service (for example,“Azure Active Directory Premium”); or

(iii) Company’s purchase of a third-party “on-premises” multi-factor authentication service that supports Azure Active Directory federated services"

But you wrote previously:

"Making some exceptions for certain locations/IP ranges will not be compliant"

Condition 2 tells:

"(ii) Company’s purchase of a Microsoft offer that includes a multi-factor authentication service (for example,“Azure Active Directory Premium”)"

If we enable Azure MFA via your own conditional access policies (Azure AD Premium Plan1 required) - so condition 2, but with excluded users (eg API user) would it be compliant?

Thank you

(edited to be more clear)

[JanoschUlmer]

No, user exclusion is not allowed. If it is for API access, the recommendation is to adopt the secure app model.

[AdamWeldon]

"If you use conditional access with custom controls to integrate a 3rd party solution for MFA (Does also require AzureAD Premium Plan1), then you can use any method provided by the 3rd party (Note: I'm still seeking out for official confirmation that custom controls will work to fulfill the security requirements and what technical requirements need to be fulfilled by the 3rd party control)"

We want to use Duo via a Conditional Access Custom Control Policy - So very much looking to know if there is an official confirmation to this ASAP.  

Else we will need to change the way our organisation uses MFa nd switch all our Administrators and Staff user bass across.

Any news welcome! 🙂

[alorenzen]

We manage a handful of clients and I personally access the Partner Portal for when adding ourselves to a client’s partner of record. My role is Admin agent. We also have non-technical users with no Roles and permissions yet they still show up as users in the Partner Center. Do these users need to have MFA enabled in order for us to meet the new requirements?

[timearl]

Hi all,

We are a member of the CSP program reselling through a distributor (Ingram Micro).  Myself and my colleagues interpret the new security requirements as:

• Only we the CSP have to enable MFA on our tenancy, not our customers tenancies.
• We can use the baseline policies OR we can enable MFA through Azure manually, but that will mean it will be an always on MFA rather than the intelligent 14 day MFA for users.  Both would make it so we comply with the new agreement.
• The baseline policies only use Microsoft authenticator app, there is not any other MFA options through this method.

Please let me know if I am interpreting this correctly and that we are heading in the right direction.

Many thanks,

Tim Earl

[Phogfan]

Tim,

This is the way I read it but I'm waiting on clarification from our CSP vendor.  Did you find an answer?

[timearl]

Hi @Phogfan ,

The only clarification I have received is by reading this message board.  My CSP gave us little clarification at best.  The only way forward so far seems to be applying the baseline policies to just ourselves and not our customers which we are not happy about applying to ourselves as it very limiting.  I am looking at when we MUST apply the policies.

Thanks,

Tim Earl

[JanoschUlmer]

@timearl :

From contract perspective you need to apply MFA by August 1st.

Technical enforcement will not happen on August 1st, there is no ETA yet on when this happens.

Beneath baseline policies you can alternatively enable MFA for each user and/or use your own conditional access policies (AzureAD Premium Plan1 required). When enabling MFA per user some of of the limitations might be resolved by leveraging app passwords.

[mortalwombats]

Hi Janosch,

Where you finish by saying 'When enabling MFA per user some of of the limitations might be resolved by leveraging app passwords', does this mean that the use of app passwords are still completely accetpable in the case of the new requirements?

My own use case is being able to schedule a runbook in Azure Automation which creates a CSV file and uploads it to a document library in Sharepoint Online. That runbook must authenticate to SP Online as part of the process.

I referenced some official documentation (source: https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azuread) to create an app-only azure ad identity for the purposes of this automated process - specifically the authentication piece. However, this is not a secure enough alternative in my opinion, since the only four available permissions are too broadly scoped, and, at best, still results in the Automation Account/runbook identity having the ability to read data in "all" site collections within our tenant (please refer to screenshot).

Thus I would very much like to execute the runbook under the context of a user which I then can define granular enough permissions for in Sharepoint Online. Since the script is not run interactively, 'app passwords' would be a good solution to our problem.

Please clarify.

Thanks

[JanoschUlmer]

@mortalwombats Sorry for not replying earlier, I was in vacation and it took some while to catch up.

For Sharepoint Online - for this type of access I do not think app passwords will work, app passwords only work when the protocol does not support modern authentication. But you can try and I can confirm that app passwords are a valid option (also confirmed in the FAQs now)

App only model does work and is not affected by the MFA requirements - see also the FAQ. While the 4 predefined permissions do not allow for much customization, app only is secure enough for the purpose of securing the account in the CSP tenant (user credentials are not used to get access tokens).

What might work is to leverage the same workaround mentioned for Exchange Online Powershell in the official guidance - however, this will not be a long term solution and I would recommend to use app only.