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

Сценарии аудита и создания отчетов в 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.4 или более поздней.
- Безопасность & соответствия Требованиям PowerShell (Connect-IPPSSession): версия 3.0.0 или более поздняя.
Инструкции по установке или обновлению модуля см. в статье Установка и обслуживание Exchange Online модуля PowerShell. Инструкции по использованию модуля в служба автоматизации Azure см. в разделе Управление модулями в служба автоматизации Azure.
Проверка подлинности CBA или только для приложений доступна в Office 365, управляемых компанией 21Vianet в Китае.
Для подключений 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 Purview, включая, помимо прочего:
Делегированные сценарии поддерживаются в 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.

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

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

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

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

Важно!

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

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

Для сред Microsoft 365 GCC High, Microsoft 365 DoD или Microsoft 365 для Китая (управляется 21Vianet) требуются следующие дополнительные параметры и значения:
Microsoft 365 GCC High
- Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovGCCHigh
- Connect-IPPSSession -ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/organizations^*
Microsoft 365 DoD
- Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovDoD
- Connect-IPPSSession -ConnectionUri https://compliance.dod.microsoft.com/powershell-liveid -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/organizations^*
Microsoft 365 под управлением 21Vianet (Китай)
- Connect-ExchangeOnline -ExchangeEnvironmentName O365China
- Connect-IPPSSession -ConnectionUri https://ps.compliance.protection.partner.outlook.cn/powershell-liveid -AzureADAuthorizationEndpointUri https://login.chinacloudapi.cn/organizations^*
^* Значение AzureADAuthorizationEndpointUri , заканчивающееся на /organizations , разрешает использовать только рабочие или учебные учетные записи. Старое значение URI, заканчивающееся на/common, по-прежнему работает, но может предложить выбрать между личная учетная запись и рабочей или учебной учетной записью. Мы рекомендуем использовать /organizations значение URI в корпоративных сценариях, в которых следует исключить учетные записи потребителей.
Если команда 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 ID см. в разделе https://aka.ms/azuread-app.

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

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

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

Примечание.

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

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

Или, чтобы перейти непосредственно на страницу Регистрация приложений, используйте https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade.
На странице Регистрация приложений выберите Новая регистрация.
На открывшейся странице Регистрация приложения настройте следующие параметры.
- Имя: введите описательное имя. Например, ExO PowerShell CBA.
- Поддерживаемые типы учетных записей. Убедитесь, что выбраны только учетные записи в этом каталоге организации (<только имя_организации> — один клиент).
  
  Примечание.
  
  Чтобы сделать приложение мультитенантным для Exchange Online делегированных сценариев, выберите значение Учетные записи в любом каталоге организации (любой каталог Microsoft Entra — Multitenant).
- 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. Создание сертификата

Примечание.

Шифрование. Сертификаты следующего поколения (CNG) не поддерживаются для проверки подлинности только для приложений, как описано в этой статье. Сертификаты CNG создаются по умолчанию в современных версиях Windows. Необходимо использовать сертификат от поставщика ключей CSP.

Вы можете использовать самозаверяющий сертификат, сертификат, выданный внутренней инфраструктурой открытых ключей или PKI (например, службами сертификатов Active Directory или AD CS) или сертификатом, выданным доверенным коммерческим центром сертификации (ЦС).

Единственными требованиями к сертификату X.509 являются экспортируемый и доступный закрытый ключ (PFX-файл) и открытый сертификат (.cer).

Для самозаверяющего сертификата используйте один из следующих методов:

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

# Export the X.509 certificate and the associated private key to a password-protected .pfx file
$mycert | Export-PfxCertificate -FilePath mycert.pfx -Password (Get-Credential).password

# Export the X.509 public certificate to a .cer file
$mycert | Export-Certificate -FilePath mycert.cer
```
Используйте сценарий Create-SelfSignedCertificate, чтобы создать сертификаты SHA1.
```
.\Create-SelfSignedCertificate.ps1 -CommonName "MyCompanyName" -StartDate 2026-01-06 -EndDate 2027-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. Назначение приложению разрешений роли

Возможны следующие варианты:

Вариант 1. Назначение Microsoft Entra ролей приложению. Используйте встроенные Microsoft Entra роли для предоставления всех разрешений роли. Эти роли нельзя настроить или область.
Вариант 2. Назначение пользовательских групп ролей приложению с помощью субъектов-служб. Мы рекомендуем использовать этот вариант в следующих сценариях:
- Необходимо ограничить доступные команды в приложении.
- Чтобы ограничить число получателей, которые можно изменить, необходимо использовать область записи.
Вариант 3. Объединение Microsoft Entra ролей с настраиваемыми группами ролей: RBAC объединяет разрешения из всех источников. Этот метод рекомендуется для расширения возможностей встроенной роли Microsoft Entra. Например, можно расширить возможности роли администратора получателей Exchange , предоставив дополнительные разрешения от пользовательской роли.

Эти параметры описаны в следующих подразделах.

Примечание.

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

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

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

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

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

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

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

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

Общие инструкции по назначению ролей в Microsoft Entra ID см. в статье Назначение 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 безопасности и соответствия требованиям:

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

Примечание.

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

Сведения о создании настраиваемых групп ролей см. в разделах Создание групп ролей в Exchange Online и Создание групп ролей Email & совместной работы на портале 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.

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

Были ли сведения на этой странице полезными?

Last updated on 2026-03-11

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

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

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

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

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

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

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

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

Шаг 3. Создание сертификата

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

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

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

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

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

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

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