編集

Share via

セキュリティ強化されたハイブリッド メッセージング インフラストラクチャ - デスクトップ クライアント アクセス

Microsoft Entra ID
Microsoft 365
Office 365

この記事では、Microsoft Exchange にアクセスする Outlook デスクトップ クライアントに対する多要素認証を実装する方法について説明します。 ユーザー メールボックスを持つ Microsoft Exchange には、4 つの異なる可能性に対応する 4 つのアーキテクチャがあります。

Note

図では、ローカルの Active Directory、Microsoft Entra Connect、Microsoft Entra ID、AD FS、および Web アプリケーション プロキシの各コンポーネント間の基本的な対話を黒い破線で示しています。 こうした対話の詳細については、「ハイブリッド ID で必要なポートとプロトコル」を参照してください。

アーキテクチャ (Exchange Online)

Diagram that shows an architecture for enhanced security in an Outlook client access scenario. The user's mailbox is in Exchange Online.

"この記事のすべての図の Visio ファイルをダウンロードします。"

このシナリオでは、ユーザーは先進認証をサポートするバージョンの Outlook クライアントを使用する必要があります。 詳細については、「Office 2013、Office 2016、および Office 2019 のクライアント アプリの先進認証のしくみ」を参照してください。 このアーキテクチャは、Outlook for Windows と Outlook for Mac の両方に対応しています。

ワークフロー (Exchange Online)

  1. ユーザーが Outlook 経由で Exchange Online にアクセスしようとします。
  2. Exchange Online が、メールボックスにアクセスするためのアクセス トークンを取得するのに必要な Microsoft Entra エンドポイントの URL を提供します。
  3. Outlook はその URL を使用して Microsoft Entra ID に接続します。
  4. ドメインがフェデレーションされるとすぐに、Microsoft Entra ID がその要求をオンプレミスの AD FS にリダイレクトします。
  5. ユーザーが AD FS サインイン ページで資格情報を入力します。
  6. AD FS は、セッションを Microsoft Entra ID にリダイレクトします。
  7. Microsoft Entra ID は、モバイル アプリとデスクトップ クライアントのための多要素認証要件を持つ Azure 条件付きアクセス ポリシーを適用します。 そのポリシーの設定については、この記事のデプロイのセクションを参照してください。
  8. 条件付きアクセス ポリシーにより、Microsoft Entra 多要素認証が呼び出されます。 ユーザーは多要素認証を完了するように要求されます。
  9. ユーザーが多要素認証を完了します。
  10. Microsoft Entra ID はアクセス トークンと更新トークンを発行し、クライアントに返します。
  11. クライアントが、アクセス トークンを使用して Exchange Online に接続し、コンテンツを取得します。

構成 (Exchange Online)

レガシ認証 (図の赤い破線) を使用した Exchange Online へのアクセス試行をブロックするには、Outlook サービスが使用するプロトコルに対してレガシ認証を無効にする 認証ポリシー を作成する必要があります。 無効にする必要がある具体的なプロトコルは、自動検出、MAPI、オフライン アドレス帳、および EWS です。 対応する構成は次のとおりです。

AllowBasicAuthAutodiscover : False

AllowBasicAuthMapi : False

AllowBasicAuthOfflineAddressBook : False

AllowBasicAuthWebServices : False

AllowBasicAuthRpc : False

リモート プロシージャ コール (RPC) プロトコルは Office 365 でサポートされなくなったため、最後のパラメーターはクライアントに影響しません。

この認証ポリシーを作成するためのコマンドの例を次に示します。

New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false

Note

既定では、このポリシーを作成すると、他のすべてのプロトコル (IMAP、POP、ActiveSync など) のレガシ認証も無効になります。 この動作を変更するには、次のような PowerShell コマンドを使用することにより、プロトコルを有効にできます。

Set-AuthenticationPolicy -Identity BlockOutlook -AllowBasicAuthImap:$true

