Создание сервисного принципала Azure с помощью Azure PowerShell

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

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

В этой статье показано, как создать, получить сведения и сбросить служебного принципала с помощью Azure PowerShell.

Предостережение

При создании учетной записи службы с помощью команды New-AzADServicePrincipal результат включает в себя учетные данные, которые необходимо защитить. В качестве альтернативы рекомендуется использовать управляемые удостоверения , чтобы избежать необходимости использования учетных данных.

Необходимые условия

Создайте сервисного принципала

Создайте принципал службы с помощью командлета New-AzADServicePrincipal. При создании учетной записи службы вы выбираете тип аутентификации, которую она использует.

Это важно

Начиная с модуля Az PowerShell версии 7.x , New-AzADServicePrincipal больше не назначает роль Участника служебному субъекту по умолчанию. Чтобы назначить определенную роль субъекту-службе, см. инструкции по добавлению назначения ролей.

Замечание

Если у вашей учетной записи нет разрешения на создание субъекта-службы, New-AzADServicePrincipal возвращает сообщение об ошибке, которое содержит текст "Недостаточно привилегий для завершения операции". Обратитесь к администратору Microsoft Entra, чтобы создать учетную запись службы.

В каталоге Microsoft Entra ID, где для параметра пользователя Users можно зарегистрировать приложения задано значение No, необходимо быть членом одной из Microsoft Entra ID следующих встроенных ролей (которые имеют действие: microsoft.directory/applications/createAsOwner или microsoft.directory/applications/create):

Для получения дополнительной информации о параметрах пользователей в Microsoft Entra ID смотрите Restrict who can create applications.

Существует два типа проверки подлинности для субъектов-служб: аутентификация на основе паролей и проверка подлинности на основе сертификатов.

Аутентификация на основе пароля

Это важно

Роль по умолчанию для службы проверки подлинности на основе паролей — Сотрудник. Эта роль имеет полные разрешения на чтение и запись в учетную запись Azure. Сведения об управлении назначениями ролей см. в разделе "Управление ролями субъекта-службы".

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

$sp = New-AzADServicePrincipal -DisplayName ServicePrincipalName

Возвращаемый объект содержит PasswordCredentials.SecretText свойство, содержащее созданный пароль. Убедитесь, что вы храните это значение в безопасном месте для аутентификации с помощью учетной записи основной службы. Его значение не будет отображаться в выходных данных консоли. Если вы потеряли пароль, сбросьте учетные данные сервисного принципала.

Следующий код позволяет экспортировать секрет:

$sp.PasswordCredentials.SecretText

Объект, возвращаемый из New-AzADServicePrincipal, содержит Id и DisplayName свойства, которые можно использовать для входа с помощью учетной записи службы.

Это важно

Для входа с помощью учетной записи службы требуется идентификатор арендатора, под которым была создана учетная запись службы. Чтобы получить активный клиент при создании субъекта-службы, выполните следующую команду сразу после создания субъекта-службы:

(Get-AzContext).Tenant.Id

Проверка подлинности на основе сертификатов

Это важно

При создании принципала службы аутентификации на основе сертификатов роль по умолчанию не назначается. Сведения об управлении назначениями ролей см. в разделе "Управление ролями субъекта-службы".

Субъекты-службы, использующие проверку подлинности на основе сертификатов, создаются с параметром CertValue . Этот параметр принимает строку ASCII в кодировке Base64 общедоступного сертификата. Это представлено PEM-файлом или текстовым кодом CRT или CER. Двоичные кодировки общедоступного сертификата не поддерживаются. В этих инструкциях предполагается, что у вас уже есть сертификат.

$cert = <public certificate as base64-encoded string>
$sp = New-AzADServicePrincipal -DisplayName ServicePrincipalName -CertValue $cert

Объект, возвращаемый из New-AzADServicePrincipal, содержит свойства Id и DisplayName, любой из которых можно использовать для входа с помощью учетной записи службы. Клиентам, которые входят в систему с помощью субъекта-службы, также требуется доступ к закрытому ключу сертификата.

Это важно

