Проверка подлинности только для приложений для автоматических сценариев в Exchange Online PowerShell и PowerShell для обеспечения безопасности & соответствия требованиям

Статья
06/26/2024

Сценарии аудита и создания отчетов в Microsoft 365 часто включают автоматические сценарии в Exchange Online PowerShell и PowerShell безопасности и соответствия требованиям. Раньше для автоматического входа требовалось хранить имя пользователя и пароль в локальном файле или в секретном хранилище, которое открывалось при запуске. Но, как мы все знаем, хранение учетных данных пользователя локально не является хорошей практикой безопасности.

Проверка подлинности на основе сертификатов (CBA) или проверка подлинности только для приложений, как описано в этой статье, поддерживает сценарии автоматического выполнения скриптов и автоматизации с помощью приложений Microsoft Entra и самозаверяющих сертификатов.

Примечание.

Знаете ли вы, что можно подключиться к Exchange Online PowerShell с помощью управляемых удостоверений в Azure? См . сведения об использовании управляемых удостоверений Azure для подключения к Exchange Online PowerShell.
Для функций и процедур, описанных в этой статье, требуются следующие версии модуля Exchange Online PowerShell:
- Exchange Online PowerShell (Connect-ExchangeOnline): версия 2.0.3 или более поздняя.
- Безопасность & соответствия Требованиям PowerShell (Connect-IPPSSession): версия 3.0.0 или более поздняя.
Инструкции по установке или обновлению модуля см. в статье Установка и обслуживание модуля Exchange Online PowerShell. Инструкции по использованию модуля в службе автоматизации Azure см. в статье Управление модулями в службе автоматизации Azure.
Для подключений REST API в модуле Exchange Online PowerShell версии 3 требуются модули PowerShellGet и PackageManagement. Дополнительные сведения см. в статье PowerShellGet для подключений на основе REST в Windows.

Если процедуры, описанные в этой статье, не работают, убедитесь, что у вас нет установленных бета-версий модулей PackageManagement или PowerShellGet, выполнив следующую команду: Get-InstalledModule PackageManagement -AllVersions; Get-InstalledModule PowerShellGet -AllVersions.
В PowerShell Exchange Online нельзя использовать процедуры, описанные в этой статье, со следующими командлетами групп Microsoft 365.
Вы можете использовать Microsoft Graph для замены большинства функциональных возможностей этих командлетов. Дополнительные сведения см. в статье Работа с группами в Microsoft Graph.
В разделе Безопасность & соответствия требованиям PowerShell нельзя использовать процедуры, описанные в этой статье, со следующими командлетами группы Microsoft 365:
Делегированные сценарии поддерживаются в Exchange Online. Рекомендуемый метод подключения с помощью делегирования — использование GDAP и согласия приложения. Дополнительные сведения см. в статье Использование модуля Exchange Online PowerShell версии 3 с GDAP и согласием приложения. Вы также можете использовать мультитенантные приложения, если отношения CSP не создаются с клиентом. Необходимые шаги для использования мультитенантных приложений описаны в обычных инструкциях в этой статье.
Используйте переключатель SkipLoadingFormatData в командлете Connect-ExchangeOnline , если при использовании пакета SDK для Windows PowerShell для подключения появляется следующая ошибка: The term 'Update-ModuleManifest' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Как это работает?

Модуль Exchange Online PowerShell использует библиотеку проверки подлинности Active Directory для получения маркера только для приложения с помощью идентификатора приложения, идентификатора клиента (организации) и отпечатка сертификата. Объекту приложения, подготовленному внутри Идентификатора Microsoft Entra, назначена роль каталога, которая возвращается в маркере доступа. Управление доступом на основе ролей (RBAC) в этом сеансе настроено с помощью информации о роли каталога, которая доступна в маркере.

Примеры подключения

В следующих примерах показано, как использовать модуль PowerShell Exchange Online с проверкой подлинности только для приложений.

Важно!

В следующих командах подключения используйте основной .onmicrosoft.com домен организации в качестве значения параметра Organization .

Следующие команды подключения имеют многие из доступных параметров, описанных в разделах Подключение к Exchange Online PowerShell и Подключение к powerShell & соответствия требованиям. Например:

Для сред Microsoft 365 GCC High или Microsoft 365 DoD требуются следующие дополнительные параметры и значения:
- Connect-ExchangeOnline в GCC High: -ExchangeEnvironmentName O365USGovGCCHigh.
- Connect-IPPSSession в GCC High: -ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common.
- Connect-ExchangeOnline в DoD: -ExchangeEnvironmentName O365USGovDoD.
- Connect-IPPSSession в DoD: -ConnectionUri https://l5.ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common.
Если команда Connect-IPPSSession отображает запрос на вход, выполните команду: $Global:IsWindows = $true перед командой Connect-IPPSSession .

Подключение с помощью отпечатка сертификата:

Примечание.

Параметр CertificateThumbprint поддерживается только в Microsoft Windows.

Сертификат должен быть установлен на компьютере, где выполняется команда. Сертификат должен быть установлен в хранилище сертификатов пользователя.
- Exchange Online PowerShell:
```
Connect-ExchangeOnline -CertificateThumbPrint "012THISISADEMOTHUMBPRINT" -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
```
- PowerShell безопасности и соответствия требованиям:
```
Connect-IPPSSession -CertificateThumbPrint "012THISISADEMOTHUMBPRINT" -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
```
Подключение с помощью объекта сертификата:

Сертификат не требуется устанавливать на компьютере, где выполняется команда. Объект сертификата можно хранить удаленно. Сертификат извлекается при выполнении скрипта.
- Exchange Online PowerShell:
```
Connect-ExchangeOnline -Certificate <%X509Certificate2 Object%> -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
```
- PowerShell безопасности и соответствия требованиям:
```
Connect-IPPSSession -Certificate <%X509Certificate2 Object%> -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
```
Подключитесь с помощью локального сертификата:

Примечание.

Использование команды ConvertTo-SecureString для локального хранения пароля сертификата не позволяет использовать безопасный метод подключения для сценариев автоматизации. Использование команды Get-Credential для безопасного запроса пароля сертификата не подходит для сценариев автоматизации. Другими словами, на самом деле нет автоматизированного и безопасного способа подключения с помощью локального сертификата.
- Exchange Online PowerShell:
```
Connect-ExchangeOnline -CertificateFilePath "C:\Users\navin\Desktop\automation-cert.pfx" -CertificatePassword (Get-Credential).password -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
```
- PowerShell безопасности и соответствия требованиям:
```
Connect-IPPSSession -CertificateFilePath "C:\Users\navin\Desktop\automation-cert.pfx" -CertificatePassword (Get-Credential).password -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" -Organization "contosoelectronics.onmicrosoft.com"
```

Настройка проверки подлинности только для приложений

Для проверки подлинности с помощью объектов приложения необходимо выполнить первоначальное подключение. Приложение и субъект-служба взаимозаменяемы, но приложение является объектом класса, а субъект — экземпляром класса. Дополнительные сведения см. в статье Объекты приложения и субъекта-службы в Microsoft Entra ID.

Подробные сведения о создании приложений с идентификатором Microsoft Entra см. в разделе https://aka.ms/azuread-app.

Зарегистрируйте приложение в Microsoft Entra ID.
Назначьте приложению разрешения API.

Объект приложения по умолчанию имеет разрешение делегированного APIUser.ReadMicrosoft Graph>. Для доступа к ресурсам в Exchange объекту приложения требуется разрешение API приложенийOffice 365 Exchange Online>Exchange.ManageAsApp.
Создайте самозаверяющий сертификат.
- Для проверки подлинности только для приложений в Идентификаторе Microsoft Entra обычно используется сертификат для запроса доступа. Любой пользователь, у которого есть сертификат и его закрытый ключ, может использовать приложение с разрешениями, предоставленными приложению.
- Создайте и настройте самозаверяющий сертификат X.509, который используется для проверки подлинности приложения по идентификатору Microsoft Entra при запросе маркера доступа только для приложения.
- Эта процедура аналогична созданию пароля для учетных записей пользователей. Сертификат также может быть самозаверяющим. Инструкции по созданию сертификатов в PowerShell см. далее в этой статье.
  
  Примечание.
  
  Шифрование. Сертификаты следующего поколения (CNG) не поддерживаются для проверки подлинности только для приложений в Exchange. Сертификаты CNG создаются по умолчанию в современных версиях Windows. Необходимо использовать сертификат от поставщика ключей CSP. В этом разделе рассматриваются два поддерживаемых метода создания сертификата CSP.
Присоединение сертификата к приложению Microsoft Entra
Назначение ролей Microsoft Entra приложению

Приложению я должны быть назначены соответствующие роли RBAC. Так как приложения подготовлены с помощью Идентификатора Microsoft Entra, можно использовать любую из поддерживаемых встроенных ролей.

