Перенос приложений CPV/CSP на использование подробных делегированных прав администратора

Статья
11/10/2023

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

Внимание

Azure Active Directory (Azure AD) Graph не рекомендуется использовать с 30 июня 2023 г. Идти вперед, мы не делаем дальнейших инвестиций в Azure AD Graph. API Azure AD Graph не имеют соглашения об уровне обслуживания или обслуживании за пределами исправлений, связанных с безопасностью. Инвестиции в новые функции и функциональные возможности будут сделаны только в Microsoft Graph.

Мы отставим Azure AD Graph на добавочных шагах, чтобы у вас было достаточно времени для переноса приложений в API Microsoft Graph. На более позднюю дату, которую мы объявим, мы заблокируем создание новых приложений с помощью Azure AD Graph.

Дополнительные сведения см. в статье "Важно: выход на пенсию в Azure AD Graph и отключение модуля PowerShell".

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

Сравнение GDAP с DAP

Модель GDAP заменяет модель делегированных прав администратора (DAP), и она не совместима с обратной совместимостью. Модель DAP устарела.

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

Риск использования преконсервов еще больше усиливается, так как партнеры не могут просматривать или проверять согласие. Хотя на странице приложения Microsoft Entra Enterprise отображается другое согласие, оно не показывает приложения, которые предварительно согласились. Это устаревшее поведение не соответствует концепции минимальных прав в платформа удостоверений Майкрософт.

В модели GDAP клиент или администратор с отношением от имени (OBO) с клиентом дает согласие на то, чтобы приложения, управляемые партнером, могли использовать свой клиент. Это поведение обеспечивает трассировку для клиента и соответствует модели приложения платформа удостоверений Майкрософт и платформе безопасной модели приложений.

GDAP не требует создания определенной связи или группы безопасности для субъекта-службы приложений.

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

Разрешения приложения и роли Microsoft Entra

Разрешения приложений можно назначить в идентификаторе Microsoft Entra на вкладке разрешений API.

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

Согласие приложения — это процесс предоставления владельца ресурса авторизации клиентскому приложению для доступа к защищенным ресурсам в соответствии с определенными разрешениями от имени владельца ресурса.

В следующей таблице перечислены модели службы приложений, которые работают с согласием приложения.

Модель приложения	Согласие для приложения	ОБО
Мультитенантное приложение (только DAP, не поддерживаемое в GDAP)	Да	Нет
Мультитенантное приложение + пользователь	Да	Нет
Мультитенантное приложение + пользователь + OBO	Да	Требуется связь GDAP

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

Центр партнеров предоставляет API, позволяющий CPV или CSP предоставить согласие приложению через автоматизацию в клиенте клиента. Явное приложение + согласие пользователя требуется для каждого клиента.

Шаблон приложения + пользователя учитывает контракт с минимальными минимальными правами, которым управляет GDAP. Дополнительные сведения см. в разделе:

Этот API требует, чтобы вызывающий пользователь-партнер был членом группы безопасности, которая имеет связь GDAP с целевым клиентом или клиентом. Связь GDAP и связанная группа безопасности должны включать по крайней мере одну из этих подтвержденных ролей:

Глобальный администратор
Администратор приложения (заменен администратор привилегированных ролей)
Администратор облачных приложений

Примечание.

Использование администратора привилегированных ролей больше не рекомендуется.

Пользователь-партнер также должен быть членом группы безопасности AdminAgents, которая требуется для вызова API Центра партнеров.

Партнеры могут автоматически предоставить согласие приложению, настроив учетную запись администратора OBO, установив разрешения, создав временный маркер и связав учетную запись с пользователем.

