Azure AD アプリケーション プロキシ コネクタを理解する

  • [アーティクル]

コネクタとは、Azure AD アプリケーション プロキシを実行可能にするもののことです。 シンプルで、デプロイと管理が簡単なうえに、非常に強力です。 この記事では、コネクタの詳細と動作、およびデプロイを最適化する方法の推奨事項について説明します。

アプリケーション プロキシ コネクタとは

コネクタは、オンプレミスにある軽量エージェントで、アプリケーション プロキシ サービスへの送信接続を容易にします。 コネクタは、バックエンド アプリケーションへのアクセス権を持つ Windows Server にインストールする必要があります。 コネクタはコネクタ グループに編成でき、各グループが特定のアプリケーションへのトラフィックを処理します。 アプリケーション プロキシの詳細と、アプリケーション プロキシ アーキテクチャの図解については、「Azure AD アプリケーション プロキシを使用してリモート ユーザー向けにオンプレミス アプリを発行する」を参照してください。

要件とデプロイ

アプリケーション プロキシを正常にデプロイするには、少なくとも 1 つのコネクタが必要ですが、回復性向上のために 2 つ以上のコネクタを使うことをお勧めします。 Windows Server 2012 R2 以降が実行されているマシンにコネクタをインストールします。 コネクタは、アプリケーション プロキシ サービスおよび公開するオンプレミス アプリケーションと通信する必要があります。

Windows Server

Windows Server 2012 R2 以降が実行されていて、アプリケーション プロキシ コネクタをインストールできるサーバーが必要です。 サーバーは、Azure 内のアプリケーション プロキシ サービスと、公開するオンプレミス アプリケーションに接続する必要があります。

アプリケーション プロキシ コネクタをインストールするには、サーバーで TLS 1.2 が有効になっている必要があります。 サーバー上で TLS 1.2 を有効にするには、次の手順に従います。

  1. 次のレジストリ キーを設定します。

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001

  2. サーバーを再起動します

コネクタ サーバーのネットワーク要件の詳細については、アプリケーション プロキシの概要とコネクタのインストールに関するページをご覧ください。

メンテナンス

コネクタとサービスは、高可用性のすべてのタスクに対処します。 コネクタは動的に追加したり削除できます。 新しい要求は、受信するたびにその時点で使用できるコネクタのいずれかにルーティングされます。 コネクタは、一時的に使用できない場合はトラフィックに応答しません。

コネクタはステートレスであり、コンピューター上に構成データはありません。 保存されているデータは、サービスに接続するための設定とその認証証明書のみです。 サービスに接続すると、すべての必要な構成データをプルして、数分ごとに更新します。

また、コネクタはサーバーをポーリングして、新しいバージョンのコネクタがあるかどうかを調べます。 新しいバージョンが見つかると、コネクタは自身を更新します。

イベント ログとパフォーマンス カウンターを使用して、コネクタを実行しているコンピューターからコネクタを監視することができます。 または、Azure Portal のアプリケーション プロキシ ページからその状態を表示できます。

例:Azure AD アプリケーション プロキシ コネクタ

使用されていないコネクタを手動で削除する必要はありません。 コネクタが動作してサービスに接続すると、アクティブな状態が保たれます。 使用していないコネクタは 非アクティブ としてタグ付けされ、非アクティブな状態が 10 日間続くと削除されます。 コネクタをアンインストールする場合は、コネクタ サービスと更新サービスの両方をサーバーからアンインストールします。 コンピューターを再起動して、サービスを完全に削除します。

自動更新

Azure AD では、デプロイしたすべてのコネクタの自動更新を提供します。 アプリケーション プロキシ コネクタ アップデーター サービスを実行している限り、コネクタは自動的に最新のメジャー コネクタ リリースを使用して更新されます。 サーバーにコネクタ アップデーター サービスが見つからない場合は、コネクタを再インストールして更新プログラムを取得する必要があります。

