Часто задаваемые вопросы о GDAP

Кто-то с ролью агента администратора в партнерской организации может создать запрос на установление связи GDAP.

Да. Срок действия запросов связи GDAP истекает через 90 дней.

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

Да. Связь GDAP может автоматически продлеваться на шесть месяцев до её завершения или до изменения настройки автоматического продления на "Отключено".

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

Чтобы расширить или продлить отношения GDAP, партнер или клиент должны установить Auto extend на Enabled. Дополнительные сведения см. в Управление автоматическим расширением GDAP и API.

Да. Если GDAP активен, его можно расширить.

Предположим, что GDAP создается на 365 дней с включенным автоматическим продлением. В 365-й день дата окончания фактически обновляется на 180 дней.

Да. Вы можете автоматически расширить любой активный GDAP.

Нет. Согласие клиента не требуется для установки режима автоматического продления на Включено для существующего активного GDAP.

Нет. Гранулированные разрешения, назначенные группам безопасности, остаются без изменений.

Нет. Нельзя автоматически продлить административные полномочия при роли глобального администратора.

Страница «Истекающие гранулярные отношения» доступна только для партнёров с ролью агента администратора. Эта страница помогает фильтровать GDAPs, срок действия которых истекает в разные периоды времени, и помогает обновить автоматическую пролонгацию (включить или отключить) для одного или нескольких GDAPs.

Нет. При истечении срока действия отношения GDAP нет изменений в существующих подписках клиента.

Дополнительные сведения см. в статье Устранение неполадок многофакторной проверки подлинности Microsoft Entra и Не удается использовать многофакторную проверку подлинности Microsoft Entra для входа в облачные службы после потери телефона или изменения номера телефона.

Партнер должен запросить роль администратора привилегированной проверки подлинности Microsoft Entra при создании первого GDAP.

• Эта роль позволяет партнеру сбрасывать пароль и метод проверки подлинности для администратора или пользователя, отличного от администратора. Роль администратора привилегированной проверки подлинности является частью ролей, настроенных средством Майкрософт Led Tool, и планируется стать доступной с GDAP по умолчанию во время создания процесса клиента (запланировано на сентябрь).
• Партнер может предложить администратору клиента попробовать сбросить пароль.
• В качестве меры предосторожности партнер должен настроить SSPR (самостоятельный сброс пароля) для своих клиентов. Дополнительные сведения см. в статье Разрешить пользователям сбрасывать свои пароли.

• В организации партнера лица с ролью администратора агента получают уведомление о завершении.
• В организации клиента пользователи с ролью глобального администратора получают уведомление о завершении.

Да. Партнеры могут видеть, когда клиент удаляет GDAP в журналах действий Центра партнеров.

Нет. GDAP — это необязательная возможность для партнеров, которые хотят более детально и в определенные сроки управлять услугами своих клиентов. Вы можете выбрать, с какими клиентами вы хотите создать связь GDAP.

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

• Если вы хотите, чтобы пользователи-партнеры могли управлять всеми клиентами, вы можете поместить всех пользователей-партнеров в одну группу безопасности и что одна группа может управлять всеми вашими клиентами.
• Если вы предпочитаете, чтобы различные партнерские пользователи управляли разными клиентами, назначьте этих партнерских пользователей в отдельные группы безопасности для изоляции клиентов.

Да. Косвенные реселлеры (а также косвенные поставщики и партнеры с прямым выставлением счетов) могут создавать запросы на установление отношений GDAP в Центре партнеров.

В рамках настройки GDAP убедитесь, что выбраны группы безопасности, созданные в клиенте партнера с пользователями-партнерами. Кроме того, убедитесь, что нужные роли Microsoft Entra назначаются группе безопасности. См. Assign Microsoft Entra roles.

Теперь клиенты могут исключить поставщики СЛУЖБ из политики условного доступа, чтобы партнеры могли перейти в GDAP без блокировки.

