Microsoft Entra アプリケーション プロキシに関してよく寄せられる質問

いいえ。次の構成項目はアプリ プロキシによって使用されており、変更および削除しないでください。

• [パブリック クライアント フローを許可する] を有効または無効にする。
• CWAP_AuthSecret (クライアント シークレット)。
• API 使用権限。 [アプリの登録] ページで上記の構成項目のいずれかを変更すると、Microsoft Entra アプリケーション プロキシの事前認証が破棄されます。

いいえ。アプリケーション プロキシ アプリは、Microsoft Entra 管理センターのエンタープライズ アプリケーション領域から削除する必要があります。 Microsoft Entra 管理センターの [アプリの登録] 領域からアプリケーション プロキシ アプリを削除すると、問題が発生する可能性があります。

Microsoft Entra アプリケーション プロキシを使用するには、Microsoft Entra ID P1 または P2 ライセンスが必要です。 ライセンスの詳細については、「Microsoft Entra の価格」を参照してください

ライセンスの有効期限が切れると、アプリケーション プロキシは自動的に無効になります。 アプリケーションの情報は、最大 1 年間保存されます。

少なくとも Microsoft Entra ID P1 または P2 ライセンスと、Microsoft Entra プライベート ネットワーク コネクタがインストールされていることを確認してください。 最初のコネクタを正常にインストールすると、Microsoft Entra アプリケーション プロキシ サービスが自動的に有効になります。

はい。Microsoft Entra アプリケーション プロキシと Microsoft Entra Private Access の両方が、Microsoft Entra プライベート ネットワーク コネクタを使用します。 コネクタの詳細については、「Microsoft Entra プライベート ネットワーク コネクタ」を参照してください。 コネクタの構成のトラブルシューティングを行うには、「コネクタのトラブルシューティング」を参照してください。

これらのサフィックスはサフィックス リストに表示されていますが、使用しないでください。 これらのドメイン サフィックスは、Microsoft Entra アプリケーション プロキシで使用するためのものではありません。 これらのドメイン サフィックスを使用すると、作成した Microsoft Entra アプリケーション プロキシ アプリケーションは機能しません。 標準ドメイン サフィックス msappproxy.net またはカスタム ドメインのいずれかを使用できます。

Microsoft Entra ID のアプリケーション プロキシ サービスを使うと、ユーザーは Microsoft Entra アカウントでサインインして、オンプレミスのアプリケーションにアクセスできます。 異なるリージョンにコネクタをインストールしていた場合は、各コネクタ グループで使用する、最も近いアプリケーション プロキシ クラウド サービスのリージョンを選択することで、トラフィックを最適化できます。「Microsoft Entra アプリケーション プロキシを使用してトラフィック フローを最適化する」を参照してください。

SSL 証明書のアップロード後に、ポータルに「証明書が無効であるか、パスワードが間違っている可能性がある」というメッセージが表示されます。

このエラーの問題解決に使用できるヒントを、次にいくつか示します。

• 証明書に問題がないことを確認します。 それをお使いのローカル コンピューターにインストールします。 問題が発生しなかった場合、その証明書には問題はありません。
• パスワードに特殊文字が含まれていないことを確認します。 パスワードには 0 から 9、A から Z、a から z の文字のみが含まれている必要があります。
• 証明書が Microsoft ソフトウェア キー格納プロバイダーで作成されている場合は、RSA アルゴリズムが使用されている必要があります。

既定の長さは 85 秒です。 「長い」設定は 180 秒です。 タイムアウト制限を延長することはできません。

いいえ。現在これはサポートされていません。

クライアント シークレット (CWAP_AuthSecret とも呼ばれます) は、Microsoft Entra アプリケーション プロキシ アプリが作成されるときに、アプリケーション オブジェクトに自動的に追加されます (アプリの登録)。

クライアント シークレットは 1 年間有効です。 現在有効なクライアント シークレットの有効期限が切れる前に、新しい 1 年間有効のクライアント シークレットが自動的に作成されます。 アプリケーション オブジェクトには、常に 3 つの CWAP_AuthSecret クライアント シークレットが保持されます。

いいえ。元のフォールバック ドメインを使用する必要があります。

質問で言及されている記事: Microsoft 365 で onmicrosoft.com フォールバック ドメインを追加して置き換える

[アプリケーションの登録] ページで、ホームページの URL を任意のランディング ページの外部 URL に変更できます。 アプリケーションがマイ アプリまたは Office 365 ポータルから起動されると、指定したページが読み込まれます。 構成手順については、「Microsoft Entra アプリケーション プロキシを使用して、発行されたアプリのカスタム ホーム ページを設定する」を参照してください