認証ポリシーを作成した後、Set-User user01 -AuthenticationPolicy <name_of_policy> コマンドを使用することにより、そのポリシーをまずユーザーのパイロット グループに割り当てることができます。 テスト後に、ポリシーを展開してすべてのユーザーを含めることができます。 組織レベルでポリシーを適用するには、Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> コマンドを使用します。 この構成には Exchange Online PowerShell を使用する必要があります。

アーキテクチャ (Exchange Online、AD FS)

Diagram that shows an alternative architecture for enhanced security in an Outlook client access scenario.

"この記事のすべての図の Visio ファイルをダウンロードします。"

このシナリオは、多要素認証に別のトリガーを使用する点を除けば、前のシナリオと同じです。 前のシナリオでは、認証にローカル AD FS を使用しました。 次に、成功した認証に関する情報を Microsoft Entra ID にリダイレクトし、条件付きアクセス ポリシーによって多要素認証が適用されました。 このシナリオでは、条件付きアクセスを使用して多要素認証を適用する代わりに、AD FS レベルでアクセス制御ポリシーを作成し、そこで多要素認証を適用します。 アーキテクチャの残りの部分は、前のアーキテクチャと同じです。

Note

このシナリオは、前のシナリオを使用できない場合にのみお勧めします。

このシナリオでは、ユーザーは先進認証をサポートするバージョンの Outlook クライアントを使用する必要があります。 詳細については、「Office 2013、Office 2016、および Office 2019 のクライアント アプリの先進認証のしくみ」を参照してください。 このアーキテクチャは、Outlook for Windows と Outlook for Mac の両方に対応しています。

ワークフロー (Exchange Online、AD FS)

  1. ユーザーが Outlook 経由で Exchange Online にアクセスしようとします。

  2. Exchange Online が、メールボックスにアクセスするためのアクセス トークンを取得するのに必要な Microsoft Entra エンドポイントの URL を提供します。

  3. Outlook はその URL を使用して Microsoft Entra ID に接続します。

  4. ドメインがフェデレーションされている場合、Microsoft Entra ID はオンプレミスの AD FS に要求をリダイレクトします。

  5. ユーザーが AD FS サインイン ページで資格情報を入力します。

  6. AF DS アクセス制御ポリシーに応答して、AD FS が Microsoft Entra 多要素認証を呼び出して認証を完了します。 次に、この種類の AD FS アクセス制御ポリシーの例を示します。

    Screenshot that shows an example of an AD FS access control policy.

    ユーザーは多要素認証を完了するように要求されます。

  7. ユーザーが多要素認証を完了します。

  8. AD FS は、セッションを Microsoft Entra ID にリダイレクトします。

  9. Microsoft Entra ID はアクセス トークンと更新トークンを発行し、クライアントに返します。

  10. クライアントが、アクセス トークンを使用して Exchange Online に接続し、コンテンツを取得します。

構成 (Exchange Online, AD FS)

Note

手順 6 で実装したアクセス制御ポリシーは、証明書利用者信頼レベルで適用されるため、AD FS を通過するすべての Office 365 サービスのすべての認証要求に影響します。 AD FS 認証規則を使用して、追加のフィルター処理を適用できます。 ただし、Microsoft 365 サービスに対して AD FS アクセス制御ポリシーを使用するよりも、前のアーキテクチャで説明した条件付きアクセス ポリシーを使用することをお勧めします。 前のシナリオの方が一般的であり、これを使用することにより柔軟性を向上できます。

レガシ認証 (図の赤い破線) を使用した Exchange Online へのアクセス試行をブロックするには、Outlook サービスが使用するプロトコルに対してレガシ認証を無効にする 認証ポリシー を作成する必要があります。 無効にする必要がある具体的なプロトコルは、自動検出、MAPI、オフライン アドレス帳、および EWS です。 対応する構成は次のとおりです。

AllowBasicAuthAutodiscover : False

AllowBasicAuthMapi : False

AllowBasicAuthOfflineAddressBook : False

AllowBasicAuthWebServices : False

