Exchange Online PowerShell とセキュリティ & コンプライアンス PowerShell での無人スクリプトのアプリ専用認証
Microsoft 365の監査とレポートのシナリオには、多くの場合、Exchange Online PowerShell と セキュリティ/コンプライアンス PowerShell の無人スクリプトが含まれます。 以前は、無人サインインでは、ユーザー名とパスワードをローカル ファイルまたは実行時にアクセスされるシークレット コンテナーに格納する必要がありました。 ただし、ご存じのように、ユーザー資格情報をローカルに格納することは、セキュリティ上の良い方法ではありません。
この記事で説明するように、証明書ベースの認証 (CBA) またはアプリのみの認証では、Microsoft Entra アプリと自己署名証明書を使用した無人スクリプトと自動化のシナリオがサポートされています。
注:
Azure でマネージド ID を使用して Exchange Online PowerShell に接続できることをご存知でしたか? 「 Azure マネージド ID を使用して Exchange Online PowerShell に接続する」を参照してください。
この記事で説明する機能と手順には、次のバージョンの Exchange Online PowerShell モジュールが必要です。
- Exchange Online PowerShell (Connect-ExchangeOnline): バージョン 2.0.3 以降。
- セキュリティ & コンプライアンス PowerShell (Connect-IPPSSession): バージョン 3.0.0 以降。
モジュールをインストールまたは更新する方法については、「 Exchange Online PowerShell モジュールのインストールと保守」を参照してください。 Azure Automation でモジュールを使用する方法については、「Azure Automation での モジュールの管理」を参照してください。
Exchange Online PowerShell V3 モジュールの REST API 接続には、PowerShellGet モジュールと PackageManagement モジュールが必要です。 詳細については、「 Windows での REST ベースの接続用 PowerShellGet」を参照してください。
この記事の手順がうまくいかない場合は、次のコマンドを実行して PackageManagement モジュールまたは PowerShellGet モジュールのベータ版がインストールされていないことを確認します:
Get-InstalledModule PackageManagement -AllVersions; Get-InstalledModule PowerShellGet -AllVersions
。Exchange Online PowerShell では、この記事の手順を次の Microsoft 365 グループ コマンドレットで使用することはできません。
Microsoft Graph を使用して、これらのコマンドレットのほとんどの機能を置き換えることができます。 詳細については、「Microsoft Graph でのグループの操作」を参照してください。
セキュリティ & コンプライアンス PowerShell では、次の Microsoft 365 グループ コマンドレットでは、この記事の手順を使用できません。
委任されたシナリオは、Exchange Online でサポートされています。 委任を使用して接続する場合に推奨される方法は、GDAP とアプリの同意を使用することです。 詳細については、「 GDAP とアプリの同意で Exchange Online PowerShell v3 モジュールを使用する」を参照してください。 また、CSP リレーションシップが顧客と作成されていない場合は、マルチテナント アプリケーションを使用することもできます。 マルチテナント アプリケーションを使用するために必要な手順については、この記事の通常の手順で説明します。
Windows PowerShell SDK を使用して接続するときに次のエラーが発生する場合は、Connect-ExchangeOnline コマンドレットの SkipLoadingFormatData スイッチを使用します。
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 認証ライブラリを使用して、アプリケーション ID、テナント ID (組織)、証明書の拇印を使用してアプリ専用トークンをフェッチします。 Microsoft Entra ID 内でプロビジョニングされたアプリケーション オブジェクトには、アクセス トークンで返されるディレクトリ ロールが割り当てられます。 セッションのロール ベースのアクセス制御 (RBAC) は、トークンで使用可能なディレクトリ ロール情報を使用して構成されます。
接続の例
次の例は、アプリ専用認証で Exchange Online PowerShell モジュールを使用する方法を示しています。
重要
次の接続コマンドでは、Organization パラメーターの値として、組織のプライマリ .onmicrosoft.com
ドメインを使用します。
次の接続コマンドには、「 Exchange Online PowerShell に接続する 」および「 セキュリティへの接続 & コンプライアンス PowerShell」の説明に従って、同じオプションの多くを使用できます。 例:
Microsoft 365 GCC High または Microsoft 365 DoD 環境には、次の追加のパラメーターと値が必要です。
-
GCC High の Connect-ExchangeOnline:
-ExchangeEnvironmentName O365USGovGCCHigh
。 -
GCC High での Connect-IPPSSession:
-ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common
。 -
DoD の Connect-ExchangeOnline:
-ExchangeEnvironmentName O365USGovDoD
。 -
DoD の Connect-IPPSSession:
-ConnectionUri https://l5.ps.compliance.protection.office365.us/powershell-liveid/ -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/common
。
-
GCC High の Connect-ExchangeOnline:
Connect-IPPSSession コマンドでログイン プロンプトが表示される場合は、Connect-IPPSSession コマンドの前に
$Global:IsWindows = $true
コマンドを実行します。
証明書の拇印を使用して接続します。
注:
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 Graph>User.Read の委任された API アクセス許可があります。 アプリケーション オブジェクトが Exchange のリソースにアクセスするには、 アプリケーション API アクセス許可 Office 365 Exchange Online>Exchange.ManageAsApp が必要です。
-
Microsoft Entra ID でのアプリ専用認証の場合、通常は証明書を使用してアクセスを要求します。 証明書とその秘密キーを持つすべてのユーザーは、アプリに付与されたアクセス許可を持つアプリを使用できます。
アプリ専用アクセス トークンを要求しながら、Microsoft Entra ID に対するアプリケーションの認証に使用される自己署名 X.509 証明書を作成して構成します。
この手順は、ユーザー アカウントのパスワードの生成に似ています。 証明書も自己署名できます。 PowerShell で証明書を生成する手順については、この記事の後半の セクション を参照してください。
注:
暗号化: 次世代 (CNG) 証明書は、Exchange でのアプリのみの認証ではサポートされていません。 CNG 証明書は、最新バージョンの Windows で既定で作成されます。 CSP キー プロバイダーからの証明書を使用する必要があります。 このセクション では、CSP 証明書を作成するためにサポートされる 2 つの方法について説明します。
Microsoft Entra ロールをアプリケーションに割り当てる
アプリケーションには、適切な RBAC ロールが割り当てられている必要があります。 アプリは Microsoft Entra ID でプロビジョニングされるため、サポートされている組み込みロールのいずれかを使用できます。
手順 1: Microsoft Entra ID でアプリケーションを登録する
注:
問題が発生した場合は、必要なアクセス許可を確認して、アカウントが ID を作成できることを確認します。
https://portal.azure.com/で Microsoft Entra 管理センターを開きます。
ページの上部にある [検索] ボックスに「アプリの登録」と入力し、[サービス] セクションの結果から [アプリの登録] を選択します。
または、[ アプリの登録 ] ページに直接移動するには、 https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBladeを使用します。
[アプリの登録] ページで、[新規登録] を選択します。
[アプリケーションの登録] ページが開いたら、次の設定を構成します:
名前: 分かりやすい名前を入力します。 たとえば、ExO PowerShell CBA です。
サポートされているアカウントの種類: この組織のディレクトリ内のアカウント (<YourOrganizationName> のみ - シングル テナント) が選択されていることを確認します。
注:
Exchange Online の委任されたシナリオでアプリケーションをマルチテナントにするには、任意の組織ディレクトリ (Any Microsoft Entra directory - Multitenant) 内の [アカウント] の値を選択します。
リダイレクト URI (省略可能): この設定は省略可能です。 使用する必要がある場合は、次の設定を構成します。
- [プラットフォーム]: [Web] を選択 します。
- 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 が一覧表示され、次の値が含まれていることを確認します。
型: アプリケーション。
管理者の同意が必要:はい。
状態: 現在の正しくない値は、<Organization> に付与されません。
この値を変更するには、[<Organization に管理者の同意を付与する] を選択し>開いた確認ダイアログを読み取り、[はい] を選択します。
< Organization> に対して[状態] の値が [許可] になりました。
既定の Microsoft Graph>User.Read エントリの場合は、[...>] を選択します。管理者の同意を取り消し、開いた確認ダイアログで [はい] を選択して、状態を既定の空白の値に戻します。
(ブラウザ タブではなく) 現在の [API アクセス許可] ページを閉じて、[アプリ登録] ページに戻ります。 今後の手順では、[ アプリの登録 ] ページを使用します。
API アクセス許可を割り当てるためにアプリ マニフェストを変更する
注:
このセクションの手順では、アプリに対する既存の既定のアクセス許可 (Microsoft Graph で委任された User.Read アクセス許可) に、Office 365 Exchange Online で必要なアプリケーション Exchange.ManageAsApp アクセス許可を追加します。
アプリの [概要] ページで、[管理] セクションから [マニフェスト] を選択します。
[アプリ マニフェスト ] ページで、
requiredResourceAccess
エントリ (42 行目または約 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 が一覧表示され、次の値が含まれていることを確認します。
型: アプリケーション。
管理者の同意が必要:はい。
状態: 現在の正しくない値は、Office 365 Exchange Online>Exchange.ManageAsApp エントリの<Organization>には付与されません。
[<Organization>の管理者の同意を付与する] を選択し、開いた確認ダイアログを読み取り、[はい] を選択して、[状態] の値を変更します。
< Organization> に対して[状態] の値が [許可] になりました。
既定の Microsoft Graph>User.Read エントリの場合は、[...>] を選択します。管理者の同意を取り消し、開いた確認ダイアログで [はい] を選択して、状態を既定の空白の値に戻します。
(ブラウザ タブではなく) 現在の [API アクセス許可] ページを閉じて、[アプリ登録] ページに戻ります。 今後の手順では、[ アプリの登録 ] ページを使用します。
手順 3: 自己署名証明書を生成する
次のいずれかの方法で、自己署名 x.509 証明書を作成します:
(推奨) 昇格した (管理者として実行する) Windows PowerShell セッションで New-SelfSignedCertificate、Export-Certificate、および Export-PfxCertificate コマンドレットを使用して、自己署名証明書を要求し、それを
.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 script スクリプトを使用して、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を使用し、[所有されているアプリケーション] タブが選択されていることを確認してから、アプリケーションを選択します。
開いたアプリケーション ページで、[管理] セクションから [証明書 & シークレット] を選択します。
[ 証明書 & シークレット ] ページで、[ 証明書のアップロード] を選択します。
開いたダイアログで、手順 3 で作成した自己署名証明書 (
.cer
ファイル) を参照します。完了したら、[追加] を選択します。
これで、証明書が [証明書] セクションに表示されます。
現在の [証明書とシークレット] ページを閉じてから、[アプリの登録] ページを閉じてメイン https://portal.azure.com/ ページに戻ります。 次の手順で使用します。
手順 4b: Exchange Online の委任されたシナリオのみ: マルチテナント アプリの管理者の同意を付与する
手順 1 で Exchange Online 委任シナリオ用のアプリケーション マルチテナントを作成した場合は、各テナント組織で Exchange Online でコマンドレットを実行できるように、Exchange.ManageAsApp アクセス許可に管理者の同意を付与する必要があります。 これを行うには、顧客テナントごとに管理者の同意 URL を生成します。 マルチテナント アプリケーションを使用してテナント組織の Exchange Online に接続する前に、顧客テナントの管理者は次の URL を開く必要があります。
https://login.microsoftonline.com/<tenant-id>/adminconsent?client_id=<client-id>&scope=https://outlook.office365.com/.default
-
<tenant-id>
は、顧客のテナント ID です。 -
<client-id>
はマルチテナント アプリケーションの ID です。 - 既定のスコープは、アプリケーションのアクセス許可を付与するために使用されます。
URL 構文の詳細については、「 ディレクトリ管理者にアクセス許可を要求する」を参照してください。
手順 5: Microsoft Entra ロールをアプリケーションに割り当てる
次の 2 つの方法があります。
- Microsoft Entra ロールをアプリケーションに割り当てる
- サービス プリンシパルを使用してカスタム ロール グループをアプリケーションに割り当てる: このメソッドは、 REST API モードで Exchange Online PowerShell またはセキュリティ & コンプライアンス PowerShell に接続する場合にのみサポートされます。 セキュリティ & コンプライアンス PowerShell では、v3.2.0 以降の REST API モードがサポートされています。
注:
両方の方法を組み合わせてアクセス許可を割り当てることもできます。 たとえば、"Exchange 受信者管理者" ロールに Microsoft Entra ロールを使用し、カスタム RBAC ロールを割り当ててアクセス許可を拡張することもできます。
Exchange Online 委任シナリオのマルチテナント アプリケーションの場合は、各顧客テナントにアクセス許可を割り当てる必要があります。
Microsoft Entra ロールをアプリケーションに割り当てる
サポートされている Microsoft Entra ロールについては、次の表を参照してください。
役割 | Exchange Online PowerShell |
セキュリティとコンプライアンス PowerShell |
---|---|---|
コンプライアンス管理者 | ✔ | ✔ |
Exchange 管理者¹ | ✔ | |
"Exchange Recipient Administrator/Exchange 受信者管理者" | ✔ | |
全体管理者¹ ² | ✔ | ✔ |
グローバル リーダー | ✔ | ✔ |
ヘルプデスク管理者 | ✔ | |
セキュリティ管理者¹ | ✔ | ✔ |
セキュリティ閲覧者 | ✔ | ✔ |
¹ 全体管理者ロールと Exchange 管理者ロールは、Exchange Online PowerShell のタスクに必要なアクセス許可を提供します。 例:
- 受信者の管理。
- セキュリティと保護機能。 たとえば、スパム対策、マルウェア対策、フィッシング詐欺対策、関連するレポートなどです。
セキュリティ管理者の役割には、同じタスクに必要なアクセス許可がありません。
² Microsoft では、アクセス許可が最も少ないロールを使用することをお勧めします。 アクセス許可の低いアカウントを使用すると、組織のセキュリティが向上します。 グローバル管理者は高い特権を持つロールであり、既存のロールを使用できない場合の緊急シナリオに限定する必要があります。
Microsoft Entra ID でのロールの割り当てに関する一般的な手順については、「 Microsoft Entra ロールをユーザーに割り当てる」を参照してください。
注:
次の手順は、Exchange Online PowerShell と セキュリティ/コンプライアンス PowerShell では若干異なります。 両方の環境の手順を示します。 両方の環境の役割を構成するには、このセクションの手順を繰り返します。
https://portal.azure.com/の Microsoft Entra 管理センターで、ページ上部の [検索] ボックスにロールと管理者の入力を開始し、[サービス] セクションの結果から [Microsoft Entra ロールと管理者] を選択します。
または、 Microsoft Entra ロールと管理者 ページに直接移動するには、 https://portal.azure.com/#view/Microsoft_AAD_IAM/AllRolesBladeを使用します。
開いた [役割と管理者] ページで、 (チェックボックスではなく) 結果の役割の名前をクリックして、サポートされている役割の 1 つを見つけて選択します。
Exchange Online PowerShell: たとえば、 Exchange 管理者 ロールを見つけて選択します。
セキュリティ & コンプライアンス PowerShell: たとえば、 コンプライアンス管理者 ロールを見つけて選択します。
開いた [ 割り当て] ページで、[ 割り当ての追加] を選択します。
Exchange Online PowerShell:
セキュリティ/コンプライアンス PowerShell:
開いた [割り当ての追加] フライアウトで、手順 1 で作成したアプリを見つけて選択します。
[ 割り当ての追加] ポップアップが完了したら、[追加] を選択 します。
[ 割り当て] ページに戻り、ロールがアプリに割り当てられていることを確認します。
Exchange Online PowerShell:
セキュリティ/コンプライアンス PowerShell:
サービス プリンシパルを使用してカスタム ロール グループをアプリケーションに割り当てる
注:
新しいサービス プリンシパルを作成する手順を完了する 前 に、Exchange Online PowerShell または Security & Compliance PowerShell に接続する必要があります。 PowerShell に接続せずに新しいサービス プリンシパルを作成することはできません (新しいサービス プリンシパルを作成するには、Azure アプリ ID とオブジェクト ID が必要です)。
このメソッドは、 REST API モードで Exchange Online PowerShell またはセキュリティ & コンプライアンス PowerShell に接続する場合にのみサポートされます。 セキュリティ & コンプライアンス PowerShell では、v3.2.0 以降の REST API モードがサポートされています。
カスタム ロール グループの作成の詳細については、「 Exchange Online で役割グループを作成 する」および 「Microsoft Defender ポータルで電子メール & コラボレーション役割グループを作成する」を参照してください。 アプリケーションに割り当てるカスタム ロール グループには、組み込みロールとカスタム ロールの任意の組み合わせを含めることができます。
サービス プリンシパルを使用してカスタム ロール グループをアプリケーションに割り当てるには、次の手順を実行します。
Microsoft Graph PowerShell で、次のコマンドを実行して、手順 1 で登録した Microsoft Entra アプリケーションの詳細を変数に格納します。
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」を参照してください。