• Включение пользователей. Этот список пользователей обычно включает всех пользователей, на которых организация нацелена в используемой организацией политике условного доступа.
• При создании политики условного доступа доступны следующие параметры:
• Выбор пользователей и групп
• Гостевые или внешние пользователи (предварительная версия)
• Этот выбор предоставляет несколько вариантов, которые можно использовать для целевых политик условного доступа для определенных гостевых или внешних типов пользователей и конкретных клиентов, содержащих эти типы пользователей. Есть несколько различных типов гостевых или внешних пользователей, которые можно выбрать, и можно выбрать несколько вариантов:
• Пользователи поставщика услуг, например поставщик облачных решений (CSP).
• Можно указать одного или нескольких тенантов для выбранных типов пользователей или указать всех тенантов.
• доступ к внешним партнерам . Политики условного доступа, предназначенные для внешних пользователей, могут препятствовать доступу к поставщику услуг, например детализированные делегированные права администратора. Дополнительные сведения см. в разделе Введение в детализированные делегированные права администратора (GDAP). Для политик, предназначенных для целевых клиентов поставщика услуг, используйте пользователь поставщика услуг внешний тип пользователя, доступный в параметрах выбора гостевых или внешних пользователей.
• исключить пользователей. Если организации включают и исключают пользователя или группу, пользователь или группа исключены из политики, так как действие исключения переопределяет действие включения в политику.
• При создании политики условного доступа доступны следующие параметры для исключения.
• Гостевые или внешние пользователи
• Этот выбор предоставляет несколько вариантов, которые можно использовать для целевых политик условного доступа для определенных гостевых или внешних типов пользователей и конкретных клиентов, содержащих эти типы пользователей. Существует несколько различных типов гостевых или внешних пользователей, которые можно выбрать, и можно выбрать несколько вариантов.
• Пользователи поставщика услуг, например поставщик облачных решений (CSP)
• Один или несколько арендаторов можно задать для выбранных типов пользователей или указать всех арендаторов. Дополнительные сведения см. в следующем разделе:
• API Graph Интерфейс. Бета-API с новыми сведениями о типе внешнего пользователя
• Политика условного доступа
• условный доступ для внешних пользователей

Да. Независимо от плана поддержки, наименее привилегированная роль для пользователей-партнёров для возможности создавать билеты в службу поддержки для своего клиента — администратор службы поддержки.

Нет. В настоящее время партнер не может прекратить GDAP в состоянии в ожидании утверждения. Срок действия истекает через 90 дней, если клиент не принимает никаких действий.

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

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

Нет. Поставщик услуг не может быть частью мультитенантной организации, они взаимоисключающие.

1. Убедитесь, что GDAP настроен правильно, включая предоставление разрешений для групп безопасности.
2. Убедитесь, что разрешения группы безопасности правильны.
3. Обратитесь к Security Copilot: Часто задаваемые вопросы за помощью.

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

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

Да. Мы рекомендуем партнерам использовать бета-версии API GDAP, для рабочей среды, а затем перейти на API версии 1, когда они становятся доступными. Хотя есть предупреждение "Использование этих API в рабочих приложениях не поддерживается", это универсальное руководство предназначено для всех бета-API в Graph и не применимо к бета-API GDAP Graph.

Да. Связи GDAP можно создавать с помощью API, что позволяет партнерам масштабировать этот процесс. Но создание нескольких связей GDAP недоступно в Центре партнеров. Сведения об API и GDAP см. в документации по разработке Центра партнеров .

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

Выполните отдельные вызовы для каждого ресурса. При выполнении одного запроса POST передайте только один ресурс и соответствующие области. Например, чтобы запросить разрешения для обоих https://graph.microsoft.com/Directory.AccessAsUser.All и https://graph.microsoft.com/Organization.Read.All, сделайте два разных запроса, по одному для каждого.

Используйте указанную ссылку для поиска имени ресурса: Проверка собственных приложений Майкрософт в отчетах о входе — Active Directory. Например, чтобы найти идентификатор ресурса 00000003-0000-0000-c000-0000000000000 для graph.microsoft.com:

Эта ошибка обычно возникает, когда неправильный идентификатор используется в фильтре запросов. Чтобы устранить эту проблему, убедитесь, что вы используете свойство enterpriseApplicationId с правильным идентификатором ресурса , а не именем ресурса.

• неверный запрос For enterpriseApplicationId, не используйте имя ресурса, например graph.microsoft.com.
• Правильный запрос Вместо этого для enterpriseApplicationIdиспользуйте идентификатор ресурса, например 0000003-0000-0000-c000-0000000000000000.

Например, ранее в ресурсе graph.microsoft.com было дано согласие только для области применения "profile". Теперь необходимо также добавить профиль и user.read. Чтобы добавить новые области в ранее согласованному приложению, выполните приведенные выше действия.