お使いのコネクタの番まで自動更新を待てない場合は、手動アップグレードを実行できます。 コネクタが配置されたサーバーのコネクタ ダウンロード ページに移動し、 [ダウンロード] を選択します。 このプロセスによって、ローカル コネクタのアップグレードが開始されます。

複数のコネクタを持つテナントの場合、環境でのダウンタイムを避けるために、自動更新では各グループで一度に 1 つのコネクタが対象となります。

コネクタの更新を行う際、次のような場合ダウンタイムが生じることがあります。

  • コネクタが 1 つしかない場合。2 つ目のコネクタをインストールして、コネクタ グループを作成することをお勧めします。 これにより、ダウンタイムを回避して、より高い可用性を提供します。
  • 更新の開始時にコネクタがトランザクションの処理中であった場合: 初期トランザクションは失われますが、ブラウザーにより自動で操作が再試行されます。ページを更新しても構いません。 要求が再送信されると、トラフィックはバックアップ コネクタへルーティングされます。

過去にリリースされたバージョンと変更履歴については、アプリケーション プロキシのバージョン リリース履歴に関するページを参照してください。

コネクタ グループの作成

コネクタ グループは、特定のアプリケーションに対応する特定のコネクタを割り当てることのできる機能です。 多数のコネクタを 1 つにグループ化したうえで、それぞれのアプリケーションをグループに割り当てることができます。

コネクタ グループによって大規模なデプロイが管理しやすくなります。 また、ローカル アプリケーションにのみサービスを提供する位置ベースのコネクタ グループを作成できるため、さまざまなリージョンでアプリケーションのホストとなっているテナントの待ち時間が改善されます。

コネクタ グループの詳細については、「コネクタ グループを使用して別のネットワークや場所にアプリケーションを発行する」をご覧ください。

容量計画

予想されるトラフィック ボリュームを処理するための十分な容量をコネクタ間に確実に計画していることが重要です。 高可用性とスケールを実現するために、各コネクタ グループには少なくとも 2 つのコネクタを用意することをお勧めします。 任意の時点でコンピューターにサービスを提供する必要がある場合は、3 つのコネクタを用意するのが最適です。

一般的に、ユーザー数が多いほど、大規模なマシンが必要になります。 以下の表は、さまざまなマシンが処理できるボリュームと予想される待機時間の概要を示しています。 使用パターンはさまざまで、負荷の予測には使用できないため、ユーザーあたりのトランザクション数ではなく、期待される 1 秒あたりのトランザクション数 (TPS) に基づいていることに注意してください。 また、応答のサイズとバックエンド アプリケーションの応答時間によっても、違いが出てきます。応答のサイズが大きくなり、応答時間が遅くなるほど、最大 TPS は低くなります。 マシン間で分散される負荷に常に十分なバッファーが提供されるように、マシンを追加することもお勧めします。 余剰の容量によって、高可用性と回復性を確実に備えることができます。

コア RAM 予想される待機時間 (ミリ秒) - P99 最大 TPS
2 8 325 586
4 16 320 1150
8 32 270 1190
16 64 245 1200*

* このマシンでは、既定の接続制限の一部を .NET の推奨設定を超えて引き上げるために、カスタム設定を使用しました。 お使いのテナントでこの上限値を変更する場合は、サポートに連絡する前に、既定の設定でテストを実行することをお勧めします。

注意

4、8、および 16 コアのマシンの間で、最大 TPS に大きな違いはありません。 これらのマシンで主に違うのは、予想される待機時間です。

この表はまた、インストールされているコンピューターの種類に基づいたコネクタの予測されるパフォーマンスに焦点を絞っています。 これは、アプリケーション プロキシ サービスの調整制限とは別です。サービスの制限と制約に関するページを参照してください。

セキュリティとネットワーク

コネクタは、アプリケーション プロキシ サービスに要求を送信することを許可するネットワーク上の任意の場所にインストールできます。 ただし、コネクタを実行するコンピューターもアプリにアクセスできる必要があります。 企業ネットワーク内またはクラウドで実行されている仮想マシンにもコネクタをインストールできます。 コネクタは、非武装地帯 (DMZ) とも呼ばれる境界ネットワーク内で実行できますが、すべてのトラフィックはアウトバウンドであり、ネットワークはセキュリティで保護された状態が保たれるため、これは必須ではありません。

