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

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

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

Примечание.

Знаете ли вы, что можете подключиться к Exchange Online PowerShell с помощью управляемых удостоверений в Azure? Ознакомьтесь со статьей Использование управляемых удостоверений Azure для подключения к Exchange Online PowerShell.
Для функций и процедур, описанных в этой статье, требуются следующие версии модуля PowerShell Exchange Online:
- Exchange Online PowerShell (Connect-ExchangeOnline): версия 2.0.4 или более поздняя.
- Безопасность & соответствие требованиям PowerShell (Connect-IPPSSession): версия 3.0.0 или более поздняя.
Инструкции по установке или обновлению модуля см. в статье Установка и обновление модуля PowerShell Exchange Online. Инструкции по использованию модуля в службе автоматизации Azure см. в статье Управление модулями в службе автоматизации Azure.
CBA или проверка подлинности только для приложений доступна в Office 365, предоставляемом 21Vianet в Китае.
Для подключений REST API в модуле PowerShell V3 Exchange Online требуются модули PowerShellGet и PackageManagement. Дополнительные сведения см. в статье PowerShellGet для подключений на основе REST в Windows.
Если процедуры, описанные в этой статье, не подошли, убедитесь, что у вас не установлены предварительные версии модулей PackageManagement или PowerShellGet, выполнив следующую команду: Get-InstalledModule PackageManagement -AllVersions; Get-InstalledModule PowerShellGet -AllVersions.
В PowerShell Exchange Online нельзя использовать процедуры, описанные в этой статье, со следующими командлетами групп Microsoft 365.
Вы можете использовать Microsoft Graph, чтобы заменить большую часть функций этих командлетов. Дополнительные сведения см. в статье Работа с группами в Microsoft Graph.
Проверка подлинности только для приложений не поддерживается для Microsoft Purview eDiscovery командлетов в Security & Compliance PowerShell, включая, помимо прочего:
По возможности перенесите существующие средства автоматизации на API Microsoft Graph. Чтобы обеспечить поддержку функциональности для автоматизаций, которые продолжают использовать эту неподдерживаемую конфигурацию, используйте модуль ExchangeOnlineManagement версии 3.10.1 или более поздней, коммутатор EnableSearchOnlySession с Connect-IPPSSession, а также требуемый субъект-службу и конфигурацию управления доступом на основе ролей (RBAC) для обнаружения электронных данных. Эти меры не влияют на состояние неподдерживаемой конфигурации Дополнительные сведения см. в статье Настройка проверки подлинности только приложений для обнаружения электронных данных PowerShell.
Делегированные сценарии поддерживаются в Exchange Online. Рекомендуемый способ подключения к делегированию — использование GDAP и согласия приложения. Дополнительные сведения см. в статье "Использование модуля Exchange Online PowerShell v3 с 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 с проверкой подлинности только приложения:

Важно!

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

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

Для сред Microsoft 365 GCC High, Microsoft 365 DoD или Microsoft 365 China (управляемых 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", по-прежнему работает, но может предложить вам выбрать между личной учетной записью и рабочей или учебной учетной записью. Значение URI рекомендуется использовать /organizations в корпоративных сценариях, где следует исключить учетные записи потребителей.
Если команда Connect-IPPSSession отображает приглашение на вход, запустите команду: $Global:IsWindows = $true перед командой Connect-IPPSSession .
Для существующих автоматизаций обнаружения электронных данных, которые продолжают использовать неподдерживаемую конфигурацию "только приложение", используйте ExchangeOnlineManagement 3.10.1 или более поздней версии и добавьте ключ EnableSearchOnlySession в команду 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.

Объект приложения по умолчанию имеет разрешение делегированного API Microsoft Graph>User.Read . Добавьте разрешение приложения , соответствующее подключению PowerShell:
- Exchange Online PowerShell (Connect-ExchangeOnline):Office 365 Exchange Online>Exchange.ManageAsApp.
- Security & Compliance PowerShell (Connect-IPPSSession):Microsoft Exchange Online Protection>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 — многоклиентский)".
- URI перенаправления (необязательно): этот параметр необязателен. При необходимости настройте следующие параметры:
  - Платформа: выберите Интернет.
  - URI: введите URI, куда отправляется маркер доступа.
  Примечание.
  
  Невозможно создавать учетные данные для собственных приложений, так как нельзя использовать собственные приложения для автоматизированных приложений.