1. Используйте метод DELETE, чтобы отозвать существующее согласие приложения от клиента.
2. Используйте метод POST для создания нового согласия приложения с дополнительными областями.

Объедините необходимые области с запятой и пробелом. Например, область действия: "profile, User.Read"

1. Убедитесь, что свойства displayName и ApplicationId в тексте запроса точны и соответствуют приложению, которое вы пытаетесь предоставить клиенту.
2. Убедитесь, что вы используете то же приложение для создания токена доступа, для которого вы пытаетесь получить согласие в арендатора клиента. Например: если идентификатор приложения равен "12341234-1234-1234-12341234", утверждение "appId" в маркере доступа также должно быть "12341234-1234-1234-12341234".
3. Убедитесь, что выполняется одно из следующих условий:

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

• Чтобы управлять Azure с секционированием доступа для каждого клиента (рекомендуется), создайте группу безопасности (например, Azure Менеджеры) и вложите её в агенты администрирования.
• Чтобы получить доступ к подписке Azure в качестве владельца клиента, вы можете назначить любую встроенную роль Microsoft Entra (например, Directory readers, наименьшая привилегированная роль) группе безопасности Azure Managers. Инструкции по настройке Azure GDAP см. в разделе Workloads, поддерживаемые подробными делегированными правами администратора (GDAP).

Да. Сведения о том, как ограничить разрешения администратора пользователя путем назначения наименее привилегированных ролей в Microsoft Entra, см. в разделе Наименее привилегированные роли по задачам в Microsoft Entra.

Рекомендуем назначить роль администратор службы поддержки. Дополнительные сведения см. в статье Наименее привилегированные роли по задачам в Microsoft Entra.

• Чтобы уменьшить разрыв между ролями Microsoft Entra, доступными в API Центра партнеров и пользовательском интерфейсе, список из девяти ролей доступен в пользовательском интерфейсе Центра партнеров в июле 2024 года.
• В разделе "Совместная работа"
  • Администратор Microsoft Edge
  • Администратор виртуальных посещений
  • Администратор Viva Goals
  • Администратор Viva Pulse
  • Администратор Yammer
• Под удостоверением:
  • Администратор управления разрешениями
  • Администратор рабочих процессов жизненного цикла
• В разделе "Другое"
  • Администратор фирменной символики организации
  • Утверждающий организационные сообщения

• Чтобы уменьшить разрыв между ролями Microsoft Entra, доступными в API Центра партнеров и пользовательском интерфейсе, список 17 ролей были доступны в пользовательском интерфейсе Центра партнеров в декабре 2024 года.
• В разделе "Совместная работа"
  • Аналитик данных
  • Администратор миграции Microsoft 365
  • Автор организационных сообщений
  • SharePoint Внедренный администратор
  • Администратор телефонии Teams
  • Диспетчер успешности взаимодействия с пользователем
• На устройствах:
  • администратор гарантии оборудования Майкрософт
  • специалист по гарантии оборудования Майкрософт
• Под удостоверением:
  • Администратор назначения атрибутов
  • Средство чтения назначений атрибутов
  • Администратор определения атрибутов
  • Средство чтения определений атрибутов
  • Администратор журнала атрибутов
  • Читатель журналов атрибутов
  • Администратор расширения проверки подлинности
  • Глобальный администратор безопасного доступа
  • Создатель клиента

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

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

Многие роли используются для центра администрирования Microsoft 365. Для получения дополнительных сведений см. раздел Общие роли администраторов центра управления Microsoft 365.

Да. Создайте группу безопасности, назначьте утвержденные роли и затем добавьте пользователей арендатора-партнера в эту группу безопасности.

Доступ только для чтения к подпискам клиента предоставляется ролями глобального читателя, читателя каталога и поддержки партнера уровня 2.

Мы рекомендуем удалить партнерских агентов из роли Admin agent и добавить их только в группу безопасности GDAP. Таким образом, они могут администрировать службы (например, управлять службами и регистрировать запросы на обслуживание), но они не могут приобретать и управлять подписками (изменять их количество, отменять, планировать изменения и т. д.).

Группы безопасности, назначенные для связи, теряют доступ к клиенту. Такая же ситуация происходит, если клиент разрывает отношения с DAP.

Да. Удаление отношений GDAP с клиентом не прекращает партнёрские реселлерские отношения с клиентом. Партнеры по-прежнему могут приобретать продукты для клиента и управлять Azure бюджетом и другими связанными действиями.

