Microsoft Entra アプリケーション プロキシ内のワイルドカード アプリケーション

Microsoft Entra ID では、大量のオンプレミス アプリケーションを構成すると、すぐに管理できなくなる可能性があります。また、それらのアプリケーションの多数で同じ設定が必要な場合に構成エラーが発生する不要なリスクが生じます。 Microsoft Entra アプリケーション プロキシでは、ワイルドカード アプリケーション発行を使用して多数のアプリケーションを同時に発行および管理し、この問題を解決できます。 このソリューションでは、以下が可能になります。

• 管理オーバーヘッドを軽減する
• 潜在的な構成エラーの数を減少させる
• ユーザーがより多くのリソースに安全にアクセスできるようにする

この記事では、ご利用の環境でワイルドカード アプリケーション発行を構成するために必要な情報を提供します。

ワイルドカード アプリケーションの作成

構成が同じアプリケーションのグループがある場合、ワイルドカード (*) アプリケーションを作成できます。 ワイルドカード アプリケーションの候補として考えられるのは、次の設定を共有しているアプリケーションです。

• それらへのアクセス権を持つユーザーのグループ
• SSO 方法
• アクセス プロトコル (http、https)

内部 URL と外部 URL の両方が次の形式の場合、ワイルドカードでアプリケーションを発行できます。

http(s)://*.<ドメイン>

