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

Руководство по устранению неполадок с партнерскими баллами

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

Устранение распространенных сценариев

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

В этой статье приведены основные рекомендации по устранению неполадок, если PEC не предоставлен.

Предварительные условия

Если у вас возникли проблемы с PEC, например доступом или отсутствующими сведениями, начните с проверки следующих элементов.

Примечание.

Только косвенные поставщики и партнеры с прямым выставлением счетов имеют право на получение PEC.

  • Убедитесь, что вы просматриваете файл счета-фактуры и сверки G (новая коммерческая версия). План Azure и PEC не отображаются в счете D (устаревшая) или файле выверки.

  • Убедитесь, что ваше соглашение по программе Microsoft AI Cloud Partner активно.

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

  • Убедитесь, что у вас (или у косвенного торгового посредника, назначенного официально в качестве посредника по записи в плане Azure), есть действующее право администрирования от имени (AOBO) или роли управления доступом, основанной на ролях Azure (Azure RBAC) для подписки, группы ресурсов или ресурса. Еще один вариант:

  • Проверьте, удалил ли клиент ваши разрешения AOBO. Разрешения задаются по умолчанию при подготовке плана Azure. Если они удалены, см. статью Восстановление прав администратора для подписок клиента на программу "Поставщик облачных решений Azure" (CSP).

  • Убедитесь, что у вас есть доступ администратора на весь день.

  • Убедитесь, что вы просматриваете правильные столбцы в файлах сверки. Дополнительные сведения см. в статье Выставление счетов в плане Azure: о вашем файле сверки счета.

Общие сведения о сценариях работы с несколькими партнерами

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

Другой партнер, устанавливающий дополнительные разрешения AOBO или другие разрешения, а также настройка дополнительных разрешений Azure RBAC для пользователей с разрешениями Azure RBAC не влияет на PEC для партнера, осуществляющего транзакцию.

В следующей таблице MPN1 является косвенным поставщиком, а MPN2 — косвенным торговым посредником, связанным с транзакцией в качестве зарегистрированного торгового посредника. MPN3 — еще один партнер CSP (прямой или другой косвенный реселлер):

Партнер по транзакциям (BillTo) Azure RBAC (для пользователя или Lighthouse в роли, подходящей для PEC) AOBO (роль, соответствующая критериям PEC) ПЭК
МПН1 МПН1 Не применимо Да
МПН1 Не применимо МПН1 Да
МПН1 МПН2 Не применимо Да
МПН1 Не применимо МПН2 Да
МПН1 МПН3 МПН1 Да
МПН1 МПН1 МПН3 Да
МПН1 МПН1 МПН2 Да
МПН1 МПН2 МПН1 Да
МПН1 МПН2 МПН3 Да
МПН1 МПН3 МПН2 Да
МПН1 МПН3 Не применимо Нет
МПН1 Не применимо МПН3 Нет
МПН1 Не применимо Не применимо Нет
МПН1 МПН3 МПН3 Нет

Общие сведения о передаче подписок Azure

Когда партнер передает подписку Azure или другому партнеру, разрешения на эту передачу не изменяются.

Таким образом, если до передачи использовалась AOBO или другая модель разрешений с разрешениями, установленными для предыдущего «партнера по сделке», разрешения все равно указывают на предыдущего партнера после передачи. Но теперь другой партнер становится "партнером, совершающим транзакцию".

Для передачи подписок Azure рекомендуется добавить разрешения нового целевого партнера, например Azure RBAC, перед передачей. Они могут безопасно сделать это, не затрагивая PEC старого партнера до передачи.

Общие сведения об обновлениях PartnerID

Центр партнеров позволяет изменить идентификатор PartnerID, связанный с регистрацией CSP. Обновление PartnerID до другого идентификатора местоположения в программе Microsoft AI Cloud Partner в рамках той же глобальной организации Microsoft AI Cloud Partner (другой идентификатор местоположения Microsoft AI Cloud Partner под тем же глобальным идентификатором программы Microsoft AI Cloud Partner) не влияет на PEC.