コネクタは送信要求を送信するだけです。 送信トラフィックは、アプリケーション プロキシ サービスと公開済みアプリケーションに送信されます。 セッションが確立するとトラフィックは両方向に流れるため、受信ポートを開く必要はありません。 また、ファイアウォール経由での受信アクセスを構成する必要はありません。

送信トラフィックのファイアウォール規則を構成する方法の詳細については、「既存のオンプレミス プロキシ サーバーと連携する」をご覧ください。

パフォーマンスと拡張性

アプリケーション プロキシ サービスではスケールについてユーザーが気にする必要はありませんが、コネクタに関してはスケールが重要な要因になります。 ピーク時のトラフィックを処理するには十分なコネクタが必要です。 コネクタはステートレスであるため、ユーザー数やセッション数の影響を受けません。 その代わりに、要求数やペイロード サイズに反応します。 標準的な Web トラフィックの場合、平均的なコンピューターでは 1 秒間に数千件の要求を処理されます。 具体的な容量は、実際のコンピューターの特性によって異なります。

コネクタのパフォーマンスは、CPU とネットワークの制約を受けます。 TLS による暗号化と暗号化解除には CPU のパフォーマンスが必要であり、Azure でアプリケーションとオンライン サービスへの高速接続を実現するにはネットワークが重要です。

これに対し、コネクタにとってメモリはあまり重要ではありません。 処理の大半はオンライン サービスによって行われ、すべての認証されていないトラフィックが処理されます。 クラウドでできることはすべてクラウドで実行しています。

何らかの理由でコネクタまたはマシンが利用できなくなったら、トラフィックはグループ内の他のコネクトに移動し始めます。 この回復性も、複数のコネクタを推奨する理由です。

パフォーマンスに関するその他の要因としては、コネクタと次の項目間のネットワークの品質が挙げられます。

  • オンライン サービス:Azure のアプリケーション プロキシ サービスへの接続が遅いまたは待機時間が長いと、コネクタのパフォーマンスに影響します。 最高のパフォーマンスを実現するには、Express Route を使用して組織を Azure に接続します。 それ以外の場合は、ネットワーク チームに、Azure への接続が可能な限り効率的に処理されるように依頼してください。
  • バックエンド アプリケーション:コネクタとバックエンド アプリケーション間にプロキシが追加されていて、接続が遅くなったり、接続できなくなったりする場合があります。 このシナリオをトラブルシューティングするには、コネクタ サーバーからブラウザーを開き、アプリケーションにアクセスします。 コネクタを Azure で実行し、アプリケーションはオンプレミスで実行している場合は、ユーザーが期待するほどのエクスペリエンスが得られないことがあります。
  • ドメイン コントローラー:コネクタでは、Kerberos の制約付き委任を使用してシングル サインオン (SSO) を実行する場合、バックエンドに要求を送信する前にドメイン コントローラーに接続します。 コネクタには Kerberos チケットのキャッシュがありますが、ビジー状態では、ドメイン コントローラーの応答性がパフォーマンスに影響することがあります。 こうした問題は、コネクタを Azure で実行していながらオンプレミスのドメイン コントローラーと通信している場合によく見られます。

ネットワークの最適化の詳細については、「Azure Active Directory アプリケーション プロキシを使用する場合のネットワーク トポロジに関する注意事項」をご覧ください。

ドメイン参加

コネクタは、ドメインに参加していないコンピューターで実行できます。 ただし、統合 Windows 認証 (IWA) を使用するアプリケーションへのシングル サインオン (SSO) が必要な場合は、ドメイン参加済みマシンが必要です。 この場合、コネクタを実行するコンピューターは、公開済みアプリケーションのユーザーの代わりに Kerberos の制約付き委任を実行できるドメインに参加する必要があります。