Создайте новую учетную запись пользователя или выберите существующую учетную запись пользователя, которая будет использоваться в качестве учетной записи CPV/CSP OBO (например, AdminOnBehalfOf@contoso.onmicrosoft.com).
Создайте группу безопасности для связи GDAP клиента (например, AdminOnBehalfOfSG).
Добавьте пользователя OBO () в группу безопасности GDAP клиента (AdminOnBehalfOf@contoso.onmicrosoft.comAdminOnBehalfOfSG).
Определите следующие параметры связи GDAP. Вы будете использовать их позже.
- Длительность в днях.
- Запрошенные роли Microsoft Entra, необходимые для OBO.
- Если вы хотите автоматизировать согласие приложения, как описано в предыдущем разделе. Связь GDAP должна включать по крайней мере одну из следующих: администратор облачных приложений, администратор приложений, глобальный администратор для выполнения операции согласия с помощью API.
CPV или CSP создает новую регистрацию мультитенантного приложения или использует существующую регистрацию в клиенте партнера.

Запишите идентификатор приложения (например, A5000000-F000-4000-8000-30000000000000000).
Создайте и обновите маркер обновления OBO с помощью мультитенантного приложения + удостоверения пользователя AdminOnBehalfOf , созданного на шаге 1.

В следующих примерах показано, как создать соответствующий токен с помощью однократного интерактивного входа. Убедитесь, что вход использует многофакторную проверку подлинности (MFA), так как маркер обновления должен быть создан с помощью MFA для работы с сценариями OBO.
Сохраните маркер обновления пользователя OBO в безопасном расположении, к которому можно получить доступ из мультитенантного приложения. Azure Key Vault может быть одним из вариантов, но не требуется. Дополнительные сведения см. в обзоре Azure Key Vault и документации по API Key Vault.

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

Каждый раз, когда необходимо пройти проверку подлинности в клиенте клиента для операций, получите последний маркер обновления из защищенного хранилища и используйте его для создания маркера доступа (и нового маркера обновления) для проверки подлинности.
Для каждого клиента, который будет использовать мультитенантное приложение и для которого вы хотите выполнять действия через делегированное администрирование, выполните следующие действия:
1. Создайте связь GDAP с помощью сведений, определенных на шаге 4.
2. Отправьте связь GDAP для утверждения.
3. После активной связи GDAP назначьте группу безопасности, определенную на шаге 2, с соответствующими ролями Microsoft Entra, определенными на шаге 4.
4. Убедитесь, что администратор предоставил согласие для приложения в клиенте клиента. Для автоматического подхода к согласию можно сделать это после установки GDAP. Для предоставления согласия вручную администратор клиента может сделать это перед настройкой GDAP.

Примечание.

Маркер обновления, созданный на шаге 6, можно использовать для проверки подлинности для каждого клиента. Вам не нужно выполнять шаг 6 для каждого клиента отдельно. При выполнении операций в клиенте клиента вы принимаете изначально созданный токен и обменяете его на маркер, созданный клиентом. Это возможно из-за связи или ролей GDAP и согласия приложения.

Чтобы настроить нескольких клиентов в масштабе, рекомендуется выполнить следующий процесс:

Для новых клиентов, где нет привилегий делегирования, включите одну из необходимых ролей согласия в исходном запросе связи GDAP (например, администратор облачных приложений).

Кроме того, если вы предпочитаете краткосрочное делегирование привилегий, оцените, можно ли использовать второй запрос связи GDAP с коротким сроком (например, один день) с помощью разрешения, позволяющего делегированию согласия (например, администратору облачных приложений). Этот подход позволяет удалить более привилегированную роль после проверки функции согласия. Этот второй запрос GDAP можно удалить вручную в любое время.
В случаях, когда существует привилегия делегирования, и партнер имеет DAP, выполняет автоматическое согласие массово (например, с помощью скрипта new-PartnerCustomerApplicationConsentPowerShell).

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

В этом разделе рассматривается приложение API CPV/CSP и согласие пользователя в клиенте клиента более подробно.

Определение корпоративных приложений и областей (также известных как разрешения)

Для каждого приложения, для которого планируется предоставить согласие, сопоставляйте API приложения и разрешения с полезными данными JSON. Сведения о приложении можно найти в портал Azure, выбрав идентификатор Microsoft Entra: регистрация приложений "ваше приложение", а затем выберите вкладку "Разрешения API".

