よくある質問:Citrix Secure Gateway/NetScaler Gateway Secure Ticket Authority

Posted on by admin

注:同じ原則と概念がNetScaler Gatewayにも適しています。

この記事では、Citrix Secure Ticket Authority(STA)に関するよくある質問に回答します。 質問は次の4つのカテゴリに分かれています。

概要

Q:安全なチケット認証局とは何ですか?
Q:Staと対話するCitrix製品は何ですか?
Q:STAが必要なのはなぜですか？
Q:STAサービスはどのように実装されていますか？
: IISを必要としないSTAのバージョンはありますか？
Q:STAサーバーはどこにありますか?
Q:STAの異なるバージョンの違いは何ですか？

セキュリティ

Q:STAチケットはどのように生成されますか?
Q:STAチケットは何を構成しますか？
Q:チケットはワークステーションに対して検証されますか？
Q:チケットは使用後に削除されますか？
Q:チケットはSTAでディスクに書き込まれますか？
Q:誰かがチケットをハイジャックすることは可能ですか？
Q:SSLでSTAトラフィックを保護するにはどうすればよいですか?
: STAは常に完全修飾ドメイン名を使用してアドレス指定する必要がありますか？
Q:STAポートを80から他のものに変更するにはどうすればよいですか?
Q:攻撃者はゲートウェイにランダムなチケットを送信してログオンできますか?
Q:有効なSTAチケット以外のログオンには、他にどのような情報が必要ですか？
Q：STAチケットの有効期限を設定するにはどうすればよいですか？

スケーラビリティ

Q:どのように多くのStaが必要ですか?
: ユーザーは午前中にゲートウェイを介してログオンし、単一の公開されたアプリケーションを一日中実行しますか、または一日を通して複数のアプリケー
Q:STAフォールトトレランスを確保するにはどうすればよいですか?
Q:複数のStaをロードバランスするにはどうすればよいですか?
Q:Microsoftネットワーク負荷分散で複数のStaを使用できますか?
Q:単一のSTAを複数のファーム、ゲートウェイ、および列挙サーバーと共有できますか?Q:STAをホストするようにIISをどのように設定する必要がありますか?
Q:STAでロギングを有効にするにはどうすればよいですか?
: Microsoft IISLockDownツールがSTAを壊すのはなぜですか？
Q:STAが正常に動作していることを確認するにはどうすればよいですか?
Q:STAログファイルはどのように解釈されますか?
Q:Citrixテクニカルサポートで見られる一般的な構成エラーの一部は何ですか?

概要

Q:セキュアチケットオーソリティとは何ですか？

A:Secure Ticket Authority(STA)は、ランダムに生成されたチケットのXenAppサーバー情報を交換するXML webサービスです。 これは、Citrix Secure Gatewayサーバーのアクセスを制御するために使用されます。

Q:Staと対話するCitrix製品は何ですか?

A:XenMobile、Webインターフェイス、StoreFront、XenApp Secure Access Manager、NetScaler Gateway、およびCitrix Secure GatewayはSTAと相互作用します。 この記事では、次の種類のサーバーを、アプリケーション列挙サーバーと呼ばれる単一のカテゴリにグループ化しています:

  • Web Interface2.0以降
  • Secure Access Manager2.0以降
  • StoreFront
  • アプリケーション列挙サーバーは、ユーザーの認証、公開されたアプリケーションアイコンの列挙、およびSecure Gatewayサーバーを介して公開されたアプリケーション

Q:STAが必要なのはなぜですか？

A:Citrix Secure Gateway展開では、ゲートウェイサーバーは受信要求の認証を実行しません。 代わりに、ゲートウェイサーバーはアプリケーション列挙サーバーに認証を延期し、STAを使用して各ユーザーが認証されることを保証します。 Application enumerationサーバーは、Webサーバーに対して既に認証されているユーザーに対してのみチケットを要求します。 ユーザーが有効なSTAチケットを持っている場合、ゲートウェイは、webサーバーでの認証チェックに合格したと想定し、アクセスを許可する必要があります。

この設計により、Citrix Secure Gatewayサーバーはwebサーバー内の任意の認証方法を継承できます。 たとえば、Web InterfaceサーバーがRSA SecurIDで保護されている場合、設計上、Securidで認証されたユーザーのみがSecure Gatewayサーバーをトラバースできます。Q:STAサービスはどのように実装されていますか?