AllowBasicAuthRpc : False

RPC プロトコルは Office 365 でサポートされなくなったため、最後のパラメーターはクライアントに影響しません。

この認証ポリシーを作成するためのコマンドの例を次に示します。

New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false

アーキテクチャ (Exchange On-premises)

Diagram that shows an enhanced security architecture in an on-premises Outlook client access scenario.

"この記事のすべての図の Visio ファイルをダウンロードします。"

このアーキテクチャは、Outlook for Windows と Outlook for Mac の両方に対応しています。

ワークフロー (Exchange On-premises)

  1. Exchange Server にメールボックスを持つユーザーが、Outlook クライアントを起動します。 Outlook クライアントが Exchange Server に接続し、先進認証機能があることを指定します。
  2. Exchange Server は、Microsoft Entra ID からトークンを取得することを要求する応答をクライアントに送信します。
  3. Outlook クライアントは、Exchange Server によって提供される Microsoft Entra URL に接続します。
  4. Azure は、そのユーザーのドメインがフェデレーションされていることを識別し、AD FS に (Web アプリケーション プロキシ経由で) 要求を送信します。
  5. ユーザーが AD FS サインイン ページで資格情報を入力します。
  6. AD FS は、セッションを Microsoft Entra ID にリダイレクトします。
  7. Microsoft Entra ID は、モバイル アプリとデスクトップ クライアントのための多要素認証要件を持つ Azure 条件付きアクセス ポリシーを適用します。 そのポリシーの設定については、この記事のデプロイのセクションを参照してください。
  8. 条件付きアクセス ポリシーにより、Microsoft Entra 多要素認証が呼び出されます。 ユーザーは多要素認証を完了するように要求されます。
  9. ユーザーが多要素認証を完了します。
  10. Microsoft Entra ID はアクセス トークンと更新トークンを発行し、クライアントに返します。
  11. ユーザーが Exchange Server にアクセス トークンを提示し、Exchange がメールボックスへのアクセスを認可します。

構成 (Exchange On-premises)

レガシ認証 (図の赤い破線) を使用した Exchange オンプレミスへのアクセス試行をブロックするには、Outlook サービスが使用するプロトコルに対してレガシ認証を無効にする認証ポリシーを作成する必要があります。 無効にする必要がある具体的なプロトコルは、自動検出、MAPI、オフライン アドレス帳、EWS、および RPC です。 対応する構成は次のとおりです。

BlockLegacyAuthAutodiscover : True

BlockLegacyAuthMapi : True

BlockLegacyAuthOfflineAddressBook : True

BlockLegacyAuthRpc : True

BlockLegacyAuthWebServices : True

RPC プロトコルは先進認証をサポートしていないため、Microsoft Entra 多要素認証はサポートされません。 Microsoft では、Outlook for Windows クライアントには MAPI プロトコルをお勧めしています。

この認証ポリシーを作成するためのコマンドの例を次に示します。

New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc

認証ポリシーを作成した後、Set-User user01 -AuthenticationPolicy <name_of_policy> コマンドを使用することにより、そのポリシーをまずユーザーのパイロット グループに割り当てることができます。 テスト後に、ポリシーを展開してすべてのユーザーを含めることができます。 組織レベルでポリシーを適用するには、Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> コマンドを使用します。 この構成には Exchange オンプレミス PowerShell を使用する必要があります。

アーキテクチャ (Exchange On-premises、AD FS)

Diagram that shows an alternative enhanced security architecture in an on-premises Outlook client access scenario.

"この記事のすべての図の Visio ファイルをダウンロードします。"

このシナリオは、前のシナリオに似ています。 ただし、このシナリオでは、多要素認証は AD FS によってトリガーされます。 このアーキテクチャは、Outlook for Windows と Outlook for Mac の両方に対応しています。

Note

このシナリオは、前のシナリオを使用できない場合にのみお勧めします。

