VPN および条件付きアクセス
VPN クライアントは、クラウド ベースの条件付きアクセス プラットフォームと統合して、リモート クライアント用のデバイス コンプライアンス オプションを提供することができるようになりました。 条件付きアクセスはポリシー ベースの評価エンジンであり、接続されているアプリケーションMicrosoft Entraアクセス規則を作成できます。
注
条件付きアクセスは、P1 または P2 のMicrosoft Entra ID機能です。
デバイス コンプライアンスのために使用される条件付きアクセス プラットフォームのコンポーネントには、次のクラウド ベースのサービスが含まれます。
- 条件付きアクセス フレームワーク
- 接続の正常性Microsoft Entra
- Windows 正常性構成証明サービス (オプション)
- 証明機関Microsoft Entra - クラウドベースのデバイス コンプライアンス ソリューションに使用されるクライアント証明書は、Microsoft Entra ID ベースの証明機関 (CA) によって発行される必要があります。 Microsoft Entra CA は、基本的に Azure のミニ CA クラウド テナントです。 Microsoft Entra CA は、オンプレミスのエンタープライズ CA の一部として構成できません。 「Windows Server と Windows 10 の VPN 展開Always On」も参照してください。
- Microsoft Entra ID発行された有効期間の短い証明書 - VPN 接続の試行が行われると、ローカル デバイス上のMicrosoft Entra トークン ブローカーがMicrosoft Entra IDと通信し、コンプライアンス 規則に基づいて正常性をチェックします。 準拠している場合、Microsoft Entra IDは、VPN の認証に使用される有効期間の短い証明書を返します。 証明書の認証方法として、EAP-TLS などを使用できます。 クライアントが再接続し、証明書の有効期限が切れていると判断すると、クライアントは、新しい証明書が発行される前に、正常性検証のためにMicrosoft Entra IDを使用して再びチェックします。
-
Microsoft Intuneデバイス コンプライアンス ポリシー: クラウドベースのデバイス コンプライアンスでは、Microsoft Intuneコンプライアンス ポリシーが使用されます。このポリシーでは、デバイスの状態を照会し、次のようなコンプライアンス規則を定義できます。
- ウイルス対策の状態
- 自動更新の状態および更新プログラムの準拠
- パスワード ポリシーの準拠
- 暗号化の準拠
- デバイスの正常性構成証明の状態 (クエリの実行後に構成証明サービスに対して検証されます)
次のクライアント側のコンポーネントも必要です。
- 正常性構成証明の構成サービス プロバイダー (CSP)
- VPNv2 CSP の DeviceCompliance ノードの設定
- トラステッド プラットフォーム モジュール (TPM)
VPN デバイス コンプライアンス
現時点では、ユーザーに発行されたMicrosoft Entra証明書には CRL 配布ポイント (CDP) が含まれていないので、キー配布センター (KDC) が Kerberos トークンを発行するのに適していません。 ユーザーがネットワーク共有上のファイルなどのオンプレミス リソースにアクセスできるようにするには、クライアント認証証明書をユーザーの Windows プロファイルに展開し、VPNv2 プロファイルに SSO> セクションを<含める必要があります。
VPN デバイス コンプライアンスをサポートするためのサーバー側のインフラストラクチャ要件は次のとおりです。
- VPN サーバーは、証明書認証用に構成する必要があります。
- VPN サーバーは、テナント固有のMicrosoft Entra CA を信頼する必要があります。
- Kerberos/NTLM を使用したクライアント アクセスの場合、ドメイン信頼証明書がクライアント デバイスに展開され、シングル サインオン (SSO) に使用するように構成されます。
サーバー側のセットアップが終了したら、VPN 管理者は、VPNv2 の DeviceCompliance ノードを使用して、条件付きアクセス用のポリシー設定を VPN プロファイルに追加できます。
クライアント側の 2 つの構成サービス プロバイダーは、VPN デバイス コンプライアンス用に利用されます。
- VPNv2 CSP DeviceCompliance 設定:
- Enabled: クライアントからのデバイス コンプライアンスのフローを有効にします。 true とマークされている場合、VPN クライアントは認証に使用する証明書を取得するためにMicrosoft Entra IDと通信しようとします。 VPN は証明書認証を使用するように設定する必要があり、VPN サーバーはMicrosoft Entra IDによって返されたサーバーを信頼する必要があります。
- Sso: SSO の下のエントリを使用して、Kerberos 認証を必要とするリソースにアクセスするときに VPN 認証証明書以外の証明書を使用するように VPN クライアントに指示する必要があります。
- Sso/Enabled: このフィールドが true に設定されている場合、VPN クライアントは Kerberos 認証用の別の証明書を探します。
- Sso/IssuerHash: VPN クライアントが Kerberos 認証用の適切な証明書を検索するためのハッシュです。
- Sso/Eku: VPN クライアントが Kerberos 認証用の正しい証明書を検索するための拡張キー使用法 (EKU) 拡張機能のコンマ区切りの一覧。
- HealthAttestation CSP (必須ではありません) - HealthAttestation CSP で実行される機能です。次のような機能があります。
- 正常性の状態を確認するために使用する TPM データを収集します。
- そのデータを正常性構成証明サービス (HAS) に転送します。
- HAS サービスから受け取った正常性構成証明の証明書をプロビジョニングします。
- 要求に応じて、正常性構成証明証明書 (HAS から受信) と関連するランタイム情報を MDM サーバーに転送して検証します
注
オンプレミスの CA から Kerberos チケットを取得するために使用される証明書を発行し、その SSO をユーザーの VPN プロファイルで有効にする必要があります。 これにより、ユーザーはオンプレミスのリソースにアクセスできるようになります。 AzureAD 専用参加済みデバイス (ハイブリッド参加済みデバイスではない) の場合、オンプレミス CA によって発行されたユーザー証明書に、サブジェクトと SAN (サブジェクト代替名) の AzureAD からのユーザー UPN がある場合は、クライアントが VPN 認証に使用する資格情報をキャッシュしないように VPN プロファイルを変更する必要があります。 これを行うには、VPN プロファイルをクライアントに展開した後、UseRasCredentials のエントリを 1 (既定値) から 0 (ゼロ) に変更して、クライアントの Rasphone.pbk を変更します。
クライアント接続フロー
VPN クライアント側の接続フローは次のように動作します。
VPNv2 プロファイルが DeviceCompliance<>Enabled true</Enabled>> で<構成されている場合、VPN クライアントはこの接続フローを使用します。
- VPN クライアントは、Windows 10またはWindows 11のMicrosoft Entra トークン ブローカーを呼び出し、VPN クライアントとして識別します。
- Microsoft Entra トークン ブローカーは、Microsoft Entra IDに対して認証を行い、接続しようとしているデバイスに関する情報を提供します。 Microsoft Entra サーバーは、デバイスがポリシーに準拠しているかどうかを確認します。
- 準拠している場合、Microsoft Entra IDは有効期間の短い証明書を要求します。
- Microsoft Entra IDトークン ブローカーを使用して、有効期間の短い証明書を証明書ストアにプッシュダウンします。 その後、トークン ブローカーは VPN クライアントに制御を戻し、さらに接続処理を行います。
- VPN クライアントは、Microsoft Entra ID発行された証明書を使用して VPN サーバーで認証します。
条件付きのアクセスの構成
XML 構成については、「VPN プロファイル オプション」と「VPNv2 CSP」をご覧ください。
条件付きアクセスとMicrosoft Entra正常性の詳細
- 条件付きアクセスのMicrosoft Entra
- Microsoft Entra条件付きアクセスの概要
- Windows デバイスの正常性を制御する
- ヒント: VPN の条件付き Access フレームワークとデバイスのポリシー準拠 (パート 1)
- ヒント: VPN の条件付き Access フレームワークとデバイスのポリシー準拠 (パート 2)
- ヒント: VPN の条件付き Access フレームワークとデバイスのポリシー準拠 (パート 3)
- ヒント: VPN の条件付き Access フレームワークとデバイスのポリシー準拠 (パート 4)