Для входа с помощью учетной записи службы требуется идентификатор арендатора, под которым была создана учетная запись службы. Чтобы получить активный клиент при создании субъекта-службы, выполните следующую команду сразу после создания субъекта-службы:

(Get-AzContext).Tenant.Id

Получить существующего субъекта-службы

Список основных служб для активного клиента можно получить с помощью Get-AzADServicePrincipal. По умолчанию эта команда возвращает все субъекты-службы в клиенте. Для крупных организаций может потребоваться много времени для возврата результатов. Вместо этого рекомендуется использовать один из необязательных аргументов фильтрации на стороне сервера:

  • DisplayNameBeginsWith запрашивает сервисные учетные записи, имеющие префикс, соответствующий предоставленному значению. Отображаемое имя субъекта-службы — это значение, заданное DisplayName во время создания.
  • DisplayName запрашивает точное совпадение имени сущности службы.

Управление ролями сервисного принципала

Azure PowerShell имеет следующие командлеты для управления назначениями ролей:

Дополнительные сведения о Role-Based контроль доступа (RBAC) и ролях см. в разделе RBAC: встроенные роли.

В следующем примере добавляется роль читателя и удаляется роль участника :

New-AzRoleAssignment -ApplicationId <service principal application ID> -RoleDefinitionName 'Reader'
Remove-AzRoleAssignment -ObjectId <service principal object ID> -RoleDefinitionName 'Contributor'

Это важно

Командлеты назначения ролей не принимают идентификатор объекта субъекта-службы. Они принимают связанный идентификатор приложения, который создается при создании. Чтобы получить идентификатор приложения для субъекта-службы, используйте Get-AzADServicePrincipal.

Замечание

Если у вашей учетной записи нет разрешения на назначение роли, вы увидите сообщение об ошибке, сообщающее, что у вашей учетной записи отсутствует авторизация для выполнения действия 'Майкрософт.Authorization/roleAssignments/write'. Обратитесь к администратору Microsoft Entra для управления ролями.

Добавление роли не ограничивает ранее назначенные разрешения. При ограничении разрешений сервисного принципала роль участника должна быть удалена.

Изменения можно проверить, перечислив назначенные роли:

Get-AzRoleAssignment -ServicePrincipalName ServicePrincipalName

Вход с помощью учетной записи службы

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

Чтобы войти с использованием учетной записи службы через пароль:

# Use the application ID as the username, and the secret as password
$credentials = Get-Credential
Connect-AzAccount -ServicePrincipal -Credential $credentials -Tenant <tenant ID>

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

Connect-AzAccount -ServicePrincipal -Tenant <TenantId> -CertificateThumbprint <Thumbprint> -ApplicationId <ApplicationId>

Инструкции по импорту сертификата в хранилище учетных данных, доступного PowerShell, см. в разделе "Проверка подлинности на основе сертификатов"

Сброс учетных данных

Если вы забыли учетные данные для объекта службы, используйте New-AzADSpCredential чтобы добавить новые учетные данные со случайным паролем. Этот командлет не поддерживает заданные пользователем учетные данные при сбросе пароля.

Это важно

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

Remove-AzADSpCredential -DisplayName ServicePrincipalName

$newCredential = New-AzADSpCredential -ServicePrincipalName ServicePrincipalName

Troubleshooting

Если вы получите сообщение об ошибке "New-AzADServicePrincipal: Another object with the same value for property identifierUris already exists.", убедитесь, что служебный принципал с тем же именем еще не существует.

Get-AzAdServicePrincipal -DisplayName ServicePrincipalName

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

Remove-AzAdServicePrincipal -DisplayName ServicePrincipalName

Эта ошибка также может возникнуть, если ранее был создан служебный принципал для приложения в Azure Active Directory. Если удалить учетную запись службы, приложение по-прежнему будет доступно. Это приложение предотвращает создание другого субъекта-службы с тем же именем.

В следующем примере можно убедиться, что приложение Microsoft Entra с тем же именем не существует:

Get-AzADApplication -DisplayName ServicePrincipalName

Если приложение с тем же именем существует и больше не требуется, его можно удалить с помощью следующего примера.

Remove-AzADApplication -DisplayName ServicePrincipalName

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

  • Last updated on