ワークフロー (Exchange On-premises、AD FS)

  1. ユーザーが Outlook クライアントを起動します。 クライアントが Exchange Server に接続し、先進認証機能があることを指定します。

  2. Exchange Server は、Microsoft Entra ID からトークンを取得することを要求する応答をクライアントに送信します。 Exchange Server は、Microsoft Entra ID への URL をクライアントに提供します。

  3. クライアントは、その URL を使用して Microsoft Entra ID にアクセスします。

  4. このシナリオでは、ドメインはフェデレーションされます。 Microsoft Entra ID は、Web アプリケーション プロキシ経由でクライアントを AD FS にリダイレクトします。

  5. ユーザーが AD FS サインイン ページで資格情報を入力します。

  6. AD FS によって多要素認証がトリガーされます。 次に、この種類の AD FS アクセス制御ポリシーの例を示します。

    Screenshot that shows an AD FS access control policy.

    ユーザーは多要素認証を完了するように要求されます。

  7. ユーザーが多要素認証を完了します。

  8. AD FS は、セッションを Microsoft Entra ID にリダイレクトします。

  9. Microsoft Entra ID は、アクセス トークンと更新トークンをユーザーに発行します。

  10. クライアントが Exchange オンプレミス サーバーにそのアクセス トークンを提示します。 Exchange がユーザーのメールボックスへのアクセスを認可します。

構成 (Exchange On-premises、AD FS)

Note

手順 6 で実装したアクセス制御ポリシーは、証明書利用者信頼レベルで適用されるため、AD FS を通過するすべての Office 365 サービスのすべての認証要求に影響します。 AD FS 認証規則を使用して、追加のフィルター処理を適用できます。 ただし、Microsoft 365 サービスに対して AD FS アクセス制御ポリシーを使用するよりも、前のアーキテクチャで説明した条件付きアクセス ポリシーを使用することをお勧めします。 前のシナリオの方が一般的であり、これを使用することにより柔軟性を向上できます。

レガシ認証 (図の赤い破線) を使用した Exchange オンプレミスへのアクセス試行をブロックするには、Outlook サービスが使用するプロトコルに対してレガシ認証を無効にする認証ポリシーを作成する必要があります。 無効にする必要がある具体的なプロトコルは、自動検出、MAPI、オフライン アドレス帳、EWS、および RPC です。 対応する構成は次のとおりです。

BlockLegacyAuthAutodiscover : True

BlockLegacyAuthMapi : True

BlockLegacyAuthOfflineAddressBook : True

BlockLegacyAuthRpc : True

BlockLegacyAuthWebServices : True

RPC プロトコルは先進認証をサポートしていないため、Microsoft Entra 多要素認証はサポートされません。 Microsoft では、Outlook for Windows クライアントには MAPI プロトコルをお勧めしています。

この認証ポリシーを作成するためのコマンドの例を次に示します。

New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc

認証ポリシーを作成した後、Set-User user01 -AuthenticationPolicy <name_of_policy> コマンドを使用することにより、そのポリシーをまずユーザーのパイロット グループに割り当てることができます。 テスト後に、ポリシーを展開してすべてのユーザーを含めることができます。 組織レベルでポリシーを適用するには、Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> コマンドを使用します。 この構成には Exchange オンプレミス PowerShell を使用する必要があります。