При изменении идентификатора партнера на идентификатор расположения в другой организации программы Microsoft AI Cloud Partner Program могут возникнуть проблемы с PEC. В этом случае, а также при отсутствии PEC, рекомендуем обратиться в службу поддержки. Упомяните, что вы недавно переназначили регистрацию CSP в другую организацию Microsoft AI Cloud Partner Program.

Проверка разрешений администратора от имени (AOBO)

Когда партнер создает подписку на план Azure для клиента, AOBO задается в виде внешнего участника. Иностранный принципал наследует права владельца в подписке Azure. Разрешения AOBO означают, что определенная группа в клиенте Центра партнеров CSP (агенты администратора) наследуют разрешения.

Внешний субъект, как показано в портале Azure, не содержит подробные сведения о группе, с которой он сопоставляется в клиенте конкретного партнера.

При просмотре внешнего принципала в портале Azure отображается имя партнера, например "Внешний принципал для 'Contoso'" ..., но "Contoso" — это только отображаемое имя клиента Microsoft Entra партнера, и оно не уникально.

Снимок экрана с неуникальными отображаемыми именами.

Используйте AZ PowerShell или Azure CLI, чтобы с уверенностью 100% убедиться, что AOBO задан правильно, указывает на правильную группу и находится в правильном клиенте CSP.

Шаг 1. Определение идентификаторов объектов групп агентов партнера по транзакциям

  • С помощью портала Azure: партнеры могут входить на портал Azure в своем клиенте и искать соответствующие группы в группах Microsoft Entra ID>. Объектный идентификатор отображается справа от имени группы.

Снимок экрана, на котором показано получение идентификатора объекта из интерфейса портала Azure.

Прежде чем использовать Azure Cloud Shell, необходимо настроить учетную запись хранения. За эту учетную запись взимается небольшая ежемесячная плата в рамках подписки Azure, доступной в контексте клиента. Вы можете удалить общую папку после описанных ниже действий.

Примечание.

Модули Azure AD и MSOnline PowerShell устарели с 30 марта 2024 г. Чтобы узнать больше, прочитайте обновлённую информацию о прекращении поддержки. После этой даты поддержка этих модулей ограничена поддержкой миграции в пакет SDK Для Microsoft Graph PowerShell и исправления безопасности. Устаревшие модули будут продолжать функционировать до 30 марта 2025 года.

Рекомендуем перейти на Microsoft Graph PowerShell для работы с Microsoft Entra ID (ранее Azure AD). Часто задаваемые вопросы о миграции см. в разделе "Вопросы и ответы о миграции". Примечание: Версии 1.0.x MSOnline могут испытывать сбои после 30 июня 2024 г.

Убедитесь, что установлены и обновлены следующие модули до последней версии:

При необходимости выполните следующие действия cmdlets из Windows PowerShell для установки этих модулей:

Install-Module -Name AzureAD -Force

Install-Module -Name Az -AllowClobber -Force

Сначала подключитесь к клиенту Центра партнеров с учетной записью пользователя Центра партнеров и получите идентификаторы объектов группы AdminAgents и HelpdeskAgents:

Connect-AzureAD -TenantDomain CSPtenantname.onmicrosoft.com

Войдите с помощью учетных данных Центра партнеров:

Снимок экрана, на котором показан пример подключения к Центру партнеров в оболочке.

Запросите сведения о группах агентов:

Get-AzureADGroup | Where-Object { $_.DisplayName.Endswith('Agents') }

Группы ObjectID отображаются вместе с их названиями:

Скриншот, на котором показано окно оболочки с примером ObjectID групп.

Примечание.

Если вы не получили результат, убедитесь, что вы подключились к учетной записи Центра партнеров.

Примечание.

Косвенные торговые посредники не видят группу SalesAgents. Этот шаг нужно выполнить только один раз, так как AOBO в каждом клиенте использует одни и те же идентификаторы.