Шаг 1. Регистрация приложения в Идентификаторе Microsoft Entra

Примечание.

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

Откройте Центр администрирования Microsoft Entra по адресу https://portal.azure.com/.
В поле Поиск в верхней части страницы начните вводить регистрация приложений, а затем выберите Регистрация приложений в результатах в разделе Службы .

Или, чтобы перейти непосредственно на страницу Регистрации приложений , используйте https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade.
На странице Регистрация приложений выберите Новая регистрация.

На открывшейся странице Регистрация приложения настройте следующие параметры.
- Имя: введите описательное имя. Например, ExO PowerShell CBA.
- Поддерживаемые типы учетных записей. Убедитесь, что выбраны только учетные записи в этом каталоге организации (<только имя_организации> — один клиент).
  
  Примечание.
  
  Чтобы сделать приложение мультитенантным для делегированных сценариев Exchange Online , выберите значение Учетные записи в любом каталоге организации (любой каталог Microsoft Entra — Мультитенантный)..
- URI перенаправления (необязательно): этот параметр является необязательным. Если вам нужно его использовать, настройте следующие параметры:
  - Платформа: выберите Интернет.
  - URI. Введите универсальный код ресурса (URI), куда отправляется маркер доступа.
  Примечание.
  
  Нельзя создавать учетные данные для собственных приложений, так как нельзя использовать собственные приложения для автоматизированных приложений.
Завершив работу на странице Регистрация приложений , выберите Зарегистрировать.
Вы перейдете на страницу Обзор только что зарегистрированного приложения. Оставьте эту страницу открытой. Она вам понадобится на следующем шаге.

Шаг 2. Назначение приложению разрешений API

Выберите один из следующих методов в этом разделе, чтобы назначить приложению разрешения API:

Выберите и назначьте разрешения API на портале.
Измените манифест приложения, чтобы назначить разрешения API. (Организации Microsoft 365 GCC High и DoD должны использовать этот метод)

Выбор и назначение разрешений API на портале

На странице Обзор приложения выберите Разрешения API в разделе Управление .
На странице Разрешения API приложения выберите Добавить разрешение.
Во всплывающем окне Запрос разрешений API выберите вкладку API, которые использует моя организация , начните вводить Office 365 Exchange Online в поле Поиск и выберите его в результатах.
Во всплывающем окне Какой тип разрешений требуется приложению? выберите Разрешения приложения.
В появившемся списке разрешений разверните узел Exchange, выберите Exchange.ManageAsApp, а затем выберите Добавить разрешения.
Вернитесь на страницу разрешений API приложения, убедитесь, что Office 365 Exchange Online>Exchange.ManageAsApp указан и содержит следующие значения:
- Тип: Application.
- Требуется согласие администратора. Да.
- Состояние: текущее неверное значение не предоставлено для <организации>.
  
  Измените это значение, выбрав Предоставить согласие администратора для <организации>, проверив открывающееся диалоговое окно подтверждения и выбрав Да.
  
  Теперь значение Status (Состояние ) предоставлено для <организации>.
Для записи По умолчанию Microsoft Graph>User.Read выберите ...>Отмените согласие администратора, а затем выберите Да в открывшемся диалоговом окне подтверждения, чтобы вернуть состояние к пустому значению по умолчанию.
Закройте текущую страницу Разрешения API (не вкладку браузера), чтобы вернуться на страницу Регистрация приложений. На следующем шаге вы будете использовать страницу Регистрация приложений .

Изменение манифеста приложения для назначения разрешений API

Примечание.

Процедуры в этом разделе добавляют существующие разрешения по умолчанию для приложения (делегированные разрешения User.Read в Microsoft Graph) с необходимыми разрешениями приложения Exchange.ManageAsApp в Office 365 Exchange Online.

На странице обзор приложения выберите Манифест в разделе Управление .

На странице манифеста приложения найдите requiredResourceAccess запись (в строке 42 или около нее) и сделайте запись похожей на следующий фрагмент кода:

"requiredResourceAccess": [
    {
        "resourceAppId": "00000002-0000-0ff1-ce00-000000000000",
        "resourceAccess": [
            {
                "id": "dc50a0fb-09a3-484d-be87-e023b12c6440",
                "type": "Role"
            }
        ]
    },
    {
        "resourceAppId": "00000003-0000-0000-c000-000000000000",
        "resourceAccess": [
            {
                "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
                "type": "Scope"
            }
        ]
    }
],