コンポーネント

  • Microsoft Entra ID。 Microsoft Entra ID は、Microsoft のクラウドベースの ID およびアクセス管理サービスです。 これは、本質的に EvoSTS (Microsoft Entra ID で使用されるセキュリティ トークン サービス) に基づく先進認証を提供します。 これは、Exchange Server オンプレミスの認証サーバーとして使用されます。
  • Microsoft Entra 多要素認証。 多要素認証は、サインイン プロセスでユーザーに別の形式の ID (携帯電話に示されるコードや指紋スキャンなど) を求めるプロセスです。
  • Microsoft Entra 条件付きアクセス。 条件付きアクセスは、Microsoft Entra ID が多要素認証などの組織のポリシーを適用するために使う機能です。
  • AD FS。 AD FS を使用すると、セキュリティを向上しながらセキュリティとエンタープライズの境界を越えてデジタル ID とエンタイトルメント権限を共有することで、フェデレーション ID とアクセス管理が使用できるようになります。 これらのアーキテクチャでは、AD FS はフェデレーション ID を使用したユーザーのサインインを円滑にするために使用されます。
  • Web アプリケーション プロキシ。 Web アプリケーション プロキシは、AD FS を使用することで、Web アプリケーションへのアクセスを事前認証します。 さらに、AD FS プロキシとしても機能します。
  • Microsoft Intune。 Intune は、Windows、Android、Mac、iOS、Linux オペレーティング システムの各エンドポイントを管理する、クラウドベースの統合エンドポイント管理です。
  • Exchange Server。 Exchange Server は、ユーザーのオンプレミスのメールボックスを管理します。 これらのアーキテクチャでは、Microsoft Entra ID によってユーザーに発行されたトークンを使うことで、メールボックスへのアクセスを認可します。
  • Active Directory サービス。 Active Directory サービスは、ドメインのメンバーに関する情報 (デバイスとユーザーを含む) を格納します。 これらのアーキテクチャでは、ユーザー アカウントは Active Directory サービスに属していて、Microsoft Entra ID に同期されます。
  • ビジネスのための Outlook。 Outlook は、先進認証をサポートするクライアント アプリケーションです。

シナリオの詳細

エンタープライズ メッセージング インフラストラクチャ (EMI) は、組織の主要なサービスです。 旧式で安全性の低い認証と認可の方法から最新の認証への移行は、リモート ワークが普通になる世界では重要な課題になります。 メッセージング サービスのアクセスに多要素認証の要件を実装することは、その課題に対応する最も効果的な方法の 1 つです。

この記事では、Microsoft Entra 多要素認証を使用することで Outlook デスクトップ クライアント アクセス シナリオのセキュリティを強化するための 4 つのアーキテクチャについて説明します。

これらは、Microsoft Exchange の 4 つの異なる可能性に従った 4 つのアーキテクチャです。

4 つのアーキテクチャはいずれも、Outlook for Windows と Outlook for Mac の両方に対応しています。

その他のハイブリッド メッセージング シナリオで多要素認証を適用する場合の情報については、次の記事を参照してください。

この記事では、その他のプロトコル (IMAP や POP など) については説明しません。 通常、これらのシナリオでは上記プロトコルを使用しません。

一般的な注意事項

  • これらのアーキテクチャでは、フェデレーション Microsoft Entra ID モデルが使用されます。 パスワード ハッシュ同期とパススルー認証モデルについては、ロジックとフローが同じになります。 唯一の違いは、Microsoft Entra ID が認証要求をオンプレミスの Active Directory フェデレーション サービス (AD FS) にリダイレクトしないという事実に関連しています。
  • Exchange On-premises は、最新の更新プログラム とメールボックスの役割を適用した Exchange 2019 を表しています。
  • 実際の環境では、サーバーが 1 台のみではありません。 高可用性を実現するために、負荷分散された Exchange サーバー アレイを使用していることもあります。 ここで説明するシナリオは、その構成に適したものです。

考えられるユース ケース

このアーキテクチャは、次のシナリオに関連しています。

  • EMI セキュリティの強化。
  • ゼロ トラスト セキュリティ戦略の導入。
  • Exchange Online への移行時または共存時のオンプレミス メッセージング サービスに対する標準の高レベル保護の適用。
  • 非公開または高度にセキュリティ保護された組織 (金融分野の組織など) での厳格なセキュリティまたはコンプライアンスの要件の強制的な適用。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

可用性

全体的な可用性は、関係するコンポーネントの可用性に依存します。 可用性の詳細については、次のリソースを参照してください。

オンプレミス ソリューションのコンポーネントの可用性は、実装した設計、ハードウェアの可用性、および内部の操作と保守のルーチンに応じて異なります。 こうしたコンポーネントの一部の可用性の詳細については、次のリソースを参照してください。