Выполните действия, описанные в разделе "Проверка первых приложений Майкрософт в отчетах о входе в систему" в идентификаторе Microsoft Entra, чтобы отфильтровать приложения Майкрософт. Найдите API корпоративных приложений, на которые ссылается ваше приложение, и получите идентификаторы конкретных приложений. Эти идентификаторы приложений будут назначены enterpriseApplicationId в следующем примере JSON.

Следующие идентификаторы получены из примеров разрешений приложения:

Имя приложения	Идентификатор приложения == enterpriseApplicationId
Microsoft Entra ID	00000002-0000-0000-c000-000000000000
Microsoft Graph	0000003-0000-0000-c000-0000000000000000000

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

Пример полезных данных JSON:

{
    "applicationId": "57667d41-992a-49b0-99d8-ddf68328373f",
    "applicationGrants": [
        {
            "enterpriseApplicationId":"00000002-0000-0000-c000-000000000000",
            "scope":"Directory.ReadWrite.All"
        },
        {
            "enterpriseApplicationId":"00000003-0000-0000-c000-000000000000",
            "scope":"Directory.ReadWrite.All"
        }
    ]
}

Примечание.

Перед вызовом API убедитесь, что созданный маркер проверки подлинности использует тот же идентификатор приложения, для которого требуется предоставить согласие в клиенте клиента. Вы можете использовать популярный веб-сайт, например jwt.ms для декодирования маркера носителя и обеспечения соответствия идентификаторов приложений. В маркере "appID":"57667d41-992a-49b0-99d8-ddf68328373f" носителя должно соответствовать значению applicationID полезных данных JSON.

Получение понятных имен разрешений и областей

Следующие сведения полезны, если вы хотите обнаружить понятные имена разрешений API приложений, как показано портал Azure в разделе регистрации приложений Microsoft Entra для конкретного приложения.

Получение списка приложений

Запустите graph api get application.

Получение списка идентификаторов приложений и отображаемых имен. Значением id является идентификатор объекта приложения.

https://graph.microsoft.com/v1.0/applications?$select=id,displayName

Получите значение приложенияrequiredResourceAccess, которое содержит API приложения и разрешения, как показано в портал Azure. Замените {applicationObjectId} идентификатор приложения на предыдущем шаге.

https://graph.microsoft.com/v1.0/applications/{applicationObjectId}?$select=requiredResourceAccess](https://graph.microsoft.com/v1.0/applications/{applicationObjectId}?$select=requiredResourceAccess)

Пример ответа:

"requiredResourceAccess": [
    {
        "resourceAppId": "00000003-0000-0000-c000-000000000000",
        "resourceAccess": [
            {
                "id": "885f682f-a990-4bad-a642-36736a74b0c7",
                "type": "Scope"
            },
            {
                "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
                "type": "Scope"
            },
            {
                "id": "06da0dbc-49e2-44d2-8312-53f166ab848a",
                "type": "Scope"
            },
            {
                "id": "c5366453-9fb0-48a5-a156-24f0c49a4b84",
                "type": "Scope"
            }
        ]
    }
]

Получение субъекта-службы

Запустите API Graph get servicePrincipal.

Получите значение определенного субъекта-службы oauth2PermissionScopes . Замените {resourceAppId} значением, возвращаемым в массиве requiredResourceAccess . (Может быть несколько.)

https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appid eq '{resourceAppId}'&$select=oauth2PermissionScopes

Найдите определения области по идентификатору в ответе и понятное имя, хранящееся в свойстве value .

Пример измененного ответа (сокращен для ясности):

{
    "adminConsentDisplayName": "Manage Delegated Admin relationships with customers",
    "id": "885f682f-a990-4bad-a642-36736a74b0c7",
    "isEnabled": true,
     "type": "Admin",
    "value": "DelegatedAdminRelationship.ReadWrite.All"
},
{
    "adminConsentDisplayName": "Sign in and read user profile",
    "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
    "isEnabled": true,
    "type": "User",
    "value": "User.Read"
},
{
    "adminConsentDisplayName": "Read directory data",
    "id": "06da0dbc-49e2-44d2-8312-53f166ab848a",
    "isEnabled": true,
    "type": "Admin",
    "value": "Directory.Read.All"
},
{
    "adminConsentDisplayName": "Read and write directory data",
    "id": "c5366453-9fb0-48a5-a156-24f0c49a4b84",
    "isEnabled": true,
    "type": "Admin",
    "value": "Directory.ReadWrite.All"
},