Шаг 2. Сравнение идентификаторов objectID с теми, которые используются внешним субъектом

Важно использовать TenantID в качестве значения параметра tenant (а не доменного имени клиента) с учетной записью пользователя, которая:

  • имеет доступ к нескольким каталогам и клиентам, таким как учетная запись пользователя Центра партнеров;
  • Был добавлен в качестве гостя в несколько клиентов.

Таким образом, вам нужен TenantID для клиента.

  • С помощью портала Azure: вы можете легко получить идентификатор клиента из списка клиентов в Центре партнеров. Идентификатор клиента помечен как Microsoft ID:

    Снимок экрана, на котором идентификатор Майкрософт указан как tenantId.

  • С помощью PowerShell: подключитесь к подписке Azure клиента с действительными учетными данными. Учетные данные должны иметь разрешение на чтение подписки Azure и AzureAD клиента:

    Connect-AzAccount -Tenant $CustomerTenantID
    • Чтение назначений ролей для внешнего участника подписок Azure клиента:
    Get-AzRoleassignment | ? {$_.DisplayName -like "Foreign*"}

    Снимок экрана, на котором показан пример назначения ролей в оболочке.

    • Результирующий objectID должен соответствовать ObjectID группы AdminAgent или HelpDeskAgent, определенной на шаге 1.

Итоги

Для получения PEC через AOBO должны совпадать все аспекты:

  • Подписка Azure клиента имеет иностранного участника с соответствующим назначением ролей RBAC Azure.
  • ObjectID группы, используемой внешним субъектом, ссылается на ObjectID группы AdminAgent или HelpdeskAgent в клиенте партнера.
  • "Клиент партнера" означает прямой клиент партнера по выставлению счетов. В косвенной модели это означает косвенный поставщик или косвенный клиент партнера торгового посредника.

Примеры сценариев

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

  • Описание сведений AOBO для одного клиента: в этом примере используется идентификатор Microsoft Entra и модули Azure PowerShell.
### Install-Module -Name AzureAD -Force ###
### Install-Module -Name Az -AllowClobber -Force ###
### Variables ####
$CSVname = "c:tempAOBOchecker.csv"
$CustomertenantId = ""
### Get Agent-Groups Object IDs and write to CSV - This step needs to be done with a Partner Center User ###
Connect-AzureAD -TenantDomain $PartnerTenantDomain
$Headers = "GroupName`tObjectID`tPartnerTenantName`tPartnerTenantID" >>$CSVname
$PartnerTenant = Get-AzureADTenantDetail
$groups = Get-AzureADGroup | Where-Object { $_.DisplayName.Endswith('Agents') }
ForEach ($Group in $Groups)
{
$NewLine = $Group.DisplayName + "`t" + $Group.ObjectID + "`t" + $PartnerTenant.DisplayName + "`t" + $PartnerTenant.ObjectID
$NewLine >>$CSVname
}
### Get list of Azure Subscriptions for a customer, get list of Foreign Principals and add them to the same CSV ###
Clear-AzContext -Scope CurrentUser -Force
Connect-AzAccount -Tenant $CustomertenantId
$CustomerTenant = Get-AzureADTenantDetail
$CustomerTenantSubscriptions = Get-AzSubscription -TenantId $CustomertenantId
ForEach ($Subscription in $CustomerTenantSubscriptions)
{
$Roles = Get-AzRoleassignment -Scope /subscriptions/$Subscription | ? {$_.DisplayName -like "Foreign*"}
ForEach ($Role in $Roles)
{
$NewLine = $CustomerTenant.Domain + "`t" + $CustomerTenant.CustomerId + "`t" + $Subscription.Id + "`t" + $Role.DisplayName + "`t" + $Role.ObjectID + "`t" + $Role.RoleDefinitionName
$NewLine >>$CSVname
}
}
  • Перечисление сведений AOBO для нескольких клиентов: этот код служит исключительно для примера.
    • Получите список всех подписок клиентов CSP и всех внешних субъектов и определите несоответствие. Этот код также можно использовать для сбора сведений о поддержке.
    • Проверьте, какие подписки Azure (права на план Azure) были проданы, а какие доступны с текущими учетными данными.
    • Для косвенных торговых посредников этот сценарий также работает. Но все подписки будут иметь примечание "не продано", даже если они являются официальным партнером для данной продажи.