Примечание.

Среды Microsoft 365 GCC High или DoD имеют доступ только к PowerShell & соответствия требованиям безопасности. Используйте следующие значения для requiredResourceAccess записи:

"requiredResourceAccess": [
    {
        "resourceAppId": "00000007-0000-0ff1-ce00-000000000000",
        "resourceAccess": [
            {
                "id": "455e5cd2-84e8-4751-8344-5672145dfa17",
                "type": "Role"
            }
        ]
    },
    {
        "resourceAppId": "00000003-0000-0000-c000-000000000000",
        "resourceAccess": [
            {
                "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
                "type": "Scope"
            }
        ]
    }
],

По завершении работы на странице Манифест нажмите кнопку Сохранить.

На странице Манифест выберите Разрешения API в разделе Управление .
На странице Разрешения API убедитесь, что office 365 Exchange Online>Exchange.ManageAsApp указан и содержит следующие значения:
- Тип: Application.
- Требуется согласие администратора. Да.
- Состояние. Текущее неверное значение не предоставлено для <> записи Office 365 Exchange Online>Exchange.ManageAsApp.
  
  Измените значение состояния , выбрав Предоставить согласие администратора для <организации>, прочитав открывающееся диалоговое окно подтверждения, а затем выберите Да.
  
  Теперь значение Status (Состояние ) предоставлено для <организации>.
Для записи По умолчанию Microsoft Graph>User.Read выберите ...>Отмените согласие администратора, а затем выберите Да в открывшемся диалоговом окне подтверждения, чтобы вернуть состояние к пустому значению по умолчанию.
Закройте текущую страницу Разрешения API (не вкладку браузера), чтобы вернуться на страницу Регистрация приложений. На следующем шаге вы будете использовать страницу Регистрация приложений .

Шаг 3. Создание самозаверяющего сертификата

Создайте самозаверяющий сертификат x.509 с помощью одного из следующих способов.

Рекомендуется. Используйте командлеты New-SelfSignedCertificate, Export-Certificate и Export-PfxCertificate в сеансе Windows PowerShell с повышенными правами (запуск в качестве администратора), чтобы запросить самозаверяющий сертификат и экспортировать его в .cer и .pfx (SHA1 по умолчанию). Например:
```
# Create certificate
$mycert = New-SelfSignedCertificate -DnsName "contoso.org" -CertStoreLocation "cert:\CurrentUser\My" -NotAfter (Get-Date).AddYears(1) -KeySpec KeyExchange

# Export certificate to .pfx file
$mycert | Export-PfxCertificate -FilePath mycert.pfx -Password (Get-Credential).password

# Export certificate to .cer file
$mycert | Export-Certificate -FilePath mycert.cer
```
Используйте сценарий Create-SelfSignedCertificate, чтобы создать сертификаты SHA1.
```
.\Create-SelfSignedCertificate.ps1 -CommonName "MyCompanyName" -StartDate 2021-01-06 -EndDate 2022-01-06
```

Шаг 4. Присоединение сертификата к приложению Microsoft Entra

Зарегистрировав сертификат в приложении, вы сможете использовать для проверки подлинности закрытый ключ (файл .pfx) или отпечаток.

На вкладке Собственные приложения на странице Регистрация приложений в конце шага 2 выберите свое приложение.

Если вам нужно вернуться на страницу регистрации приложений , используйте https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/RegisteredApps, убедитесь, что выбрана вкладка Принадлежащие приложения , а затем выберите свое приложение.
На открывающейся странице приложения выберите Сертификаты & секреты в разделе Управление .
На странице Сертификаты & секреты выберите Отправить сертификат.

В открывшемся диалоговом окне перейдите к самозаверяющему сертификату (файл .cer), созданному на шаге 3.

Когда вы закончите, нажмите Добавить.

Сертификат теперь отображается в разделе Сертификаты.
Закройте текущую страницу Сертификаты и секреты и страницу Регистрация приложений, чтобы вернуться к главной странице https://portal.azure.com/. Она вам понадобится на следующем шаге.

Если вы сделали приложение мультитенантным для делегированных сценариев Exchange Online на шаге 1, необходимо предоставить согласие администратора на разрешение Exchange.ManageAsApp, чтобы приложение можло выполнять командлеты в Exchange Online в каждой организации клиента. Для этого создайте URL-адрес согласия администратора для каждого клиента клиента. Прежде чем использовать мультитенантное приложение для подключения к Exchange Online в организации клиента, администратор клиента должен открыть следующий URL-адрес:

