Question regarding MFA compliance
Hello Microsoft Support,
- 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?
- If the user is MFA enabled and we add MFA trusted IP of our office, would it be considered compliant?
- Does disabled admins account (for emergency purposes or rare use occasions) will make us non compliant if they are not MFA enabled?
- 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.
- 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!
It sounds like the baseline policies would be great for many of us if it allowed exclusions for those "special" accounts like the one used by Connectwise for syncing tickets and calendars at Managed Service Providers. Is there any plan to put the option back in place for the baseline policies to exclude certain users so we could setup per-user MFA for those unique accounts with app passwords?
If not, can we make a request for this and upvote it? I would imagine putting that one feature back would help a large swath of partners to be compliant quickly. Isn't that what everyone wants?
Baseline policies won't work for most partners because they can only be applied universally. That leaves us with manually setting up per-user MFA exclusively, which is error prone, or setting up conditional access policies which require Azure AD Premium P1 licenses that many of us do not have. Even AAD P1 does not include all the features of the user baseline policy unless you upgrade to P2. Very few partners and customers can implement baseline policies without some kind of exceptions. Even the recommended break the glass account cannot be used if you implement both baseline policies. If we could exclude a user, group, and IP address/location from a baseline policy, we could then actually use baseline policies for ourselves and implement them for our customers to improve security, reduce risk, and reduce credential compromise breaches.
As a partner, our ideal scenario would be to implement the baseline policies with exceptions for a few special accounts and then setup per user MFA for those special accounts with App Passwords. Then we could move on to revenue generating activities.
It seems like Microsoft could significantly help partners meet the spirit of the requirement by simply putting the feature back in place that allowed a baseline policy to be excluded from specific accounts. Then we could setup per user MFA and app passwords on those excluded accounts. It would probably save everyone a lot of time and effort, as well as hundreds of blog postings...
To keep a single thread on the MFA Requirements side I will move this post here https://www.microsoftpartnercommunity.com/t5/Multi-Factor-Authentication-MFA/Question-regarding-MFA-compliance/m-p/11160#M99.
You may refer to existing thread for clarifications.
In the Program Guide for Microsoft Cloud Solution Providers that Janosch Ulmer linked above (https://www.microsoftpartnercommunity.com/t5/Multi-Factor-Authentication-MFA/Question-regarding-MFA-compliance/m-p/11229/highlight/true#M111) Section 1.4 defines "users" as "its agents and, as applicable, Customers" and then goes on to state that "Company must, and must require its Indirect Resellers, as applicable, to, apply and enforce the use of the underlying multi-factor authentication service for all users in their accessing any Microsoft Commercial Cloud portal or any underlying service."
This reads to me that if I have a non-user mailbox that is used to process support emails for my company, it does not need to be MFA'd. Now, I would define such an account as a "service account" and yet the communication from Isaiah Williams on Partner Office Hours for Security Requirements: Option 3 - 3:38 was that all Service Accounts need to be MFA'd as well.
Am I correct in my interpretation or can you help me understand where the breakdown is?
The requirement for MFA enforcement applies to all user, including service, accounts in your partner tenant. This means each user account, regardless of it's function, will need to have MFA enforced.
Your reponse is consistent with your comments in the Office Hours, but my secondary question is still unaddressed: Can you help me understand where the breakdown in communication is?
As I mentioned, the program guide has a definition for "users". Is that definition incorrect and needs to be updated by Microsoft? Does "agents" mean something that Microsoft failed to define clearly in the Program Guide?
Word on the street is August 1st is just the "contractual" dealine, there's no word on a deadline nor any technical details about how Microsoft is going to enforce this technically.
I have all the same questiosn without answers.
Many of us are using "Modern Desktops" with Intune and Azure AD Join, with compliance policies to ensure devices are compliant, and only enforce MFA on non-compliant or untrusted devices.
If we can't do location based exclusions, the assumption would be we can't do device complaint, or hybrid-join exclusions either, which essentially puts the user experience back in the stoneage of "Enforced MFA" days.
Always require MFA, at Every Login, No exceptions? Just doesn't sound correct, and I think we'll all have to wait until some more detailed technical requirements are released around how this information is going to be validated.
The update program guide does include the official wording on what is required to be compliant:
Of course this is not a detailed technical guide - but these are the offical terms on what to ensure for compliance.
It is correct that August 1 marks the date when it is contractually enforced to have MFA in place. The technical enforcement will happen later - and there are no additional details yet available on how a check would be done (stay tuned). Likely it might be by checking the claim in the access tokens/refresh tokens when accessing the services - since there are various option how MFA can be implemented (3rd party MFA also allowed) - so it is not possible to just check if baseline polices are enabled. As said, just a guess to give some examples on how it could be checked technically, not a confirmation that this will be the solution.
Making some exceptions for certain locations/IP ranges will not be compliant - considering my example from above there would be no MFA claim in the token of the user then. Personally, I also consider this to be a relatively weak control also.
Reg. disabled admin accounts - I'm trying to get some more guidance on this. Generally our recommendations on this are documented here: https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-emergency-access.
Reg. the Partner Center security requirements one option could be to use a different MFA method for the emergency account - but then you can not enable the baseline policies since it targets all users/admins. Currently trying to get answers if Conditional Access with Custom Controls can be considered as option (Most users will enforce Azure MFA, only for the mergency accounts a custom control is used with 3rd party MFA) , will update the thread once I know more. Since you mentioned "disabled" - I guess that you are talking about a disabled account on-premises? Please note that it is important to have an emergency account in the cloud - since when all Admins or synced from local AD and when using ADFS, any issue in local AD would completely lock you out of the cloud.
Can not answer Question 4 on Exchange Online. For question 5 - have not heard any plans, for now focus oin fulfilling the contractual requirements as staed in the program guide.
@cstelzer : For the specific scenario you mentioned the user experience might not be impacted. Since, when you are AAD joined or Hybrid Joined and you device has a TPM (and/or Windows Hello For Business is used), you might already have the MFA claim in your token (see https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token for details) - because the device registration info prtected by the TPM is technically another factor for MFA. So accessing the services from a Hybrid Joined WIndows 10 machine can technically fulfill the MFA requirements (You can test this yourself by setting conditional access rules that enforce MFA and test logging in with such a device - Azure AD sign IN report might show that no MFA is triggered because of hybrid join). As mentioned above, we need to wait how exactly the technical check on Partner Center security requirements will be done, but there are good chances there is little impact for those scenarios.
It seems that using app passwords doesn't work for admins. So, if our user account has any of the admin roles, they aren't able to use Outlook. Should we setup an account for admin duties under the .onmicrosoft.com accounts or is there another method to continue using Outlook that I have missed?
While having two accounts for our admins would be an inconvenience, it is something we can live with.
You can use 'modern' authentication instead of app paswords to have MFA on Outlook. If you have an older tenant (like most partners) it's something you need to enable. In newer Office 365 tenants it's on by default. If you open Outlook, you get the Office 365 login window where you can enter your pasword and complete MFA. link to docs
Thank you for providing the updated version of the contract.
No, our tenant is cloud only. The disabled user (Which he is excluded from baseline polices), is used when we need to bypass MFA or emergency purposes. The main reason we still need it is because Skype/teams and Exchange Online (PowerShell EXO Module) does not support MFA via delegated access in PowerShell.
Here is an example of usage: Script that get the onboarding date of the Skype Migration of all tenants and report tenants where the skype client will be disactivated in the next 30 days. The only way to see the migration date was to read all message in the Message Center or via PowerShell (But the module does not support MFA). Many customers don't read Microsoft announcements or the message center news and got their skype disactivated without possibility to install the Teams client because they don't have admins rights which cause an unplanned down time. The script without MFA helped us to get the information and reach out our customer the fastest way possible.
In case of emergency, so when no other admin can log on, how do you then enable the disabled user account?
The only workaround for this I know is to create a user account in each customer tenant, since I believe for Exchange powershell it will also not work to work with a service principal (Secure app model with app registration in each customer tenant) - but I might be wrong here. What also could work is to deploy an Azure Automation solution in each customer tenant (you can build it and provide it via GitHub to customers) - where the EXO powershell can run with an automation account in customer environment and then it sends the information back to you.
Making an exception for this account is not possible according to program terms - all user (accounts) in the tenant need to be protected by MFA. Baseline policy also dos not allow to make per-user exceptions anymore, but even when doing this with a custom conditional access rule the contractual requirement stand against it.
Btw - The information on planned Teams migration can be seen in Partner Center for all customers - in MPN section in Partner Center, under Analytics there is a "cloud performance" report. On the very bottom of this report you see a table/list of customer tenants where you are delegated admin - and this includes columns showing the planned and actual migration date.
So the program guide says that ALL USER must have MFA required to logon to all different cloud apps?
1. We have dedicated service accounts today to do automation account on services that cant be solved with APP based tokens. These accounts CANT have MFA enabled, It will just brake everything.
2. We need to have a emergency account to be able to get back into our tenant if for instance Azure MFA are down or phone with app is lost for the "last admin" How can we solve that? The emergency account is monitored and alerted by Cloud App Security.
3. What about Guest users? Do they count?
For 1 - Do you use Azure Automation with an automation account or a service account and automation scripts running somewhere else?
For 2 - As of now, guidance would be to have e.g. conditional Access with Azure MFA for some, and another MFA service for others. This other MFA service can be implemented via ADFS +3rd party MFA integrated in ADFS - and I'm still in process of clarifying if conditional access with custom controls will work.
Also, afaik user can register multiple phones for MFA.
I have also discussed internally reg. our guidance for emergency accounts - but as of now there is no confirmation that such an account is allowed to be excluded. So unfortunately it will take a few days more until we have more clarity on this.
For 3 - Yes, guest users count - they are managed in another tenant, but still they are users in the tenant. End user baseline policy will also trigger MFA for guests.
Regarding the enablement of the disabled account, you are right that if no admins can login, we can't enable it back. All Our active admins are MFA enabled. Most of the time, this is due to a portal or MFA service degradation. If the problem come from the MFA service, we would log back using a conditional access that allow a specific IP to connect with MFA to the an office portal from another country then we enable the user.
I also noticed that something is trying to patch baseline policies in our tenant to remove the exception list.
Regarding the Analytics panel, the panel report nothing in our MPN portal. We opened a ticket about that I believe the issue is because we are indirect, causing the panel being unavailable. I will have to follow up with our sales team regarding the current status of the ticket.
I will try to attend to the next office hours webinar since I noticed that Microsoft is aware of all these caveats. The next big thing will be to find a way to send emails for other services as SMTP client send with MFA on port 587. I don't think this is currently possible, so we might have to use another mail service for that.