### Note - below examples use interactive login experience and aren't suitable for production use ###
### See /partner-center/develop/enable-secure-app-model#powershell for info on how to authenticate to each customer tenant silently using secure app model ###
### Below examples use AzureAD, AZ and Partner Center PowerShell modules ###
### Install-Module -Name AzureAD -Force ###
### Install-Module -Name Az -AllowClobber -Force ###
### Install-Module -Name PartnerCenter -Force ###
### Variables ####
$PartnertenantDomain = "xyz.onmicrosoft.com"
$PartnerTenantID = ""
$CSVname = "c:tempAOBOchecker.csv"
### Get Agent-Groups Object IDs and write to CSV ###
Connect-AzureAD -TenantDomain $PartnerTenantDomain
$Headers = "GroupName`tObjectID`tPartnerTenantName`tPartnerTenantID" >>$CSVname
$PartnerTenant = Get-AzureADTenantDetail
$groups = Get-AzureADGroup | Where-Object { $_.DisplayName.Endswith('Agents') }
ForEach ($Group in $Groups)
{
$NewLine = $Group.DisplayName + "`t" + $Group.ObjectID + "`t" + $PartnerTenant.DisplayName + "`t" + $PartnerTenant.ObjectID
$NewLine >>$CSVname
}
### Get list of CSP Customers, get List of Azure Subscriptions, get list of Foreign Principals and add them to the same CSV ###
Connect-PartnerCenter -TenantID $PartnertenantID
$Customers = Get-PartnerCustomer
$Headers = "`r`nCustomerTenantName`tCustomerTenantID`tSubscriptionId`tForeignPrincipalName`tObjectID`tAzureRBACRole`tTimeChecked`tNotes`tCredentialsUsedForAccessCheck" >>$CSVname
Foreach ($customer in $Customers)
{
$AzurePlanId = Get-PartnerCustomerSubscription -CustomerId $Customer.CustomerId | ? {$_.OfferName -eq "Azure Plan"}
if ($AzurePlanID -eq $null)
{
Write-Host "Customer $($Customer.Name) does not have Azure Plan"
}
else
{
$AzurePlanSubscriptionsSold = Get-PartnerCustomerAzurePlanEntitlement -CustomerId $Customer.CustomerId -SubscriptionId $AzurePlanId.SubscriptionId
}
Clear-AzContext -Scope CurrentUser -Force
Connect-AzAccount -Tenant $Customer.CustomerId
$CurrentUser = Get-azcontext
$CustomerTenantSubscriptionsAccessible = Get-AzSubscription -TenantId $Customer.CustomerId
$SoldAndAccessibleSubscriptions = $AzurePlanSubscriptionsSold | Where {$CustomerTenantSubscriptionsAccessible -Contains $_}
$SoldButNotAccessibleSubscriptions = $AzurePlanSubscriptionsSold | Where {$CustomerTenantSubscriptionsAccessible -notcontains $_}
$NotSoldButAccessibleSubscriptions = $CustomerTenantSubscriptionsAccessible | Where {$AzurePlanSubscriptionsSold -notcontains $_}
ForEach ($Subscription in $SoldAndAccessibleSubscriptions)
{
$Roles = Get-AzRoleassignment -Scope /subscriptions/$Subscription | ? {$_.DisplayName -like "Foreign*"}
ForEach ($Role in $Roles)
{
$CurrentTime = Get-Date -format "dd-MMM-yyyy HH:mm:ss"
$NewLine = $Customer.Domain + "`t" + $Customer.CustomerId + "`t" + $Subscription.Id + "`t" + $Role.DisplayName + "`t" + $Role.ObjectID + "`t" + $Role.RoleDefinitionName + "`t" + $CurrentTime + "`t" + "Access with current credentials and sold as CSP Partner" + "`t" + $CurrentUser.Account.Id
$NewLine >>$CSVname
}
}
ForEach ($Subscription in $SoldButNotAccessibleSubscriptions)
{
$CurrentTime = Get-Date -format "dd-MMM-yyyy HH:mm:ss"
$NewLine = $Customer.Domain + "`t" + $Customer.CustomerId + "`t" + "N/A" + "`t" + "N/A" + "`t" + "N/A" + "`t" + "N/A" + "`t" + $CurrentTime + "`t" + "Sold via CSP, but no access with current credentials" + "`t" + $CurrentUser.Account.Id
$NewLine >>$CSVname
}
ForEach ($Subscription in $NotSoldButAccessibleSubscriptions)
{
$Roles = Get-AzRoleassignment -Scope /subscriptions/$Subscription | ? {$_.DisplayName -like "Foreign*"}
ForEach ($Role in $Roles)
{
$CurrentTime = Get-Date -format "dd-MMM-yyyy HH:mm:ss"
$NewLine = $Customer.Domain + "`t" + $Customer.CustomerId + "`t" + $Subscription.Id + "`t" + $Role.DisplayName + "`t" + $Role.ObjectID + "`t" + $Role.RoleDefinitionName + "`t" + $CurrentTime + "`t" + "Access with current credentials, but not sold as CSP Partner" + "`t" + $CurrentUser.Account.Id
$NewLine >>$CSVname
}
}
}

  • Выходные данные этого скрипта можно отформатировать следующим образом:

    Скриншот с примером выходного формата.