https://login.microsoftonline.com/<tenant-id>/adminconsent?client_id=<client-id>&scope=https://outlook.office365.com/.default

<tenant-id> — это идентификатор клиента.
<client-id> — это идентификатор мультитенантного приложения.
Область по умолчанию используется для предоставления приложению разрешений.

Дополнительные сведения о синтаксисе URL-адресов см. в разделе Запрос разрешений у администратора каталога.

Шаг 5. Назначение приложению ролей Microsoft Entra

У вас есть два варианта:

Назначение ролей Microsoft Entra приложению
Назначение пользовательских групп ролей приложению с помощью субъектов-служб. Этот метод поддерживается только при подключении к Exchange Online PowerShell или PowerShell & соответствия требованиям безопасности в режиме REST API. Безопасность & соответствия PowerShell поддерживает режим REST API в версии 3.2.0 или более поздней версии.

Примечание.

Вы также можете объединить оба метода для назначения разрешений. Например, можно использовать роли Microsoft Entra для роли "Администратор получателей Exchange", а также назначить пользовательскую роль RBAC для расширения разрешений.

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

Назначение ролей Microsoft Entra приложению

Поддерживаемые роли Microsoft Entra описаны в следующей таблице:

Role	Exchange Online. PowerShell	Безопасность и соответствие требованиям PowerShell
Администратор соответствия	✔	✔
Администратор Exchange¹	✔
Администратор получателей Exchange	✔
Глобальный администратор¹ 2	✔	✔
Глобальное средство чтения	✔	✔
Администратор службы поддержки	✔
Администратор безопасности¹	✔	✔
Читатель сведений о безопасности	✔	✔

¹ Роли глобального администратора и администратора Exchange предоставляют необходимые разрешения для любой задачи в Exchange Online PowerShell. Например:

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

Роль администратора безопасности не имеет необходимых разрешений для этих задач.

2 Корпорация Майкрософт рекомендует использовать роли с наименьшими разрешениями. Использование учетных записей с более низкими разрешениями помогает повысить безопасность организации. Глобальный администратор — это очень привилегированная роль, которая должна быть ограничена сценариями чрезвычайных ситуаций, когда вы не можете использовать существующую роль.

Общие инструкции по назначению ролей в Идентификаторе Microsoft Entra см. в статье Назначение ролей Microsoft Entra пользователям.

Примечание.

Следующие действия немного отличаются в Exchange Online PowerShell и PowerShell безопасности и соответствия требованиям. Показаны действия для обеих сред. Чтобы настроить роли для обеих сред, повторите действия из этого раздела.

В Центре администрирования Microsoft Entra начните https://portal.azure.com/вводить роли и администраторы в поле Поиск в верхней части страницы, а затем выберите Роли и администраторы Microsoft Entra в результатах в разделе Службы .

Или, чтобы перейти непосредственно на страницу ролей и администраторов Microsoft Entra , используйте https://portal.azure.com/#view/Microsoft_AAD_IAM/AllRolesBlade.
На открывшейся странице Роли и администраторы найдите и выберите одну из поддерживаемых ролей, щелкнув название роли (не флажок) в результатах.
- Exchange Online PowerShell. Например, найдите и выберите роль администратора Exchange .
- Безопасность & соответствия Требованиям PowerShell. Например, найдите и выберите роль Администратор соответствия требованиям .
На открывающейся странице Назначения выберите Добавить назначения.
- Exchange Online PowerShell:
- PowerShell безопасности и соответствия требованиям:
В появившейся всплывающей области Добавить назначения найдите и выберите приложение, созданное на шаге 1.

По завершении во всплывающем окне Добавление назначений нажмите кнопку Добавить.
Вернитесь на страницу Назначения и убедитесь, что роль назначена приложению.
- Exchange Online PowerShell:
- PowerShell безопасности и соответствия требованиям:

Назначение пользовательских групп ролей приложению с помощью субъектов-служб

Примечание.

Прежде чем выполнять действия по созданию субъекта-службы, необходимо подключиться к Exchange Online PowerShell или PowerShell & безопасности. Создание субъекта-службы без подключения к PowerShell не будет работать (для создания нового субъекта-службы необходимы идентификатор приложения Azure и идентификатор объекта).

