Mandating Multi-factor Authentication (MFA) for your partner tenant

Applies to

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

Affected roles

  • Admin agent
  • Sales agent
  • Helpdesk agent
  • Billing administrator
  • Global administrator

The intent of this feature is to help partners secure their access to customer resources against credentials compromise. Partners are required to enforce Multi-factor Authentication(MFA) for all user accounts in their partner tenant including the guest user, with this feature these partner roles will be mandated to complete MFA verification for the following areas:

Greater and ongoing security and privacy safeguards are among our top priorities and we continue to help partners protect their customers and tenants. All partners participating in the Cloud Solution Provider (CSP) program, Control Panel Vendors (CPVs) and Advisors should implement the Partner Security Requirements to stay compliant.

Microsoft began the activation of additional security safeguards for partner tenants. This activation of safeguards can help partners secure their tenants and their customers by mandating multi-factor authentication (MFA) verification to prevent unauthorized access.

We successfully completed the activation for partner Delegated Administration capabilities to all partner tenants. To further help protect partners and customers, starting May 1, 2020, we will begin the activation for Partner Center transactions in CSP, helping partners protect their businesses and customers from identity-theft related incidents.

This documentation provides partners with detailed experience and guidance regarding the activation of security safeguards.

Partner Center dashboard

Certain pages in the Partner Center dashboard will be MFA-protected, including:

If you try to access any of these pages and you haven't completed MFA verification earlier, you will be required to do so.

Note

Other pages on Partner Center such as Overview page, Service Health Status check page will not be MFA-protected.

The following user types are authorized to access these MFA-protected pages and are therefore affected by this feature

MFA protected pages Admin agents Sales agents Helpdesk agents Global administrator Billing administrator
All pages under Customers tab x x x
All pages under Support > Customer requests tab x x
Billing page x x x

Examples

To illustrate how verification works, consider the following two examples.