Нет. Все роли в отношениях GDAP имеют один и тот же срок действия: длительность, выбранная при создании этих отношений.

Нет. Для выполнения заказов для новых и существующих клиентов не требуется GDAP. Вы можете продолжать использовать тот же процесс для выполнения заказов клиентов в Центре партнеров.

Отношения GDAP специфичны для каждого клиента. Вы можете иметь несколько связей для каждого клиента. Каждая связь GDAP может иметь разные роли и использовать разные группы Microsoft Entra в клиенте CSP. В Центре партнеров назначение ролей работает на уровне отношений между клиентами и GDAP. Если требуется назначение ролей для нескольких клиентов, вы можете автоматизировать это с помощью API.

Нет. Гостевые учетные записи не работают с GDAP. Клиенты должны удалить все гостевые учетные записи, чтобы получить GDAP для работы.

Гостевые администраторы GDAP не могут управлять собственными сведениями о безопасности на My Security-Info. Вместо этого они нуждаются в помощи администратора клиента, где они являются гостем, для регистрации, обновления или удаления информации по безопасности. Организации могут настроить политики доступа между клиентами для доверия MFA из доверенного клиента CSP. В противном случае гостевые администраторы GDAP ограничены только методами, которые регистрируются администратором клиентов, что является службой коротких сообщений (SMS) или голосовой связью. Для получения дополнительной информации см. политики межарендаторского доступа.

Выравнивайте основополагающий принцип "Никому не доверяй": используйте минимально необходимый доступ.

• Мы рекомендуем использовать роль с минимальными привилегиями для задач и задач рабочей нагрузки рабочих нагрузок, поддерживаемых подробными делегированными правами администратора (GDAP), поддерживаемыми GDAP.
• Если необходимо обойти перечисленные известные проблемы, обратитесь к клиенту, чтобы запросить роль глобального администратора с привязкой времени.
• Мы не рекомендуем заменять роль глобального администратора всеми возможными ролями Microsoft Entra.

Да. В период перехода DAP и GDAP будут сосуществовать с разрешениями GDAP, которые имеют приоритет над разрешениями DAP для рабочих нагрузок Microsoft 365, Dynamics 365 и Azure.

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

В существующем процессе отношений DAP изменения не предусмотрены, пока DAP и GDAP сосуществуют.

DAP в настоящее время предоставляется при создании нового клиента. 25 сентября 2023 г. Майкрософт больше не предоставляет DAP для создания нового клиента и вместо этого предоставляет GDAP по умолчанию с определенными ролями. Роли по умолчанию зависят от типа партнера, как показано в следующей таблице:

Партнеры могут внедрить управление привилегированными пользователями (PIM) в группе безопасности GDAP в клиенте партнера, чтобы повысить доступ у нескольких высокопривилегированных пользователей по принципу "just in time", предоставляя им роли с высоким уровнем привилегий, такие как администратор паролей, с автоматическим снятием доступа. До января 2023г. требуется, чтобы каждая группа привилегированного доступа (прежнее имя функции PIM для групп ) должна находиться в группе с возможностью назначения ролей. Это ограничение теперь снято. Учитывая это изменение, можно включить более 500 групп для каждого арендатора в PIM, но только до 500 групп могут быть назначаемыми ролям. Сводка:

• Партнеры могут использовать как группы, которым можно назначить роли , так и группы, которым нельзя назначить роли в PIM. Этот параметр эффективно удаляет ограничение на 500 групп/арендатора в PIM.
• С последними обновлениями существует два способа подключать группу к PIM (с точки зрения UX): из меню PIM или из меню Группы. Независимо от выбранного способа, чистый результат совпадает.
  • Возможность настройки групп с назначаемыми ролями/без назначения ролей через меню PIM уже доступна.
  • Возможность включения групп с назначаемыми ролями и без назначаемых ролей через меню «Группы» уже доступна.
• Дополнительные сведения см. в разделе управление привилегированными пользователями (PIM) для групп (предварительная версия) — Microsoft Entra.

GDAP общедоступен со поддержкой всех коммерческих облачных служб Майкрософт (Microsoft 365, Dynamics 365, Microsoft Azure и Microsoft Power Platform рабочих нагрузок). Дополнительные сведения о том, как могут сосуществовать DAP и GDAP и как GDAP имеет приоритет, выполните в этом разделе поиск вопроса: «Как разрешения GDAP имеют приоритет над разрешениями DAP, а DAP и GDAP сосуществуют?».

