How to validate your solution

[idwilliams]

Microsoft will soon be requiring multi-factor authentication when accessing Partner Center Dashboard and the Partner Center API when using app + user authentication. The Partner Center platform will be checking the access token sent with each request for the presences of the MFA claim. If that claim is not present, then you will not be able to access Partner Center resources through the dashboard or API. There are numerous solutions that you can implement to fulfill this requirement. It is important that you verify your solution is compliant with how Microsoft will be enforcing this requirement. You can use one of the following methods to validate your solution will work with how this requirement will be enforced.

Partner Center PowerShell

Starting with version 1.5.1902.4 of the PartnerCenter and PartnerCenter.NetCore, you can leverage the Connect-PartnerCenter commnad with the EnforceMFA  parameter to instruct Partner Center to require multi-factor authentication for each request. This parameter will only be available until Microsoft starts enforcing this requirement. At that point it will be removed from the PowerShell module. The following is example of how you can use this command to validate your solution 

Connect-PartnerCenter -ApplicationId fa2e5f2b-d98e-42d4-9891-cbcb51e6b960 -EnforceMFA

Note there are several ways you can invoked the Connect-PartnerCenter command. The above example will prompt you for credentials. In the event you would like to connect using an access token, then see the Powershell Secure Application Model documentation for more information. If your solution is not compliant you will receive the following error

Connect-PartnerCenter : Unauthorized - MFA required

Partner Center REST API

When you are working directly with the Partner Center REST API there are several headers you can send with each request. Headers such as MS-CorrelationId, MS-RequestId, and X-locale are the most commonly used because they help with troubleshooting and provide localization. To enforce the requirement for multi-factor authentication you can send a header with the name MS-Enforce-MFA with a value of true. This will instruct the Partner Center API to require multi-factor authentication for that specific request. The following is an example request 

GET https://api.partnercenter.microsoft.com/v1/profiles/organization HTTP/1.1
MS-Enforce-MFA: True
Accept: application/json
MS-CorrelationId: 193ecbde-7ee5-42c5-9cf8-c37cfafe4649
X-Locale: en-US
MS-RequestId: 80a925e9-1c94-4b3c-91f4-e8f0ff457047
Authorization: Bearer REMOVED
Host: api.partnercenter.microsoft.com

This header will only impact the requests being made when using app + user authentication. App only authentication is not impacted by this requirement. If the method you used to generate the access token is compliant with how Microsoft is going to enforce the requirement for multi-factor authentication, then the request will return the data as excepted. However, if your solution is compliant you will receive a response similar to the following

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

0

Manually validate 

You can validate your solution manually, by using tools such as Fiddler to intercept the HTTP operations made by browsing to Partner Center Dashboard or tasks perform by any automation you have developed. This will allow you to extract the access token sent with each request. Below is an example request made to the Partner Center API. 

GET https://api.partnercenter.microsoft.com/v1/profiles/organization HTTP/1.1
MS-Enforce-MFA: True
Accept: application/json
MS-PartnerCenter-Client: Partner Center PowerShell
MS-CorrelationId: 193ecbde-7ee5-42c5-9cf8-c37cfafe4649
X-Locale: en-US
MS-RequestId: 80a925e9-1c94-4b3c-91f4-e8f0ff457047
MS-SdkVersion: 1.5.1902.4
Authorization: Bearer REMOVED
User-Agent: FxVersion/4.8.3740.0 OSName/Windows OSVersion/10.0.18334.0 Microsoft.Store.PartnerCenter.Network.PartnerServiceClient/1.5.1902.4
Host: api.partnercenter.microsoft.com

Note the access token value has replaced with the word REMOVED in the above sample. To validate your solution copy the entire value that follows Authorization: Bearer. Then will you will decode the token using the JWT Decoder, and you will want to verify that mfa is listed in the amr element. The following shows what a decoded access token look like

