はじめに
Dirbatoの社内技術横断支援組織Backbeatに所属しているアーキテクトの福岡です。
前回の記事ではActive DirectoryのGPOからブラウザへ設定を配布して、個人Googleアカウントのログインを制限しました。
今回はMicrosoft側でも同じようなことはできないのか！？
会社のPCで業務用のMicrosoft 365は使ってほしいけど個人アカウントの領域や野良テナントは使わせたくない！
※必要な取引先だけは例外（信頼する）にしたい。
というニーズがあるはずです。
今回はこれを Microsoft Entra IDのテナント制限v2とGlobal Secure Access で試してみました。
結果として、検証端末からの個人Microsoftアカウントのサインイン拒否と明示的に許可した別テナントの組織アカウントでのサインイン成功まで確認できました。
途中で個人OneDriveも弾かれたり許可したはずのテナントへ入れなかったりと、実際に触って分かったことがいくつかあります。
設定だけでなく、そのあたりも含めてまとめます！
検証日：2026年9月20日〜21日
公式仕様の確認日：2026年9月21日
本文のドメイン名、アカウント名、端末名は説明用の表記に置き換えています。
この記事は個人検証環境でのPoCです。
自分のテナント以外のサイトをすべて遮断する構成でも既存セッションを一斉に強制ログアウトする構成でもありません。
今回確認したサインイン制御と端末全体で回避経路をなくす設計は分けて扱います。
まずは仕組みから
TRv2とGSAとUTR、何が違うのか
今回使うものを並べると少し名前が多いので整理します。
| 機能 | 今回の役割 |
|---|---|
| テナント制限v2（TRv2） | 外部アカウントによる外部アプリへのアクセスを許可・拒否するポリシー |
| Global Secure Access（GSA） | 対象通信を経由させるMicrosoftのセキュリティサービス |
| Microsoftトラフィックプロファイル | 対応するMicrosoftサービスへの通信をGSAへ転送するための設定 |
| ユニバーサルテナント制限（UTR） | GSA経由の通信にTRv2の適用に必要なシグナルを付ける仕組み |
TRv2がルールでUTRがそのルールをGSA経由で適用させる仕組みと分けると理解しやすいです。公式のUTR構成手順もTRv2ポリシーを先に構成してからUTRを有効化する流れになっています。
今回の構成イメージは次のとおりです。
自テナントのEntra管理センター
└ TRv2ポリシー
├ 既定：外部アカウントを拒否
├ Microsoft Accounts：拒否
└ Partner A：例外として許可
↑ ポリシーを参照して判定
検証端末
└ GSAクライアント
└ Microsoft向けの対象通信を転送
└ GSA / UTRで適用シグナルを付与
└ Microsoft側でサインインを許可・拒否
自前のプロキシを新設してそこで認証通信へヘッダーを追加する方式は使いません。
ただ、通信経路に何も挟まないというわけではなく、対象通信はGSAを経由します。
もう一つのv2と混同しない
途中の画面にはトラフィック転送プロファイルv2に切り替えるというプレビュー機能の案内も出てきますが、これはTRv2とは別のv2です。（私も途中で少し混乱しました...）
今回はその切替を行わずに従来のトラフィック転送画面のまま進めています。
制御するのは何か
TRv2が扱うのは主に外部アカウントで外部アプリを使うケースです。
自社のアカウントで外部組織へB2Bアクセスする制御や外部ゲストが自社リソースへ入る制御とは別になります。
| 設定項目 | 誰が | どこへ | 具体的なシーン |
|---|---|---|---|
| 受信設定（Inbound） | 外部のユーザー | 自社テナントのアプリ | 取引先ユーザーが、自社の Teams や SharePoint などへ B2B ゲストとしてアクセスする場合を制御する |
| 送信設定（Outbound） | 自社のユーザー | 外部テナントのアプリ | 自社ユーザーが、自社アカウントのまま取引先テナントの Teams や SharePoint などへ B2B でアクセスする場合を制御する |
| テナント制限（Tenant Restrictions） | 外部アカウントを使用するユーザー | 外部テナントのアプリ | 自社端末上で、個人 Microsoft アカウントや他社 Entra ID アカウントへ切り替えて、外部の Microsoft サービスへサインインする場合を制御する |
同じ設定画面に並んでいますが今回変更するのは テナントの制限 です。受信アクセスや送信アクセスは変更しません。
この区別はMicrosoftのTRv2ドキュメントにも記載されています。
検証環境
最初はプライベートで使っているゲーミングノートPCで試そうと思ったのですが、認証まわりで何か起きると普通に困るので検証端末を使い、普段のPCは管理用の退避経路として残すことにします。
| 項目 | 今回の構成 |
|---|---|
| 自テナント |
contoso.onmicrosoft.com（説明用） |
| 検証端末 | Windows 11 / x64 / Microsoft Entra ID Join |
| 検証端末名 |
TRV2-TEST-PC（説明用） |
| Windowsサインインユーザ |
admin@contoso.onmicrosoft.com（説明用） |
| GSAクライアント | 2.32.294.0 |
| 適用範囲 | Microsoftトラフィックプロファイルを検証ユーザ1名へ割当て |
| 退避・比較用端末 | GSAクライアントを導入しない普段のPC |
| Partner A | 所有している別のEntraテナント 本文では fabrikam.onmicrosoft.com と表記 |
| 個人アカウント | GmailアドレスをサインインIDにした個人Microsoftアカウント |
| 使用しないもの | GSAのリモートネットワーク、Private Access、Internet Accessの各追加構成、Windows方式のTRv2ポリシー配布 |
ライセンス
今回利用するMicrosoftトラフィックプロファイルとUTRはMicrosoft Entra ID P1 / P2に含まれる機能です。
一般のインターネット通信を制御するEntra Internet AccessやEntra SuiteをこのPoCのために追加購入する構成ではありません。
P1/P2がテナントに1本あれば何人でも使えるという意味ではありません。
GSAは原則ユーザ単位のライセンスなので対象ユーザ分を確認のうえライセンス購入してください。
詳細はGlobal Secure Accessのライセンス概要を参照してください。
管理者と検証ユーザー
今回は自分の検証環境なので管理者アカウントをWindowsサインインとプロファイル割当ての対象にも使用しました。
あくまでも検証上の構成であって普段使いのユーザにグローバル管理者を付ける必要があるという意味ではありません。
設定作業ではTRv2側にセキュリティ管理者、GSA側にGlobal Secure Access管理者、ユーザ割当てにアプリケーション管理者などのロールが必要になります。
UTRの有効化にはGSA管理者とセキュリティ管理者を使用します。
各操作の権限は末尾の公式手順で確認してください。
検証端末を分けてもクラウド側のポリシーはテナントの設定です。
すでにGSAや別方式のTRv2を利用している環境では他の利用者への影響範囲を確認してから変更してください。
1. 現行設定と端末の状態を確認しておく
Graphで変更前の状態を退避
先に戻せる状態を作っておきます。
Microsoft Graph Explorerで自テナントへサインインし、以下をGETします。
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/default
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners
今回は読み取りのためGraph Explorerには Policy.Read.All を同意します。
取得できたらレスポンス全文をJSONで保存します。
EV-00_default.json
EV-00_partners.json
isServiceDefault既定の tenantRestrictions既存パートナーの一覧と個別設定を残します。
@odata.nextLink が返る場合は続きも取得しておきます。
今回の既定構成は次の状態でした。（以下は取得結果の一部だけを抜粋しています）
{
"isServiceDefault": true,
"tenantRestrictions": {
"devices": null,
"usersAndGroups": {
"accessType": "blocked",
"targets": [
{
"target": "AllUsers",
"targetType": "user"
}
]
},
"applications": {
"accessType": "blocked",
"targets": [
{
"target": "AllApplications",
"targetType": "application"
}
]
}
}
}
すでに全ユーザ・全アプリケーションの拒否になっていました。
ただ、拒否ポリシーがあることと検証端末の通信にそのポリシーが適用されていることは別です。後ほどGSAとUTRを構成します。
既存のパートナー構成は2件ありどちらも tenantRestrictions は null でした。
今回追加するMSAとPartner Aは、変更前の一覧にはありませんでした。
Windowsの参加状態とサインインユーザ
検証端末で実行します。
dsregcmd /status
whoami /upn
hostname
今回確認できた主な値は次のとおりです。
AzureAdJoined : YES
DomainJoined : NO
DeviceAuthStatus : SUCCESS
AzureAdPrt : YES
Microsoft Entra ID Join済みでデバイス認証とPRTの状態も確認できました。
ここで重要なのがEntra ID Joinに使ったアカウントだけではなく、現在Windowsへサインインしているユーザを確認することです。
プロファイルはデバイスにサインインしているEntra IDのユーザを基準に取得されます。
ブラウザで別のアカウントへ切り替えたかどうかとは別の話。ユーザー割当の公式説明
DNSと既存の通信設定も確認する
今回はDNSサーバの設定、DoHの登録状態、稼働中のネットワークアダプタも確認しました。
Get-DnsClientServerAddress |
Where-Object { $_.ServerAddresses.Count -gt 0 } |
Select-Object InterfaceAlias, AddressFamily, ServerAddresses
Get-DnsClientDohServerAddress |
Select-Object ServerAddress, AutoUpgrade, AllowFallbackToUdp, DohTemplate
Get-NetAdapter |
Where-Object { $_.Status -eq 'Up' } |
Select-Object Name, InterfaceDescription, Status
これだけでブラウザ独自のDoHや、すべてのVPN・プロキシの影響まで否定できるわけではありません。
今回も最終的にはGSAクライアントのHealth checkでOSとEdgeのSecure DNS、プロキシ、トンネリングを確認しました。
2. TRv2の既定設定とMSA向け設定を確認する
既定は外部アカウントを拒否
自テナントのEntra管理センターで次の場所を開きます。
Entra ID
→ External Identities
→ テナント間アクセス設定
→ 既定の設定
→ テナントの制限
今回のポータルでは、日本語表記がテナント間アクセス設定になっていましたがドキュメントではクロステナントアクセス設定とも表記されています。
※MSは表記揺れというかシステムアップデートに際してのドキュメント更新が間に合っていないのはよくあること...
既定のテナント制限は以下の状態です。
| タブ | アクセス状態 | 適用対象 |
|---|---|---|
| 外部のユーザとグループ | アクセスのブロック | 外部のすべてのユーザとグループ |
| 外部アプリケーション | アクセスのブロック | すべての外部アプリケーション |
今回はGraphの取得結果と一致していたので既定値は変更していません。
画面に表示される自テナントのテナントIDとポリシーIDも控えておきます。
Microsoft Accountsを明示的にブロック
続いて組織の設定からMicrosoft Accountsを追加します。
検索に使うIDは次の固定値です。
9188040d-6c67-4c5b-b112-36a304b66dad
これは自分の個人アカウントのオブジェクトIDではなく、TRv2で個人Microsoftアカウントを扱うためのMicrosoft AccountsのテナントIDです。
追加したらMicrosoft Accountsの行にあるテナントの制限 を開きます。
受信アクセスや送信アクセスではありません。
設定のカスタマイズを選択して、次の内容を保存します。
| タブ | アクセス状態 | 適用対象 |
|---|---|---|
| 外部のユーザーとグループ | アクセスのブロック | すべてのMicrosoft Accountsユーザーとグループ |
| 外部アプリケーション | アクセスのブロック | すべての外部アプリケーション |
MSAはユーザ単位のテナント制限をサポートしないため、今回は個別ユーザを選択しません。
許可アプリを限定する設計はできますが、今回はMSA全体のブロックを構成しました。
この時点では、MSA向けのポリシーを保存したところまでです。
今回の検証端末へGSA経由で適用する準備は、ここから進めます。
3. GSAを有効化して検証ユーザーを割り当てる
初回はテナントのアクティブ化から
最初はようこそ画面が出現する場合は、テナントでGSAをまだアクティブ化できていないためアクティブ化をしてください。
アクティブ化が完了すると、左メニューにダッシュボード、接続、監視、設定などが表示されます。
Microsoftトラフィックプロファイルを有効化
次の画面を開きます。
グローバル セキュア アクセス
→ 接続
→ トラフィック転送
今回は Microsoftトラフィックプロファイルだけ を有効にします。
Private AccessとInternet Accessには追加ライセンスがない旨の表示がありましたがこのPoCでは使用しません。
（先ほど触れたトラフィック転送プロファイルv2への切替も行っていません）
有効化するとユーザとグループを割り当ててくださいという案内が表示されます。
トグルをONにして終わりではなく対象ユーザの割当てまで進めます。
検証ユーザー1名だけを割り当てる
Microsoftトラフィックプロファイルのユーザおよびグループの割り当てから、検証ユーザを選択します。
今回の説明用アカウントでは admin@contoso.onmicrosoft.com です。
ユーザ選択画面で選択したあと元の画面で 割り当て まで実行します。
※この画面で割り当てるのはGSAで通信を扱う自テナント側のユーザです。
ブラウザでログインを試す個人MSAやPartner側のユーザをここに追加するわけではありませんのでご注意ください。
Windowsへサインインするユーザ
admin@contoso.onmicrosoft.com
↓ このユーザへプロファイルを割当て
GSAクライアントが対象通信を転送
↓
ブラウザでは個人MSAやPartner側アカウントのサインインを試験
ポリシーグループも確認
検証端末でGSAクライアントをインストールしている間にMicrosoftトラフィックポリシーも確認しておきます。
開いてみると今回の画面には次の4グループがありました。
Exchange Online
Skype for Business Online and Microsoft Teams
SharePoint Online and OneDrive for Business
Microsoft 365 Common and Office Online
今回はすべて有効のままにしておきます。（ここでは変更していません）
Microsoft Entra IDという5個目のグループを探し続けるのではなく、この後クライアント側でEntraのルールが取得されているか確認しました。
参考までですが、プロファイルの有効化→割当て→クライアントでの確認はMicrosoftのチュートリアルにもまとまっています。
4. 検証端末へGSAクライアントをインストールする
Entra管理センターの以下の画面からWindows用クライアントをダウンロードできます。
グローバル セキュア アクセス
→ 接続
→ クライアントのダウンロード
今回導入したのはx64版でインストール後のバージョン表示は 2.32.294.0 でした。
Windowsへ検証用のEntraアカウントでサインインしていることを確認してからインストールします。
検証端末だけにGSAクライアントを導入します。
（普段のPCには導入せず別のネットワーク経路でGSAへ転送する設定も行っていません）
Advanced diagnosticsで実際の取得状態を見る
インストール後、システムトレイのGSAクライアントから Advanced diagnostics を開きます。
Overviewでは、ユーザ、Device ID、Tenant ID、プロファイル情報、クライアントバージョンを確認しました。
対象端末と対象ユーザが合っているかここでも確認ができます。
続いてForwarding profileを開くと、次のルールが表示されました。
Entra rules
Microsoft 365 rules
ポータルで設定しただけでなく、クライアントがプロファイルを取得しているところまで確認できました。
公式チュートリアルではクライアントがトラフィック転送プロファイルの更新を約5分ごとに確認すると説明されています。
見えない場合は、対象ユーザ、プロファイルの割当、接続状態、最終確認時刻を確認します。
5. Health checkで引っ掛かった2点を直す
ルールは取得できたのですが、Health checkには赤い項目が残っていました。
今回引っ掛かったのはIPv4の優先設定と、EdgeのQUICです。
IPv4 is not preferred
まず表示されたのがこちらでした。
IPv4 is not preferred
今回の端末ではIPv4優先に使うレジストリ値が未設定でした。
管理者PowerShellで確認します。
$path = 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters'
Get-ItemProperty -Path $path -Name DisabledComponents -ErrorAction SilentlyContinue |
Select-Object DisabledComponents
今回は値が表示されなかったため、次の設定を追加しました。
既存の値がある環境では、先に値と設定意図を確認してから変更してください。
New-ItemProperty -Path $path -Name DisabledComponents -PropertyType DWord -Value 0x20 -Force
結果は次のとおりです。
DisabledComponents : 32
10進数の32は16進数の 0x20 です。
IPv6そのものを無効化するのではなくIPv4を優先させる設定です。
MicrosoftのHealth check手順ではこのレジストリ変更後にWindowsの再起動が必要とされています。
Health checkの表示が先に変わってもOSへの反映がすべて完了したとは扱わず再起動を含めて確認してください。
QUIC enabled in Edge
次に残ったのがこちらです。
QUIC enabled in Edge
今回のPoCでは、検証端末のEdgeで以下を開きました。
edge://flags/#enable-quic
Experimental QUIC protocol を Disabled に変更しEdgeを再起動します。
MS Edge再起動後
これは今回のクライアントバージョンで表示されたHealth checkへの対処です。
GSAの全機能がQUIC非対応という意味ではありません。
現行の公式説明ではMicrosoft 365ワークロードなどのQUIC対応とInternet Accessの制約が分けられています。
実運用では利用プロファイルとクライアントバージョンに合わせて判断します。
IPv4とQUICの具体的な設定は、GSAクライアントのHealth check手順を参照してください。
全チェック成功まで確認
設定後にHealth checkを更新すると次の表示になりました。
All checks are successful
OSとEdgeのSecure DNS、プロキシ設定、Entra認証とMicrosoft 365のトンネリング確認も成功しています。
ようやくクライアント側の準備が揃いました。
ただ、ここで成功しているのはクライアントの各診断項目です。
未承認アカウントが実際に拒否されるかは、次のUTR有効化後に試します。
6. ユニバーサルテナント制限をONにする
ここが最後の適用スイッチです。
グローバル セキュア アクセス
→ 設定
→ セッション管理
→ ユニバーサル テナントの制限
今回の画面では次の項目をONにしました。
Microsoft Entra ID と Microsoft Graph 用にテナント制限を有効にする
ONにするとデプロイ開始の通知が出るので監視のデプロイログで状態を確認できます。
今回はデプロイ成功になってから試験へ進めています。
（成功）
7. 実際にサインインを試す
ここからはGSAを導入した検証端末で確認していきます。
新規認証の確認ではサインアウト後に再試行し、すでに開いていたセッションの挙動とは分けて見ました。
再現する際は、既存のInPrivateウィンドウをすべて閉じてから新しく開くなどブラウザセッションも分離しておくと整理しやすいかもしれません。
※InPrivateで開いたことだけをもってすべての認証キャッシュやOSのSSOまで消えたとは判断しません。
自テナントの組織アカウントは利用できる
まず、自テナントの組織アカウントでOneDriveが利用できるかを確認します。
（ブロックする側だけでなく必要なアカウントも使えることを確認）
Gmailアドレスの個人Microsoftアカウントは拒否されること
次に、別のAzureテナントへアクセス権を持つ個人アカウントで試しました。
サインインIDはGmailアドレスですがここで使っているのはGoogle認証ではなく、GmailアドレスをIDにした個人Microsoftアカウント（MSA） です。
Azure Portalからサインアウトして再サインインすると、次の表示で拒否されました。
アクセスがブロックされました
AADSTS5000211
詳細にはデバイスまたはネットワークの管理者が付加したテナント制限ポリシーによってアクセスが許可されない旨が表示されています。
なお、UTRを有効にする前から開いていたAzure Portalのセッションは、即座には追い出されませんでした。
※サインアウト→サインインでは拒否（正常）されます。
今回確認できたのはこの差です。既存トークンやセッションの影響は考えられますが、保持時間や失効のタイミングを測定したわけではありません。
UTRをONにすれば既存セッションがすべて即時終了するとは思わないほうが良さそうです。
個人OneDriveもサインイン時に拒否された
同じ個人アカウントでOneDriveへ入ろうとしたところ、こちらも拒否されました。
ここからそこへは行けません
エラーコード: 80045C4D
画面にはコンシューマーアカウントへのサインインがテナント間アクセスポリシーにより制限されている旨が表示されています。
ここは少し補足が必要です。
MicrosoftのTRv2ドキュメントには、onedrive.live.com 経由のConsumer OneDriveに非対応経路があると記載されています。
今回の結果は、その説明を覆して全経路を保護できたという話ではありません。
個人OneDriveへ到達する途中のMSAサインインが、この検証経路では拒否されたという結果です。
| 分けて考えるもの | 今回の扱い |
|---|---|
| 個人OneDriveを使うための新規MSA認証 | 拒否されたことを確認 |
| 認証済みセッション、匿名リンク、同期クライアントなどからの利用 | 今回は網羅的に検証していない |
| Consumer OneDriveの全アクセス経路を遮断できるか | この結果だけでは保証しない |
公式の対象外範囲はTRv2とOneDriveの説明を確認してください。
個人OneDriveを一切使わせない要件なら対象外経路のWeb制御なども含めて別途設計が必要です。
GSAを入れていない普段のPCでは利用できた
比較のためにGSAを入れていない普段のPCでも同じ個人OneDriveへサインインしました。
こちらは利用できました。
| 端末 | 個人MSAでのOneDriveサインイン |
|---|---|
| GSA / UTRを適用した検証端末 | 拒否 |
| GSAを導入していない普段のPC | 成功 |
今回用意した適用経路と非適用経路で結果に差が出ている通り、この個人アカウント自体が利用不可になったわけではありません。
8. 必要なPartnerテナントだけ許可する
個人アカウントを拒否できたので次は、承認した外部テナントを例外として許可します。
新しいテナントを契約するのではなく、すでに持っている別テナントをPartner Aとして使いました。
先ほどまで拒否していたテナントを信頼するテナントに登録します。
Partner Aを追加する
自テナント側で、次の場所へ戻ります。
External Identities
→ テナント間アクセス設定
→ 組織の設定
→ 組織の追加
今回はPartner Aのドメイン名では検索結果が出なかったため、相手側で確認した テナントID を入力して追加しました。
ドメイン検索が通らなかった原因までは調べていません。
一覧には相手の表示名である既定のディレクトリが追加されました。
これを自テナントの既定ポリシーと見間違えそうになりましたが、単に相手テナントの名前がそうなっているだけです。
なお、個別のテナント制限画面の上部に表示されるテナントIDとポリシーIDは、ポリシーを管理する自テナント側の情報です。
相手テナントの確認は、追加時の検索結果や対象組織の情報で行います。
ユーザーとアプリの両方を許可する
Partner Aの行から テナントの制限 を開き、設定のカスタマイズを選択します。
今回のPoCでは次の内容で保存しました。
| タブ | アクセス状態 | 適用対象 |
|---|---|---|
| 外部のユーザーとグループ | アクセスを許可 | すべてのPartner Aユーザーとグループ |
| 外部アプリケーション | アクセスを許可 | すべての外部アプリケーション |
最初はユーザー側だけを許可してしまい、アプリ側が全ブロックのままで保存時に競合エラーが出ました。
今回のような全許可・全拒否の設定では、両方のタブを確認する必要があります。
今回はテナント単位の例外を確認するため全ユーザー・全アプリを許可しています。
実運用では、必要なユーザーやアプリへ絞る設計を検討します。
ここでの許可はTRv2の例外設定です。
相手テナントのMFAやデバイスのクレームを信頼するInbound Trustの設定ではありません。
また、TRv2で許可してもAzure RBACやアプリ側のアクセス権が新しく付与されるわけではありません。
許可したのにGmailアドレスでは入れない？
ここが今回いちばん勉強になったところです。
Partner Aを許可したので、先ほどのGmailアドレスのアカウントでも入れるだろうと思って再試行しました。
ところが、Azure Portalへのサインインは引き続き拒否されます。
最初はポリシーの反映待ちか、GSAクライアントのリフレッシュが必要なのかと思いました。
ただ、エラー画面のURLを見ると次の経路になっています。
login.microsoftonline.com/common/federation/oauth2msa
今回使っていたのは、そのテナントで新規作成した組織アカウントではなく、GmailアドレスをサインインIDにしたMSAでした。
設定上は次の2つが別々に存在しています。
Partner AのEntraテナント → 許可
Microsoft Accountsのテナント → 拒否
そのテナントへアクセス権があることと、そのアカウントがどこで認証されるかは別です。
Azureを契約したアカウントだから、認証主体もそのEntraテナントの内部ユーザーだろう、と考えたのが混乱のもとでした。
ただし、Gmailアドレスならすべて同じ認証方式になるという話でもありません。
今回は認証URLと拒否画面、その後の組織アカウントとの比較から切り分けています。
Microsoftの公式仕様には、MSAをブロックしてもコンシューマーアカウントのB2B認証や一部のパススルー認証はブロックされないという注記もあります。
そのため、ここはMSAが関係するすべてのB2Bアクセスの一般則ではなく、今回のAzure Portalのログイン経路で確認した結果です。
Partner A側で組織アカウントを作って再試験
そこでPartner A側に、クラウド専用の組織アカウントを新しく作成しました。
説明用の表記では次のようなUPNです。
testuser@fabrikam.onmicrosoft.com
PoCではテナント単位で許可します。
本番で同じ設定をするとセキュリティレビューの予定表まで一緒に増えるので、ユーザとアプリを必要最小限に絞りましょう。
（ユーザオブジェクトを指定するべきですがメンドクサイのでとりまテナントごと許可）
外部アカウントを招待するのではなく、Partner A自身で認証する内部ユーザを用意します。
#EXT# を含む既存の外部ユーザーをそのまま使う試験ではありません。
また、UserTypeをMemberに変えただけで認証元まで変わるわけではありません。Microsoftの外部・内部ユーザーの説明でも、UserTypeと認証元は分けて扱われています。
今回はその切り分けを簡単にするため組織ユーザを新規作成しました。
同じ検証端末から、この組織UPNでAzure Portalへサインインすると……
今度は入れました！
今回の画面ではサインイン後のホームが表示されており、個人MSAで試したときのテナント制限エラーにはなっていません。
Microsoft 365 Copilotのアプリ画面も、その組織アカウントで開けました。
Partner Aの例外設定は全ユーザを対象にしていたので、新しく作ったユーザを自テナント側の例外へ個別追加する操作は行っていません。
今回確認できたこと
結果をまとめると次のようになりました。
| 対象・操作 | 実機結果 |
|---|---|
| 検証端末で自テナントの組織アカウントからOneDriveを利用 | 利用可能 |
| UTR有効化前から開いていた外部Azure Portalのセッション | 観測した時点では即時終了しなかった |
| 検証端末でGmailアドレスのMSAからAzure Portalへ再サインイン |
AADSTS5000211 で拒否 |
| 検証端末で個人OneDriveへMSAで新規サインイン |
80045C4D で拒否 |
| GSA未導入端末で同じ個人OneDriveを利用 | 利用可能 |
| Partner Aを許可後、同じMSAでAzure Portalへ再サインイン | 今回のログイン経路では引き続き拒否 |
| Partner Aを許可後、同テナントで新規作成した組織アカウントでAzure Portalへサインイン | 成功 |
| 同じPartner Aの組織アカウントでMicrosoft 365 Copilotのアプリ画面を表示 | 成功 |
今回、許可前の拒否確認に使ったのはMSAで、Partner許可後の成功確認に使ったのは新しく作った組織アカウントです。
そのため、同一のネイティブEntra IDのユーザを使った許可前後の比較や、別の未許可Entra IDテナントの組織ユーザによる拒否確認まで実施済みとはしていません。
これらとB2Bゲストの各パターン、Graphへの直接アクセス、匿名リンク、トークン持ち込みへのデータプレーン保護は追加試験の範囲なのでエンプラ向け試験では実施してください。
今回は、適用端末で個人MSAを拒否し、承認したPartnerの組織アカウントは利用できる ところまでをPoCの成果としてまとめています。
本番へ持っていく前に考えたいこと
クライアントが動いていることも前提
今回の成功条件にはGSAクライアントが動作し、対象通信がGSAを経由していることが含まれます。
Microsoftトラフィックプロファイルの説明にはサービスへ接続できない場合に直接接続へバイパスする動作も記載されています。
そのため、今回のPoCだけで利用者による停止や迂回まで防いだとは扱いません。
本番ではクライアントを止められる権限、別端末や別経路、業務アプリとの共存まで確認する必要があります。
サインイン制御とデータプレーン保護は分ける
公式仕様では、GSAのシグナリングは認証プレーンに加えてMicrosoft Graphのデータプレーンにも対応すると説明されています。
が、一方でWindowsデバイス方式のTRv2には別途GPOなどを使う構成とプレビュー扱いの範囲があります。
今回実施したのはGSA / UTRによるサインインと画面アクセスの検証です。
これだけでSharePoint、Teams、Consumer OneDriveなどの匿名アクセスや取得済みトークンを使う全経路まで保護できたとはしていません。
自社アカウントが外部へアクセスするケースは別
今回の主題は、管理端末で外部アカウントを使うケースです。
自テナントの組織アカウントが別組織のB2Bゲストとしてアクセスすることまで一律禁止する設計ではありません。
必要に応じてクロステナントアクセスの送信設定などを組み合わせる必要があります。
また、Microsoft以外の独立した認証で利用するGoogleのサービスやAWSまでこのTRv2設定でまとめて制御するわけではありません。
自動化処理も影響範囲に入れる
TRv2の適用対象経路を通るサービスプリンシパルのサインインにも影響し得ます。
本番の運用スクリプトやセルフホストのCI/CDランナーなどは使っているテナントと通信経路を確認しておいた方がよさそうです。
すべてのGitHub Actionsやクラウド上の処理がこの設定だけで自動的に影響を受けるという意味ではありません。
どの処理がGSAや別のTRv2適用経路を通るかで切り分ける必要があります。
検証後に戻す場合
これは今回の動作検証結果ではなく切り戻す場合の注意点です。
記事の動作確認はUTRとPartnerの例外を有効にした状態で行っています。
今回のようにPoC専用で構成した環境なら退避用の管理経路からUTR、プロファイルの割当て、追加した組織設定などを変更前の状態へ戻します。
すでに本番利用中のGSAがある環境でプロファイルやUTRを一括で無効化する手順としては使わないでください。
特に resetToSystemDefault は、TRv2だけでなくクロステナントアクセスの既定構成をシステム既定へ戻すAPIです。
保存したJSONへ戻す操作と同じではありません。APIの対象範囲を確認した上で、PoCで変更した部分だけを復元する必要があります。
| 対象 | 戻す際に確認すること |
|---|---|
| 既定のクロステナント設定 | バックアップと現行値を比較し、既存の受信・送信設定を巻き込まない |
| MSA / Partner Aの個別設定 | 今回新規に追加したものか、元から存在したものかを分ける。他用途の変更が入っていないことも確認する |
| GSA / UTR | 変更前の有効・無効と割当へ戻す。既存利用者の制御を外さない |
| Windows / Edge | IPv4優先、QUICなど、PoCで変更した設定の元の値を確認する |
| Graph Explorer | PoC用に同意した権限を継続して残す必要があるか確認する |
別の管理者が途中で入れた正規の変更まで消さないように変更凍結か差分確認も必要になりますのでご注意ください。
まとめ
今回はTRv2のポリシーを構成しGSAクライアントとUTRを使って検証端末へ適用しました。
個人Microsoftアカウントの新規サインインは拒否され、自テナントの組織アカウントは引き続き利用できました。
さらに、例外許可したPartnerテナントで組織アカウントを作成するとそちらのサインインも成功しました。
個人的にいちばん大きな収穫は、アクセスしたいテナントと、サインインに使っているアカウントの認証元を分けて考えることでした。
Partnerを許可したのにGmailアドレスでは入れず組織アカウントなら入れたところは実際に触ると分かりやすかったです。
Azureテナントって最初どのアドレスでも契約できるじゃないですか。その際の契約アカウントではアクセス拒否されるが、組織アカウントならアクセスは許可されるところまで判定されているんだなぁ...と。
また、個人OneDriveが認証時に拒否されたことと、Consumer OneDriveの全経路を制御できることも別です。
このあたりをまとめて全部止まった！としてしまわないことが大事だと思います。
P1/P2で利用できるMicrosoft向け機能からここまで試せるのはなかなか便利でした。
同じように野良アカウントの利用を制御したい方の参考になれば幸いです！