Как и AOBO, Azure Lighthouse позволяет группам пользователей в клиенте управления (партнера) наследовать делегированные разрешения в подписке Azure клиента. Разница в том, что он поддерживает более детальное определение групп и уровней разрешений, чем AOBO.

Для этой модели разрешений проще проверить, правильно ли она настроена, с помощью пользовательского интерфейса портала Azure. Только партнер может предоставить полную проверку правильности настройки Azure Lighthouse.

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

Шаг 1. Проверка делегирований Lighthouse на клиентах

Убедитесь, что применимые делегирования используют роли Azure RBAC, подходящие по требованиям PEC.

  • Откройте портал Azure (с пользователем из клиента управления партнера). Затем найдите "Lighthouse" и выберите "Мои клиенты".

    Снимок экрана, на котором показан пример службы Azure Lighthouse.

  • В обзоре клиента выберите Делегирования слева. При этом открывается список ресурсов (подписок или групп ресурсов), к которым был предоставлен делегированный доступ:

    Скриншот со страницей «Делегирование».

  • Откройте делегирование в правом столбце в разделе Назначения ролей , чтобы узнать, какая группа пользователей в клиенте партнера или управления наследует каждый тип разрешений (см. столбец Роль ). Вы также можете узнать, являются ли эти разрешения постоянными (см. столбец Access Type):

    Снимок экрана, на котором показана страница Назначения ролей.

Шаг 2. Проверка членства в группах

Выберите отображаемое имя группы. Откройте данные о группе. Выберите "Участники", чтобы контролировать, какой пользователь имеет набор RBAC Azure и входит в соответствующую группу:

Скриншот, на котором показано членство в группе.

Шаг 3 – Проверьте, настроил ли пользователь Azure PAL

Только пользователь, настроивший Azure PAL, может проверить назначение Azure PAL. Ни один другой пользователь с правами администратора не может этого сделать. Дополнительные сведения о том, как пользователь может проверить, был ли настроен Azure PAL с помощью пользовательского интерфейса или PowerShell, см. в статье Связывание учетной записи Azure с идентификатором PartnerID.

Примечание.

