Product Documentation

ストアに内部および外部アクセスするための単一のFQDNの作成

Dec 15, 2016
注:この機能をネイティブのReceiverで使用するには、以下のバージョンが必要です。
  • Windows Receiver 4.2
  • Receiver for Mac 11.9

会社のネットワーク内外のクライアント用に単一の完全修飾ドメイン名(Fully Qualified Domain Name:FQDN)を作成することで、そのネットワーク内、およびネットワーク外からNetScaler Gateway経由でリソースにアクセスするユーザーの使い勝手を簡素化することができます。

単一のFQDNを作成すると、ユーザーが各プラットフォーム用のReceiverを簡単に構成できるようになります ネットワーク内からアクセスする場合もインターネット経由で外部からアクセスする場合も、ユーザーが覚える必要のあるURLは1つのみになります。

ネイティブReceiverのStoreFrontビーコン

Citrix Receiverは、ユーザーがローカルネットワークと公共のネットワークのどちらに接続しているのかをビーコンポイントを使用して識別します。 ユーザーがデスクトップやアプリケーションにアクセスすると、そのリソースを提供するサーバーがそのユーザーの位置情報に基づいて適切な接続詳細をCitrix Receiverに返します。 これにより、ユーザーがデスクトップやアプリケーションにアクセスするときに再ログオンする必要がなくなります。 ビーコンポイントの構成については、「ビーコンポイントを構成」を参照してください。

NetScaler Gateway仮想サーバーとSSL証明書の構成

外部のクライアントが会社のネットワーク外からリソースにアクセスしようとしたときに、共有FQDNはDMZの外部ファイアウォールルーターインターフェイスのIP、またはNetScaler Gateway仮想サーバーのIPに解決されます。 SSL証明書の[Common Name](一般名)フィールドと[Subject Alternative Name](SAN:サブジェクトの別名)フィールドに、ストアの外部アクセスに使用する共有FQDNが含まれていることを確認します。 ゲートウェイ証明書への署名に、会社の証明機関(Certification Authority:CA)ではなくVerisign社などのサードパーティのルートCAを使用すると、すべての外部クライアントは、NetScaler Gateway仮想サーバーの証明書を自動的に信頼します。 Verisign社などのサードパーティのルートCAを使用する場合は、外部クライアントに追加のルートCA証明書をインポートする必要はありません。

NetScaler GatewayとStoreFrontサーバーの両方に対して、共有FQDNの一般名を使用して単一の証明書を展開する場合は、リモート検出をサポートするかどうかを検討します。 サポートする場合は、証明書がSANの仕様に準拠していることを確認してください。

NetScaler Gateway仮想サーバーの証明書の例:storefront.example.com
  1. 共有FQDN、コールバックURL、およびアカウントエイリアスURLが、SANとして[DNS]フィールドに含まれていることを確認します。
  2. 証明書と秘密キーをNetScaler Gatewayにインポートできるように、秘密キーがエクスポート可能になっていることを確認します。
  3. Default AuthorizationがAllowと設定されていることを確認します。
  4. Verisign社などのサードパーティのCA、または会社のルートCAを使用して証明書に署名します。

2ノードサーバーグループのSANの例:

storefront.example.com(必須)

storefrontcb.example.com(必須)

accounts.example.com(必須)

storefrontserver1.example.com(オプション)

storefrontserver2.example.com(オプション)

NetScaler Gateway仮想サーバーのSSL証明書の署名

要件に応じて、2つの種類のCA署名付き証明書を選択できます。

  • サードパーティのCA署名付き証明書 - NetScaler Gateway仮想サーバーの証明書が信頼されたサードパーティによって署名されている場合は、外部クライアントの信頼されたルートCA証明書ストアにCA証明書をコピーする必要はほとんどありません。 Windowsクライアントには、一般的なほとんどの署名機関のルートCA証明書が付属しています。 使用できる商用のサードパーティCAの例としては、DigiCert、Thawte、Verisignなどがあります。 ただし、iPad、iPhone、Androidタブレットや電話などのモバイルデバイスには、ルートCAをデバイスにコピーして、NetScaler Gateway仮想サーバーを信頼するように構成することが必要な場合があります。
  • 会社のルートCA署名付き証明書 — これを選択する場合は、すべての外部クライアントの信頼されたルートCAストアに会社のルートCA証明書をコピーする必要があります。 iPhoneやiPadなどのポータブルデバイスにネイティブのReceiverをインストールしている場合は、これらのデバイスでセキュリティプロファイルを作成します。

ポータブルデバイスへのルート証明書のインポート

  • 通常、iOSデバイスのローカルストレージにアクセスすることはできないので、iOSデバイスではメールの添付ファイルを使用して.CER x.509証明書ファイルをインポートします。
  • Androidデバイスにも同じ.CER x.509形式が必要です。 証明書は、デバイスのローカルストレージまたはメールの添付ファイルからインポートできます。

外部DNS:storefront.example.com