A:STAは、Microsoft Internet Information Services(IIS)用のISAPI拡張機能として記述されています。 拡張子はCtxStaと呼ばれます。dllは、デフォルトで/Scriptsフォルダにホストされています。 他のコンポーネントは、HTTPを介してXMLを使用してSTAと通信します。

ユーザー追加イメージ

アプリケーション列挙サーバーは、チケット要求の一部としてSTAにデータを送信することにより、アプリケーションの起動時にチケッ STAに送信されるデータには、ユーザーが接続するXenAppサーバーのアドレス、およびWeb Interface2.0およびSecure Access Manager2.0の場合は、現在のユーザーの名前およびユーザーが実行する公開 STAは、チケットを生成し、それをアプリケーション列挙サーバーに送り返すことによって応答します。 このチケットおよびそれに対応するデータは、設定可能な秒数（デフォルトでは100）の間、STAのメモリに残ります。
アプリケーション列挙サーバーは、ユーザー用のICAファイルを作成し、ICAファイルのアドレスフィールドにSTAチケットを挿入します。 クライアントがSecure Gatewayに接続すると、チケットが提示され、ゲートウェイはクライアントのセキュリティで保護されたセッションを確立する前にチ ゲートウェイは、チケットをSTAに送り返し、その代わりに対応するデータを要求することによって、データ要求を実行します。 検証に成功すると、STAは元のデータをゲートウェイに転送し、ゲートウェイはエンドユーザーとXenAppサーバー間のリレーを確立します。

チケット要求とデータ要求の両方がXML要求/応答ドキュメントとして実行されます。Q：IISを必要としないSTAのバージョンはありますか？

A:いいえ、現時点ではSTAをホストするにはIISが必要です。 STAは、インターネットのような信頼されていないネットワークに公開する必要はないことに注意してくださ; STAは信頼されたネットワーク上に存在し、ゲートウェイおよびアプリケーション列挙サーバーによってのみアクセスされます。

Q:STAサーバーはどこにありますか?

A:Staサーバーは、Secure Gatewayおよびapplication enumerationサーバーが到達できる限り、任意の場所に配置できます。 STAを信頼されたネットワークまたは内部ファイアウォールの別のレッグに配置することをお勧めしますが、IIS以外のSTAサーバーの要件はありません。 ＳＴＡは、任意のドメイン、Ｘｅｎａｐｐサーバファーム、Ｓｅｃｕｒｅ Ａｃｃｅｓｓ Ｍａｎａｇｅｒファーム、または他の内部ウェブサーバに属する必要はないが、ＳＴＡを別の機能と共有することが一般的である。 STAはSecure Access Manager2.0のセットアップの一部として自動的に含まれます。

Q:STAの異なるバージョン間の違いは何ですか？

A:バージョン1.0と1.1の間に重要な機能上の違いはありませんが、2.0STAをWeb Interface2.0またはSecure Access Manager2で使用する場合。0、拡張情報がチケット要求に追加されます：ユーザーの名前とユーザーが実行したいアプリケーション。 この拡張データは、ゲートウェイサービスによって使用され、Secure Gateway2.0管理コンソールに各ゲートウェイセッションの詳細が表示されます。

Secure Gateway2.0がバージョン1.1または1.0の古いSTAを使用するように構成されている場合、ユーザーはアプリケーションに接続できますが、Secure Gateway管理コンソールには、各ICAセ Secure Gatewayで拡張情報を表示するには2.0管理コンソールでは、STAのバージョン2.0以降を使用し、アプリケーション列挙サーバーとしてSecure Access Manager2.0またはWeb Interface2.0を使用する必要があります。

セキュリティ

Q:STAチケットはどのように生成されますか?

A:ISAPI拡張子CtxSta。dllは擬似乱数生成を使用して、16バイトの16進文字列を生成します。 セキュリティ上の理由から、Citrixはこのランダムな文字シーケンスを生成するために使用される正確な手順を開示していません。

Q:STAチケットは何を構成しますか？

A:エンコード形式は、

という形式の文字列です。;STA_VERSION;STA_ID;チケット