ハイブリッド先進認証を使うには、ネットワーク上のすべてのクライアントが Microsoft Entra ID にアクセスできることを確認する必要があります。 また、Office 365 ファイアウォール ポートと IP 範囲の開放を常に維持する必要があります。

Exchange Server のプロトコルとポートの要件については、オンプレミスの Skype for Business および Exchange サーバーでのハイブリッド先進認証の使用の概要を説明した記事の、「Exchange クライアントとプロトコルの要件」のセクションを参照してください。

Office 365 の IP 範囲とポートについては、「Office 365 URL および IP アドレス範囲」を参照してください。

ハイブリッド先進認証とモバイル デバイスの詳細については、「Office 365 IP アドレスと URL Web サービスに含まれない他のエンドポイント」の AutoDetect エンドポイントに関するセクションを参照してください。

回復性

このアーキテクチャに含まれるコンポーネントの回復性の詳細については、次のリソースを参照してください。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

セキュリティとハイブリッド先進認証の詳細については、「詳細情報: ハイブリッド認証のしくみ」を参照してください。

従来の強力な境界保護を使用しているクローズドな組織の場合、Exchange ハイブリッド クラシック構成に関連するセキュリティ上の問題があります。 Exchange ハイブリッド モダン構成は、ハイブリッド先進認証をサポートしていません。

Microsoft Entra ID については、「Microsoft Entra セキュリティ オペレーション ガイド」を参照してください。

AD FS セキュリティを使用するシナリオの詳細については、次の記事を参照してください。

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

実装にかかるコストは、Microsoft Entra ID と Microsoft 365 のライセンスのコストによって異なります。 合計コストには、オンプレミス コンポーネントのソフトウェアとハードウェアのコスト、IT 運用、トレーニングと教育、およびプロジェクト実装のコストも含まれます。

これらのソリューションには、少なくとも Microsoft Entra ID P1 が必要です。 価格の詳細については、Microsoft Entra の価格に関するページを参照してください。

AD FS と Web アプリケーション プロキシの詳細については、「Windows Server 2022 の価格とライセンス体系」を参照してください。

価格の詳細については、次のリソースを参照してください。

パフォーマンス効率

パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

ワークロードのパフォーマンスは、関係するコンポーネントのパフォーマンスとネットワーク パフォーマンスに依存します。 詳細については、「ベースラインとパフォーマンス履歴を使用した Office 365 パフォーマンスのチューニング」を参照してください。

AD FS サービスが含まれるシナリオのパフォーマンスに影響するオンプレミスの要因の詳細については、次のリソースを参照してください。

AD FS スケーラビリティの詳細については、「AD FS サーバーの容量の計画」を参照してください。

Exchange Server オンプレミスのスケーラビリティの詳細については、「Exchange 2019 の優先アーキテクチャ」を参照してください。

このシナリオのデプロイ

手順の概要は次のとおりです。

  1. Exchange ハイブリッド構成を構成し、ハイブリッド先進認証を有効にすることにより、Outlook デスクトップ アクセスを保護します。
  2. Microsoft Entra ID レベルで、すべてのレガシ認証の試行をブロックします。 認証ポリシーを使用して、メッセージング サービス レベルでのレガシ認証の試行をブロックします。

条件付きアクセス ポリシーを設定する

多要素認証を適用する Microsoft Entra 条件付きアクセス ポリシーを、この記事のいくつかのアーキテクチャで説明したように設定します。

  1. [クライアント アプリ] ウィンドウで、[モバイル アプリとデスクトップ クライアント] を選択します。

    Screenshot that shows the Client apps window.

  2. [許可] ウィンドウで、多要素認証の要件を適用します。

    Screenshot that shows the Grant window.

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • Pavel Kondrashov | クラウド ソリューション アーキテクト
  • Ella Parkum | プリンシパル カスタマー ソリューション アーキテクト - エンジニアリング

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