Partner security requirements for partners using Partner Center or Partner Center APIs
- All partners in the Cloud Solution Provider program
- Direct bill
- Indirect provider
- Indirect reseller
- All Control Panel Vendors
- All Advisors
- All enabled users including guest users
Greater privacy safeguards and security are among our top priorities. We know that the best defense is prevention and that we are only as strong as our weakest link. That is why we need everyone in our ecosystem to act and ensure appropriate security protections are in place. To help safeguard partners and customers, we are introducing a set of mandatory security requirements for Advisors, Control Panel Vendors, and partners participating in the Cloud Solution Provider program.
Partners are required to enforce multi-factor authentication for all user accounts in their partner tenant. The terms associated with the partner security requirements have been added to the Microsoft Partner Agreement. As it relates to Advisors, the same contractual requirements will be in place.
Partners who do not implement the mandatory security requirements will not be able to transact in the Cloud Solution Provider program or manage customer tenants leveraging delegated admin rights, once these requirements are enforced. In addition, partners who do not implement the security requirements may put their participation in programs at risk.
To protect you and your customers, we are requiring partners to take the following actions immediately:
Enable Multi-Factor Authentication (MFA) for all user accounts in your partner tenant. All user accounts in your partner tenant(s) must be challenged by multi-factor authentication (MFA) when they sign into Microsoft commercial cloud services or when they transact in the Cloud Solution Provider program through Partner Center or via APIs.
Adopt the Secure Application Model framework. Adopt the Secure Application Model framework. All partners integrating with Partner Center API must adopt the Secure Application Model framework for any app + user auth model applications.
We strongly recommend that partners implement the Secure Application Model for integrating with a Microsoft API such as Azure Resource Manager, Microsoft Graph, or leveraging automation such as PowerShell using user credentials, to avoid any disruption when MFA is enforced.
Enabling Multi-Factor Authentication (MFA) and adopting the Secure Application Model framework will help protect your infrastructure and safeguard your customer's data from potential security risks such as identify theft or other fraud incidents.
Actions that you need to take
To comply with the partner security requirements, you must enforce multi-factor authentication for each user account in your partner tenant. You can do this one of the way following ways:
Implementing Azure AD security defaults.
Purchasing Azure Active Directory Premium for each user account. For more information, see Planning a cloud-based Azure Multi-Factor Authentication deployment.
Using a third-party solution to enforce multi-factor authentication for each user account in your partner tenant. To ensure the solution will provide the expected solution, see how the security requirements will be enforced.
Although multi-factor authentication is not contractually required for a sovereign cloud (21Vianet, US Government, and Germany) it is highly recommended you adopt these security requirements.
Security defaults policy is one of the options that partners can choose to implement MFA for the security requirements depending on their business needs. It offers a basic level of security enabled at no extra cost. Review how to enable MFA for your organization with Azure AD and the key considerations below before enabling the security defaults.
Baseline policies will stay for the next couple of months, and deprecated targeting at the end of Feb 2020.
Partners who already adopted baseline policies need to take action to transition to security defaults.
Security defaults are the general availability replacement of the preview baseline policies. Once a partner enables the security defaults, they will no longer be able to enable baseline policies.
With security defaults, all policies will be enabled at once.
Blocking legacy authentication will not be enforced for partners at this time. However, as most events related to compromised identities come from sign-in attempts using legacy authentication, partners are encouraged to move away from these older protocols.
Azure AD Connect synchronization account is excluded from security defaults.
For detailed information, read Enable Multi-Factor Authentication for your organization and Azure Active Directory security defaults.
Azure AD security defaults is the evolution of the baseline protection policies simplified. If you have already enabled the baseline protection policies, then it is highly recommended that you enable security defaults.
To transition from baseline policies to security defaults, read What are security defaults?.
Because these requirements apply to all user accounts in your partner tenant, you need to consider several things to ensure a smooth deployment, including identifying user accounts in Azure Active Directory that cannot perform multi-factor authentication, as well as applications and devices used by your organization that do not support modern authentication.
Prior to performing any action, we recommend you identify the following:
Do you have an application or device that does not support the use of modern authentication?
When you enforce multi-factor authentication legacy authentication use protocols such as IMAP, POP3, SMTP, etc. will be blocked because they don't support multi-factor authentication. To address this limitation a feature known as app passwords can be used to ensure the application or device will still authenticate. You should review the considerations for using app passwords documented here to determine if they can be used in your environment.
Do you have users using Office 365 provided by licenses associated with your partner tenant?
Prior to implementing any solution, we recommend that you determine what version of Microsoft Office is being used by users in your partner tenant. Review plan for multi-factor authentication for Office 365 Deployments before taking any action. There is a chance your users will experience connectivity issues with applications like Outlook. Before enforcing multi-factor authentication, it is important to ensure that Outlook 2013 SP1, or later, is being used and that your organization has modern authentication enabled. See Enable modern authentication in Exchange Online for more information.
To enable modern authentication for any devices running Windows, that have Microsoft Office 2013 installed, you will need to create two registry keys. See Enable Modern Authentication for Office 2013 on Windows devices.
Is there a policy preventing any of your users from using their mobile devices while working?
It is important to identify any corporate policy that prevents employees from using mobile devices while working because it will influence what multi-factor authentication solution you implement. There are solutions, such as the one provided through the implementation of Azure AD security defaults, that only allow the use of an authenticator app for verification. If your organization has a policy preventing the use of mobile devices, then consider one of the following options:
Deploy a time-based one-time base password (TOTP) application that can run on secure system
Implement a third-party solution that enforces multi-factor authentication for each user account in the partner tenant that provides the most appropriate verification option
Purchase Azure Active Directory Premium licenses for the impacted users
What automation or integration do you have to leverage user credentials for authentication?
Since the requirement is to enforce MFA for each user, including service accounts, in your partner directory any automation or integration that leverages user credentials for authentication will be impacted. So, it important that you identify what accounts are being used in these situations. See the following list of sample applications or services to consider:
Control panel used to provision resources on behalf of your customers
Integration with any platform that is used for invoicing (as it relates to the CSP program) and supporting your customers
PowerShell scripts that utilize the Az, AzureRM, Azure AD, MS Online, etc. modules
The above list is not comprehensive. So, it important that you perform a complete assessment of any application or service in your environment that leverages user credentials for authentication. To contend with the requirement for multi-factor authentication, you should implement the guidance in the Secure Application Model framework where possible.
Accessing your environment
To better understand what or who is authenticating without being challenged for multi-factor authentication, we recommend you review the sign-in activity. Through Azure Active Directory Premium, you can leverage the sign-in report. See sign-in activity reports in the Azure Active Directory portal for more information. If you do not have Azure Active Directory Premium, or you are looking for a way obtain this through PowerShell, then you will need to leverage the Get-PartnerUserSignActivity cmdlet from the Partner Center PowerShell module.
How the requirements will be enforced
The partner security requirements will be enforced by Azure Active Directory, and in turn Partner Center, by checking for the presence of the MFA claim to identify that multi-factor authentication verification has taken place. Starting November 18, 2019, Microsoft will activate additional security safeguards (previously known as “technical enforcement”) to partner tenants.
Upon activation, users in the partner tenant will be requested to complete multi-factor authentication (MFA) verification when performing any admin on behalf of (AOBO) operations. We will continue to extend the scope of the security safeguards to additional scenarios and user roles, providing partners with advance notice. For more information, please refer to this document, which will be updated frequently. Partners who have not met the requirements should implement these measures as soon as possible to avoid any business disruptions.
If you are using Azure Multi-Factor Authentication or Azure AD security defaults, there are no additional actions you need to take.
When using a third-party multi-factor authentication solution, there is a chance the MFA claim may not be issued. If this claim is missing, Azure Active Directory will not be able determine if the authentication request was challenged by multi-factor authentication. For information on how to verify your solution is issuing the expected claim, read Testing the Partner Security Requirements.
If your third-party solution does not issue the expected claim, then you will need to work with the vendor who developed the solution to determine what actions should be taken.
Resources and support
See the following resources for support and sample code:
- Partner Center Security Guidance Group community: The Partner Center Security Guidance Group community is an online community where you can learn about upcoming events and ask any questions that you might have.
- Partner Center .NET Samples: This GitHub repository contains samples, developed using .NET, that will demonstrate how you can implement the Secure Application Model framework.
- Partner Center Java Samples: This GitHub repository contains samples, developed using Java, that will demonstrate how you can implement the Secure Application Model framework.
- Partner Center PowerShell - Multi-Factor Authentication: This Multi-Factor Authentication article provides details on how to implement the Secure Application Model framework using PowerShell.