Where:

  • ＳＴＡ＿ＶＥＲＳＩＯＮは、ＳＴＡのバージョンを識別する数値フィールドである。 現在、このフィールドの有効な値は、STAバージョン1.0および1.1の場合は「10」、STAバージョン2.0の場合は「20」のみです。
  • STA_IDは、管理者によって特定のSTAに割り当てられた任意の名前を表す0–16文字のシーケンスです。 バージョン1で。x、この文字列のデフォルトはSTA01、STA02などです。 StaがSecure Access Manager2.0の一部として自動的にインストールされる場合、STA IDはサーバー名のハッシュになります。 複数のStaが単一のゲートウェイサーバーによって共有される場合、各STA IDは一意である必要があります。 これにより、ゲートウェイはチケットを作成したSTAを検索し、チケットの検証のためにそのSTAに戻ることができます。 STA01で作成されたチケットはSTA02には存在しません。
  • チケットは、32の大文字のアルファベットまたは数字のランダムに生成されたシーケンスです。

    例:
    ;10;STA01;FE0A7B2CE2E77DDC17C7FD3EE7959E79

Q:チケットはワークステーションに対して検証されますか?

A:いいえ、チケットを特定のワークステーションに関連付けるものは何もありません。 このリスクを軽減するには、ワークステーションAからチケットを要求し、ワークステーションBから使用することが理論的に可能です:

  • クライアントとアプリケーション列挙サーバーの間で常にHTTPSを使用して、攻撃者がサーバーからクライアントに移動するときにチケットを傍受するのを防
  • 攻撃者がマシンAからマシンBにチケットを転送するのに必要な時間を減らすために、チケットの生存までの時間を可能な限り短縮します。

STAによって発行されたチケットは一度だけ使用できるので、マシンA上の意図されたユーザーが正常に接続した場合、チケットはマシンaまたはマシンB

A:はい、チケットはデータリクエストが成功した直後に消去されるため、一度だけ使用できます。 また、使用しない場合は、設定可能なタイムアウト（デフォルトは100秒）後に削除されます。

Q:チケットはSTAでディスクに書き込まれますか？