Это действие можно выполнить с помощью API.

Нет. Ваши доходы PEC не затрагиваются при переходе на GDAP. Изменений в PAL при переходе не происходит, что гарантирует вам продолжение заработка PEC.

• Если клиент партнера имеет только DAP и DAP удаляется, PEC не теряется.
• Если клиент партнера имеет DAP, и они переходят в GDAP для Microsoft 365 и Azure одновременно, а DAP удаляется, PEC не теряется.
• Если у клиента партнера есть DAP, и они переходят в GDAP для Microsoft 365, но оставляют Azure без изменений (не переходят в GDAP) и DAP удаляется, PEC не теряется, но доступ к подписке Azure пропадает.
• Если роль RBAC удалена, PEC теряется, но удаление GDAP не удаляет RBAC.

Если пользователь входит в группу безопасности GDAP и группу агентов администрирования DAP, и клиент имеет отношения DAP и GDAP, доступ GDAP имеет приоритет на уровне партнера, клиента и рабочей нагрузки.

Например, если пользователь-партнёр выполняет вход для рабочей нагрузки, а для роли "Глобальный администратор" настроен DAP и для роли "Глобальный читатель" настроен GDAP, пользователь-партнёр получает разрешения только для роли "Глобальный читатель".

Если существует три клиента с назначениями ролей GDAP только группе безопасности GDAP (а не агентам администратора):

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

DAP и GDAP не являются допустимыми типами ассоциаций для назначений партнеров решений. Отключение или переход с DAP на GDAP не влияет на получение статусов партнёра по решениям. Кроме того, обновление устаревших преимуществ компетенций или преимуществ партнеров решений не затрагивается. Чтобы просмотреть другие типы ассоциаций партнеров, подходящие для присвоения статуса Партнера по Решениям, см. назначения Партнера по Решениям в Центре Партнеров.

Взаимоотношения между Azure Lighthouse и DAP/GDAP можно рассматривать как независимые параллельные пути к ресурсам Azure. Отключение одного не должно повлиять на другое.

• В сценарии Azure Lighthouse пользователи из клиента партнера никогда не входят в клиент заказчика и не имеют разрешений Microsoft Entra в клиенте заказчика. Azure RBAC назначения ролей также хранятся в арендаторе партнера.
• В сценарии GDAP пользователи из арендатора партнера входят в тенант клиента. Назначение роли Azure RBAC группе агентов администрирования также находится в клиенте клиента. Вы можете заблокировать канал GDAP (пользователи больше не смогут войти), при этом канал Azure Lighthouse останется без изменений. Напротив, можно разорвать связь с Lighthouse (проекцией), не влияя на GDAP. Дополнительные сведения см. в документации Azure Lighthouse.

Управляемые поставщики услуг (MSPs), зарегистрированные в программе поставщик облачных решений (CSP), как косвенные торговые посредники или партнеры с прямым биллингом, теперь могут использовать Microsoft 365 Lighthouse для настройки GDAP для любого клиента. Поскольку существует несколько способов, которыми партнеры управляют переходом в GDAP, этот мастер позволяет партнерам Lighthouse принимать рекомендации по ролям, которые соответствуют их бизнес-потребностям. Он также позволяет им внедрять меры безопасности, такие как доступ по требованию (JIT). MSPs также может создавать шаблоны GDAP с помощью Lighthouse, чтобы легко сохранять и повторно применять параметры, которые обеспечивают доступ клиентов с минимальными привилегиями. Дополнительные сведения и просмотр демонстрации см. в мастере установки Lighthouse GDAP. MSP могут настроить GDAP для любого пользователя в Lighthouse. Для доступа к данным рабочей нагрузки клиента в Lighthouse требуется связь GDAP или DAP. Если GDAP и DAP совместно работают в клиенте, разрешения GDAP имеют приоритет для технических специалистов MSP в группах безопасности с поддержкой GDAP. Дополнительные сведения о требованиях для Microsoft 365 Lighthouse см. в разделе Requirements для Microsoft 365 Lighthouse.

Правильная последовательность для этого сценария:

1. Создайте связь GDAP для как Microsoft 365, так и Azure.
2. Назначьте роли Microsoft Entra группам безопасности для both Microsoft 365 и Azure.
3. Настройте GDAP, чтобы иметь приоритет над DAP.
4. Удалите DAP.