Завершив работу на странице "Регистрация приложений", нажмите "Зарегистрироваться".
Вы перейдете на страницу обзора зарегистрированного приложения. Оставьте эту страницу открытой. Используйте его на следующем шаге.

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

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

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

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

На странице "Обзор приложения" выберите "Разрешения API" в разделе "Управление ".
На странице разрешений API приложения выберите "Добавить разрешение".
Во всплывающем окне " Запросить разрешения API " выберите вкладку "API для моей организации ", а затем выберите API, соответствующий подключению PowerShell:
- Exchange Online PowerShell (Connect-ExchangeOnline): найдите и выберите Office 365 Exchange Online.
- Оболочка безопасности & соответствия требованиям PowerShell (Connect-IPPSSession): найдите и выберите Microsoft Exchange Online Защита.
Если приложение подключается к обеим средам, повторите шаги 2–5 для другого API, прежде чем переходить к шагу 6.

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

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

Примечание.

Процедуры, описанные в этом разделе , добавляют к существующим разрешениям по умолчанию для приложения (делегированные разрешения User.Read в Microsoft Graph) с необходимым разрешением приложения Exchange.ManageAsApp . Используйте значения ресурсов, соответствующие подключению PowerShell. Если приложение подключается к Exchange Online PowerShell и Security & Compliance PowerShell, включите оба объекта ресурса Exchange и один объект ресурса Microsoft Graph.

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

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

"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"
            }
        ]
    }
],

Примечание.

Для обеспечения безопасности & соответствия требованиям PowerShell в любой среде, включая Microsoft 365 GCC High и DoD, используйте следующие значения для 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 убедитесь, что каждое необходимое разрешение Exchange.ManageAsApp указано и содержит следующие значения:
- Тип: Применение.
- Требуется согласие администратора: да.
- Состояние: Организация не предоставляет <текущее> неверное значение.
  
  Измените значение состояния, выбрав "Предоставить согласие администратора для <организации", прочитайте открывшееся диалоговое окно подтверждения и выберите "Да>".
  
  Состояние теперь предоставлено <организации>.
Для записи 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/. Используйте его на следующем шаге.

Если на шаге 1 вы создали многотенантное приложение для делегированных сценариев Exchange Online, необходимо предоставить согласие администратора на разрешение 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	✔
Глобальный администратор¹ ²	✔	✔
Global Reader	✔	✔
Администратор службы технической поддержки	✔
Администратор безопасности¹	✔	✔
Читатель сведений о безопасности	✔	✔

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

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

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

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

Общие инструкции по назначению ролей в 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 или Security & Compliance. Создание субъекта-службы без подключения к 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 или Security & Compliance 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 или Security & Compliance PowerShell выполните следующую команду, чтобы добавить субъект-службу в качестве участника настраиваемой группы ролей:
```
Add-RoleGroupMember -Identity "<CustomRoleGroupName>" -Member <$<VariableName2>.Identity | $<VariableName2>.ObjectId | $<VariableName2>.Id>
```
Например, вы можете:
```
Add-RoleGroupMember -Identity "Contoso View-Only Recipients" -Member $SP.Identity
```
Дополнительные сведения о синтаксисе и параметрах см. в разделе Add-RoleGroupMember.

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

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

Последнее обновление: 2026-08-26

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

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

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

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

Шаг 1. Зарегистрируйте приложение в Microsoft Entra ID

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

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

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

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

Шаг 4. Вложение сертификата в приложение Microsoft Entra

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

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

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

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

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

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