: CtxStaでLogLevel=3を設定して冗長ログが有効になっている場合にのみ。設定。 それ以外の場合、STAは、インメモリデータベースを使用して、すべての未処理のチケット(アプリケーション列挙サーバーによって要求されたが、セキュアゲートウェ XMLデータは常にHTTP POSTコマンドを使用してSTAに送信されるため、意味のあるチケットデータはSTA Webサーバーのログに書き込まれません。

Q:誰かがチケットをハイジャックすることは可能ですか？

A:通常の操作中、チケットはネットワークの次の四つのセグメントを移動する必要があります:

  • STAからアプリケーション列挙サーバーへ
  • アプリケーション列挙サーバーからクライアントへ
  • クライアントからSecure Gatewayサーバーへ
  • ゲートウェイからSTAへ

最初と最後のセグメントは、DMZ内のサーバーと信頼されたネットワーク上のSTAとの間にのみ存在します。侵入者は、それらの線に沿ってチケットを傍受するためにあなたのネットワークにアクセスする必要があります。 それでも、Secure Gatewayバージョン2.0を使用している場合は、これらの経路をSSLで暗号化できます。 Citrix Secure Gatewayでは、1.1以前は、STAへのトラフィックはSSLを使用して暗号化できません。

第二のセグメントを保護するには、アプリケーション列挙Webサーバーに証明書を置き、クライアントがHTTPSを使用する場合にのみ接続できるようにします。 第三のセグメントは、常にSSLで保護されています。

上記のすべてのリンクがSSLで保護されていても、クライアントはクライアントの活動を監視するトロイの木馬プログラムによる攻撃を受け このリスクを軽減するには、ウイルス対策およびトロイの木馬検出ソフトウェアがインストールされているマシンから接続するようにユーザーに

Q:SSLでSTAトラフィックを保護するにはどうすればよいですか?

A:まず、STAをホストするIISのコピーにWebサーバー証明書をインストールします。 詳細については、IISのドキュメントを参照してください。

ゲートウェイとの通信時にHTTPSを使用するようにapplication enumeration serverおよびSecure Gateway serverを構成します。 HTTPSで接続する場合は、常に次のルールを満たす必要があります:

  • STAサーバ証明書のサブジェクトと一致する完全修飾ドメイン名を使用してSTAをアドレス指定する必要があります。
  • STAと通信するマシンは、STAの完全修飾ドメイン名を適切なIPアドレスに解決できる必要があります。
  • STAと通信するマシンは、STAサーバー証明書を発行した認証局(CA)を信頼する必要があります。
  • 第三の箇条書き項目の要件を満たすには、Caルート証明書をSecure Gatewayサーバーとapplication enumerationサーバーにインストールする必要があります。 ルート証明書ファイルをダブルクリックして、証明書のインポートウィザードを実行することはできません。

(これは、サーバーやシステムサービスではなく、ユーザーアカウントがCAを信頼していることを示します。 Citrix Secure GatewayまたはWeb Interfaceで使用するルート証明書をインストールするには、次の手順に従います:

ユーザーが追加した画像

  1. Mmcを実行します。exeを実行し、証明書スナップインを追加します。
  2. どの証明書を管理するかを尋ねられたら、コンピュータアカウントを選択し、ローカルコンピュータを選択します。
  3. 証明書(ローカルコンピュータ)>信頼されたルート証明機関ノードを展開します。 [証明書]を右クリックし、[すべてのタスク>インポート]を選択します。
  4. CAルート証明書を参照して選択し、インポートウィザードを完了します。

Q:STAは常に完全修飾ドメイン名を使用してアドレス指定する必要がありますか?

A:SSLを使用してSTAへのトラフィックを保護する場合は、ゲートウェイサーバーやアプリケーション列挙サーバーを含むSTAにアクセスするコンポーネントは、STA上のIISが使用するサーバー証明書のサブジェクトと一致する完全修飾ドメイン名(FQDN)を使用してSTAをアドレス指定する必要があります。 たとえば、Web Interface2.0では、STAアドレスは次のように入力されます。:STAへのトラフィックを保護しないことを選択した場合は、IPアドレス、ホスト名、またはFQDNを使用してSTAをアドレス指定できます。Q:STAポートを80から他のものに変更するにはどうすればよいですか?

A:STAはIISによって処理されるため、IISポートを変更するときにSTAポートを変更します。 次の例は、IISポートを80から81に変更する方法を示しています。

ユーザー追加画像

  1. インターネットサービスマネージャを開きます。
  2. デフォルトのWebサイトを右クリックし、プロパティを表示します。
  3. [Web site]タブで、TCPポート番号を80から81に変更します。
  4. OKをクリックします。
    上記の変更は、STA Webサーバーから公開した他のリソースにも影響します。 同じWebサーバーでホストされている他のWebページに影響を与えずにSTA通信ポートを変更する場合は、STAをホストするためだけにIISで新しいWebサイトを作成 次に、STAのポート81に新しいWebサイトを作成する方法の例を示します。
  5. Cなどの新しい物理フォルダを作成します:WEBサーバーのハードドライブ上の\MYSTAは、STAサイトのドキュメントルートとして機能します。
  6. スクリプトと呼ばれるMYSTAの下にサブディレクトリを作成します。 既存のSTAから新しいScriptsフォルダ
    • CtxStaに次のファイルを移動します。
    • 設定
    • ctxxmlss.txt
  7. インターネットサービスマネージャを開きます。
  8. サーバー名を右クリックし、新規>Webサイトを選択します。
  9. “My STA site”という新しいWebサイトを作成し、C:\MYSTA ドキュメントルートディレクトリとして。
  10. 新しいwebサイトのプロパティを表示し、TCPポートを81に変更します。
  11. Internet Services ManagerのMY STAサイトの下で、Scriptsフォルダを右クリックしてプロパティを表示します。 “アプリケーション設定”セクションで、”実行権限”を”スクリプトと実行可能ファイル”に変更します。”

注:”Scripts”以外のフォルダ名を選択できますが、Secure GatewayおよびWeb Interfaceなどのすべてのアプリケーション列挙サーバーは、STAが/Scripts/CtxStaとして公開されていると想定していdllなので、これらのサーバーの設定でSTA URLも更新する必要があります。

Q:攻撃者はゲートウェイにランダムなチケットを送信してログオンできますか?

A:攻撃者は有効なチケットを推測し、クライアントが要求してからゲートウェイが要求する前に数ミリ秒以内にそれを償還する必要があります。

Q:有効なSTAチケット以外のログオンには、他にどのような情報が必要ですか？

A:ユーザーには、ドメイン資格情報またはアプリケーション列挙サーバーによって要求されるXenAppサーバーチケットも必要です。 (XenAppサーバーチケットはSTAチケットと同じではありません。）ＳＴＡを満足させることは、特定のサーバのための信頼されたネットワークへのパスのみを開く。 一度そこに、ユーザーはまだ有効なドメイン資格情報で認証する必要があります。
Q：STAチケットの有効期限を設定するにはどうすればよいですか？
場所:HKLM\Software\Citrix\DesktopServer
名前:X M L Staticketlifetimeinseconds
種類:Dword値: Give value in seconds(Decimal)
レジストリ値を編集する前にレジストリのバックアップを取ってください。

Q:何台のStaが必要ですか?

A:STAは、ユーザーがアプリケーションを起動したときにのみアクセスされます。

Q:ユーザーは午前中にゲートウェイを介してログオンし、単一の公開されたアプリケーションを一日中実行しますか、または一日を通して複数のアプリケー

: これは、IISのパフォーマンスによってのみ制限される軽いXMLサービスです。 あるテストでは、1ghzプロセッサと256MBのRAMを搭載した低域サーバーは、毎秒250以上のチケット要求をサポートしましたが、CPU使用率は60％を下回っていました。

Q:STAフォールトトレランスを確保するにはどうすればよいですか?

A:次のアプリケーション列挙サーバーでは、Secure Gatewayのパラメータを構成するときに複数のSTA Urlを入力できます:

  • Web Interface2.0
  • Secure Access Manager2.0
  • StoreFront

いずれの場合も、STAが応答に失敗した場合、アプリケーション列挙サーバーはリスト上の別のSTAを試行します。 各ゲートウェイサーバーは、STA URLと各チケット認証局の一意のSTA IDを使用して構成する必要があります。

Q:複数のStaをロードバランシングするにはどうすればよいですか?

A:安全なチケット当局の負荷分散には特別な注意が必要です。 アプリケーション列挙型サーバーとSta間の接続を負荷分散するには、さまざまな方法を使用できますが、Secure Gatewayサーバーは、常にSTA IDに基づいて各STAに個別に接続す ゲートウェイサービス構成ツールで各STAのアドレスを構成する場合、各STAアドレスはSTAサーバーの真のアドレスである必要があります。

StoreFront、Web Interface2.0、およびSecure Access Manager2。0複数のStaがリストされている場合、すべてのStaのラウンドロビン負荷分散をサポートします。 このオプションを有効にすると、追加の負荷分散ソフトウェアまたはハードウェアは必要ありません。

アプリケーション列挙サーバーは、受信した各チケットには、それを生成したSTAの一意のIDを示すフィールドが含まれているため、チケット要求を発行するた 各STA IDが一意であり、すべてのゲートウェイサーバーがSTA IDを特定の（負荷分散されていない）サーバーアドレスに解決できる限り、操作は成功し、STAトラフィックは負荷分散されます。

: Microsoftネットワーク負荷分散で複数のStaを使用できますか?

A:Secure Gatewayサーバーと複数のSta間でネットワーク負荷分散を使用することはできません。 このように構成すると、チケットの検証プロセス中に、ゲートウェイが最初にユーザーのチケットを生成しなかった権限に負荷分散される可能性があるた

Q:単一のSTAを複数のファーム、ゲートウェイ、および列挙サーバーと共有できますか?

: はい、単一のSTAは、任意の数のSecure Gatewayサーバーとアプリケーション列挙サーバー間で共有できます。 STAは、特定のドメイン、ファーム、またはアプリケーション列挙サーバーに制限されません。 これは匿名のXMLサービスです。Q:STAをホストするようにIISをどのように設定する必要がありますか?

dllは、匿名アクセスを有効にして提供する必要があります。 WEBブラウザをSTA URLにポイントすると、パスワードの入力は求められません。

  • IISメタベースでリソーススクリプトと実行可能ファイルのアクセス許可を付与する必要があります。 この権限は/Scriptsフォルダ全体には必要ありませんが、CtxStaに設定できます。dllファイル個別に。Secure Gatewayバージョン1.1以前の場合は、Require SSLおよびRequire128-bit SSLオプションを有効にしないでください。
  • デフォルトでは、次のアカウント権限が必要です:

Windows2000サーバー

  • の場合、Iusr_MachinenameアカウントにはCtxStaへの読み取りアクセス権が必要です。dll。
  • Iwam_Machinenameアカウントは、デフォルトで\Inetpub\Scriptsであるログファイルディレクトリへの変更アクセス権を必要とします。Windows2003サーバーの場合、Iusr_MachinenameアカウントにはCtxStaへの読み取りアクセス権が必要です。dll。
  • 組み込みのネットワークサービスアカウントには、ログファイルディレクトリ(既定では\Inetpub\Scripts)への変更アクセス権が必要です。

Q:STAでロギングを有効にするにはどうすればよいですか?

A:メモ帳を使用して、ファイル\Inetpub\Scripts\CtxStaを編集します。STAサーバー上の設定を行い、LogLevel=0という行を見つけます。 ログを最大にするには、これをLogLevel=3に変更します。 変更を有効にするには、World Wide Web発行サービスを再起動する必要があります。
メモ:ログ記録を有効にした後、STAが実行する権限を持つユーザーアカウント(既定ではWindows2000ではIusr_Machinename、Windows2003ではNetwork Service)には、ログファイルディレクトリ(既定では\Inetpub\Scripts) CtxStaを編集するときにログファイルディレクトリを変更することもできます。設定。

Q:Microsoft IISLockDownツールがSTAを壊すのはなぜですか?

: IISLockDownツールの既定の設定をすべて受け入れると、/Scriptsフォルダーは無効になります。 STAは、/Scripts/CtxStaとして公開されたISAPIフィルタとして実装されます。dll;/Scriptsディレクトリを無効にすると、STAへのアクセスが拒否されます。 /Scriptsフォルダーを有効にし、STAが機能するためのスクリプトと実行可能ファイルへのアクセスを許可します。Q:STAが正常に動作していることを確認するにはどうすればよいですか?

A:WebブラウザをSTA URLにポイントすると、空白の白いページまたはメッセージ”405リソースは許可されていません。”これらの結果のいずれかが機能STAを示しています。 この方法でSTAに接続するには、Secure Gatewayサーバーのコンソールと、ゲートウェイを使用するように構成されたアプリケーション列挙サーバーからもできます。 パスワードの入力を求める認証ダイアログボックスが表示された場合、STAは匿名で公開されず、認証要件を削除する必要があります。

アプリケーション列挙サーバーがSTAチケットを正常に要求していることを確認するには、生成されたICAファイルを調べます。 たとえば、Web Interface2.0からは、公開されたアプリケーションアイコンを右クリックして、結果を起動として保存できます。アイカ 起動を開きます。メモ帳でicaを表示し、Address=行を表示します。 通常のSecure Gateway操作では、Addressパラメーターには実際のXenAppサーバーアドレスではなくチケットが含まれます。Q:STAログファイルはどのように解釈されますか?

A:CtxStaでLogLevel=3を設定してロギングを有効にした場合。設定すると、STAによって受信された各チケットとデータ要求の詳細が表示されます。 チケット要求はWeb Interfaceのようなアプリケーション列挙サーバーによって生成され、データ要求はSecure Gatewayサービスによって実行されることに注意してくださ ログファイルに複数のチケット要求が表示され、データ要求がない場合、アプリケーション列挙サーバーはSTAに到達できますが、Secure Gatewayサーバーは到達できません。 また、ユーザーがゲートウェイサーバーに到達できないことを意味することもあります。

通常の動作中、ICAクライアントのセッション共有機能により、チケットがSTAから要求されますが、ゲートウェイによって要求されることはありません。 次のシナリオを考えてみましょう:

  • ユーザーがWebインターフェイスにログオンし、Outlookアイコンをクリックします。 WebインターフェイスはSTAからチケットを要求し、ICAファイルでユーザーに送信します。
  • ユーザーはSecure Gatewayを介して接続し、入場券を提示します。 ゲートウェイはチケットを検証し、ユーザーがOutlookをホストするXenAppサーバーに接続できるようにします。
  • 数分間作業した後、ユーザーはWebインターフェイスページのアプリケーションリストに戻り、Excelアイコンをクリックします。 WebインターフェイスはSTAからの第二のチケットを要求し、ICAファイルでユーザーに送信します。
  • EXCEL用の新しいサーバーに接続する前に、ICAクライアントはまず、クライアントが既に接続されている既存のサーバーにExcel公開アプリケーションが使用可能であ
  • クライアントが既にOutlookを実行しているサーバーにもExcelがインストールされているため、ICAクライアントはICAファイルを破棄し、既存のICAセッション内でExcel
  • 第二のICAセッションが必要なかったため、Webインターフェイスによって要求された第二のチケットは使用されません。 デフォルトでは、チケットは100秒後にタイムアウトします。

このシナリオでは、次のような一連のSTAログファイルエントリが生成されます:

CSG1305 Request Ticket - Successful 8DE802AE5A2F561233450B6CFD553035 ...CSG1304 Request Data - Successful 8DE802AE5A2F561233450B6CFD553035 ...CSG1305 Request Ticket - Successful 63EF3EAB182D846958143D19C1FDAEBA ...CSG1303 Ticket Timed Out 63EF3EAB182D846958143D19C1FDAEBA

より疑わしい活動は次のようになります:

CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB804 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB805 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB806 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB807 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB808 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB809

ここでは、攻撃者がさまざまなチケットを一度に1つずつ試行し、試行ごとにチケットIDをインクリメントしているように見えるものを確認します。 いずれの場合も、接続が拒否され、STAは、クライアントが有効であると認識されなかったチケットを提示したことを示すエントリを記録した。 攻撃者のIPアドレスを特定するには、Secure Gatewayサーバーのイベントビューアで次のメッセージを探します:

CSG3207 Service received error from STA or Authentication Service , Client IP connection dropped.

一部の”Ticket NOT found”メッセージを攻撃として解釈しないでください。 Win32ICAクライアントは、ユーザーのネットワーク接続が一時的に切断された場合、切断されたセッションに再接続しようとする可能性があります。 再接続の試行のたびに、クライアントは最初に接続した使用済みSTAチケットを再送信するため、Citrix Secure Gatewayユーザーには自動クライアント再接続機能は機能し クライアントは通常、あきらめる前に3回以上再接続を試みるため、この問題が発生するたびにSTAログに同じチケットを参照する3つ以上の「Ticket NOT found」メッ クライアントの再接続の試行は、以前に成功したチケットの再利用の試行によって特徴付けられます:

CSG1305 Request Ticket - Successful 766D558270CE32695903698AFA0F67A6 …CSG1304 Request Data - Successful 766D558270CE32695903698AFA0F67A6 …CSG1203 Request Data - Ticket NOT found766D558270CE32695903698AFA0F67A6 CSG1203 Request Data - Ticket NOT found766D558270CE32695903698AFA0F67A6 CSG1203 Request Data - Ticket NOT found766D558270CE32695903698AFA0F67A6

TRANSPORTRECONNECTENABLED=OffをICAファイルのセクションに追加して、Secure Gatewayユーザーの自動クライアント再接続を切断します。 Secure Gatewayを使用するときに切断されたセッションに再接続する正しい方法は、application enumeration serverに戻り、アプリケーションアイコンを再度クリックすることです。

Q:Citrixテクニカルサポートで見られる一般的な構成エラーの一部は何ですか?

  • IISLockDownを実行するか、webサーバーを保護するための会社のポリシーを遵守した結果、/Scriptsフォルダーまたは既定のWebサイト全体が無効になります。
  • CtxStaでロギングが有効になっています。ただし、STAが実行する権限の下にあるユーザーアカウント(デフォルトではIusr_Machinename)には、ログファイルディレクトリへの書き込みアクセス権がありません。
  • STAサーバー上のIISはSSLを必要とするように構成されていますが、Secure Gatewayは通常のHTTPを使用してSTAにアクセスするように構成されています。
  • アプリの起動に失敗した場合、最初に確認する必要があるのは、StoreFront/Web InterfaceとNetScalerのStaがまったく同じ方法で指定されているかどうか、つまり、SF/WIのIPアドレ

コメントを残す

メールアドレスが公開されることはありません。