Example 1: Partner has implemented Azure AD MFA

  1. Jane works for CSP Contoso. Contoso has implemented MFA for all their users under Contoso partner tenant using AAzure Active Directory (Azure AD) MFA.
  2. Jane starts a new browser session and navigates to Partner Center dashboard overview page (which isn't MFA-protected). Partner Center redirects Jane to Azure AD to sign in.
  3. Due to the existing Azure AD MFA setup by Contoso, Jane is required to complete MFA verification. Upon successful sign in and MFA verification, Jane is redirected back to Partner Center dashboard overview page.
  4. Jane tries to access one of the MFA-protected pages in Partner Center. Since Jane has already completed MFA verification during sign-in earlier, Jane can access the MFA-protected page without being required to go through MFA verification again.

Example 2: Partner has implemented third-party MFA using identity federation

  1. Trent works for CSP Wingtip. Wingtip has implemented MFA for all their users under Wingtip partner tenant using third-party MFA, which is integrated with Azure AD via identity federation.
  2. Trent starts a new browser session and navigates to Partner Center dashboard overview page (which isn't MFA-protected). Partner Center redirects Trent to Azure AD to sign in.
  3. Since Wingtip has setup identity federation, Azure AD redirects Trent to the federated identity provider to complete sign-in and MFA verification. Upon successful sign in and MFA verification, Trent is redirected back to Azure AD and then to Partner Center dashboard overview page.
  4. Trent tries to access one of the MFA-protected pages in Partner Center. Since Trent has already completed MFA verification during sign-in earlier, Trent can access the MFA protected page without being required to go through MFA verification again.

Example 3: Partner hasn't implemented MFA

  1. John works for CSP Fabrikam. Fabrikam hasn't implemented MFA for any user under Fabrikam partner tenant.
  2. John starts a new browser session and navigates to Partner Center dashboard overview page (which isn't MFA-protected). Partner Center redirects John to Azure AD to sign in.
  3. Since Fabrikam hasn't implemented MFA, John isn't required to complete MFA verification. Upon successful sign in, John is redirected back to Partner Center dashboard overview page.
  4. John tries to access one of the MFA-protected pages in Partner Center. Since John hasn't completed MFA verification, Partner Center redirects John to Azure AD to complete MFA verification. Since this is the first time John is required to complete MFA, John is also requested to register for MFA. Upon successful MFA registration and MFA verification, John can now access the MFA-protected page.
  5. Another day before Fabrikam implementing MFA for any user, John starts a new browser session and navigates to Partner Center dashboard overview page (which isn't MFA-protected). Partner Center redirects John to Azure AD to sign in without MFA prompt.
  6. John tries to access one of the MFA-protected pages in Partner Center. Since John hasn't completed MFA verification, Partner Center redirects John to Azure AD to complete MFA verification. Since John has registered MFA, so this time he is only asked to complete the MFA verification.

Note

Action: Company administrator should implement MFA now via any of those options suggested by Partner Center.

Partner Center API

Partner Center API supports both App-only authentication and App+User authentication.

When App+User authentication is used, Partner Center will require MFA verification. More specifically, when a partner application wants to send an API request to Partner Center, it must include an access token in the Authorization header of the request.

Note

Secure Application Model is a secure, scalable framework for authenticating CSP partners and CPVs through the Microsoft Azure MFA architecture when you calling Partner Center API, you need to implement it before enabling MFA on your tenant.

When Partner Center receives an API request with an access token obtained using App+User authentication, the Partner Center API will check for the presence of the MFA value in the Authentication Method Reference (AMR) claim. You can use a JWT decoder to validate whether an access token contains the expected authentication method reference (AMR) value or not:

{
  "aud": "https://api.partnercenter.microsoft.com",
  "iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
  "iat": 1549088552,
  "nbf": 1549088552,
  "exp": 1549092452,
  "acr": "1",
  "amr": [
    "pwd",
    "mfa"
  ],
  "appid": "23ec45a3-5127-4185-9eff-c8887839e6ab",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "4988e250-5aee-482a-9136-6d269cb755c0",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "df845f1a-7b35-40a2-ba78-6481de91f8ae",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

If the value is present, Partner Center concludes that MFA verification was completed and processes the API request. If the value isn't present, Partner Center API will reject the request with the following response:

HTTP/1.1 401 Unauthorized - MFA required
Transfer-Encoding: chunked
Request-Context: appId=cid-v1:03ce8ca8-8373-4021-8f25-d5dd45c7b12f
WWW-Authenticate: Bearer error="invalid_token"
Date: Thu, 14 Feb 2019 21:54:58 GMT

When App-Only authentication is used, the APIs which support App-Only authentication will be continuously working without requiring MFA.

Partner Delegated Administration

Using service portals

Partner accounts, including Admin Agents and Helpdesk Agents, can use their Partner Delegated Admin Privileges to manage customer resources through Microsoft Online Services Portals, command-line interface (CLI), and APIs (using App+User authentication).

When accessing Microsoft Online Services Portals using the Partner Delegated Admin Privileges(Admin-On-Behalf-Of) to manage customer resources, many of these portals require the partner account to authenticate interactively, with the customer Azure Active Directory tenant set as the authentication context - the partner account is required to sign into the customer tenant.

When Azure Active Directory receives such authentication requests, it will require the partner account to complete MFA verification. There are two possible user experiences, depending on whether the partner account is a managed or federated identity:

  • If the partner account is a managed identity, Azure Active Directory will directly prompt the user to complete MFA verification. If the partner account has not registered for MFA with Azure Active Directory before, the user will be asked to complete MFA registration first.

  • If the partner account is a federated identity, the experience is dependent on how the partner administrator has configured federation in Azure Active Directory. When setting up federation in Azure Active Directory, the partner administrator can indicate to Azure Active Directory whether the federated identity provider supports MFA or not. If so, Azure Active Directory will redirect the user to the federated identity provider to complete MFA verification. Otherwise, Azure Active Directory will directly prompt the user to complete MFA verification. If the partner account has not registered for MFA with Azure Active Directory before, the user will be asked to complete MFA registration first.

The overall experience is similar to the scenario where an end customer tenant has implemented MFA for its administrators. For example, the customer tenant has enabled Azure AD security defaults, which requires all accounts with administrative rights to sign into the customer tenant with MFA verification, including Admin Agents and Helpdesk Agents. For testing purposes, partners can enable the Azure AD security defaults in the customer tenant and then try using Partner Delegated Administration Privileges to access the customer tenant.

Note

Not all Microsoft Online Service Portals require partner accounts to sign into the customer tenant when accessing customer resources using Partner Delegated Admin Privileges. Instead, they only require the partner accounts to sign into the partner tenant. An example is the Exchange Admin Center. Over time, we expect these portals to require partner accounts to sign into the customer tenant when using Partner Delegated Admin Privileges.

Using service APIs

Some Microsoft Online Services APIs (such as Azure Resource Manager, Azure AD Graph, Microsoft Graph, etc.) support partners using Partner Delegated Admin Privileges to programmatically manage customer resources. To leverage Partner Delegated Admin Privileges with these APIs, the partner application must include an access token in the API request Authorization header, where the access token is obtained by having a partner user account to authenticate with Azure AD, with the customer Azure AD set as the authentication context. The partner application is required to have a partner user account sign in to the customer tenant.

When Azure AD receives such as authentication request, Azure AD will require the partner user account to complete MFA verification. If the partner user account hasn't registered for MFA before, the user account will be prompted to complete MFA registration first.

All partner applications that are integrated with these APIs using Partner Delegated Admin Privileges are affected by this feature. To ensure partner applications can continue to work with these APIs without interruption:

  • Partner must avoid using non-interactive user authentication method with Azure AD to obtain the access token. When using non-interactive user authentication method such as Password Flow, Azure AD will not be able to prompt the user to complete MFA verification. Partner must switch to using interactive user authentication method such as OpenID Connect flow instead.
  • During interactive user authentication method, partner should use a partner user account that is already enabled for MFA. Alternatively, when prompted by Azure AD, partner can complete MFA registration and MFA verification during sign-in.
  • This is similar to the scenario where an end customer tenant has implemented MFA for its administrators. For example, the customer tenant has enabled Azure AD security defaults, which requires all user accounts with administrative rights to sign into the customer tenant with MFA verification, including Admin Agents and Helpdesk Agents. For testing purposes, partners can enable the Azure AD security defaults in the customer tenant and then try using Partner Delegated Administration Privileges to programmatically access the customer tenant.

MFA registration experience

During MFA verification, if the partner account hasn't registered for MFA before, Azure AD will prompt the user to complete MFA registration first:

MFA registration step 1

After clicking Next, the user will be asked to choose from a list of verification methods.

MFA registration step 2

Upon successful registration, the user is then required to complete MFA verification based on the verification chosen by the user.

Request for technical exception

Partners can apply for technical exception to suppress MFA verification if they are encountering technical issues with Microsoft Online Services and there are no feasible solution or workaround. Before doing so, review the following sections:

List of common issues reported by partners

Before applying for technical exception, review the list of common issues reported by other partners to understand whether they are valid reasons for technical exception or not.

Issue 1: Partner needs more time to implement MFA for their partner agents

A partner hasn't started or is still in the process of implementing MFA for their partner agents who require access to Microsoft Online Services Portals using Partner Delegated Administration Privileges to manage customer resources. The partner needs more time to complete MFA implementation. Is this issue a valid reason for technical exception?

Answer: No. Partner needs to make plans to implement MFA for their users to avoid disruption.

Note

Even though the partner hasn't implemented MFA for their partner agents, the partner agents can still access Microsoft Online Services Portals using Partner Delegated Administration Privileges provided they can complete MFA registration and MFA verification when prompted during sign-in to customer tenant. Completing MFA registration does not automatically enable the user for MFA.

Issue 2: Partner has not implemented MFA for user accounts not using Delegated Admin Privileges

A partner has some users in their partner tenants who do not require access to Microsoft Online Services Portals to manage customer resources using Partner Delegated Administration Privileges. The partner is in the process of implementing MFA for these users and needs more time to complete. Is this issue a valid reason for technical exception?

Answer: No. Since these user accounts are not using Partner Delegated Administration Privileges to manage customer resources, they will not be required to sign in to customer tenant. They will not be affected by Azure AD requiring MFA verification during sign-in to customer tenant.

Issue 3: Partner has not implemented MFA for user service accounts

A partner has some user accounts in their partner tenants, which are being used by devices as service accounts. These are low privileged accounts which do not require access Partner Center nor Microsoft Online Services Portals to manage customer resources using Partner Delegated Administration Privileges. Is this issue a valid reason for technical exception?

Answer: No. Since these user accounts are not using Partner Delegated Administration Privileges to manage customer resources, they will not be required to sign in to customer tenant. They will not be affected by Azure AD requiring MFA verification during sign-in to customer tenant.

Issue 4: Partner cannot implement MFA using MS Authenticator App

A partner has "clean desk" policy, which does not permit employees bringing their personal mobile devices to their work area. Without access to their personal mobile devices, the employees cannot install the MS Authenticator App, which is the only MFA verification supported by Azure AD security defaults. Is this issue a valid reason for technical exception?

Answer: No, this isn't a valid reason for technical exception. The partner should consider following alternatives, so that their employees can still complete MFA verification when accessing Partner Center:

  • Partner can also sign up for Azure AD Premium or third-party MFA solutions (compatible with Azure AD) which can provide additional verification methods.

Issue 5: Partner cannot implement MFA due to the use of legacy authentication protocols

A partner has some partner agents who are still using legacy authentication protocols, which aren't MFA compatible. For example, the users are still using Outlook 2010, which is based on legacy authentication protocols. Enabling MFA for these partner agents will disrupt the use of legacy authentication protocols.

Answer: No, this isn't a valid reason for technical exception. Partners are strongly encouraged to move away from the use of legacy authentication protocols because of potential security implications since these protocols cannot be protected with MFA verification and are much more susceptible to credential compromise. If moving away from the use of legacy authentication protocols is not an option, partners should consider signing up for Azure AD Premium, which supports the use of Application Passwords. Application Passwords are one-time system-generated passwords, and are usually stronger than human-generated passwords. By using Application Passwords, partners can implement MFA for their users, while falling back to Application Passwords for legacy authentication protocols only.

Read the post about the Basic Auth and Exchange Online to understand latest plan on supporting legacy authentication for Outlook, and follow the Exchange team blog to get the upcoming news.

Note

Even though the partner hasn't implemented MFA for their partner agents, the partner agents can still access Microsoft Online Services Portals using Partner Delegated Administration Privileges provided they can complete MFA registration and MFA verification when prompted during sign-in to customer tenant. Completing MFA registration does not automatically enable the user for MFA.

Issue 6: Partner has implemented third-party MFA that isn't recognized by Azure AD

A partner has implemented MFA for their users using a third-party MFA solution. However, the partner is unable to correctly configure the third-party MFA solution to relay to Azure AD that MFA verification has been completed during user authentication. Is this a valid reason for technical exception?

Answer: Yes, this issue may be considered as a valid reason for technical exception. Before submitting a request for technical exception, confirm with the third-party MFA solution provider that the MFA solution cannot be configured to flow the authenticationmethodsreferences claim (with value multipleauthn) to Azure AD to indicate that MFA verification has been completed during user authentication. While submitting a request for technical exception, you must provide details of the third-party MFA solution used, and indicate method of integration (such as through identity federation or use of Azure AD Custom Control), and provide the following information in the technical exception request as the supporting documents:

  • The third-party MFA configurations.
  • The result of Test the Partner Security Requirements running by the third-party MFA enabled account.
  • The purchase order of the third-party MFA solution you are using or you plan to use.

How to submit a request for technical exception

To submit a request for technical exception:

  1. Log in to Partner Center as Global Admin or Admin Agent.
  2. Create a new partner service request by navigating to Support > Partner support requests and clicking New request.
  3. Search for MFA - Request for exception in the search box; or select CSP from Category, then select Accounts, Onboarding, Access from Topic, then select MFA - Request for exception from the sub topic, then select next step.
  4. Provide details requested to submit a service request for technical exception and click Submit.

Microsoft may take up to three working days to provide a response to request for technical exception.