Отсутствующие субъекты безопасности в клиенте клиента

API согласия приложения требует, чтобы API приложения (субъекты-службы) существовали в клиенте клиента. При получении согласия может появиться сообщение об ошибке, как показано в следующем примере. Он сигнализирует о том, что приложение не существует в клиенте клиента.

"Приложение пытается получить доступ к службе c5393580-f805-4401-95e8-94b7a6ef2fc2" (API управления Office 365), для организации contosoxyz.onmicrosoft.com не хватает субъекта-службы. Обратитесь к ИТ-администратору, чтобы просмотреть конфигурацию подписок службы или согласие на приложение, чтобы создать необходимый субъект-службу".

В примере ошибки говорится, что API управления Office 365 не установлен в клиенте клиента. Предварительные требования для обеспечения установки субъекта-службы см. в статье "Начало работы с API управления Office 365".

Чтобы проверить, существует ли субъект-служба в клиенте клиента, можно вызвать API Graph для servicePrincipals этого клиента.

Для приложения, которому требуется согласие в клиенте клиента, можно запросить массив приложения requiredResourceAccess . В этом массиве для каждого resourceAppId экземпляра можно вызвать API в целевом клиенте. Замените {resourceIDvalue} значением resourceAppId .

https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appid eq '{resourceID value}'&$select=id,appId,appDisplayName

Например:

https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appid eq 'c5393580-f805-4401-95e8-94b7a6ef2fc2'&$select=id,appId,appDisplayName

Это результат, если субъект-служба найден:

    "value": [
        {
            "id": "6cf71994-a896-4e8a-a7a4-6d64276bf370",
            "appId": "c5393580-f805-4401-95e8-94b7a6ef2fc2",
            "appDisplayName": "Office 365 Management APIs"
        }
    ]

Это результат, если субъект-служба не найден:

    "value": []

Результат определит ваш путь вперед: опустить субъект-службу, определить, почему субъект-служба отсутствует для клиента или другие действия, относящиеся к вашему бизнесу.

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

Чтобы получить согласие для приложения в клиенте клиента, создайте универсальный код ресурса (URI) следующим образом. Замените {customertenant} клиентом клиента. Замените {appid} приложением, для которого требуется предоставить согласие.

https://login.microsoftonline.com/{customertenant}.onmicrosoft.com/adminconsent?client_id={appid}

Введите созданный URI в веб-браузере и следуйте запросам на вход и согласие.

Ресурсы

Ниже приведены ссылки на ресурсы, предлагаемые порядок чтения.

Согласие приложения GDAP
- Проверка подлинности Центра партнеров: согласие партнера
- API CPV/CSP для приложения: согласие клиента
Модель безопасного приложения
Платформа удостоверений Майкрософт

Поделиться через

Перенос приложений CPV/CSP на использование подробных делегированных прав администратора

Сравнение GDAP с DAP

Разрешения приложения и роли Microsoft Entra

Определение корпоративных приложений и областей (также известных как разрешения)

Получение понятных имен разрешений и областей

Получение списка приложений

Получение субъекта-службы

Отсутствующие субъекты безопасности в клиенте клиента

Ресурсы

Обратная связь

Дополнительные ресурсы

Поделиться через

Перенос приложений CPV/CSP на использование подробных делегированных прав администратора

Сравнение GDAP с DAP

Разрешения приложения и роли Microsoft Entra

Согласие для приложения

Явное согласие только для мультитенантных приложений

Явное мультитенантное приложение и согласие пользователя

Использование учетной записи администратора для предоставления согласия от имени пользователей в модели безопасного приложения

API согласия

Определение корпоративных приложений и областей (также известных как разрешения)

Получение понятных имен разрешений и областей

Получение списка приложений

Получение субъекта-службы

Отсутствующие субъекты безопасности в клиенте клиента

Запрос согласия приложения вручную

Ресурсы

Обратная связь

Дополнительные ресурсы