クラウドインテグレーション部の張陽です。
本記事は、パスロジ株式会社のPassLogic Bridge - Microsoft 365用セカンダリ認証（以下、Bridge M365）を題材にした検証レポートです。
Microsoft Entra IDによる認証強化を進める上で、避けて通れないのが「ユーザーへのデバイス配布コスト」や「私物スマホ利用（BYOD）に伴う運用負荷」という壁です。せっかくセキュリティを高めたくても、現場の反発や管理の手間を理由に、脆弱な固定パスワードのまま運用を放置せざるを得ないケースは少なくありません。
こうした「Entra IDの認証強化における現場の課題」を根本から解決するアプローチとして注目されているのが、スマホや物理トークンを必要としない「デバイスレス認証」です。
今回は、PassLogicと「Bridge M365」を組み合わせ、Microsoft Entra IDの外部MFAとして連携させることで、デバイスレスでありながら強固な多要素認証と端末制御を両立させる仕組みについて技術検証を行いました。
本検証の目的は以下の2点です。
Bridge M365を使用したPassLogicによるセカンダリ認証の動作確認
Bridge M365をMicrosoft Entra IDの 外部MFA として登録し、Entra IDのパスワード認証に続けてPassLogicのマトリックス方式ワンタイムパスワード認証が実行されることを確認します。
Microsoft IntuneとEntra IDの条件付きアクセスによるアクセス元端末の制御の確認
セカンダリ認証通過後のアクセス制御として、Microsoft Intuneの 準拠デバイス評価 とEntra IDの 条件付きアクセス を組み合わせ、組織管理下の端末からのみAzure Virtual Desktop（以下、AVD）およびMicrosoft Teamsへ接続できる構成を検証します。Bridge M365経由で外部MFAとして連携する構成では、PassLogic単体で提供される 端末認証（クライアント証明書、Cookieによる認証可能端末の固定） が利用できなくなるため、その代用としてIntuneの準拠デバイス評価による端末制御が成立することを確認します。
当TechBlogでは過去に「ユーザ連携編」「SAML認証編」「シームレスサインオン編」のPassLogic検証シリーズを公開してきました。今回扱うBridge M365は、過去シリーズで扱ったSAML連携と比べて、Entra ID側でのPassLogic適用範囲の指定単位が異なります。要点を以下に整理します。
| 観点 | SAML連携（過去記事） | Bridge M365（本記事・外部MFA方式） |
|---|---|---|
| Entra ID側でのPassLogic適用範囲 | ドメイン単位（フェデレーション対象ドメインのユーザーが一律対象） | ユーザー単位（外部MFAの割り当て対象ユーザーのみ） |
| Entra ID側の設定先 | フェデレーション設定 | 認証方法 → 外部認証方法／ユーザーごとの認証方法割り当て |
なお、本記事の内容は2026年5月時点のものです。
Bridge M365は、Entra IDの外部MFAとして動作するセカンダリ認証コンポーネントです。Entra IDのパスワード認証に続けて、ブラウザ上でPassLogicのマトリックス方式ワンタイムパスワード認証を実行します。
特徴は以下です。
検証で構築した全体構成は以下のとおりです。
主要コンポーネントは以下です。
| グループ | コンポーネント | 役割 |
|---|---|---|
| ユーザーサイド | Intune管理Windows端末 | Autopilotで自動登録した検証用PC（被管理側）。準拠デバイス評価の対象 |
| M365・Azure関連 | Microsoft Entra ID | 認証の起点。外部MFAとしてBridge M365を呼び出す |
| M365・Azure関連 | Microsoft Intune | 端末のMDM登録とコンプライアンス評価（管理側） |
| M365・Azure関連 | Azure Virtual Desktop | 検証で接続先とした仮想デスクトップ |
| M365・Azure関連 | Microsoft Teams | 検証で接続先としたクラウド型コミュニケーションアプリ |
| PassLogic関連 | Bridge M365 | Entra IDとPassLogic認証サーバの橋渡し役 |
| PassLogic関連 | PassLogic認証サーバ | ワンタイムパスワードを発行・検証する認証エンジン |
検証を始める前提として、以下を満たしている必要があります。
Bridge M365はEntra IDから見ると「外部認証方法」プロバイダの1つです。連携の要点は以下です。
両者を繋ぐ「鍵」となる設定値を整理すると以下のようになります。詳細手順を読む前にこの対応関係を押さえておくと迷いません。
| 設定場所 | 設定対象 | 値の出どころ・ポイント |
|---|---|---|
| PassLogic | ドメイン | Entra IDのカスタムドメインと一致させる |
| PassLogic | ポリシー（認証方式 / Windows Logonの使用） | マトリックス方式を選択し、「Windows Logonの使用」を有効化 |
| PassLogic | ユーザー（uid） | Entra IDのユーザー名（@より左、大文字小文字区別あり） |
| Microsoft Entra ID | アプリの登録（リダイレクトURI） | パスロジから払い出されたBridge M365リダイレクトURL |
| Microsoft Entra ID | 認証方法 → 外部認証方法（検出エンドポイント） | Bridge M365エンドポイントURL |
| Microsoft Entra ID | 外部認証方法のターゲット | セカンダリ認証対象とするセキュリティグループ |
PassLogicテナント管理者で管理者画面にログインしたあと、以下を順に設定します。
PassLogic（マトリックス方式）を選択uid：Entra IDに登録したユーザー名（半角英数字、大文字小文字を区別）ドメイン：手順1で登録したドメインを選択ポリシー：手順3で作成したポリシーを選択パターン：「パターンをランダムに設定する」の左横のチェックボックスをONMicrosoft 365管理センターからMicrosoft Entra管理センターへ遷移し、以下を順に設定します。既存運用への影響を避けるため、セカンダリ認証用のグループを別途作成してユーザーを紐づける構成にしています。
グループの種類：セキュリティグループ名：任意（例：pltest）メンバーシップの種類：割り当て済み名前：任意（例：passlogic）サポートされているアカウントの種類：シングルテナントのみリダイレクトURI：種別Web、値はパスロジから払い出されたリダイレクトURL名前：任意（ユーザーがセカンダリ認証を選ぶ際に画面表示される名称、例：passlogic_bridge）クライアントID：手順3で控えた値検出エンドポイント：値はパスロジから払い出されたBridge M365エンドポイントURLアプリID：手順3で控えた値（クライアントIDと同一）管理者の同意の要求：［アクセス許可の要求］をクリックし、管理者アカウントでアクセスを承認有効化：オフからオンへ切り替えターゲットの追加：手順1で作成したセキュリティグループ（pltest）を選択pltest）を選択します。外部認証方法を選択し、手順4で登録したターゲット（passlogic_bridge）を［追加］します。以上で「Entra IDのパスワード認証 → Bridge M365経由でPassLogicのマトリックス認証」という連携が成立します。設定時にエラーが発生した場合は、Entra管理センター左ペイン［監視と正常性］→［監査ログ］から原因を確認します。
PassLogic Bridge M365連携を確認する接続先として、AVD環境を新規構築しました。本記事ではBridge M365が主題のため、AVD構築の詳細手順は割愛し、本検証で採用した構成のポイントを以下にまとめます。
| 構成要素 | 採用した内容 |
|---|---|
| サブスクリプション | Azureサブスクリプション（課金単位） |
| M365ライセンス | Microsoft 365 Business Premium（Intuneによるデバイス管理に必要） |
| リソースグループ | AVD関連リソースをまとめる管理単位 |
| 仮想ネットワーク | セッションホストVMを配置するプライベートネットワーク |
| サブネット | セッションホストVM配置用 |
| NAT Gateway | セッションホストのインターネット通信出口。Entra ID認証・AVDエージェント取得に必要 |
| キーコンテナー | セッションホストのローカル管理者認証情報を安全に保管 |
| ホストプール | 複数ユーザーで1台のセッションホストを共有（プール型） |
| ワークスペース／アプリケーショングループ | デスクトップ向けアプリケーショングループを1つ作成 |
| セッションホストVM | Windows 11 Enterprise multi-session、サイズStandard_B2s_v2（2 vCPU / 8 GB RAM） |
| VMの参加形態 | Microsoft Entra ID |
| ユーザー割り当て | 検証ポイント①で作成したセキュリティグループ（pltest）をアプリケーショングループに割り当て |
| 条件付きアクセスポリシー | 準拠デバイス要件＋セカンダリ認証を要求 |
| 利用クライアント | Windows App（Web版） |
検証用Windows 11端末はAutopilotで自動登録しました。流れは以下です。
OOBE時もBridge M365のセカンダリ認証が走ります。MDM登録後、Intuneコンプライアンスに「準拠」と評価されることで条件付きアクセスを通過できます。
検証では以下のリソースをポリシーで保護しました。各リソースの役割と用途はMicrosoft Learnの公式記載に拠ります。
| 対象リソース（アプリID） | 含めた理由（除外時の影響） |
|---|---|
| Azure Virtual Desktop | Windows AppからAVDへの接続要求時のEntra ID認証点。除外するとAVDデスクトップ到達までPassLogicが要求されない |
| Windows 365 | Windows Appのリソース列挙とCloud PC操作の認証を担う。Windows Appが本アプリへ認証を試みる仕様のため、除外するとWindows Appのリソース列挙時にPassLogicが要求されない |
| Windows Cloud Login | SSO構成時にCloud PC／AVDセッションホストへユーザーをサインオンさせる。除外するとSSO経路でPassLogicが要求されない |
| Office 365 | Exchange・SharePoint・Teamsを含むMicrosoft 365のサービス一式を指す論理グループ。除外するとTeamsへの直接サインインから業務データに到達できる経路が残る。サービス間依存を取りこぼさないため、個別アプリではなくOffice 365論理グループとして指定する |
| passlogic（自テナントに登録したBridge M365用アプリ） | Bridge M365用アプリのクライアントIDを利用したトークン取得経路を評価対象に含めるための多層防御（Defense-in-depth）。AVD・Office 365など主要アプリは既にCAで保護されているが、本アプリ自体がトークン要求の起点となる将来の変更や攻撃ベクトルに備える |
検証用端末からAVDとTeamsへそれぞれ到達する認証フローを示します。本検証では、検証用端末からAVDへの接続と、検証用端末からTeamsへの接続をそれぞれ確認しました。両者は同一の条件付きアクセスポリシーで横並びに保護されています。
Windows App（Web版）にアクセスし、Entra IDアカウントでサインインします。
パスワード認証のあと、Bridge M365のマトリックス表が表示されます。登録パターンに従って読み取った数字を入力します。
条件付きアクセス評価に通過すると、AVDデスクトップが表示されます。
Intune管理端末上で（AVDセッションホストではなく手元側で）Teamsを起動し、Entra IDアカウントでサインインします。
パスワード認証のあと、Bridge M365のマトリックス表が表示されます。登録パターンに従って読み取った数字を入力します。
条件付きアクセス評価に通過すると、Teamsが起動します。
targetisaadjoined:i:1 を追加：Microsoft Entra JoinのセッションホストにRDP接続するため、ホストプール側RDPプロパティに必須です。クリップボード共有が必要なら redirectclipboard:i:1 も追加します。Standard B2s_v2 ファミリのvCPUクォータが0のことがあります。セッションホストVMのデプロイ前に「使用量＋クォータ」で引き上げが必要です。本検証の結果は以下です。
別途物理端末を利用したMFAを導入しにくい組織に、Bridge M365は有力な選択肢です。
最後までお読みいただきありがとうございました。
確かな技術力で弊社の代理店としても深く連携させていただいているアジアクエスト様に、この度の検証をご依頼いたしました。
Microsoft 365やAVDの認証強化が必要となる中、今回の検証により、Intuneの端末制限（所有物認証）とPassLogic認証（知識認証）を組み合わせた、デバイスレスな多要素認証でのAVD接続が実証されました。
これにより、スマートフォンが持ち込めない現場や、私物スマートフォンの利用が難しい環境であっても、セキュアな環境が実現可能になります。
具体的には、以下のメリットが実現します。
画面上に表示される乱数表を用いるマトリックス方式を採用しているため、認証用のスマートフォンアプリや物理トークンが一切不要です。デバイスコストが削減され、紛失・盗難による再発行の手間や、私物スマートフォンの業務利用（BYOD）を巡る社内トラブルも回避できます。
PCの起動からクラウドアクセスまで、丸ごと守れるAVDへのアクセス時だけでなく、手元の「Windows PCの起動時（オフライン対応）」や「Intuneによるデバイス管理」とも柔軟に連携できます。「PCの電源を入れてから、クラウド上のデスクトップ環境で業務を開始するまで」のすべてを一気通貫でセキュアな状態にでき、ゼロトラスト環境が完成します。
AVDの「その先」にある社内・校務システムも保護オプション機能（PassLogic Bridge - Microsoft 365用セカンダリ認証）の活用により、AVDを介してアクセスする社内システムや、学校の校務系システム等の認証基盤（Microsoft Entra ID）も同時に強化できます。仮想デスクトップの入り口だけでなく、社員や教職員が最終的に業務で使用する「各種システムへのアクセス全体」を一括して安全に保護することが可能になります。
本機能に興味をお持ちの方は、ぜひアジアクエスト様または弊社までお気軽にお問い合わせください。
パスロジ株式会社 市場戦略部 / 相原 彩花 様