Azure PAL должен использовать идентификатор партнера, который является частью той же организации Microsoft AI Cloud Partner Program, которая является партнером по транзакциям для этой подписки Azure. В косвенной модели это может быть идентификатор партнера поставщика или конкретного торгового посредника, прикрепленный к этой продаже.

Шаг 4. Проверка назначений групп с привязкой к времени

Так как членство в группах не может быть постоянным, проверьте, включена ли группа для управления привилегированным доступом. Посмотрите, где "Привилегированный доступ" находится слева под "Действие" в настройках группы. Если задано значение true, проверьте, имеет ли пользователь активное назначение и интервал времени для этого назначения.

Примечание.

Поскольку назначение времени окончания — это момент, когда пользователь автоматически удаляется из группы, PEC будет потерян для пользователей, для которых был настроен Azure RBAC. Аналогично, PEC будет предоставлен только после времени начала назначения.

Снимок экрана, на котором показана группа привилегированного доступа.

Проверка индивидуального назначения пользователя и Azure PAL

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

Если вы используете отдельные учетные записи пользователей в качестве средства для получения PEC, проверка включает в себя проверку назначенных разрешений в управлении подписками Azure для пользователя и проверку правильности настройки Azure RBAC для пользователя. При использовании субъекта-службы проверка Azure RBAC происходит с помощью PowerShell.

Шаг 1. Проверка разрешений в службе управления подписками Azure

  • Откройте портал Azure. Учтите, что вы вошли в систему как пользователь с ролью Azure RBAC, имеющий по крайней мере доступ на чтение к соответствующей подписке.

  • Найдите "Подписки" в строке поиска, чтобы открыть сведения о подписке:

    Снимок экрана со страницей сведений о подписке.

  • Перейдите в раздел "контроль доступа (IAM)" в сведениях о подписке. Затем выберите "Назначения ролей", чтобы просмотреть пользователей, имеющих доступ на уровне подписки, и если в столбце "Роль" отображаются соответствующие роли Azure RBAC, подходящие для PEC. Если разрешения были заданы на уровне группы ресурсов, то такое же представление "Управление доступом (IAM)" также доступно в группе ресурсов.

Примечание.

Разрешения также можно предоставить группе пользователей, где необходимо проверить членство в группе пользователя с набором RBAC Azure.

Снимок экрана, на котором показан контроль доступа по подписке Azure.

Шаг 2. Убедитесь, что разрешения постоянны и что не применяются никакие отказы.

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

Процесс назначения роли Azure RBAC с помощью Управления привилегированными идентификационными данными (PIM) может быть ограничен по времени. Хотя вы можете видеть пользователей с разрешениями, они могут существовать только в течение короткого времени. Чтобы убедиться, что назначение ролей Azure RBAC является постоянным, проверьте администрирование PIM в портале Azure. В частности, проверьте, где политики PIM управляют ресурсами Azure в подписке и распространяется ли на пользователя какие-либо политики.

Снимок экрана, показывающий, что подписка Azure не управляется с помощью PIM.

Кроме того, список разрешений может показать, что у пользователя есть разрешения на подписку, но могут быть запреты назначений, которые по-прежнему блокируют доступ пользователя к чему-то. В разделе "Контроль доступа (IAM)" выберите вкладку Запреты, чтобы узнать, применяются ли запреты на назначения:

Снимок экрана, на котором показана страница результатов Запретить задания.

Примечание.

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

Шаг 3 – Проверьте, настроил ли пользователь Azure PAL

Только пользователь, настроивший Azure PAL, может проверить назначения Azure PAL. Ни один другой пользователь с правами администратора не может этого сделать. Дополнительные сведения о том, как пользователь может проверить, был ли настроен Azure PAL, см. в статье Связывание учетной записи Azure с идентификатором PartnerID.

Примечание.

Azure PAL должен использовать идентификатор партнера, который является частью той же организации Microsoft AI Cloud Partner Program, которая является партнером по транзакциям для этой подписки Azure. В косвенной модели это может быть либо PartnerID поставщика, либо PartnerID торгового посредника, прикрепленный к этой продаже.

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