Как использовать шаблоны ARM для развертывания назначения ролей для участника службы регистрации приложений? - PullRequest
1 голос
/ 12 июня 2019

В моем текущем проекте я работаю с предварительно созданными принципалами регистрации приложений в Azure AD. Я использую шаблон ARM для создания учетной записи StorageV2 плюс несколько контейнеров BLOB-объектов, а затем создаю роль roleAssignment, предоставляющую права Storage Blob Contributor одному из Принципов обслуживания. Соответствующий раздел шаблона ARM находится в конце этого поста.

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

Если я использую сервисный принципал ObjectId, я получаю следующую ошибку:

Deployment failed. Correlation ID: 40e0c146-165a-47c0-b022-ac04781d8194. {
  "error": {
    "code": "PrincipalTypeNotSupported",
    "message": "Principals of type Application cannot validly be used in role assignments."
  }
}

Заметив некоторые предложения для пользователей Azure Powershell о том, что вместо этого я должен использовать идентификатор приложения (клиента), я попытался это сделать, но получил следующую ошибку (Guids отредактирован):

Deployment failed. Correlation ID: 5c725a51-230a-4d85-bb61-b2f4cdf849ff. {
  "error": {
    "code": "PrincipalNotFound",
    "message": "Principal 9f****30 does not exist in the directory db****75."
  }
}

Так что ObjectId он может найти, но не использовать, а ClientId он не может найти.

Я обнаружил, что если я использую Azure Powershell и использую команду New-AzureRmRoleAssignment, я могу воспроизвести ошибку PrincipalTypeNotSupported, указав ObjectId участника службы для переключателя -ObjectId. Тем не менее, эта команда также имеет переключатель -ServicePrincipalName в качестве альтернативы, и если я дам этому ClientId принципала обслуживания, он будет работать!

Есть ли эквивалент -ServicePrincipalName для шаблонов ARM, и если нет, есть ли другой способ добиться этого? Я могу использовать Azure Powershell в качестве обходного пути, но он сложнее, чем хотелось бы.

Если это пробел в функции, где лучшее место, чтобы сообщить об этом?

Соответствующий раздел шаблона ARM следует:

"resources": [
    {
        "name": "[variables('storageAccountName')]",
        "type": "Microsoft.Storage/storageAccounts",
        "location": "[resourceGroup().location]",
        "apiVersion": "2018-07-01",
        "sku": {
            "name": "[parameters('storageAccountSku')]"
        },
        "dependsOn": [],
        "tags": {
            "displayName": "Storage Account"
        },
        "kind": "StorageV2",
        "properties": {
            "accessTier": "Hot",
            "supportsHttpsTrafficOnly": true,
            "networkAcls": {
                "bypass": "AzureServices",
                "virtualNetworkRules": [],
                "ipRules": [],
                "defaultAction": "Deny"
            }
        },
        "resources": [
            {
                "type": "blobServices/containers",
                "name": "[concat('default/', variables('myBlobContainerName'))]",
                "apiVersion": "2018-07-01",
                "dependsOn": [
                    "[variables('storageAccountName')]"
                ],
                "resources": [
                    {
                        "type": "Microsoft.Authorization/roleAssignments",
                        "name": "[variables('myRoleAssignmentGuid')]",
                        "apiVersion": "2018-07-01",
                        "properties": {
                            "roleDefinitionId": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Authorization/roleDefinitions/ba92f5b4-2d11-453d-a403-e96b0029c9fe')]",
                            "principalId": "[variables('myPrincipalId')]"
                        },
                        "dependsOn": [
                            "[concat('Microsoft.Storage/storageAccounts/', variables('storageAccountName'), '/blobServices/default/containers/', variables('myBlobContainerName'))]"
                        ]
                    }
                ]
            }
        ]
    }
]

1 Ответ

1 голос
/ 13 июня 2019

Наконец-то решил эту проблему, отчасти благодаря указателям из @ 4c74356b41.

Когда создается объект регистрации приложения, объект с идентичным именем также создается в разделе «Приложения предприятия». У него тот же ApplicationId, но другой ObjectId, и это ObjectId этого объекта Enterprise Application, который нужен нашему скрипту ARM.

Вы можете найти этот объект на портале, перейдя к записи регистрации приложения и нажав ссылку после Managed application in...

Screenshot of App Registration with Link Снимок экрана регистрации приложения по ссылке

Как только вы окажетесь в соответствующем объекте корпоративного приложения, вы можете получить ObjectId из Свойства и использовать это значение для principalId в шаблоне ARM.

На момент написания документа Microsoft немного расплывчато, с терминами Application и Service Principal, казалось бы, перегруженными. В этой статье говорится, что при регистрации приложения вы получаете объект приложения и объект принципала службы, но не используете фразу Enterprise Application один раз или обращаетесь к регистрации приложения объекты per se, так что непонятно, что есть что.

Я предполагаю, что приложение == регистрация приложения и принципал обслуживания == корпоративное приложение. Этот пост SO может показаться, что это именно тот случай, как и решение выше.

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