(例: http(s)://*.adventure-works.com)。

内部 URL と外部 URL には異なるドメインを使用できますが、同じドメインにすることがベスト プラクティスとして推奨されます。 アプリケーションの発行時、いずれかの URL にワイルドカードがないとエラーが表示されます。

ワイルドカード アプリケーションの作成は、他のすべてのアプリケーションで使用できるのと同じアプリケーション発行フローに基づきます。 唯一の違いは、URL にワイルドカードを含めることだけです。場合によっては SSO 構成にもワイルドカードを含めます。

前提条件

開始するには、これらの要件を満たしていることを確認してください。

カスタム ドメイン

カスタム ドメインは他のすべてのアプリケーションではオプションですが、ワイルドカード アプリケーションでは前提条件です。 カスタム ドメインの作成には以下が必要です。

1. Azure 内で確認済みドメインを作成する。
2. PFX 形式の TLS/SSL 証明書をアプリケーション プロキシにアップロードする。

作成する予定のアプリケーションに一致するワイルドカード証明書を使用することを検討する必要があります。

セキュリティ上の理由から、これは厳格な要件になっています。外部 URL にカスタム ドメインを使用できないアプリケーションのワイルドカードはサポートされません。

DNS の更新

カスタム ドメインを使用する場合、アプリケーション プロキシ エンドポイントの外部 URL を指す外部 URL 用の CNAME レコードで DNS エントリ (例: *.adventure-works.com) を作成します。 ワイルドカード アプリケーションでは、CNAME レコードが関連する外部 URL を指す必要があります。

<yourAADTenantId>.tenant.runtime.msappproxy.net

CNAME を正しく構成したことを確認するには、いずれかのターゲット エンドポイントで nslookup を使用できます (例: expenses.adventure-works.com)。 応答には、既に述べたエイリアス (<yourAADTenantId>.tenant.runtime.msappproxy.net) が含まれます。

既定のリージョン以外のアプリケーション プロキシ クラウド サービス リージョンに割り当てられているコネクタ グループを使用する

既定のテナント リージョンとは異なるリージョンにコネクタがインストールされている場合、これらのアプリケーションへのアクセスのパフォーマンスを向上させるには、コネクタ グループをどのリージョンに対して最適化するかを変更すると有益です。 詳細については、「最も近いアプリケーション プロキシ クラウド サービスを使用するようにコネクタ グループを最適化する」を参照してください。

ワイルドカード アプリケーションに割り当てられているコネクタ グループが既定のリージョンとは異なるリージョンを使用している場合は、CNAME レコードを更新して、地域固有の外部 URL を指定する必要があります。 次の表を使用して、関連する URL を決定します。

考慮事項

ワイルドカード アプリケーションに対して考慮する必要があるいくつかの考慮事項を次に示します。

許容される形式

ワイルドカード アプリケーションでは、内部 URL は http(s)://*.<domain> の形式である必要があります。

外部 URL を構成する際は、https://*.<custom domain> の形式を使用する必要があります。

他の位置のワイルドカード、複数のワイルドカード、または他の正規表現文字列はサポートされておらず、エラーの原因になります。

ワイルドカードからのアプリケーションの除外

次の方法で、ワイルドカード アプリケーションからアプリケーションを除外できます

• 例外アプリケーションを通常のアプリケーションとして発行する
• DNS 設定を通じて、特定のアプリケーションに関してのみワイルドカードを有効にする

アプリケーションを通常のアプリケーションとして発行することは、ワイルドカードからアプリケーションを除外する際に推奨される方法です。 除外されるアプリケーションをワイルドカード アプリケーションの前に発行する必要があります。これにより、最初から例外が適用されます。 最も固有なアプリケーションは常に優先されます。budgets.finance.adventure-works.com として発行されたアプリケーションは、アプリケーション *.finance.adventure-works.com より優先されます。そして、このアプリケーションはアプリケーション *.adventure-works.com より優先されます。

DNS 管理を通じて、特定のアプリケーションに対してのみ機能するようワイルドカードを制限することもできます。 ワイルドカードが含まれており、構成した外部 URL の形式に一致する CNAME エントリを作成することがベスト プラクティスとして推奨されます。 ただし、代わりに特定のアプリケーション URL でワイルドカードを指すこともできます。 たとえば、*.adventure-works.com の代わりに hr.adventure-works.com、expenses.adventure-works.com、travel.adventure-works.com individually で 00001111-aaaa-2222-bbbb-3333cccc4444.tenant.runtime.msappproxy.net を指します。

このオプションを使用する場合、同じ場所を指している、値 AppId.domain の別の CNAME エントリ (たとえば 00001111-aaaa-2222-bbbb-3333cccc4444.adventure-works.com) も必要です。 AppId は、ワイルドカード アプリケーションのアプリケーション プロパティ ページにあります。

MyApps パネルのホームページ URL の設定

MyApps パネルでは、ワイルドカード アプリケーションが単一のタイルで表されます。 既定では、このタイルは非表示です。 タイルを表示してユーザーを特定のページに到達させるには:

1. ホームページ URL の設定に関するガイドラインに従います。
2. アプリケーション プロパティ ページで [Show Application](アプリケーションの表示) を true に設定します。

Kerberos の制約付き委任

Kerberos の制約付き委任 (KCD) を SSO 方法として使用しているアプリケーションでは、SSO 方法に関してリストされる SPN にはワイルドカードが必要です。 たとえば、SPN は HTTP/*.adventure-works.com などになります。 さらに、バックエンド サーバーで個別の SPN を構成する必要があります (例: HTTP/expenses.adventure-works.com and HTTP/travel.adventure-works.com)。

シナリオ 1:一般的なワイルドカード アプリケーション

このシナリオでは、発行したい異なる 3 つのアプリケーションがあります。

• expenses.adventure-works.com
• hr.adventure-works.com
• travel.adventure-works.com

3 つのアプリケーションはすべて、

• 全ユーザーによって使用されます
• "統合 Windows 認証" を使用します
• プロパティが同じです

「Microsoft Entra アプリケーション プロキシを使用してアプリケーションを発行する」で説明されている手順を使用して、ワイルドカード アプリケーションを発行できます。 このシナリオは以下を前提とします。

• ID が aaaabbbb-0000-cccc-1111-dddd2222eeee のテナント
• adventure-works.com という名前の確認済みドメインが構成されている。
• *.adventure-works.com が 00001111-aaaa-2222-bbbb-3333cccc4444.tenant.runtime.msappproxy.net を指す CNAME エントリが作成されている。

文書化されている手順に従って、新しいアプリケーション プロキシ アプリケーションをテナントに作成します。 この例では、ワイルドカードが次のフィールド内にあります。

• 内部 URL:

  

• 外部 URL:

  

• 内部アプリケーション SPN:

  

ワイルドカード アプリケーションを発行することで、良く知っている URL に移動して 3 つのアプリケーションにアクセスできるようになりました (travel.adventure-works.com など)。

この構成では次の構造が実装されます。

シナリオ 2: 一般的なワイルドカード アプリケーション (例外あり)

このシナリオでは、3 つの一般的なアプリケーションに加えてもう 1 つアプリケーション (finance.adventure-works.com) を用意します。これは、財務部門のみがアクセスできるようにする必要があります。 現在のアプリケーション構造では、ワイルドカード アプリケーションを通じてすべての従業員が財務アプリケーションにアクセスできます。 これを変更するため、財務をアクセス許可の制限が強い別個のアプリケーションとして構成して、ワイルドカードからアプリケーションを除外します。

finance.adventure-works.com が (アプリケーション用のアプリケーション プロキシ ページで指定された) 特定のアプリケーション エンドポイントを指す CNAME レコードを用意する必要があります。 このシナリオでは、finance.adventure-works.com が https://finance-awcycles.msappproxy.net/ を指します。

文書化された手順に従うと、このシナリオには以下の設定が必要です。

• 内部 URL で、ワイルドカードの代わりに finance を設定します。

  

• 外部 URL で、ワイルドカードの代わりに finance を設定します。

  

• 内部アプリケーション SPN で、ワイルドカードの代わりに finance を設定します。

  

この構成では次のシナリオが実装されます。

finance.adventure-works.com は固有の URL です。 *.adventure-works.com は固有の URL ではありません。 固有の URL の方が優先されます。 finance.adventure-works.com に移動するユーザーには、財務リソースのアプリケーションで指定されたエクスペリエンスが表示されます。 この場合、finance.adventure-works.com にアクセスできるのは財務関連の従業員のみです。

財務用に発行された複数のアプリケーションがあり、finance.adventure-works.com が確認済みドメインとしてある場合、別のワイルドカード アプリケーション *.finance.adventure-works.com を発行できます。 これは汎用の *.adventure-works.com よりも具体的であるため、ユーザーが finance ドメインのアプリケーションにアクセスする際に優先されます。

次のステップ

• カスタム ドメインの詳細については、「アプリケーション プロキシでのカスタム ドメインの使用」を参照してください。
• アプリケーションの発行の詳細については、「Microsoft Entra アプリケーション プロキシを使用したアプリケーションの発行」を参照してください