Partner Security Requirements

• 06/25/2019
• 10 minutes to read
• • 

Applies to

• All partners in the Cloud Solution Provider program
  • Direct bill
  • Indirect provider
  • Indirect reseller
• All Control Panel Vendors
• All Advisors

Security and privacy of customers and partners are top priorities for Microsoft. We continue to see an increasing number of more sophisticated security attacks, primarily related to compromised identities. As preventive controls play a key role in an overall defense strategy to thwart security attacks, we will start enforcing a set of mandatory security requirements to help protect partners and their customers.

Overview of the requirements

All partners who are participating in the Cloud Solution Provider program, Control Panel Vendors, and Advisor partners are required to enforce Multi-Factor Authentication (MFA) for each user, including service accounts, in their partner tenant. This can be done by enabling two Azure Active Directory baseline policies. Baseline policies are a set of predefined policies that help protect organizations against many common attacks. These common attacks can include password spray, replay, and phishing. Baseline policies are available in all editions of Azure Active Directory. Microsoft is making these baseline protection policies available to everyone to further enable customers and partners to implement best-in-class security practices.

The two baseline policies that should be enabled are described in the table below.

When these policies are enabled, each user will be able to utilize Azure MFA at no additional cost. If you are using a third-party solution, then you are required to enforce MFA for each user when accessing Microsoft Commercial cloud services.

What actions do I need to take?

To ensure users in the partner tenant are protected, you are required to enforce MFA for each user (including service accounts). This can be accomplished by enabling the Require MFA for admins and End user protection baseline policies. Prior to enabling these policies, it is important to understand what they do and how they will impact any automation or integration and your users.

Considerations

Because the security requirements apply to all users in a partner directory, several considerations need to be made to ensure a smooth deployment. These considerations include identifying users in Azure Active Directory that cannot or should not perform MFA, as well as applications and clients used by your organization that do not support modern authentication.

Self Service Password Reset

Self-service password reset (SSPR) is an Azure Active Directory feature that enables employees to reset their passwords without needing to contact IT staff. Employees must register for or be registered for self-service password reset before using the service. During registration, the employee chooses one or more authentication methods enabled by their organization.

SSPR enables employees to quickly get unblocked and continue working no matter where they are or the time of day. By allowing users to unblock themselves, your organization can reduce the non-productive time and high support costs for most common password-related issues.

When the End user protection baseline policy is enabled any compromised user accounts will be blocked until their password is reset and risk events have been dismissed. Considering this it is recommended that each user, who is a global admin, perform the following to register for SSPR

1. Browse to the SSPR setup page
2. Enter your username and password
3. Configure at least one of the verifications options that will be used to verify who you are when resetting your password.

When an account has been compromised an administrator will need to take action to restore access for the impacted user. See the steps to unblock a user for details on the process to unblock the user.

Legacy protocols

Legacy authentication protocols (IMAP, SMTP, POP3, etc.) are used by mail clients to make authentication requests. These protocols do not support MFA. Most of the account compromises are caused by bad actors performing attacks against legacy protocols attempting to bypass MFA. To ensure that MFA is required when logging into an account in a partner directory and bad actors are not able to bypass MFA, these security requirements will block all authentication requests from legacy protocols.

Enabling the baseline policies

See the Implementing the partner security requirements tutorial for a guided experience regarding the implementation of the baseline policies.

Require MFA for admins

The Require MFA for admin baseline policy requires MFA for the following directory roles, considered to be the most privileged Azure Active Directory roles:

• Global administrator
• SharePoint administrator
• Exchange administrator
• Conditional access administrator
• Security administrator
• Helpdesk administrator / Password administrator
• Billing administrator
• User administrator

Upon enabling the Require MFA for admins policy, the above nine administrator roles will be required to register for MFA using the Authenticator App. Once MFA registration is complete, administrators will need to perform MFA every single time they sign-in.

If your organization has these accounts in use in scripts or code, consider replacing them with managed identities.

To enable this policy and protect your administrators:

1. Sign in to the Azure portal as a Global Administrator, Security Administrator, or Conditional Access Administrator.

2. Browse to Azure Active Directory > Conditional Access.

3. In the list of policies, select Baseline policy: Require MFA for admins.

4. Set Enable policy to Use policy immediately.

5. Click Save.

   

End user protection

The End user protection baseline policy protects all users in a directory. Enabling this policy requires all users to register for Azure MFA within 14 days. Once registered, users will be prompted for MFA only during risky sign-in attempts. Compromised user accounts are blocked until password reset and risk dismissal.

The policy Baseline policy: End user protection comes pre-configured and will show up at the top when you navigate to the Conditional Access blade in Azure portal.

To enable this policy and protect your users:

1. Sign in to the Azure portal as a Global Administrator, Security Administrator, or Conditional Access Administrator.

2. Browse to Azure Active Directory > Conditional Access.

3. In the list of policies, select Baseline policy: End user protection (preview).

4. Set Enable policy to Use policy immediately.

5. Click Save.

   

Common issues

Azure Active Directory

AADSTS50076

After enabling the baseline policies, you might find that your automation or integration is encountering an exception like the following

AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access 'MyApp'.

The reason for this exception is that you are authenticating using user credentials and MFA is now required. To address this exception, you will need to utilize an access token for authentication. See the Secure Application Model guide for more information.

AADSTS700082

Once you have implemented the Secure Application Model framework there is a chance you will receive the following exception 90 days after generating the initial refresh token

The refresh token has expired due to inactivity. The token was issued on 2019-01-02T09:19:53.5422744Z and was inactive for 90.00:00:00

With respect to Azure Active Directory the maximum lifetime for a refresh token is 90 days. To address this error, you will need to generate and securely store a new refresh token. Note it is possible to update the refresh token programmatically because with each request to Azure Active Directory for an access token a new refresh token is returned. You can implement the appropriate logic to update the securely stored refresh token before it expires.

See Configurable token lifetimes in Azure Active Directory for more information.

Recovering compromised accounts

To help protect our customers, Microsoft’s leaked credential service finds publicly available username/password pairs. If they match one of our users, we help secure that account immediately. Users identified as having a leaked credential are confirmed compromised. These users will be blocked from signing in until their password is reset.

Users assigned an Azure AD Premium license can restore access through self-service password reset (SSPR) if the capability is enabled in their directory. Users without a premium license that become blocked must contact an administrator to perform a manual password reset and dismiss the flagged user risk event.

Steps to unblock a user

Confirm that the user has been blocked by the policy by examining the user’s sign-in logs.

1. An administrator needs to sign in to the Azure portal and navigate to Azure Active Directory > Users > click on the name of the user and navigate to Sign-ins.
2. To initiate password reset on a blocked user, an administrator needs to navigate to Azure Active Directory > Users flagged for risk
3. Click on the user whose account is blocked to view information about the user’s recent sign-in activity.
4. Click Reset Password to assign a temporary password that must be changed upon the next login.
5. Click Dismiss all events to reset the user’s risk score.

The user can now sign in, reset their password, and access the application.

Known issues

Exchange Online PowerShell

When MFA is enabled partners will not be able to utilize their delegated administrative privileges with Exchange Online PowerShell to perform actions against their customers. See Connect to Exchange Online PowerShell using multi-factor authentication for more information regarding this limitation.

Resources and support

Through the Partner Center Security Guidance Group community you can will find additional resources and learn about upcoming events such as technical office hours. See the frequently asked questions document to learn more about the requirements.

Developers

• Enabling the Secure Application Model
• Partner Center .NET Samples
• Partner Center Java Samples
• Partner Center PowerShell implementing the Secure Application Model