組織のインターネットサービスプロバイダーによって提供されるDNS解決によって、DMZの外部境界に位置するファイアウォールルーターの外部に対するIPや、NetScaler Gateway仮想サーバーの仮想IPが解決されるようにします。

スプリットビューDNS

  • スプリットビューDNSを正しく構成すると、DNS要求の送信元アドレスに応じてクライアントに正しいDNS Aレコードが送信されます。
  • 公共ネットワークと社内ネットワーク間を移動するクライアントのIPアドレスは、それに応じて変更されます。 クライアントがstorefront.example.comを照会すると、そのときの接続先ネットワークに応じて適切なAレコードを受信します。

Windows CAがNetScaler Gatewayに発行した証明書のインポート

WinSCPは、WindowsマシンからNetScaler Gatewayファイルシステムへのファイル移動に役立つ無料のサードパーティツールです。 インポートする証明書を、NetScaler Gatewayファイルシステム内の/nsconfig/ssl/フォルダーにコピーします。 NetScaler Gateway上でOpenSSLツールを使用して、証明書とキーをPKCS12/PFXファイルから抽出し、NetScaler Gatewayで使用できるPEM形式で、2つの別々のCERファイルとKEY X.509ファイルを作成することができます。

  1. このPFXファイルをNetScaler GatewayアプライアンスまたはVPXの/nsconfig/sslにコピーします。
  2. NetScaler Gatewayのコマンドラインインターフェイスを開きます。
  3. FreeBSDシェルに切り替えるために、Shellと入力して、NetScaler Gatewayのコマンドラインインターフェイスを終了します。
  4. フォルダーを変更するために、cd /nsconfig/sslと入力します。
  5. openssl pkcs12 -in <inported cert file>.pfx -nokeys -out <certfilename>.cerを実行し、画面のメッセージに従ってPFXパスワードを入力します。ここで、<inported cert file>はインポートする証明書ファイル、<certfilename>は証明書ファイル名です。
  6. openssl pkcs12 -in <imported cert file>.pfx -nocerts -out <keyfilename>.keyを実行します。ここで、<keyfilename>はキーファイル名です。
  7. 画面のメッセージに従ってPFXパスワードを入力し、次に、秘密キーのPEMパスフレーズを設定してKEYファイルを保護します。
  8. /nsconfig/ssl/内にCERファイルKEYファイルが正常に作成されたことを確認するには、ls –alを実行します。
  9. NetScaler Gatewayのコマンドラインインターフェイスに戻るために、Exitと入力します。

ネイティブのReceiver for Windows/Mac用Gatewayセッションポリシー

REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver && REQ.HTTP.HEADER X-Citrix-Gateway EXISTS

Receiver for Web用Gatewayセッションポリシー

REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver && REQ.HTTP.HEADER Referer EXISTS

cVPNとSmartAccessの設定

SmartAccessを使用している場合、NetScaler Gateway仮想サーバーのプロパティページで、SmartAccessモードを有効にします。 この場合、リモートリソースに同時にアクセスするすべてのユーザー用のユニバーサルライセンスが必要です。

Receiverのプロファイル

セッションプロファイルアカウントサービスのURLとして、https://storefront.example.com/Citrix/Roaming/Accountsではなくhttps://accounts.example.com/Citrix/Roaming/Accountsを構成します。

また、StoreFrontサーバーの認証用およびローミング用の各web.configファイルにも、このURLを追加の<allowedAudiences>として追加します。 詳しくは、後述の「StoreFrontサーバーのホストベースURL、ゲートウェイ、SSL証明書の構成」を参照してください。

Receiver for Webのプロファイル

ICAプロキシと基本モードの設定

ICAプロキシを使用している場合、NetScaler Gateway仮想サーバーのプロパティページで、基本モードを有効にします。 1つのNetscalerプラットフォームライセンスのみが必要です。

Receiverのプロファイル

Receiver for Webのプロファイル

StoreFrontサーバーのホストベースURL、ゲートウェイ、SSL証明書の構成

ストアをホストするStoreFrontクラスターまたは単一のStoreFront IPが作成されている場合は、NetScaler Gateway仮想サーバーに解決される共有FQDNがStoreFrontのロードバランサーにも直接解決される必要があります。

内部DNS:3つのDNS Aレコードを作成します。

  • storefront.example.comがStoreFrontのロードバランサーまたは単一のStoreFrontサーバーIPに解決される必要があります。
  • storefrontcb.example.comがゲートウェイの仮想サーバーの仮想IPに解決される必要があるので、DMZと会社のローカルネットワークの間にファイアウォールがある場合は、これを許可します。
  • accounts.example.comstorefront.example.comのDNSエイリアスとして作成します。 StoreFrontクラスターのロードバランサーIPまたは単一のStoreFrontサーバーIPにも解決されます。