Microsoft Entra の事前認証が構成されており、アプリケーションに初めてアクセスしようとしたときにアプリケーションの URL に "#" 文字が含まれている場合、認証のために Microsoft Entra ID (login.microsoftonline.com) にリダイレクトされます。 認証が完了すると、"#" 文字の前の URL 部分にリダイレクトされ、"#" 以降のすべてが無視または削除されたように見えます。 たとえば、URL が https://www.contoso.com/#/home/index.html の場合、Microsoft Entra 認証が完了すると、ユーザーは https://www.contoso.com/ にリダイレクトされます。 この動作は仕様であり、ブラウザーによる "#" 文字の処理方法が原因です。

考えられる解決策または代替策:

• https://www.contoso.com から https://contoso.com/#/home/index.html へのリダイレクトを設定します。 ユーザーは最初に https://www.contoso.com にアクセスする必要があります。
• 最初のアクセス試行に使用される URL には、エンコードされた形式の "#" 文字 (%23) を含める必要があります。 公開されているサーバーがこれを受け付けない可能性があります。
• パススルーの事前認証の種類を構成します (推奨されません)。

いいえ。公開済みのアプリケーションには IIS の必要条件はありません。 Windows Server 以外のサーバーで実行されている Web アプリケーションを公開できます。 ただし、Web サーバーでネゴシエート (Kerberos 認証) がサポートされているかどうかによって、Windows 以外のサーバーで事前認証を使用できない場合があります。 コネクタがインストールされているサーバーでは、IIS は必要ありません。

アプリケーション プロキシでは、HTTP の Strict-Transport-Security ヘッダーは HTTPS 応答に自動的に追加されませんが、発行されたアプリケーションによって送信された元の応答にヘッダーが含まれる場合は保持されます。 この機能を有効にするための設定の証明は、ロードマップ上にあります。

いいえ。プロトコル http が外部 URL で構成されている場合、Microsoft Entra アプリケーション プロキシ エンドポイントは、ポート TCP 80 で着信要求を受け入れ、プロトコル https が構成されている場合は、ポート TCP 443 で受け入れます。

はい。ポートを含む内部 URL はたとえば http://app.contoso.local:8888/、https://app.contoso.local:8080/、https://app.contoso.local:8081/test/ のようになります。

公開された Web アプリケーションによって送信される一部の応答には、ハードコードされた URL が含まれる場合があります。 この場合、リンク変換ソリューションを使用することで、クライアントで常に正しい URL が使用されるようにする必要があります。 リンク変換ソリューションは複雑になることがあり、一部のシナリオで機能しない可能性があります。 リンク変換のためのドキュメントに記載されたソリューションについては、こちらを参照してください。

ベスト プラクティスとしては、外部 URL と内部 URL を同じにすることをお勧めします。 外部 URL と内部 URL で protocol://hostname:port/path/ が同一であれば、両方の URL は同一であると見なされます。

これは、カスタムドメイン機能を使用して実現できます。

例 :

同じ場合:

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com/test/

同じでない場合:

External URL: https://app1.contoso.com/test/
Internal URL: http://app1.contoso.com/test/

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com:8080/test/

External URL: https://app1.msappproxy.net/test/
Internal URL: https://app1.contoso.com:/test/

内部 URL に標準以外のポート (TCP 80/443 以外) が含まれている場合、外部 URL と内部 URL を同一にすることはできません。

シナリオによっては、Web アプリの構成で変更を行う必要があります。

PrincipalsAllowedToDelegateToAccount メソッドは、コネクタ サーバーが Web アプリケーション サービス アカウントとは異なるドメインにある場合に使用します。 このメソッドでは、リソースベースの制約付き委任を使用する必要があります。 コネクタサーバーと Web アプリケーション サービス アカウントが同じドメインにある場合は、[Active Directory ユーザーとコンピューター] を使用して、各コネクタ コンピューター アカウントで委任設定を構成し、ターゲット SPN に委任することができます。

コネクタ サーバーと Web アプリケーション サービス アカウントが異なるドメインにある場合は、リソース ベースの委任が使用されます。 委任されたアクセス許可は、ターゲット Web サーバーと Web アプリケーション サービス アカウントで構成されます。 この制約付き委任方法は、比較的新しいものです。 この方法は、リソース (Web サービス) 所有者が、委任できるコンピューターとサービス アカウントを制御できるようにすることで、ドメイン間の委任に対応した Windows Server 2012 で導入されました。 この構成を支援する UI はないため、PowerShell を使用する必要があります。 詳細については、「アプリケーション プロキシを使った Kerberos の制約付き委任」に関するホワイトペーパーを参照してください。

