Partner Security Requirements

• 10/11/2019
• 7 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

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 they have appropriate security protections 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.

Overview

Starting August 1, 2019 all 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 Cloud Solution Provider program guide. 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 delegate admin rights, once these requirements are enforced.

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. This can be accomplished through one of the way following ways

• Implementing the Require MFA for admins and End user protection baseline protection policies feature from Azure Active Directory at no additional cost
• Purchasing Azure Active Directory Premium for each user account. See Planning a cloud-based Azure Multi-Factor Authentication deployment for more information.
• Using a third-party solution to enforce multi-factor authentication for each user account in your partner tenant. See how the security requirements will be enforced for more details to ensure the solution will provide the expected information.

Consideration

Because these requirements apply to all user accounts in your partner tenant, there are several considerations that need to be made to ensure a smooth deployment. These considerations include 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, it is recommended that 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 these protocols do not support multi-factor authentication. To address this limitation a feature known as app passwords can be used to ensure the application or device can 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, it is recommended 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 baseline protection policies, that only allow the use of an authenticator app for verification. In the event your organization has a policy that prevent the use of mobile devices, then you should 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 that leverages 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. The following is a list of examples of applications or services that should be considered

• 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, it is recommended to query the Azure Active Directory audit logs. This can be accomplished using the Azure PowerShell module and the script below. It will generate a report that provides insight into what authentication attempts have occurred over the past day that were not challenged for multi-factor authentication.

Login-AzAccount
$context = Get-AzContext

function Get-SignInEvents
{
    param([string]$userId)

    $content = '{"startDateTime":"' + (Get-Date).AddDays(-1).ToUniversalTime().ToString("yyyy-MM-ddT05:00:00.000Z") + '","endDateTime":"' + (Get-Date).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")  + '","userId":"' + $userId +'","riskState":[],"totalRisk":[],"realtimeRisk":[],"tokenIssuerType":[],"isAdfsEnabled":false}'

    $token = [Microsoft.Azure.Commands.Common.Authentication.AzureSession]::Instance.AuthenticationFactory.Authenticate($context.Account, $context.Environment, $context.Tenant.Id, $null, "Never", $null, "74658136-14ec-4630-ad9b-26e160ff0fc6")

    $headers = @{
    'Authorization' = 'Bearer ' + $token.AccessToken
    'Content-Type' = 'application/json'
        'X-Requested-With'= 'XMLHttpRequest'
        'x-ms-client-request-id'= [guid]::NewGuid()
        'x-ms-correlation-id' = [guid]::NewGuid()
    }

    Invoke-RestMethod -Body $content -Header $headers -Method POST -Uri "https://main.iam.ad.ext.azure.com/api/Reports/SignInEventsV3"
}

$report = $()

Get-AzADUser | foreach {
    $events = Get-SignInEvents $_.Id
    $report += $events.Items
}

$report | Where-Object {$_.mfaRequired -eq $false -and $_.loginSucceeded -eq $true} | Select-Object userPrincipalName, userDisplayName, createdDateTime, resourceDisplayName, loginSucceeded, failureReason, mfaRequired, mfaAuthMethod, mfaAuthDetail, mfaResult, @{Name='policies'; Expression={[string]::join(',', $($_.conditionalAccessPolicies | Select-Object displayName).displayName )}}, conditionalAccessStatus | Export-Csv report.csv

After running the above script, the details will be available in the report.csv file. It will contain a list of authentication attempts that have occurred over the last day where the user was not challenged for MFA. You will need to review each entry to determine if this is the expected behavior and act if necessary.

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. If you are using Azure Multi-Factor Authentication or the baseline protection policies, then 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. See Testing the Partner Security Requirements for information on how to verify your solution is issuing the expected claim.

Resources and support

The following are resources where you can find support and sample code

• Partner Center Security Guidance Group community - This is 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 is an article that provides details on how to implement the Secure Application Model framework using PowerShell.