StoreFrontサーバー証明書の例:storefront.example.com

  1. StoreFrontをインストールする前に、StoreFrontサーバーまたはサーバーグループ用の適切な証明書を作成します。
  2. 共有FQDNを[Common name]フィールドと[DNS]フィールドに追加します。 これが、先に作成したNetScaler Gateway仮想サーバーのSSL証明書で使用されるFQDNと一致することを確認します。または、NetScaler Gateway仮想サーバーと同じ証明書を使用します。
  3. 別のSANとしてアカウントエイリアス(accounts.example.com)を証明書に追加します。 SANで使用されるアカウントエイリアスは、前述の手順(「ネイティブReceiver Gatewayのセッションポリシーとプロファイル」)の[Configure NetScaler Gateway Session Profile]画面で使用したものであることに注意してください。

  4. 秘密キーをエクスポート可能にして、証明書を別のサーバーまたは複数のStoreFrontサーバーグループノードに転送できるようにします。

  5. VeriSign社などのサードパーティのCA、会社のルートCA、または中間CAを使用して証明書に署名します。
  6. 秘密キーを含めて、この証明書をPFX形式でエクスポートします。
  7. 証明書と秘密キーをStoreFrontサーバーにインポートします。 Windows NLB StoreFrontクラスターを展開している場合は、すべてのノードにこの証明書をインポートします。 NetScaler LB仮想サーバーなどの代替ロードバランサーを使用している場合は、そこに証明書をインポートします。
  8. StoreFrontサーバーのIISでHTTPSバインドを作成し、インポートしたSSL証明書をバインドします。

  9. StoreFrontサーバーで、選択済みの共有FQDNに一致するように、ホストベースURLを構成します。
    注:StoreFrontでは、証明書内のSAN一覧で最後のSANが常に自動的に選択されます。 通常、自動的に選択されたものをそのまま使用できますが、StoreFront管理者は必要に応じて変更することもできます。 有効なHTTPS://<FQDN>が証明書内にSANとして存在する場合、ホストベースURLをそのいずれかに手動で設定することができます。 (例:https://storefront.example.com)
localized image

StoreFrontサーバーでのゲートウェイの構成:storefront.example.com

1.  [ストア]ノードで、[NetScaler Gatewayの管理][操作]ペインでクリックします。

2. サーバー名を変更するには、一覧から[ゲートウェイ]を選択し、[編集]をクリックします。

localized image

 

3.  [全般設定]ページで共有FQDNを[NetScaler Gateway URL]フィールドに入力します。

4.  [認証設定]タブを選択し、コールバックFQDNを[コールバックURL]フィールドに入力します。

localized image

5.  [Secure Ticket Authority]タブを選択し、Secure Ticket Authority(STA)サーバーが[ストア]ノード内で既に構成されているDelivery Controllerの一覧と一致するか確認します。 

6. このストアのリモートアクセスを有効にします。

7. 内部ビーコンにアカウントエイリアス(accounts.example.com)を手動で設定します。これは、ゲートウェイ外部からの解決が不可能なものである必要があります。 このFQDNは、StoreFrontホストベースURLとNetScaler Gateway仮想サーバーで共有される外部ビーコン(storefront.example.com)とは異なるものである必要があります。 内部ビーコンと外部ビーコンが同じものになってしまうので、共有FQDNは使用しないでください。

8. FQDNによる検出をサポートするには、次の手順に従います。 プロビジョニングファイルの構成が十分である場合、またはReceiver for Webのみを使用する場合は、次の手順を省略できます。

C:\inetpub\wwwroot\Citrix\Authentication\web.configに追加の<allowedAudiences>エントリを追加します。 認証用web.configファイルには2つの<allowedAudiences>エントリがあります。 Authentication Token Producer用である、ファイル内の最初のエントリのみに、追加の<allowedAudience>を追加する必要があります。

9. <allowedAudiences>要素を検索します。 以下のようなエントリを見つけ、太字で示されている行を追加し、保存して、web.configファイルを閉じます。

<service id="abd6f54b-7d1c-4a1b-a8d7-14804e6c8c64" displayName="Authentication Token Producer">

..........

..........
               <allowedAudiences>
                     <add name="https-storefront.example.com" audience="https://storefront.example.com/" />
                           <add name="https-accounts.example.com" audience="https://accounts.example.com/" />
                 </allowedAudiences>

9. C:\inetpub\wwwroot\Citrix\Roaming\web.configで、 以下のようなエントリを見つけ、太字で示されている行を追加し、保存して、web.configファイルを閉じます。

<tokenManager>
          <services>
                <clear />
..........

..........

                   </trustedIssuers>
                   <allowedAudiences>
                       <add name="https-storefront.example.com" audience="https://storefront.example.com/" />
                               <add name="https-accounts.example.com" audience="https://accounts.example.com/" />
                       </allowedAudiences>
                     </service>
                   </services>
                 </tokenManager>

 

または、ストアのネイティブReceiver CRプロビジョニングファイルをエクスポートすることができます。 こうすることで、初回使用時にネイティブReceiverの構成が不要になります。 このファイルをすべてのReceiver for WindowsおよびReceiver for Macクライアントに配布します。

Receiverがインストール済みでCRファイルが関連付けられている場合、プロビジョニングファイルをダブルクリックすると自動的にインポートされます。