NTLM 認証は、事前認証またはシングル サインオンの方法として使用できません。 NTLM 認証は、クライアントと発行された Web アプリケーションの間で直接ネゴシエートできる場合にのみ使用できます。 NTLM 認証を使用すると、通常、ブラウザーにサインイン プロンプトが表示されます。

いいえ。Microsoft Entra ID のゲスト ユーザーには、前述のサインイン ID で必要な属性がないため、これは機能しません。

この場合、"ユーザー プリンシパル名" へのフォールバックが発生します。 B2B シナリオの詳細については、「Microsoft Entra ID の B2B ユーザーにオンプレミスのアプリケーションへのアクセスを許可する」を参照してください。

条件付きアクセス ポリシーは、Microsoft Entra ID で正常に事前承認されたユーザーにのみ適用されます。 パススルー認証では Microsoft Entra 認証がトリガーされないため、条件付きアクセス ポリシーを適用することはできません。 パススルー認証では、オンプレミス サーバーに MFA ポリシーを実装するか (可能な場合)、または Microsoft Entra アプリケーション プロキシで事前認証を有効にする必要があります。

いいえ。TLS トラフィックはアプリケーション プロキシによって終了されるため、このシナリオはサポートされていません。

「Microsoft Entra アプリケーション プロキシを使用しでリモート デスクトップを発行する」を参照してください。

いいえ、このシナリオはサポートされていません。

はい、そうです。 事前認証のシナリオでは ActiveX コントロールが必要ですが、これはサード パーティのブラウザーではサポートされていません。

はい、このシナリオは現在パブリック プレビュー段階です。 「Microsoft Entra アプリケーション プロキシを使用しでリモート デスクトップを発行する」を参照してください。

はい、想定される動作です。 ユーザーが Microsoft Entra 参加済みコンピューターを使用している場合、そのユーザーは自動的に Microsoft Entra ID にサインインします。 ユーザーが資格情報を提供する必要があるのは、RDWeb サインイン フォームのみです。

このオプションを利用すると、ユーザーは rdp ファイルをダウンロードし、別の RDP クライアントでそれを利用できます (Remote Desktop Web Client の外で)。 一般に、別の RDP クライアント (Microsoft リモート デスクトップ クライアントなど) では事前承認をネイティブに処理できません。 そのため、このシナリオは機能しません。

「Microsoft Entra アプリケーション プロキシによる SharePoint へのリモート アクセスの有効化」を参照してください。

SharePoint モバイルアプリでは、現在、Microsoft Entra 事前承認はサポートされていません。

いいえ。Microsoft Entra アプリケーション プロキシは Microsoft Entra ID で動作するように設計されているため、AD FS プロキシとして機能するための要件を満たしていません。

いいえ、サポートされていません。

WebSocket プロトコル (QlikSense やリモート デスクトップ Web クライアント (HTML5) など) を使用するアプリケーションがサポートされるようになりました。 既知の制限事項には、次のようなものがあります。

• アプリケーション プロキシでは、WebSocket 接続を開く際に、サーバー応答に設定されている Cookie を破棄します。
• WebSocket 要求に SSO は適用されません。
• Windows Admin Center (WAC) の機能 (イベント ログ、PowerShell、リモート デスクトップ サービス) は、Microsoft Entra アプリケーション プロキシ経由では動作しません。

WebSocket アプリケーションには一意の公開要件は存在しないので、他のすべてのアプリケーション プロキシ アプリケーションと同じ方法で公開できます。

はい。 リンク変換の使用はパフォーマンスに影響します。 アプリケーション プロキシ サービスは、アプリケーションでハードコードされたリンクをスキャンし、ユーザーに公開する前にそれぞれ公開されている外部 URL で置換します。

最適なパフォーマンスを得るには、カスタム ドメインを構成して、同じ内部 URL と外部 URL を使用することをお勧めします。 カスタム ドメインを使用できない場合は、マイ アプリによるセキュリティで保護されたサインイン拡張機能またはモバイルの Microsoft Edge ブラウザーを使用することで、リンク変換のパフォーマンスを向上させることができます。 「Microsoft Entra アプリケーション プロキシを使用して公開されたアプリのハードコーディングされたリンクをリダイレクトする」を参照してください。

このシナリオは直接はサポートされていません。 このシナリオで使用できるオプションは次のとおりです。

1. ワイルドカードを使用して HTTP と HTTPS の両方の URL を個別のアプリケーションとして公開し、それぞれに異なるカスタム ドメインを指定します。 この構成は、外部 URL が異なるため機能します。

2. ワイルドカード アプリケーションを使用して HTTPS URL を公開します。 次のアプリケーション プロキシの PowerShell コマンドレットを使用して、HTTP アプリケーションを個別に公開します。

   • アプリケーション プロキシ アプリケーションの管理
   • プライベート ネットワーク コネクタの管理