Следующая последовательность может привести к потере доступа к подпискам Azure:

1. Удалите DAP. Вы не обязательно теряете доступ к подписке Azure путем удаления DAP. Но в настоящее время вы не можете просмотреть директорию клиента, чтобы выполнить какие-либо назначения ролей Azure RBAC (например, назначить нового пользователя клиента в роли участника RBAC для подписки).
2. Создайте связь GDAP для both Microsoft 365 и Azure вместе. Вы можете потерять доступ к подписке Azure на этом шаге после настройки GDAP.
3. Назначение ролей Microsoft Entra группам безопасности для как Microsoft 365, так и Azure

После завершения установки GDAP вы вновь получите доступ к подпискам Azure.

Если у вас есть подписки Azure без DAP, которыми вы управляете как владелец, при добавлении для клиента GDAP для Microsoft 365, вы можете утратить доступ к этим подпискам Azure. Чтобы избежать потери доступа, перемещайте клиента в Azure GDAP одновременно с перемещением в Microsoft 365 GDAP.

Нет. Отношения, как только они приняты, не могут быть повторно использованы.

Если у вас есть отношения торгового посредника с клиентом, вам по-прежнему необходимо установить связь GDAP для управления их подписками Azure.

1. Создайте группу безопасности (например, диспетчеры Azure) в Microsoft Entra.
2. Создайте связь GDAP с ролью читателя каталогов.
3. Сделайте группу безопасности членом группы Admin Agent. После выполнения этих действий вы можете управлять подпиской Azure клиента с помощью AOBO. Вы не можете управлять подпиской с помощью ИНТЕРФЕЙСА командной строки или PowerShell.

Да. Вы можете создать план Azure, даже если нет DAP или GDAP с существующим реселлером. Но для управления этой подпиской вам потребуется DAP или GDAP.

При переходе от DAP к GDAP партнеры должны убедиться, что выполнены следующие условия, чтобы просмотреть информацию о компании:

• Активное отношение GDAP.
• Назначается любая из следующих ролей Microsoft Entra: читатели каталогов, глобальный читатель. Ознакомьтесь с предоставлением подробных разрешений группам безопасности.

Когда поставщик служб CSP входит на портал Azure клиента (portal.azure.com) с использованием учетных данных CSP и существует связь GDAP, CSP замечает, что их имя пользователя — это "user_", за которым следует некоторое число. Он не отображает фактическое имя пользователя, как в DAP. Это задумано.

Партнеры должны явно предоставлять подробные разрешения группам безопасности, в GDAP по умолчанию.
По состоянию на 10 октября 2023 года DAP больше недоступен в реселлерских отношениях. Обновленная ссылка на запрос установки отношений с реселлером доступна в пользовательском интерфейсе Центра партнеров, а URL-адрес свойства "/v1/customers/relationship requests" возвращает URL-адрес приглашения, который будет отправлен администратору клиента.

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

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

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

Если появится следующая ошибка:

Мы не можем проверить ваш запрос «Создать новую связь GDAP» на данный момент. Анонимные подключения для этой службы не разрешены. Если вы считаете, что вы получили это сообщение в ошибке, повторите запрос. Выберите, чтобы узнать о действиях, которые можно предпринять. Если проблема сохранится, обратитесь в службу поддержки и укажите код сообщения 715-123220 и идентификатор транзакции: GUID.

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

Действия, которые можно сделать:

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

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

• Ограничено (прямой биллинг): невозможно создать новые отношения GDAP (административные отношения). Существующие GDAPs и их назначения ролей МОГУТ быть обновлены.
• Создание нового GDAP невозможно (приостановлено прямой счет/косвенный поставщик/косвенный торговый посредник). Существующие GDAPs и их назначения ролей не подлежат обновлению.
• Ограниченный (прямой счет) + активный (косвенный торговый посредник): для ограниченного прямого счета: новый GDAP (административные отношения) не может быть создан. Существующие GDAP и их назначения ролей могут быть обновлены. Для активного косвенного торгового посредника: может быть создан новый GDAP, существующие GDAP и их назначения ролей могут быть обновлены. При отключении невозможно создать новый GDAP, а существующие GDAP и их назначения ролей не могут быть обновлены.

Да. Текущий выпуск GDAP поддерживает все продукты: Microsoft 365, Dynamics 365, Microsoft Power Platform и Microsoft Azure.