Mandating multi-factor authentication (MFA) for your partner tenant

Appropriate roles: Admin agent | Sales agent | Helpdesk agent | Billing admin | Global admin

This article gives detailed examples and guidance for mandating multi-factor authentication (MFA) in Partner Center. The intent of this feature is to help partners secure their access to customer resources against credentials compromise. Partners are required to enforce MFA for all user accounts in their partner tenant, including guest users. Users 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.

To help partners protect their businesses and customers from identity-theft and unauthorized access, we activated additional security safeguards for partner tenants which mandate and verify MFA.

Partner Center dashboard

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

The following table shows which user types are authorized to access these MFA-protected pages (and are therefore affected by this feature).

MFA-protected page 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

If you try to access any of these pages and you haven't completed MFA verification earlier, you will be required to do so. Other pages on Partner Center such as the Overview page, Service Health Status check page do not require MFA.

Verification examples

To illustrate how verification works in the Partner Center dashboard, consider the following 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 Azure 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 administrators have three options for implementing MFA.

Partner Center API

The 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

The Secure Application Model framework is a scalable framework for authenticating CSP partners and CPVs through the Microsoft Azure MFA architecture when calling Partner Center APIs. You need to implement this framework 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 that support App-Only authentication will be continuously working without requiring MFA.

Partner Delegated Administration

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).

Using service portals

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 AD tenant set as the authentication context - the partner account is required to sign into the customer tenant.

When Azure AD 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 AD will directly prompt the user to complete MFA verification. If the partner account has not registered for MFA with Azure AD 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 AD. When setting up federation in Azure AD, the partner administrator can indicate to Azure AD whether the federated identity provider supports MFA or not. If so, Azure AD will redirect the user to the federated identity provider to complete MFA verification. Otherwise, Azure AD will directly prompt the user to complete MFA verification. If the partner account has not registered for MFA with Azure AD 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, Microsoft Graph, etc.) support partners using Partner Delegated Admin Privileges to programmatically manage customer resources. To use 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.

List of common issues

Before applying for technical exception from the MFA requirement, review the list of common issues reported by other partners to understand whether your request is valid.

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 that 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

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 list of common issues in the previous section.

To submit a request for technical exception:

Note

To learn more about the workspaces interface, see Getting around Partner Center.

  1. Sign in to the Partner Center dashboard as Global Admin or Admin Agent.

  2. Select the Help + support tile, then select 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 subtopic, then select next step.

  4. Provide details requested to submit a service request for technical exception and select Submit.

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

Next steps