はじめに
クラウドインテグレーション部の張陽です。
本記事は、パスロジ株式会社のPassLogic Bridge - Microsoft 365用セカンダリ認証（以下、Bridge M365）を題材にした検証レポートです。
【Microsoft Entra ID】一般的な認証強化の壁を突破する「デバイスレス」という選択肢
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の準拠デバイス評価による端末制御が成立することを確認します。
過去のPassLogic連携方式との関係
当TechBlogでは過去に「ユーザ連携編」「SAML認証編」「シームレスサインオン編」のPassLogic検証シリーズを公開してきました。今回扱うBridge M365は、過去シリーズで扱ったSAML連携と比べて、Entra ID側でのPassLogic適用範囲の指定単位が異なります。要点を以下に整理します。
| 観点 | SAML連携（過去記事） | Bridge M365（本記事・外部MFA方式） |
|---|---|---|
| Entra ID側でのPassLogic適用範囲 | ドメイン単位（フェデレーション対象ドメインのユーザーが一律対象） | ユーザー単位（外部MFAの割り当て対象ユーザーのみ） |
| Entra ID側の設定先 | フェデレーション設定 | 認証方法 → 外部認証方法／ユーザーごとの認証方法割り当て |
なお、本記事の内容は2026年5月時点のものです。
PassLogic Bridge M365とは
Bridge M365は、Entra IDの外部MFAとして動作するセカンダリ認証コンポーネントです。Entra IDのパスワード認証に続けて、ブラウザ上でPassLogicのマトリックス方式ワンタイムパスワード認証を実行します。
特徴は以下です。
- デバイスレス：スマートフォンアプリや物理トークンは不要。ブラウザだけで完結します。
- マトリックス方式：ブラウザに表示される数字のマトリックス表から、利用者があらかじめ決めた位置・順序で数字を読み取りワンタイムパスワードを生成します（位置パターンを覚えておけば、表示数字が変わるたびにパスワードを動的に再現可能）。
- 外部MFA連携：ユーザー情報はEntra ID側に集約できるため、SAML連携と比べて二重管理が不要です。
- 既存Entra MFAと併用可能：条件付きアクセスから「外部認証方法」として呼び出せます。
検証構成の全体像
検証で構築した全体構成は以下のとおりです。
主要コンポーネントは以下です。
| グループ | コンポーネント | 役割 |
|---|---|---|
| ユーザーサイド | 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認証サーバ | ワンタイムパスワードを発行・検証する認証エンジン |
検証を始める前提として、以下を満たしている必要があります。
- Microsoft Entra IDの外部MFAをサポートする契約形態であること（Entra ID P1 以上）
- Microsoft Entra IDでカスタムドメインが作成済みであること
- Microsoft 365管理センターおよびMicrosoft Entra管理センターにEntra IDの管理者アカウントでログインできること
- パスロジ株式会社から Bridge M365用のアクセスURL（エンドポイント） が払い出されていること
- PassLogicクラウド版のテナント管理者でログインできること
検証ポイント① PassLogic Bridge M365 × Entra ID外部MFA連携
Bridge M365はEntra IDから見ると「外部認証方法」プロバイダの1つです。連携の要点は以下です。
- 外部MFAセットアップ：Entra管理センターでBridge M365を外部認証方法として有効化し、Bridge M365側で発行された値を登録します。
- ユーザー紐づけ：Entra IDのユーザー識別子でPassLogicユーザーを解決します。
PassLogicとEntra IDで交換する設定値
両者を繋ぐ「鍵」となる設定値を整理すると以下のようになります。詳細手順を読む前にこの対応関係を押さえておくと迷いません。
| 設定場所 | 設定対象 | 値の出どころ・ポイント |
|---|---|---|
| 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テナント管理者で管理者画面にログインしたあと、以下を順に設定します。
- ドメインの登録：左ペインの［ドメイン管理］→［追加］から、Entra IDで管理しているドメイン名（ユーザー名@ドメイン名の「@」より右側）を入力して登録します。
- ポリシーの作成：［設定］→［追加］でポリシー名を入力し、登録します。
- ポリシーの修正：作成したポリシーの［編集］から以下2点を設定します。
- 「認証方式」プルダウンから
PassLogic（マトリックス方式）を選択 - 「Windows Logonの使用」にチェックを入れる（Bridge M365からの認証要求を受け付けるために必須）
- 「認証方式」プルダウンから
- ユーザーの作成：［ユーザー管理］→［新規作成］で以下を登録します。
uid：Entra IDに登録したユーザー名（半角英数字、大文字小文字を区別）ドメイン：手順1で登録したドメインを選択ポリシー：手順3で作成したポリシーを選択パターン：「パターンをランダムに設定する」の左横のチェックボックスをON- 作成完了画面で［通知書をプリント］をクリックし、設定されたパターンを控える
Microsoft Entra側の主要設定手順
Microsoft 365管理センターからMicrosoft Entra管理センターへ遷移し、以下を順に設定します。既存運用への影響を避けるため、セカンダリ認証用のグループを別途作成してユーザーを紐づける構成にしています。
- セキュリティグループの作成：左ペイン［グループ］→［新しいグループ］から、以下でセカンダリ認証用グループを作成します。
グループの種類：セキュリティグループ名：任意（例：pltest）メンバーシップの種類：割り当て済み
- アプリケーションの登録：左ペイン［アプリの登録］→［新規登録］で以下を入力し、登録します。
名前：任意（例：passlogic）サポートされているアカウントの種類：シングルテナントのみリダイレクトURI：種別Web、値はパスロジから払い出されたリダイレクトURL
- アプリケーション（クライアント）IDの控え：登録したアプリの［概要］→［基本］から「アプリケーション（クライアント）ID」をコピーして控えておきます（次の手順で利用）。
- 外部認証方法（ターゲットリソース）の登録：左ペイン［認証方法］→［外部認証方法の追加］で以下を入力します。
名前：任意（ユーザーがセカンダリ認証を選ぶ際に画面表示される名称、例：passlogic_bridge）クライアントID：手順3で控えた値検出エンドポイント：値はパスロジから払い出されたBridge M365エンドポイントURLアプリID：手順3で控えた値（クライアントIDと同一）管理者の同意の要求：［アクセス許可の要求］をクリックし、管理者アカウントでアクセスを承認有効化：オフからオンへ切り替えターゲットの追加：手順1で作成したセキュリティグループ（pltest）を選択
- Entra IDユーザーの作成：左ペイン［ユーザー］→［新しいユーザー］→［新しいユーザーの作成］から、PassLogic側のuidと一致するユーザープリンシパル名・ドメイン・表示名・パスワードを入力して作成します。
- ユーザーへのグループ割り当て：作成したユーザー画面の［グループ］→［メンバーシップの追加］から、手順1で作成したセキュリティグループ（
pltest）を選択します。 - ユーザーへの外部認証方法の割り当て：ユーザー画面の［認証方法］→［認証方法の追加］から、方法に
外部認証方法を選択し、手順4で登録したターゲット（passlogic_bridge）を［追加］します。
以上で「Entra IDのパスワード認証 → Bridge M365経由でPassLogicのマトリックス認証」という連携が成立します。設定時にエラーが発生した場合は、Entra管理センター左ペイン［監視と正常性］→［監査ログ］から原因を確認します。
検証ポイント② Intune準拠端末 × 条件付きアクセス × AVD/Teams
AVD環境の準備
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版） |
端末をIntuneの準拠デバイスにする
検証用Windows 11端末はAutopilotで自動登録しました。流れは以下です。
- 対象端末でPowerShellからハードウェアハッシュをCSV出力する
- Intune管理センターでCSVをインポートしてAutopilotにデバイス登録する
- 端末を初期化し、OOBEでEntra IDアカウントによりサインインするとMDM登録が完了する
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版）経由でのAVD接続
Windows App（Web版）にアクセスし、Entra IDアカウントでサインインします。
パスワード認証のあと、Bridge M365のマトリックス表が表示されます。登録パターンに従って読み取った数字を入力します。
条件付きアクセス評価に通過すると、AVDデスクトップが表示されます。
Teamsへの接続
Intune管理端末上で（AVDセッションホストではなく手元側で）Teamsを起動し、Entra IDアカウントでサインインします。
パスワード認証のあと、Bridge M365のマトリックス表が表示されます。登録パターンに従って読み取った数字を入力します。
条件付きアクセス評価に通過すると、Teamsが起動します。
検証で得た気づき・留意点
条件付きアクセスの設計
- セキュリティの既定値群は事前に無効化が必要：有効なテナントでは条件付きアクセスポリシーを新規作成できません。最初に無効化しておきます。
- 対象リソース選定が肝：AVDだけ対象にするとTeams等への抜け道が残ります。AVD・Windows 365・Windows Cloud Login・Office 365・passlogicまで横並びで保護対象にします。
Intune/AVD連携で気をつけた点
- RDPプロパティ
targetisaadjoined:i:1を追加：Microsoft Entra JoinのセッションホストにRDP接続するため、ホストプール側RDPプロパティに必須です。クリップボード共有が必要ならredirectclipboard:i:1も追加します。 - vCPUクォータの初期値に注意：新規Azureサブスクリプションでは
Standard B2s_v2ファミリのvCPUクォータが0のことがあります。セッションホストVMのデプロイ前に「使用量＋クォータ」で引き上げが必要です。
まとめ
本検証の結果は以下です。
- PassLogic Bridge M365はEntra IDの外部MFAとして動作し、Intune管理端末からAVDおよびMicrosoft Teamsへアクセスする際にBridge M365のマトリックス方式ワンタイムパスワードが要求されることを確認した
- 条件付きアクセスでAVD・Windows 365・Windows Cloud Login・Office 365・Bridge M365用アプリを横並びに保護し、Intune準拠デバイス要件と組み合わせることで、追加デバイスなしで組織管理下の端末からのみAVD・Teamsへアクセスできる構成を実装できる
別途物理端末を利用した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）も同時に強化できます。仮想デスクトップの入り口だけでなく、社員や教職員が最終的に業務で使用する「各種システムへのアクセス全体」を一括して安全に保護することが可能になります。
本機能に興味をお持ちの方は、ぜひアジアクエスト様または弊社までお気軽にお問い合わせください。
パスロジ株式会社 市場戦略部 / 相原 彩花 様
参考・引用
- パスロジ株式会社：PassLogic Bridge - Microsoft 365用セカンダリ認証
- Microsoft Learn：Microsoft Entra ID で外部多要素認証方法を管理する
- Microsoft Learn：条件付きアクセス概要
- 弊社過去記事：PassLogicを使ってみた（ユーザ連携編） / PassLogicを使ってみた（SAML認証編） / PassLogicを使ってみた（シームレスサインオン編）
