Partner Security Requirements

• 08/05/2019
• 16 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’re introducing a set of mandatory security requirements for Advisors, Control Panel Vendors, and partners participating in the Cloud Solution Provider program.

Starting August 1, 2019 all partners are required to enforce multi-factor authentication for all users, including service accounts, in their partner tenant.

The terms associated with the partner security requirements have been added to the Cloud Solution Provider program guide. Starting on August 1, 2019 all partners participating in the Cloud Solution Provider program should be in compliance with the terms. 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. We are in the process of establishing a technical enforcement date for the requirements and will notify partners of the date with detailed information.

What actions do I need to take?

Given the highly privileged nature of being a partner we need to ensure that each user has an MFA challenge for every single authentication. This can be accomplished through one of the following ways

• Implementing Azure AD Premium and ensure that MFA is enforced for each user
• Implementing the baseline protection policies
• Implementing a third-party solution and ensure MFA is enforced for each user

Considerations

Because these requirements apply to all users, including service accounts, in your partner tenant, there are several considerations that need to be made to ensure a smooth deployment. These considerations include identifying users in Azure AD that cannot perform MFA, 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 MFA when authenticating?

When you enforce MFA legacy authentication use protocols such as IMAP, POP3, SMTP, etc. will be blocked because these protocols do not support MFA. 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 why 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 MFA, it 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 MFA solution you implement. There are MFA solutions, such as the one provided through the implementation of the 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 MFA for each user in the partner tenant that provides the most appropriate verification option
• Purchasing Azure AD Premium licenses for the impacted users

Support for the use of FIDO security keys is on the road map for the baseline protection policies. Once support has been added, you will be able to leverage FIDO security keys for the second factor of authentication. Until then you are limited to the use of the Authenticator App.

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 MFA, you should implement the guidance in the Secure Application Model framework where possible. The following are additional resources that will help you understand how the Secure Application Model framework can be implemented

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

Enforcing MFA for all users

This section will cover how you can use the baseline protection policies to enforce MFA for each user, including service accounts, in your partner tenant. If you are planning to use Azure AD Premium, then follow the steps documented here.

Baseline protection 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 protection 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 protection 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 using the Authenticator App for verification at no additional cost.

Configure Self Service Password Reset

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

When the End user protection baseline protection policy is enabled, any compromised user accounts will be blocked until their password is reset and the 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 so they do not get locked out.

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.

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.

Assessing your environment

Through one of the current partner security requirements, you are required to have MFA enforced for each user in your partner tenant. Since this requirement can be fulfilled through a number of different methods it can prove difficult to assess if any additional actions are required. You can leverage tools like the Azure Active Directory audit logs and Microsoft Secure Score to evaluate if any additional actions are required to secure your tenant with the MFA. Microsoft is working on an experience in Partner Center to provide a quick compliance check on the MFA and the Secure Application Model requirements.

Microsoft Secure Score gives you robust visualizations, integration with other Microsoft products, comparison of your score with other companies, filtering by category, and much more. With this tool, you can complete security improvement actions within your organization and track the history of your score. The score can also reflect when third-party solutions have addressed recommended improvement actions.

Microsoft Secure Score will only provide a numerical representation of your security posture. To better understand what or who is authenticating without being challenged for MFA, 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 MFA.

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

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

You can work around this limitation by creating a new account and never using it to perform an interactive authentication. It is recommended that you leverage Azure AD PowerShell to create the new account and perform the initial configuration. The following PowerShell can be used to create and configure the account

Import-Module AzureAD
Connect-AzureAD

$PasswordProfile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile

$PasswordProfile.Password = "Password"
$PasswordProfile.ForceChangePasswordNextLogin = $false

$user = New-AzureADUser -DisplayName "New User" -PasswordProfile $PasswordProfile -UserPrincipalName "NewUser@contoso.com" -AccountEnabled $true

# Uncomment the following two lines if you want the account to have Admin Agent privileges
# $adminAgentsGroup = Get-AzureADGroup -Filter "DisplayName eq 'AdminAgents'"
# Add-AzureADGroupMember -ObjectId $adminAgentsGroup.ObjectId -RefObjectId $user.ObjectId

Next time you connect to Exchange Online through PowerShell use this account, it will work as expected.

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.