Этот метод поддерживается только при подключении к Exchange Online PowerShell или powerShell & обеспечения соответствия безопасности PowerShell в режиме REST API. Безопасность & соответствия PowerShell поддерживает режим REST API в версии 3.2.0 или более поздней версии.

Сведения о создании настраиваемых групп ролей см. в разделах Создание групп ролей в Exchange Online и Создание групп ролей для совместной работы & электронной почты на портале Microsoft Defender. Настраиваемая группа ролей, назначенная приложению, может содержать любое сочетание встроенных и настраиваемых ролей.

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

В Microsoft Graph PowerShell выполните следующие команды, чтобы сохранить сведения о приложении Microsoft Entra, зарегистрированном на шаге 1 , в переменной:
```
Connect-MgGraph -Scopes AppRoleAssignment.ReadWrite.All,Application.Read.All

$<VariableName1> = Get-MgServicePrincipal -Filter "DisplayName eq '<AppName>'"
```
Например:
```
Connect-MgGraph -Scopes AppRoleAssignment.ReadWrite.All,Application.Read.All

$AzureADApp = Get-MgServicePrincipal -Filter "DisplayName eq 'ExO PowerShell CBA'"
```
Подробные сведения о синтаксисе и параметрах см. в разделе Get-MgServicePrincipal.
В том же окне PowerShell подключитесь к Exchange Online PowerShell или Службе безопасности & соответствия требованиям PowerShell и выполните следующие команды, чтобы:
- Создайте объект субъекта-службы для приложения Microsoft Entra.
- Сохраните сведения о субъекте-службе в переменной, используемой на следующем шаге.
```
New-ServicePrincipal -AppId $<VariableName1>.AppId -ObjectId $<VariableName1>.Id -DisplayName "<Descriptive Name>"

$<VariableName2> = Get-ServicePrincipal -Identity "<Descriptive Name>"
```
Например:
```
New-ServicePrincipal -AppId $AzureADApp.AppId -ObjectId $AzureADApp.Id -DisplayName "SP for Azure AD App ExO PowerShell CBA"

$SP = Get-ServicePrincipal -Identity "SP for Azure AD App ExO PowerShell CBA"
```
Подробные сведения о синтаксисе и параметрах см. в разделе New-ServicePrincipal.
В Exchange Online PowerShell или PowerShell для обеспечения соответствия безопасности & выполните следующую команду, чтобы добавить субъект-службу в качестве члена настраиваемой группы ролей:
```
Add-RoleGroupMember -Identity "<CustomRoleGroupName>" -Member <$<VariableName2>.Identity | $<VariableName2>.ObjectId | $<VariableName2>.Id>
```
Например:
```
Add-RoleGroupMember -Identity "Contoso View-Only Recipients" -Member $SP.Identity
```
Дополнительные сведения о синтаксисе и параметрах см. в разделе Add-RoleGroupMember.

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

Проверка подлинности только для приложений для автоматических сценариев в Exchange Online PowerShell и PowerShell для обеспечения безопасности & соответствия требованиям

Как это работает?

Примеры подключения

Настройка проверки подлинности только для приложений

Шаг 1. Регистрация приложения в Идентификаторе Microsoft Entra

Шаг 2. Назначение приложению разрешений API

Выбор и назначение разрешений API на портале

Изменение манифеста приложения для назначения разрешений API

Шаг 3. Создание самозаверяющего сертификата

Шаг 4. Присоединение сертификата к приложению Microsoft Entra

Шаг 5. Назначение приложению ролей Microsoft Entra

Назначение ролей Microsoft Entra приложению

Назначение пользовательских групп ролей приложению с помощью субъектов-служб

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

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

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

Проверка подлинности только для приложений для автоматических сценариев в Exchange Online PowerShell и PowerShell для обеспечения безопасности & соответствия требованиям

Как это работает?

Примеры подключения

Настройка проверки подлинности только для приложений

Шаг 1. Регистрация приложения в Идентификаторе Microsoft Entra

Шаг 2. Назначение приложению разрешений API

Выбор и назначение разрешений API на портале

Изменение манифеста приложения для назначения разрешений API

Шаг 3. Создание самозаверяющего сертификата

Шаг 4. Присоединение сертификата к приложению Microsoft Entra

Шаг 4b. Только делегированные сценарии Exchange Online. Предоставление согласия администратора для мультитенантного приложения

Шаг 5. Назначение приложению ролей Microsoft Entra

Назначение ролей Microsoft Entra приложению

Назначение пользовательских групп ролей приложению с помощью субъектов-служб

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

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