Требование многофакторной идентификации (MFA) для клиента партнера

Соответствующие роли: агент администрирования | Агент продаж | Агент helpdesk | Администратор выставления счетов | Администратор безопасности

Повышение безопасности, а также постоянные гарантии безопасности и конфиденциальности являются одними из наших главных приоритетов, и мы продолжаем помогать партнерам защищать своих клиентов и клиентов.

Чтобы помочь партнерам защитить свои предприятия и клиентов от кражи удостоверений и несанкционированного доступа, мы активировали дополнительные средства защиты для клиентов-партнеров. Эти меры защиты обеспечивают мандат и проверяют MFA. Управление MFA помогает партнерам защитить доступ к ресурсам клиентов в отношении компрометации учетных данных.

---

В этой статье приведены подробные примеры и рекомендации по настройке многофакторной проверки подлинности (MFA) в Центре партнеров.

Партнеры, участвующие в программе поставщик облачных решений (CSP), панель управления поставщиков (CPV) и помощники должны реализовать требования к безопасности партнеров для обеспечения соответствия требованиям.

Партнеры обязаны применять многофакторную проверку подлинности (MFA) для всех учетных записей пользователей в своем арендаторе клиента, в том числе для гостевых пользователей. Пользователи должны выполнить проверку MFA для следующих областей:

• Центр партнеров
• API Центра партнеров
• Делегированное администрирование партнера

Центр партнеров

Некоторые страницы в Центре партнеров защищены MFA, в том числе:

• Все страницы на вкладке "Клиенты" (то есть все страницы с URL-адресом, начинающимся с https://partner.microsoft.com/commerce/*)
• Все страницы на вкладке "Запросы клиентов поддержки>" (например, все страницы, к которым обращается URL-адрес, начинающийся с )https://partner.microsoft.com/dashboard/v2/support/customers/*
• Все страницы на вкладке "Выставление счетов "

Другие страницы в Центре партнеров, такие как страница обзора и страница проверки состояния работоспособности служб, не требуют многофакторной проверки подлинности.

---

В следующей таблице показано, какие типы пользователей авторизованы для доступа к этим страницам с защитой MFA (и влияют на эту функцию).

Страница, защищенная с помощью MFA	Агенты администрирования	Агенты по продажам	Агенты службы технической поддержки	Администратор безопасности	Администратор выставления счетов
Все страницы на вкладке "Клиенты"	x	x	x
Все страницы на вкладке "Запросы клиентов в службу поддержки>"	x		x
Страница выставления счетов	x			x	x
Рабочая область безопасности	x			x

Чтобы получить доступ к этим страницам, необходимо сначала выполнить проверку MFA.

Поддерживаемые параметры MFA

• Партнеры, использующие многофакторную проверку подлинности Microsoft Entra. Дополнительные сведения см. в разделе "Несколько способов включения многофакторной проверки подлинности Microsoft Entra" (поддерживается MFA)
• Партнеры, которые реализовали интегрированную федеративную проверку подлинности MFA. Эти пользователи-партнеры могут получить доступ к Центру партнеров и управлять клиентами с помощью GDAP. Ознакомьтесь с интегрированными поставщиками MFA с предложениями MFA, доступными в AD FS: настройка методов для AD FS.

Внимание

Партнерам необходимо использовать поставщик проверки подлинности, совместимый с интегрированным утверждением MFA идентификатора Майкрософт. Встроенное утверждение указывает фактический тип учетных данных, предоставленный во время проверки подлинности. Партнерам необходимо использовать интегрированную MFA для управления клиентами с помощью GDAP.

Центр партнеров и интерфейсы API

Для следующих API Центра партнеров требуются MFA для доступа приложений и пользователей и поддержки идентификаторов Microsoft Entra ID:

• Обнаружение (цена/каталог/продвижение)
• Транзакция и управление ими
• Выставление счетов и выверка
• Управление клиентами с помощью делегированного доступа/AOBO
• Назначение пользователей и лицензий (только с DAP)
• Назначение пользователей и лицензий (с GDAP)
• Детализированные отношения администратора запрос и назначение доступа

Для партнеров доступны следующие варианты:

• Используйте встроенные методы проверки подлинности Майкрософт для удовлетворения требований MFA.
• Если вы используете федеративный поставщик удостоверений, убедитесь, что федерация настроена для принятия федеративной MFA.
• Если вы хотите использовать ADFS для настройки внешнего второго фактора, ознакомьтесь со сторонними поставщиками с предложениями MFA, доступными в AD FS: настройка методов проверки подлинности для AD FS
• Реализуйте MFA: немедленно включите MFA через параметры безопасности по умолчанию или условный доступ, следуя рекомендациям по безопасности по умолчанию.

Примеры проверки

Чтобы иллюстрировать работу проверки в Центре партнеров, рассмотрим следующие примеры.

Пример 1. Партнер реализовал многофакторную проверку подлинности Microsoft Entra

1. Alejandra работает для CSP с именем Contoso. Компания Contoso реализовала MFA для всех пользователей в клиенте партнера Contoso с помощью многофакторной проверки подлинности Microsoft Entra.

2. Alejandra запускает новый сеанс браузера и переходит на страницу обзора Центра партнеров (которая не защищена MFA). Центр партнеров перенаправляет Alejandra в Идентификатор Microsoft Entra для входа.

3. Из-за существующей установки многофакторной проверки подлинности Microsoft Entra компании Contoso для завершения проверки MFA требуется Alejandra. После успешного входа и проверки MFA Alejandra перенаправляется обратно на страницу обзора Центра партнеров.

4. Alejandra пытается получить доступ к одной из страниц, защищенных MFA, в Центре партнеров. Так как Alejandra завершил проверку MFA во время входа ранее, Alejandra может получить доступ к защищенной MFA странице без необходимости повторно пройти проверку MFA.

Пример 2. Партнер реализовал не Microsoft MFA с помощью федерации удостоверений

1. Prashob работает для CSP с именем Wingtip. Wingtip реализовал MFA для всех пользователей в клиенте партнера Wingtip с помощью MFA, отличного от Майкрософт, который интегрирован с Идентификатором Microsoft Entra через федерацию удостоверений.

2. Prashob запускает новый сеанс браузера и переходит на страницу обзора Центра партнеров (которая не защищена MFA). Центр партнеров перенаправляет Prashob на идентификатор Microsoft Entra для входа.

3. Так как Wingtip имеет федерацию удостоверений, идентификатор Microsoft Entra перенаправляет Prashob на федеративный поставщик удостоверений, чтобы завершить вход и проверку MFA. После успешного входа и проверки MFA prashob перенаправляется обратно в идентификатор Microsoft Entra ID, а затем на страницу обзора Центра партнеров.

4. Prashob пытается получить доступ к одной из страниц, защищенных MFA, в Центре партнеров. Так как Prashob уже завершил проверку MFA во время входа ранее, он может получить доступ к защищенной странице MFA, не требуя повторной проверки MFA.

5. Затем Prashob переходит на страницу управления службами, чтобы добавить пользователей в идентификатор Microsoft Entra Contoso. Так как Prashob использовал поставщик проверки подлинности, совместимый с Entra, с строгой проверкой подлинности, он может получить доступ к клиенту клиента без каких-либо проблем.

Рекомендация prashob в этом примере — использовать решение многофакторной проверки подлинности Microsoft Entra или поставщик проверки подлинности, совместимый с Entra, чтобы они могли успешно управлять клиентом клиента.

Пример 3. Партнер не реализовал MFA

1. Партнер CSP с именем Fabrikam еще не реализовал MFA. Корпорация Майкрософт рекомендует реализовать решение MFA, поддерживаемое идентификатором Microsoft Entra.

2. Джон работает на Fabrikam. Fabrikam не реализовал MFA для пользователей в клиенте партнера Fabrikam.

3. Джон запускает новый сеанс браузера и переходит на страницу обзора Центра партнеров (которая не защищена MFA). Центр партнеров перенаправляет Джона в идентификатор Microsoft Entra для входа.

4. После успешного входа Джон перенаправляется обратно на страницу обзора Центра партнеров, так как он не завершил проверку MFA.

5. Он пытается перейти на одну из страниц в Центре партнеров, защищенных с помощью MFA. Так как Джон не завершил проверку MFA, Центр партнеров перенаправляет Джона в Идентификатор Microsoft Entra для завершения проверки MFA. Поскольку это первый раз, когда Джон должен завершить MFA, Джон также запрашивается зарегистрировать для MFA. После успешной регистрации MFA и проверки MFA Джон может получить доступ к странице, защищенной MFA.

6. В другой день, прежде чем Fabrikam реализует MFA для любого пользователя, Джон запускает новый сеанс браузера и переходит на страницу обзора Центра партнеров (которая не защищена MFA). Центр партнеров перенаправляет Джона в идентификатор Microsoft Entra для входа без запроса MFA.

7. Он пытается перейти на одну из страниц в Центре партнеров, защищенных с помощью MFA. Так как Джон не завершил проверку MFA, Центр партнеров перенаправляет Джона в Идентификатор Microsoft Entra для завершения проверки MFA. Потому что Джон зарегистрировал MFA, на этот раз он попросил завершить проверку MFA.

Пример 4. Партнер реализовал не microsoft MFA, несовместимый с Microsoft Entra

1. Trent работает для CSP с именем Wingtip. Wingtip реализовал MFA для всех своих пользователей в клиенте партнера Wingtip, используя не Microsoft MFA в облачной среде с условным доступом.

2. Трент запускает новый сеанс браузера и переходит на страницу обзора Центра партнеров (которая не защищена MFA). Центр партнеров перенаправляет Trent на идентификатор Microsoft Entra для входа.

3. Так как Wingtip использовал интеграцию mFA, не совместимую с идентификатором Microsoft Entra и не имеет строгой проверки подлинности, Trent будет заблокирован доступ ко всем защищенным страницам и API MFA в Центре партнеров.

Так как Трент обращается к защищенным страницам MFA, он должен представить MFA с строгой проверкой подлинности для получения доступа к защищенным страницам MFA.

Партнеры должны использовать поставщик проверки подлинности, совместимый с идентификатором Microsoft Entra, который поддерживает утверждение метода учетных данных ("утверждение amr" в справочнике по утверждениям маркера доступа — платформа удостоверений Майкрософт, отражая фактический тип учетных данных, предоставленный во время проверки подлинности.

Мы настоятельно рекомендуем партнерам CSP реализовать MFA, совместимую с идентификатором Microsoft Entra ID немедленно, чтобы повысить базовые показатели безопасности вашего клиента.

API Центра партнеров

API Центра партнеров поддерживает проверку подлинности только для приложений, а также проверку подлинности пользователей (App+User).

При использовании проверки подлинности app+User Центр партнеров требует проверки MFA. В частности, когда партнерское приложение отправляет запрос API в Центр партнеров, он должен включать маркер доступа в заголовок авторизации запроса.

Примечание.

Платформа "Модель безопасных приложений" — это масштабируемая платформа для аутентификации партнеров CSP и CPV через архитектуру Microsoft Azure MFA при вызове API Центра партнеров. Эту платформу необходимо реализовать при использовании MFA в службе автоматизации служб.

Когда Центр партнеров получает запрос API с маркером доступа, полученным с помощью проверки подлинности App+User, API Центра партнеров проверяет наличие значения MFA в утверждении "Справочник по методу проверки подлинности" (AMR). С помощью декодера JWT можно проверить, содержит ли маркер доступа ожидаемое значение ссылки на метод проверки подлинности (AMR).

{
  "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": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

• Если это значение присутствует, Центр партнеров убедится, что проверка MFA выполнена, и обработает запрос к API.

• Если значение отсутствует, API Центра партнеров отклоняет запрос со следующим ответом:

  HTTP/1.1 401 Unauthorized - MFA required
  Transfer-Encoding: chunked
  Request-Context: appId=cid-v1:11112222-bbbb-3333-cccc-4444dddd5555
  WWW-Authenticate: Bearer error="invalid_token"
  Date: Thu, 14 Feb 2019 21:54:58 GMT
  

При вызове API Центра партнеров маркеры доступа только для приложений поддерживаются только для операций, которые не требуют назначения ролей GDAP в клиенте клиента.

Дополнительные рекомендации см. в статье "Проверка подлинности и авторизация API" — обзор.

Делегированное администрирование партнера

Клиенты партнеров должны использовать делегированные права администратора (GDAP) для управления ресурсами клиентов с помощью порталов Microsoft Online Services (portal.azure.com или admin.microsoft.com), интерфейса командной строки (CLI) и API -интерфейсов (с помощью проверки подлинности приложений и пользователей). Дополнительные сведения см. в поддерживаемых параметрах MFA.

Использование порталов служб

Партнеры CSP могут администрировать своих клиентов с портала Центра партнеров через интерфейс управления службами. Партнеры могут перейти к клиенту и выбрать управление службами, чтобы иметь возможность администрировать определенную службу для клиента. Партнеры должны следовать рекомендациям по роли GDAP, чтобы получить правильную роль GDAP для управления клиентами.

При доступе к порталам Microsoft Online Services с помощью делегированных прав администратора партнера (admin-On-Behalf-Of) для управления ресурсами клиентов многие из этих порталов требуют интерактивной проверки подлинности учетной записи партнера с клиентом Microsoft Entra, заданным в качестве контекста проверки подлинности. Для входа в клиент клиента требуется учетная запись партнера.

Проверка подлинности идентификатора Microsoft Entra требует, чтобы пользователь выполнил проверку MFA, если существует политика, требующая многофакторной проверки подлинности. Существуют два возможных варианта входа для пользователя, в зависимости от того, использует учетная запись партнера управляемое или федеративное удостоверение.

• Если учетная запись партнера является управляемым удостоверением, идентификатор Microsoft Entra напрямую предложит пользователю завершить проверку MFA. Если учетная запись партнера не зарегистрирована для MFA с идентификатором Microsoft Entra ID раньше, пользователю будет предложено сначала завершить регистрацию MFA.

• Если учетная запись партнера является федеративной , интерфейс зависит от того, как администратор партнера настроил федерацию в идентификаторе Microsoft Entra ID. При настройке федерации в идентификаторе Microsoft Entra администратор партнера может указать идентификатор Microsoft Entra, поддерживает ли федеративный поставщик удостоверений MFA или нет.

  • Если это так, идентификатор Microsoft Entra перенаправляет пользователя на федеративный поставщик удостоверений, чтобы завершить проверку MFA.
  • В противном случае идентификатор Microsoft Entra напрямую предложит пользователю завершить проверку MFA. Если учетная запись партнера не зарегистрирована для MFA с идентификатором Microsoft Entra ID раньше, пользователю будет предложено сначала завершить регистрацию MFA.

Общий интерфейс похож на сценарий, в котором клиент клиента реализовал MFA для своих администраторов. Например, клиент клиента включил параметры безопасности Microsoft Entra, для которых требуются все учетные записи с правами администратора для входа в клиент с проверкой MFA, включая агентов администрирования и агентов helpdesk.

В целях тестирования партнеры могут включить значения по умолчанию безопасности Microsoft Entra в клиенте клиента, а затем попытаться использовать права делегированного администрирования партнера (GDAP) для доступа к клиенту клиента.

Примечание.

Не все порталы Microsoft Online Service требуют, чтобы учетные записи партнеров входить в клиент клиента при доступе к ресурсам клиентов с помощью GDAP. Вместо этого для входа в клиент партнера требуются только учетные записи партнеров. Примером является центр администрирования Exchange. Со временем мы ожидаем, что эти порталы требуют, чтобы учетные записи партнеров входить в клиент клиента при использовании GDAP.

Процедура регистрации для использования MFA

При проверке MFA, если учетная запись партнера не зарегистрирована для MFA раньше, идентификатор Microsoft Entra предложит пользователю сначала завершить регистрацию MFA.

Дополнительные сведения о методе Microsoft Authenticator:

После нажатия кнопки "Далее" пользователю предлагается выбрать из списка методов проверки.

После успешной регистрации пользователь должен завершить проверку MFA с помощью выбранного метода проверки.

Распространенные проблемы

Чтобы понять, является ли запрос допустимым, просмотрите список распространенных проблем, сообщаемых другими партнерами.

Проблема 1. Партнеру требуется больше времени для реализации MFA для своих партнеров

Партнер еще не начал или не завершил реализацию MFA для своих агентов, которым требуется доступ к порталам Microsoft Online Services для управления ресурсами клиентов с помощью делегированных прав администратора партнера. Партнеру требуется больше времени, чтобы завершить реализацию MFA. Является ли это веской причиной для технического исключения?

Ответ: Нет. Партнеру необходимо планировать реализацию MFA для своих пользователей, чтобы избежать нарушений.

Примечание.

Несмотря на то, что партнер не реализовал MFA для своих агентов партнеров, агенты партнеров по-прежнему могут получать доступ к порталам Microsoft Online Services с помощью привилегий делегированного администрирования партнера, если они могут завершить регистрацию MFA и проверку MFA при появлении запроса во время входа в клиент клиента. После регистрации в службе MFA проверка MFA не включается для пользователя автоматически.

Проблема 2. Партнер не реализовал MFA, так как им не нужен доступ к управлению клиентами

У партнера есть некоторые пользователи в своих клиентах партнеров, которые не требуют доступа к порталам Microsoft Online Services для управления ресурсами клиентов с помощью привилегий делегированного администрирования партнера. Этот партнер находится в процессе реализации MFA для этих пользователей, и для его завершения требуется больше времени. Является ли это веской причиной для технического исключения?

Ответ: Нет. Так как эти учетные записи пользователей не используют привилегии делегированного администрирования партнера для управления ресурсами клиентов, они не потребуются для входа в клиент клиента. Они не будут затронуты идентификатором Microsoft Entra, требующим проверки MFA во время входа в клиент клиента. Все пользователи должны иметь MFA для доступа к Центру партнеров или рабочим нагрузкам клиента для управления ресурсами клиента.

Проблема 3. Партнер не реализовал MFA для учетных записей службы пользователей

В арендаторах партнера есть учетные записи, используемые устройствами как учетные записи службы. Эти учетные записи с низким уровнем привилегий не требуют доступа к Центру партнеров или порталам Microsoft Online Services для управления ресурсами клиентов с помощью привилегий делегированного администрирования партнера. Является ли это допустимой причиной технического исключения?

Ответ: Нет. Так как эти учетные записи пользователей не используют права делегированного администрирования партнера для управления ресурсами клиентов, они не требуются для входа в клиент. Они не будут затронуты идентификатором Microsoft Entra, требующим проверки MFA во время входа в клиент клиента. Если API или портал требует проверки подлинности приложения и пользователя, каждый пользователь должен использовать MFA для проверки подлинности.

Проблема 4. Партнер не может реализовать MFA с помощью приложения Microsoft Authenticator

Партнер имеет политику "чистого стола", которая не позволяет сотрудникам принести свои личные мобильные устройства в рабочую область. Без доступа к личным мобильным устройствам сотрудники не могут установить приложение Microsoft Authenticator, которое является единственной проверкой MFA, поддерживаемой по умолчанию безопасности Microsoft Entra. Является ли это веской причиной для технического исключения?

Ответ: Нет. Партнер должен рассмотреть следующую альтернативу, чтобы их сотрудники по-прежнему могли завершить проверку MFA при доступе к Центру партнеров:

• Партнер также может зарегистрироваться в Microsoft Entra ID P1 или P2 или использовать решения, отличные от Майкрософт MFA, совместимые с идентификатором Microsoft Entra, которые могут предоставлять дополнительные методы проверки. Дополнительные сведения см. в статье о поддерживаемых методах проверки подлинности.

Проблема 5. Партнер не может реализовать MFA из-за использования устаревших протоколов проверки подлинности

Некоторые агенты партнера все еще используют устаревшие протоколы аутентификации, не совместимые с MFA. Например, пользователи по-прежнему используют приложение Outlook 2010, основанное на устаревших протоколах аутентификации. Включение MFA для этих агентов партнера нарушит работу устаревших протоколов аутентификации. Является ли это веской причиной для технического исключения?

Ответ: Нет. Партнерам рекомендуется уйти от использования устаревших протоколов проверки подлинности из-за потенциальных последствий безопасности, так как эти протоколы не могут быть защищены с помощью проверки MFA и гораздо более подвержены компрометации учетных данных. Рекомендуется не рекомендуется использовать устаревшую проверку подлинности и использовать параметры безопасности по умолчанию или условный доступ. Чтобы подготовиться к переходу от устаревшей проверки подлинности, просмотрите входы с помощью книги устаревшей проверки подлинности и инструкции по блокировке устаревшей проверки подлинности.

Чтобы понять последний план поддержки устаревшей проверки подлинности для Outlook, ознакомьтесь со статьей об базовой проверке подлинности и Exchange Online и следуйте блогу команды Exchange, чтобы получить предстоящие новости.

Проблема 6. Партнер реализовал не microsoft MFA, который не распознается идентификатором Microsoft Entra

Партнер реализовал MFA для своих пользователей с помощью решения MFA, отличного от Майкрософт. Однако партнеру не удается правильно настроить решение MFA, отличное от Майкрософт, для ретрансляции идентификатора Microsoft Entra, который проверка MFA была завершена во время проверки подлинности пользователя. Является ли это веской причиной для технического исключения?

Ответ. Нет, партнеры должны использовать поставщик проверки подлинности, совместимый с идентификатором Microsoft Entra, который поддерживает утверждение метода учетных данных ("AMR"), справочник по утверждениям маркера доступа — платформа удостоверений Майкрософт, отражая фактический тип учетных данных, предоставленный во время проверки подлинности.

Мы настоятельно рекомендуем реализовать MFA, совместимую с идентификатором Microsoft Entra ID, немедленно повысить базовые показатели безопасности клиента.

Связанный контент

• Состояние требований к безопасности партнера