私たちエンジニアにとって、新しいFirePOWERバージョンに注目することは本当に嬉しいことです。 次のリリースノートを開くたびに、息を切らして（場合によっては完全に停止して）、開発者によって追加された新機能を調査します。
待望の革新の1つは、
Cisco Terminal Server Agent （以降TS Agent）です。 これは、ターミナルサーバーユーザー（以下TSと呼びます）の正しい認証を目的としています。 この記事では、なぜそれが必要なのか、どのように機能するのかを説明します。
TSでの認証の問題は、FirePOWERなどのほとんどのソリューションで、すべてのTSユーザーに同じIPアドレスで動作することです。
たとえば、VasilyとPeterは同時にターミナルサーバーで作業します。 会社の規則に従って、Vasily socialにアクセスできます。 ネットワーク、ピート-いいえ。 ITUは、IPアドレス以外の追加情報なしでは、VasilyとPeterのトラフィックを相互に分離できません。 したがって、どちらの従業員も社会サービスへのアクセスを拒否されます。 ネットワーク、またはその両方が許可されます。
問題を解決するにはさまざまな方法があります。 たとえば、車両でIP仮想化テクノロジーを使用する「松葉杖」オプション。 この場合、車両上の各新しいセッションには一意のIPアドレスが割り当てられます。 しかし、このアプローチには多くの微妙な違いがあることに注意してください。
Cisco WSA Webプロキシには、セッションCookieの概念が導入されています。 セッションCookieからの情報のおかげで、WSAは同じIPアドレスを持つユーザーを区別できます。 ただし、欠点があります。Cookieはブラウザセッションでのみ使用できます。 Cookieをサポートしないアプリケーション（Skype、TeamViewerなど）は機能しません。
TSにインストールされたエージェントを使用することは、問題を解決する最も一般的な方法です。 Identity Agentは、Checkpointソリューション用に長い間存在していました。 ついに、CiscoはFirePOWERに基づいた同様のITUソリューションを導入しました。 発表は2016年8月29日に行われました（これについては、ここUPD（09/02/2016）で言及しました）。 しかし、エージェントは2017年1月26日にのみダウンロード可能になりました。FirePOWERManagement Center（FMC、FirePOWER管理システム）バージョン6.1の公式リリースノートから、ターミナルエージェントに関する情報は削除され、6.2のリリースノートに移行されました。 したがって、端末エージェントはバージョン6.2以降のFMCでサポートされています。
エージェントはどのように機能しますか？
アイデアはスリッパと同じくらい簡単です。 TSユーザーごとに、起動されたセッションのソースtcp / udpポートが特定のポートプールに変換されます。 はい、はい、放送されています。 PATが発生します。 サーバーにエージェントをインストールすると、tcp / udpポートの変換を処理する特別な低レベルドライバーが追加されます。
ユーザーとポートのプールのマッピングに関する情報は、REST APIを介してFMC（FirePOWER Management Center）コントロールパネルに転送されます。
エージェントは、インストールexeファイルとしてcisco.comからダウンロードされます。 TSへのインストール後、エージェント設定ウィンドウが開きます。
ここでは、サーバーを同時に使用できるユーザー数を設定できます（最大ユーザーセッション）。 このバージョンのエージェントでは、199ユーザーが最大です。
サーバーのネットワークカードと、変換に使用できるポートと使用できないポートを選択します。
システムを機能させるには、FMCのIPアドレスとREST VDIを使用する権限を持つユーザーを指定する必要があります。 デフォルトでは、次のユーザーロールに権限があります。
FMCでエージェント用に別のロールを作成できます。これはテスト用に行いました。
[システム]タブ-> [ユーザー]-> [ユーザーロール]。 [ユーザーロールの作成]をクリックします。
「VDIの残り」サブメニューから選択します。
次に、ts-agentユーザーを作成し、新しく作成したTSエージェントの役割を割り当てます。 [ユーザー]タブで、[ユーザーの作成]をクリックします。
エージェントに戻り、FMCのIPアドレス、ユーザーts-agentおよびパスワードを入力します。 [テスト]をクリックします。
保存をクリックします。 微妙な違いがあります。エージェントはサーバーの再起動を要求します。 何もすることはありません、私たちは魂のない機械の意志に従います。 ところで（またはところで）、エージェントの設定を変更するには、再起動も必要です。
すべて準備完了です。 何が起こったかを確認できます。 FMCの2つのアクセスルールを作成しましょう。 最初のルールは、AD「IT部門」のグループに対するもので、インターネットへのフルアクセスを許可します。 2番目のルールは、他のすべてのユーザー用です。 このルールに従って、ソーシャルサービスへのアクセスをブロックします。 ネットワーク。 セットアップ：
ハードウェアでは2人のユーザーが管理しています。 「Uskov」の最初のユーザーはIT部門グループのメンバーです。 2番目のユーザー「Vasiliy」はIT部門の一部ではありません。 したがって、「Uskov」は社会に行くことが許可されます。 「Vasiliy」のネットワーク-禁止されています。 確認します。
Uskovの場合：
Vasiliyの場合：
ふう、チスコデラをだまさなかった、うまくいく！ ログを見てみましょう。 エージェントは、ユーザーに発行されるポート範囲を示します。
FMCの[分析]→[ユーザー]→[ユーザーアクティビティ]タブで、ポート情報が表示されました。
すべてが意図したとおりに機能します。
どのエージェントがインストールされているか
- Windows Server 2008 R2
- Windows Server 2012
- Windows Server 2012 R2
次の仮想化システムがサポートされています。
- Citrix XenDesktop
- Citrix XenApp
- Xen Project Hypervisor
- VMware vSphere Hypervisor / VMware ESXi 6.0
- Windowsターミナルサービス/ Windowsリモートデスクトップサービス（RDS）
エージェントの最初のバージョン（1.0.0-36）の制限と注意事項
- 車両上の最大199ユーザー。
- 使用できるTSネットワークカードは1つだけです。
- 車両の時刻はFMCの時刻と同期する必要があります。
- FMCでは、TSエージェントから受信したユーザー情報は、他のパッシブ認証ソースであるユーザーエージェントとCisco ISEからの情報よりも高くなっています。 これは論理的であり、そうでなければ奇跡はありません。 アクティブ認証はTSエージェントとペアにしないでください。