{
  "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": "Williams",
  "given_name": "Isaiah",
  "ipaddr": "127.0.0.1",
  "name": "Isaiah Williams",
  "oid": "4988e250-5aee-482a-9136-6d269cb755c0",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "df845f1a-7b35-40a2-ba78-6481de91f8ae",
  "unique_name": "Isaiah.Williams@testtestpartner.onmicrosoft.com",
  "upn": "Isaiah.Williams@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

Note that some values have been removed from the above sample. You will want to verify that amr element, which has been bolded in the sample, contains mfa. If it does not, then your solution is not compliant with how Microsoft will enforce the requirement for multi-factor authentication.

What if my solution is not compliant?

There are several reasons your solution might not be compliant with the requirement for multi-factor authentication. If you find yourself with a solution that does not validate using any of the step above, then I would like to encourage to post a new topic in the appropriate category. This will us provide the proper guidance for whatever is causing your solution to not be compliant.

[bepplerc]

I tried to run then example powershell script, but got the following error:

Connect-PartnerCenter : AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials

[JanoschUlmer]

@bepplerc Have you tried to use the -TenantID parameter to point to a certain tenant?

[VNJoe]

There needs to be a more user-friendly method to validate.  We don't have time to become SME's on this topic with PowerShell and Fiddler and all that, so a simple test script for a user/tenant and a 'Yes' or 'No' page would go a long way.

[Morten_Knudsen]

I have enabled MFA + policies on my tenant. How can I verify that I'm compliant ??

What are the specific parameters that MS will count as "you are compliant" - MS Secure Score, Policies,  etc

If I use create 2 conditional access policies with some exclusions (service accounts), will I still be compliant

When will the message on Partner Center go away "Implement partner security requirements immediately to safeguard your CSP business."

[JanoschUlmer]

@Morten_Knudsen : Technical documentation was updated on how to use Secure Score to do some validation: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements#assessing-your-environment

Note that exclusions from MFA for service accounts are generally not compliant.

[bepplerc]

Thanks!

Using the docs I found the following sites:

https://protection.office.com/homepage

https://security.microsoft.com/securescore

In there I found the information.

[Morten_Knudsen]

We cannot use this, as MS doesn't allow service-accounts to not use MFA, when we are MS partners.

We have many Azure Automation jobs, that I cannot get to work - maybe I'm missing a link here, but I cannot get Connect-MSOLService, Connect-MSOline og Connect-ExchangeOnlineShell to work with Azure Service Principal or Azure PS Automation credentials, when user is locked down with MFA.

How will MS fix this - and when ??

[PatrickP]

Is this still an issue or can we enable MFA for service accounts without it braking anything?

[JanoschUlmer]

@PatrickP  Enabling MFA for service accounts can break several scenarios, this is unchanged (and will not ever change unless we talk about a specific scenario and can be more specific on what a solution can be).

You can adjust your service accounts to use secure app model or use app passwords or there might be no direct solution for a given service/solution/client. All depends on which service this is account is used for.

[JanoschUlmer]

For Exchange Online Powershell the known issue/solution is documented since a few weeks: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements#known-issues

The same solution might also apply to other services.

Specifically for Azure Automation - it would help to get a more complete picture on what is being done and where (Azure Automation running in your Partner tenant connecting to services in customer tenant? Which Moduls are being used? Which services do you need to connect to). Maybe better to start a fresh thread for this.

You have reviewed the Powershell specific guidance on secure app model already? https://docs.microsoft.com/en-us/partner-center/develop/enable-secure-app-model#powershell 

[Morten_Knudsen]

Regarding the workaround:

For Exchange Online Powershell the known issue/solution is documented since a few weeks: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements#known-issues

Question:

1. Does that mean, that we don't have to enable MFA on the user that we create, even though it is an admin. 

2. We will still be compliant, event though this user is not running MFA

3. Should I add the credential in Azure Automation - and then use 

here is a sample automation job, which I'm trying to use

Write-Output “Connecting to Azure Automation”

$AzureAutomationAccount = "xxxT ExchangeOnlineShell"

$Credentials = Get-AutomationPSCredential -Name $AzureAutomationAccount

Write-Output “Connecting to Exchange Online”

$Session=New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Credentials -Authentication Basic -AllowRedirection

Import-PSSession -Session $Session -DisableNameChecking:$true -AllowClobber:$true | Out-Null

# Connect-MSOLservice -Credential $Credentials

Write-Verbose “Retrieving all mailbox access from delegates”

$End = Get-Date -format d

$Start = (Get-Date).AddDays(-7)

$MailBoxDelegates += Search-MailboxAuditLog -LogonTypes Delegate -StartDate "$Start" -EndDate "$End"

Write-Output "Building CSV file"

$MailBoxDelegates | Export-Csv MailBoxDelegates.csv

[JanoschUlmer]

@Morten_Knudsen The workarounds means that even when MFA is enabled on this account (or MFA enforcement is done via baseline policies or conditional access for all accounts), this account will still be able to connect without actually seeing an MFA prompt (as long as an interactive login is never performed).

So you can achieve compliance and still be able to use ExO Powershell.

Again, as mentrioned in the article, that is only a temp workaround available until the ExO powershell module is fixed, it is planned to change this behavior in AzureAD to not allow this to work.