コネクタは、部分的な信頼関係のあるフォレスト内のドメイン、または読み取り専用ドメイン コントローラーに参加することもできます。

制限の厳しい環境でのコネクタのデプロイ

通常、コネクタのデプロイはとても簡単で、特別な構成は必要ありません。 ただし、考慮すべき特別な条件がいくつかあります。

  • 送信トラフィックを制限している組織では、必要なポートを開く必要があります。
  • FIPS に準拠しているコンピューターは、コネクタ プロセスが証明書を生成して保存することを許可するよう、構成を変更する必要のある場合があります。
  • ネットワーク要求を発行するプロセスに基づいて環境をロック ダウンしている組織では、コネクタ サービスとコネクタ アップデーター サービスの両方が、すべての必要なポートと IP アドレスにアクセスできることを確認する必要があります。
  • 場合によっては、送信/転送プロキシにより証明書の双方向認証が中断されて、通信に失敗することがあります。

コネクタの認証

セキュリティで保護されたサービスを提供する場合、コネクタはサービスに対して認証を行い、サービスはコネクタに対して認証を行う必要があります。 この認証を実行するには、コネクタが接続を開始するときにクライアント証明書とサーバー証明書を使用します。 こうすることで、管理者のユーザー名とパスワードがコネクタを実行するコンピューターに保存されることはありません。

使用する証明書は、アプリケーション プロキシ サービス固有のものです。 これらの証明書は新規登録時に作成され、コネクタによって数か月ごとに自動で更新されます。

証明書の更新に初めて成功した後、Azure AD アプリケーション プロキシ コネクタ サービス (ネットワーク サービス) には、ローカル コンピューター ストアから古い証明書を削除するアクセス許可がありません。 証明書の有効期限が切れている場合、またはサービスによって使用されなくなった場合は、証明書を安全に削除することができます。

証明書の更新に関する問題を回避するには、コネクタからドキュメントに記載されている送信先までのネットワーク通信が有効になっていることを確認します。

コネクタが数か月間サービスに接続していないと、証明書の有効期限が切れることがあります。 このような場合は、コネクタをアンインストールしてから再インストールして、登録をトリガーします。 次の PowerShell コマンドを実行できます。

Import-module AppProxyPSModule
Register-AppProxyConnector -EnvironmentName "AzureCloud"

政府機関の場合は、-EnvironmentName "AzureUSGovernment" を使用します。 詳細については、「Azure Government クラウド用にエージェントをインストールする」を参照してください。

証明書の検証と問題のトラブルシューティングの方法について詳しくは、「コンピューターとバックエンド コンポーネントでアプリケーション プロキシ信頼証明書がサポートされていることを確認する」を参照してください。

しくみ

コネクタは Windows Server の Web アプリケーション プロキシをベースとしているため、Windows イベント ログや

イベント ビューアーを使用したイベント ログの管理

Windows パフォーマンス カウンターなど、同じ管理ツールのほとんどが備わっています。

パフォーマンス モニターを使用したコネクタへのカウンターの追加

コネクタには管理者ログとセッション ログがあります。 管理者ログには主要なイベントとそのエラーが含まれます。 セッション ログには、すべてのトランザクションとその処理の詳細が含まれます。

ログを表示するには、イベント ビューアーを開き、 [アプリケーションとサービス ログ]>[Microsoft]>[AadApplicationProxy]>[コネクタ] の順に移動します。 セッション ログを表示するには、 [表示] メニューの [分析およびデバッグ ログの表示] を選択します。 通常、セッション ログはトラブルシューティングに使用され、既定では無効になっています。 イベントの収集を開始するときに有効にし、その後、不要になったら無効にしてください。

[サービス] ウィンドウでサービスの状態を確認することができます。 コネクタは、実際のコネクタとアップデーターという、2 つの Windows サービスで構成されています。 この両方を常に実行する必要があります。

例:Azure AD サービスのローカルを示す [サービス] ウィンドウ

次のステップ