Citrix Secure Private Access

アダプティブ認証サービス

Citrix Cloudのお客様は、Citrix Workspaceを使用して、Citrix DaaSにアダプティブ認証を提供できます。アダプティブ認証は、Citrix Workspaceにログインしている顧客とユーザーに高度な認証を可能にするCitrix Cloudサービスです。アダプティブ認証サービスは、Citrixが管理しCitrix CloudがホストするADCであり、次のようなすべての高度な認証機能を提供します:

多要素認証: 多要素認証は、アクセスを得るために複数の身元証明の提供をユーザーに要求することにより、アプリケーションのセキュリティを強化します。顧客は、ビジネス要件に基づいて、多要素認証メカニズムの要素のさまざまな組み合わせを構成できます。詳しくは、「 認証設定の例」を参照してください。

デバイスポスチャスキャン: デバイスのポスチャに基づいてユーザを認証できます。エンドポイント分析スキャンとも呼ばれるデバイスポスチャスキャンは、デバイスが準拠しているかどうかを確認します。たとえば、デバイスで最新の OS バージョンが実行されている場合、サービスパック、およびレジストリキーが設定されます。セキュリティコンプライアンスには、ウイルス対策ソフトウェアがインストールされているか、ファイアウォールが有効になっているかなどを確認するスキャンが含まれます。デバイスのポスチャでは、デバイスが管理対象か管理対象外か、企業所有か、BYOL かを確認することもできます。

条件付き認証: ネットワークの場所、デバイスの姿勢、ユーザーグループ、時刻などのユーザーのパラメーターに基づいて、条件付き認証を有効にできます。条件付き認証を行うには、これらのパラメータのいずれかまたはこれらのパラメータの組み合わせを使用できます。 デバイスのポスチャベースの認証の例:デバイスのポスチャスキャンを実行して、デバイスが企業管理または BYOD かどうかを確認できます。デバイスが企業管理対象デバイスの場合は、簡単なAD(ユーザー名とパスワード)でユーザーにチャレンジできます。デバイスが BYOD の場合は、AD と RADIUS 認証でユーザーにチャレンジできます。

ネットワークの場所に基づいて仮想アプリと仮想デスクトップを選択的に列挙する場合は、ワークスペースではなくCitrix Studioポリシーを使用して、これらのデリバリーグループのユーザー管理を実行する必要があります。デリバリーグループを作成するときに、[ユーザー]設定で、[ このデリバリーグループの使用を次のユーザーに制限する]または[認証されたユーザーにこのデリバリーグループの使用を許可する**]を選択します。これにより、アダプティブアクセスを構成するための[デリバリーグループ]下の **[アクセスポリシー] タブが有効になります。

Citrix DaaSへのコンテキストアクセス: アダプティブ認証により、Citrix DaaSへのコンテキストアクセスが可能になります。アダプティブ認証は、ユーザーに関するすべてのポリシー情報をCitrix DaaSに表示します。管理者はポリシー構成でこの情報を使用して、Citrix DaaSで実行できるユーザーのアクションを制御できます。たとえば、ユーザーアクションでは、クリップボードへのアクセスやクライアントドライブマッピングのプリンタリダイレクトを有効または無効にすることができます。

アダプティブ認証によるセキュアインターネットアクセスおよびその他のCitrix Cloud サービスへのコンテキストアクセスは、今後のリリースで計画されています。

ログオンページのカスタマイズ: アダプティブ認証は、ユーザーがCitrix Cloud ログオンページを高度にカスタマイズするのに役立ちます。

アダプティブ認証機能

アダプティブ認証を使用するCitrix Workspace でサポートされている機能は次のとおりです。

  • LDAP (Active Directory)
  • AD、Azure AD、Oktaのディレクトリサポート
  • RADIUS サポート (Duo、Symantec)
  • AD + トークン内蔵 MFA
  • SAML 2.0
  • OAuth、OIDC サポート
  • クライアント証明書認証
  • デバイスのポスチャ評価 (エンドポイント分析)
  • サードパーティ認証プロバイダとの統合
  • アプリを介したプッシュ通知
  • reCAPTCHA
  • 条件付き/ポリシー主導の認証
  • SmartAccess (コンテキストアクセス) の認証ポリシー
  • ログオンページのカスタマイズ
  • セルフサービスパスワードリセット

前提条件

  • 適応認証インスタンスの FQDN を予約します。たとえば aauth.xyz.comxyz.com は会社のドメインであると仮定します。この FQDN は、このドキュメントではアダプティブ認証サービス FQDN と呼ばれ、インスタンスのプロビジョニング時に使用されます。FQDN を IdP 仮想サーバーのパブリック IP アドレスにマッピングします。この IP アドレスは、[ 証明書のアップロード ] ステップでプロビジョニングした後に取得されます。
  • aauth.xyz.com の証明書を入手します。証明書には SAN 属性が含まれている必要があります。そうでない場合、証明書は受け入れられません。

  • アダプティブ認証 UI は、証明書バンドルのアップロードをサポートしていません。中間証明書をリンクするには、「 中間証明書の設定」を参照してください。

  • オンプレミスの AD/RADIUS 接続の接続タイプを選択します。次の 2 つのオプションを使用できます。データセンターの到達可能性を望まない場合は、コネクタ接続タイプを使用します。

  • ネットワークタイムプロトコル (NTP) サーバーを構成して、タイムスキューを回避します。詳細については、「 システムクロックをネットワーク上のサーバーと同期させる方法」を参照してください。

注意事項

  • Citrix では、アダプティブ認証インスタンスに対してclear configを実行したり、証明書を含むプレフィックスAA付きの構成(AAuthAutoConfigなど)を変更したりしないことをお勧めします。これにより、アダプティブ認証の管理が中断され、ユーザーアクセスが影響を受けます。回復する唯一の方法は、再プロビジョニングを行うことです。
  • アダプティブ認証インスタンスには SNIP やその他のルートを追加しないでください。
  • 顧客 ID がすべて小文字でない場合、ユーザー認証は失敗します。set cloud parameter -customerID <all_lowercase_customerid>コマンドを使用して、ID をすべて小文字に変換し、ADC インスタンスに設定できます。
  • Citrix WorkspaceまたはCitrix Secure Private Accessサービスに必要なnFactor構成は、顧客がインスタンスで直接作成することになっている唯一の構成です。現在、Citrix ADCには、管理者がこれらの変更を行うことを妨げるチェックや警告はありません。
  • アダプティブ認証インスタンスをランダムな RTM ビルドにアップグレードしないでください。すべてのアップグレードはCitrix Cloud によって管理されます。
  • Windows ベースのクラウドコネクタのみがサポートされています。Connector Applianceは、このリリースではサポートされていません。
  • 既存のCitrix Cloud のお客様で、Azure AD(または他の認証方法)をすでに構成している場合は、アダプティブ認証(デバイスのポスチャチェックなど)に切り替えるには、認証方法としてアダプティブ認証を構成し、認証ポリシーをアダプティブ認証インスタンス。詳しくは、「 Citrix Cloud をAzure AD に接続する」を参照してください。
  • RADIUSサーバーの展開では、すべてのコネクタ・プライベートIPアドレスをRADIUSサーバー内のRADIUSクライアントとして追加します。
  • LDAP または RADIUS サーバーをサービスまたはサーバーとして追加しないでください。
  • 現在のリリースでは、外部ADMエージェントは許可されていないため、Citrix Analytics(CAS)はサポートされていません。
  • Citrix Application Delivery Management サービスは、アダプティブ認証インスタンスのバックアップを収集します。ADM からバックアップを抽出するには、ADM サービスをオンボーディングします。詳細については、「 構成のバックアップと復元」を参照してください。Citrix は、アダプティブ認証サービスからバックアップを明示的に取得しません。お客様は、必要に応じて、アプリケーション配信管理サービスから構成のバックアップを取る必要があります。

アダプティブ認証サービスの構成方法

アダプティブ認証のユーザーインターフェイスにアクセスする

アダプティブ認証ユーザーインターフェイスには、次のいずれかの方法でアクセスできます。

  • URL https://adaptive-authentication.cloud.comを手動で入力します。
  • 認証情報を使用してログインし、顧客を選択します。

    正常に認証されると、アダプティブ認証のユーザーインターフェイスにリダイレクトされます。

または

  • Citrix Cloud]>[IDとアクセス管理]に移動します。
  • 「認証」タブの「 アダプティブ認証」で、省略記号メニューをクリックし、「 管理」を選択します。

アダプティブ認証のユーザーインターフェイスが表示されます。

次の図は、アダプティブ認証の構成に関連する手順を示しています。

メインページのプロビジョニング

ステップ 1: アダプティブ認証をプロビジョニングする

次の手順を実行します:

  1. アダプティブ認証 UI で、[ プロビジョニング] をクリックします。
  2. アダプティブ認証の優先接続を選択します。

    • Citrix Cloud Connector: この接続タイプでは、オンプレミスネットワークにコネクタを設定する必要があります。AzureでホストされているCitrix Gateway への接続をセットアップするには、環境に少なくとも2つのCitrix Cloud Connectorを展開することをお勧めします。Citrix Cloud Connectorが、適応認証インスタンス用に予約したドメイン/URLへのアクセスを許可する必要があります。たとえば、 https://aauth.xyz.com/*許可します。

      Citrix Cloud Connectorについて詳しくは、「 Citrix Cloud Connector」を参照してください。

    • Azure VNet ピアリング -Azure の VNet ピアリングを使用してサーバー間の接続を設定する必要があります。

      • 接続をセットアップするための Azure サブスクリプションアカウントがあることを確認します。
      • ピアリングされる顧客 VNet には、Azure VPN ゲートウェイがすでにプロビジョニングされている必要があります。詳しくは、https://docs.microsoft.com/en-us/azure/vpn-gateway/tutorial-site-to-site-portalを参照してください。

    接続の種類

    Citrix Cloud Connectorを優先接続として追加するには:

    以下の手順を実行します。

    • Citrix Cloud Connector ]オプションを選択し、[エンドユーザー同意]チェックボックスをオンにします。
    • [ プロビジョニング] をクリックします。プロビジョニングのセットアップには最大 30 分かかる場合があります。

    注:

    コネクタ接続タイプの場合は、プロビジョニング後にアダプティブ認証 FQDN がコネクタ仮想マシンから到達可能であることを確認してください。

    Azure VNet ピアリングを設定するには:

    接続として Azure VNet ピアリングを選択した場合は 、アダプティブ認証インスタンスのプロビジョニングに使用する必要があるサブネット CIDR ブロックを追加する必要があります。また、CIDR ブロックが組織の他のネットワーク範囲と重複しないようにする必要があります。

    詳しくは、「 Azure VNet ピアリングを使用してオンプレミス認証サーバーへの接続をセットアップする」を参照してください。

  3. アダプティブ認証を有効にしているインスタンスにアクセスするための認証情報を設定します。認証、条件付きアクセスなどのポリシーを作成するには、管理コンソールアクセスが必要です。

    1. コンソールアクセス画面で 、ユーザー名とパスワードを入力します。
    2. [ 次へ] をクリックします。

    注:コンソールアクセス画面から作成されたユーザーには 、シェルアクセス権を持つ「スーパーユーザー」権限が付与されます。

    コンソールのアクセス

  4. アダプティブ認証サービスの FQDN を追加し、証明書とキーのペアをアップロードします。 パブリックにアクセス可能な認証サーバーに対して、選択したアダプティブ認証サービスの FQDN を入力する必要があります。

    1. [ 証明書のアップロード ] 画面で、アダプティブ認証用に予約した FQDN を入力します。
    2. 証明書の種類を選択します。
    3. 証明書とキーをアップロードします。

    注:

    • Adaptive Authentication インスタンスに中間証明書をインストールし、サーバー証明書とリンクします。

      1.  アダプティブ認証インスタンスにログインします。 1.  [ **トラフィック管理] > [SSL**] に移動します。 詳細については、「 [中間証明書を構成する](/ja-jp/citrix-gateway/current-release/install-citrix-gateway/certificate-management-on-citrix-gateway/configure-intermediate-certificate.html)」を参照してください。
      
    • 公開証明書のみが受け入れられます。プライベート CA または不明な CA によって署名された証明書は受け付けられません。
    • 証明書の設定は、アダプティブ認証 UI のみを使用して行う必要があります。インスタンスで直接変更しないでください。矛盾が生じる可能性があります。

    FQDN を追加

  5. 証明書とキーをアップロードします。

    これで、アダプティブ認証インスタンスが ID およびアクセス管理サービスに接続されました。アダプティブ認証方法のステータスが [ 接続済み] と表示されます。

    IDAM に接続されたアダプティブ認証

  6. アダプティブ認証管理コンソールにアクセスするためのIPアドレスを設定します。
    1. [ 許可された IP アドレス ] 画面で、インスタンスごとに、管理 IP アドレスとしてパブリック IP アドレスを入力します。管理 IP アドレスへのアクセスを制限するために、管理コンソールへのアクセスを許可する複数の IP アドレスを追加できます。
    2. 複数の IP アドレスを追加するには、[ 追加] をクリックし、IP アドレスを入力して、[ 完了] をクリックする必要があります。これはすべての IP アドレスに対して行う必要があります。[ 完了 ] ボタンをクリックしない場合、IP アドレスはデータベースに追加されず、ユーザーインターフェイスにのみ追加されます。

    許可される IP アドレス

  7. AD または RADIUS サーバに接続できる一連のリソースロケーション (コネクタ) を指定します。

    管理者は、バックエンドの AD サーバーと RADIUS サーバーに接続する必要があるコネクタを選択できます。この機能を有効にするには、認証トラフィックが特定のサブネットに該当する場合、そのトラフィックが特定のリソースの場所に転送されるように、バックエンドの AD/RADIUS サーバーサブネット間のマッピングを設定できます。ただし、リソースの場所がサブネットにマップされていない場合、管理者はそれらのサブネットにワイルドカードリソースの場所を使用するように指定できます。

    以前は、オンプレミスの AD/RADIUS の適応型認証トラフィックは、ラウンドロビン方式を使用して使用可能な任意のリソースロケーションに転送されていました。これにより、複数のリソースロケーションを持つお客様に問題が発生しました。

    1. アダプティブ認証 UI で、「 接続を管理」をクリックします。
    2. サブネットの詳細を入力し、それぞれのリソースの場所を選択します。 注: [ 残りのサブネットには使用可能なリソースの場所をすべて使用する ] チェックボックスをオフにすると、設定したサブネットに向けられたトラフィックのみがトンネリングされます。
    3. [ 追加] をクリックし、[ 変更を保存] をクリックします。

    注:

    • RFC1918 IP アドレスサブネットのみが許可されます。
    • 顧客ごとのサブネットリソースロケーションマッピングの数は 10 に制限されています。
    • 複数のサブネットを 1 つのリソースロケーションにマッピングできます。
    • 同じサブネットに重複したエントリは許可されません。
    • サブネットエントリを更新するには、既存のエントリを削除してから更新します。
    • リソースの場所の名前を変更したり削除したりする場合は、Adaptive Authenticationインスタンスからもエントリを削除してください。

    コネクタを指定

ステップ 2: アダプティブ認証ポリシーを構成する

プロビジョニング後、アダプティブ認証管理 IP アドレスに直接アクセスできます。ただし、IP アドレスを使用してインスタンスにアクセスすることは信頼できず、多くのブラウザは警告を表示してアクセスをブロックします。Citrix では、セキュリティ上の障壁を回避するために、FQDNを使用してアダプティブ認証管理コンソールにアクセスすることをお勧めします。Adaptive Authentication 管理コンソール用の FQDN を予約し、プライマリおよびセカンダリの管理 IP アドレスにマッピングする必要があります。

たとえば、AA インスタンスの IP が 20.1.1.1 で、セカンダリ:20.2.2.2 の場合、

  • primary.domain.com は 20.1.1.1 にマッピングできます

  • secondary.domain.com は 20.2.2.2 にマッピングできます

Adaptive Authentication インスタンスにアクセスしたら、要件に従って認証フローのユースケースを設定できます。さまざまなユースケースについては、「 認証設定の例」を参照してください。

FQDN を使用してアダプティブ認証管理コンソールにアクセスするには、 ADC 管理 UI アクセス用の SSL の設定を参照してください

アダプティブ認証ポリシーを構成する

重要:

  • 高可用性セットアップでは、同期プロセスの一環として、証明書も同期されます。そのため、必ずワイルドカード証明書を使用してください。
  • 各ノードに一意の証明書が必要な場合は、同期されない任意のフォルダに証明書ファイルとキーをアップロードし (たとえば、nsConfig/SSL ディレクトリに個別のフォルダ (nosync_cert) を作成する)、証明書を各ノードに一意にアップロードします。
  • アプリケーションへのシングルサインオンを有効にするには、OAuth IdP プロファイルで [ パスワードを送信 ] オプションを有効にしてください。

ステップ 3: Workspace のアダプティブ認証を有効にする

プロビジョニングが完了したら、[Workspace のアダプティブ認証を有効にする] セクションの [ **有効化 ] をクリックして、Workspace の認証を有効にできます** 。

Workspace のアダプティブ認証を有効にする

注:

このステップで、アダプティブ認証の構成は完了です。

認証方法をアダプティブ認証に移行する

Citrix Gateway として認証方法でアダプティブ認証をすでに使用しているお客様は、 アダプティブ認証を移行してから 、アダプティブ認証インスタンスからOAuth構成を削除する必要があります。

  1. Citrix Gateway 以外の別の認証方法に切り替えます。
  2. [Citrix Cloud]>[IDとアクセス管理]で、[Citrix Gateway]に対応する省略記号ボタンをクリックし、[ 切断]をクリックします。

    ゲートウェイを切断する

  3. [ 登録者エクスペリエンスへの影響を理解しています] を選択し、[ 確認] をクリックします。

    [ 確認] をクリックすると、エンドユーザーへのワークスペースログインが影響を受け、アダプティブ認証が再度有効になるまで、アダプティブ認証は認証に使用されません。

  4. アダプティブ認証インスタンス管理コンソールで、OAuth 関連の構成を削除します。

    CLI を使用して次の操作を行います。

    unbind authentication vs <authvsName> -policy <oauthIdpPolName>
    rm authentication oauthIdpPolicy <oauthIdpPolName>
    rm authentication oauthIdpProfile <oauthIdpProfName>
    <!--NeedCopy-->
    

    GUI を使用すると次のようになります。

    1. セキュリティ > AAA-アプリケーショントラフィック > 仮想サーバに移動します
    2. OAuth ポリシーのバインドを解除します。
    3. セキュリティ > AAA-アプリケーショントラフィック > ポリシー > 認証 > 詳細ポリシー > OAuth IDPに移動します。
    4. OAuth ポリシーとプロファイルを削除します。
  5. Citrix Cloud]>[IDとアクセス管理]に移動します。 [認証] タブの [アダプティブ認証] で、省略記号メニューをクリックし、[ 管理] を選択します。

    OR アクセス https://adaptive-authentication.cloud.com

  6. [ 詳細を表示] をクリックします。
  7. [ 証明書のアップロード ] 画面で、次の操作を行います。
    • アダプティブ認証 FQDN を追加します。
    • 証明書とキーファイルを削除して、もう一度アップロードします。

    FQDN を編集

    重要:

    アダプティブ認証に移行せずにFQDN または証明書とキーのペアを直接編集すると、ID とアクセス管理への接続が失敗し、次のエラーが表示されます。これらのエラーを修正するには、アダプティブ認証方式に移行する必要があります。

    • ADC コマンドがエラーで失敗しました。ポリシーは、指定された優先度に既にバインドされています。
    • ADC コマンドがエラーで失敗しました。バインドされていないポリシーはバインド解除できません。
  8. [変更の保存] をクリックします。

    この時点で、ID とアクセス管理では、 アダプティブ認証が [ 接続済み ] と表示され、アダプティブ認証インスタンスには OAuth プロファイルが自動構成されています。

    これは GUI から検証できます。

    1. アダプティブ認証インスタンスにアクセスし、認証情報を使用してログインします。
    2. セキュリティ > AAA-アプリケーショントラフィック > 仮想サーバに移動します。OAuth IdP プロファイルが作成されていることを確認する必要があります。
    3. Citrix Cloud]>[IDとアクセス管理]に移動します。アダプティブ認証は [ 接続済み ] ステータスです。
  9. アダプティブ認証のホームページで [ 有効にする ] (手順 3) をクリックして、アダプティブ認証方法を再度有効にします。

    認証を有効にする

    この手順により、ワークスペース構成で認証方法がアダプティブ認証として有効になります。

  10. [ 有効化] をクリックした後、手順 3 のワークスペースリンクをクリックします。認証方法がアダプティブ認証に変更されていることを確認する必要があります。

注:

新規ユーザーは、OAuth 関連の設定を削除する手順を除いて、同じ手順に従う必要があります。

FQDN を編集する

Workspace 構成で認証方法としてアダプティブ認証が選択されている場合は 、FQDN を編集できません。FQDN を編集するには、別の認証方法に切り替える必要があります。ただし、必要に応じて証明書を編集できます。

重要:

  • FQDN を変更する前に、新しい FQDN が IdP 仮想サーバーのパブリック IP アドレスにマッピングされていることを確認します。
  • OAuthポリシーを使用してCitrix Gateway に接続している既存のユーザーは、 認証方法をアダプティブ認証に移行する必要があります。詳細については、「 認証方法をアダプティブ認証に移行する」を参照してください。

FQDN を編集するには、次の手順を実行します。

  1. アダプティブ認証から別の認証方法に切り替えます

    認証方法を切り替える

  2. [ 登録者エクスペリエンスへの影響を理解しています] を選択し、 [ 確認] をクリックします。

    [ 確認] をクリックすると、エンドユーザーへのワークスペースログインが影響を受け、アダプティブ認証が再度有効になるまで、アダプティブ認証は認証に使用されません。そのため、メンテナンス時間中に FQDN を変更することをお勧めします。

  3. [ 証明書のアップロード ] 画面で、FQDN を変更します。

    FQDN を編集

  4. [変更の保存] をクリックします。

    重要:

    FQDN を編集する場合は、証明書も再度アップロードする必要があります。

  5. アダプティブ認証のホームページで [ 有効にする ] (手順 3) をクリックして、アダプティブ認証方法を再度有効にします。

    認証を有効にする

  6. [ 更新] をクリックします。

高度な構成オプション

アダプティブ認証 GUI を使用して、以下を設定することもできます。

  • Adaptive Authentication インスタンスのアップグレードをスケジュールする
  • アダプティブ認証インスタンスのプロビジョニングを解除する
  • ゲートウェイへの安全なアクセスを可能にする

詳細オプション

Adaptive Authentication インスタンスのアップグレードをスケジュールする

現在のサイトまたは配置では、アップグレードのメンテナンスウィンドウを選択できます。

重要:

アダプティブ認証インスタンスをランダムな RTM ビルドにアップグレードしないでください。すべてのアップグレードはCitrix Cloud によって管理されます。

  1. アダプティブ認証 UI の [ アダプティブ認証インスタンスのプロビジョニング ] セクションで、省略記号ボタンをクリックします。
  2. アップグレードのスケジュールをクリックします。
  3. アップグレードの日時を選択します。

アップグレードをスケジュールする

アダプティブ認証インスタンスのプロビジョニングを解除する

お客様は、以下の場合、およびCitrix サポートからの提案に従って、アダプティブ認証インスタンスのプロビジョニングを解除できます。

  • Adaptive Authenticationインスタンスにはアクセスできません (特にスケジュールされたアップグレード後)。ただし、このシナリオは発生しない可能性があります。
  • 顧客が VNet ピアリングモードからコネクタモードに、またはその逆に切り替える必要がある場合。
  • 顧客が VNet ピアリングモードのプロビジョニング時に間違ったサブネットを選択した場合 (サブネットがデータセンターまたは Azure VNet 内の他のサブネットと競合する)。

注:

プロビジョニングを解除すると、インスタンスの設定バックアップも削除されます。そのため、Adaptive Authentication インスタンスをプロビジョニング解除する前に、バックアップファイルをダウンロードして保存する必要があります。

アダプティブ認証インスタンスのプロビジョニングを解除するには、以下を実行します。

  1. アダプティブ認証 UI の [ アダプティブ認証インスタンスのプロビジョニング ] セクションで、省略記号ボタンをクリックします。
  2. プロビジョニング解除をクリックします

    注:

    プロビジョニングを解除する前に、 Citrix Gateway をワークスペース構成から切断する必要があります。

  3. アダプティブ認証インスタンスのプロビジョニングを解除する顧客 ID を入力します。

プロビジョニング解除

ゲートウェイへの安全なアクセスを可能にする

  1. アダプティブ認証 UI の [ アダプティブ認証インスタンスのプロビジョニング ] セクションで、省略記号ボタンをクリックします。
  2. [ ゲートウェイへの安全なアクセス] をクリックします。

    安全なアクセス

  3. [ キーの有効期限] で、新しい SSH キーの有効期限を選択します。
  4. [ キーを生成してダウンロード] をクリックします。 ページを閉じると表示されないため、後で使用するために SSH 秘密鍵をコピーまたはダウンロードします。このキーは、ユーザー名authadminでアダプティブ認証インスタンスにログインするために使用できます。

    以前のキーペアが期限切れになった場合は、[ Generate and Download keys ] をクリックして新しいキーペアを作成できます。ただし、アクティブにできるキーペアは 1 つだけです。

  5. [完了] をクリックします。

重要:

  • Windows で PuTTY を使用してアダプティブ認証インスタンスに接続している場合は、ダウンロードした秘密キーを PEM に変換する必要があります。詳しくは、https://www.puttygen.com/convert-pem-to-ppkを参照してください。

  • 以下のコマンドを使用して、Windows (バージョン 10) の MAC または PowerShell/Command プロンプトからターミナル経由でアダプティブ認証インスタンスに接続することをお勧めします。 ssh -i <path-to-private-key> authadmin@<ip address of ADC>
  • ADユーザーがアダプティブ認証GUIにアクセスできるようにするには、新しい管理者としてLDAPグループに追加する必要があります。詳しくは、https://support.citrix.com/article/CTX123782を参照してください。 その他のすべての構成では、CLIコマンドではなくアダプティブ認証GUIを使用することをお勧めします。

Azure VNet ピアリングを使用してオンプレミス認証サーバーへの接続をセットアップする

この構成は、接続タイプを Azure VNet ピアリングとして選択した場合にのみ設定する必要があります。

注: Okta、Azure AD、Ping などのサードパーティ IdP を使用している場合、この手順は不要です。

  1. アダプティブ認証の接続 UI で、[ プロビジョニング] をクリックし、[ Azure VNet ピアリング] をクリックします。

    VNet ピアリング

    Citrix 管理サービスプリンシパル ]フィールドには、Citrixが顧客のために作成したAzureサービスプリンシパルのアプリケーションIDが含まれます。このサービスプリンシパルは、Citrix がサブスクリプションおよびテナント内のVNetにVNetピアリングを追加できるようにするために必要です。

    このサービスプリンシパルが顧客テナントにログインできるようにするには、顧客サイトの管理者 (テナントのグローバル管理者) が次の PowerShell コマンドを実行して SPN をテナントに追加する必要があります。CloudShell も使用できます。 Connect-AzureAD New-AzureADServicePrincipal -AppId $App_ID Citrix $App_ID が共有するSPNアプリケーションIDはどこですか。

    注:

    • 前述のコマンドは、役割の割り当てに使用する必要があるサービスプリンシパル名を出力します。
    • このサービスプリンシパルがAzure VNetピアリングを追加できるようにするには、顧客サイトの管理者(グローバル管理者に限定されない)が、Citrix 管理VNetにリンクされている必要があるVNetに「ネットワーク寄稿者」役割を追加する必要があります。
    • SPN は、Azure で Citrix 仮想ネットワークを関連付けるために使用される一意の識別子です。SPN を VNet に関連付けると、Citrix 仮想ネットワークが Azure の VNet を介してお客様のオンプレミスネットワークに接続できるようになります。
  2. VNet ピアリングを作成します。

    • 前の手順を実行したテナント ID を入力し、[ 取得] をクリックします。

    これにより、カスタマー管理の VNet リソース ID に、SPN のネットワーク貢献者ロールが追加された候補 VNet が入力されます。VNet が表示されない場合は、前の手順が正しく実行されていることを確認するか、手順を繰り返します。

    注:

    テナント ID を見つける方法について詳しくは、「https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-to-find-tenant」を参照してください。

  3. オンプレミスネットワークを Azure に接続するには、[Azure VPN Gateway を使用 ] を選択します。
  4. [ カスタマー管理 VNet リソース ID] で、ピアリング用に識別された VNet を選択し、[ 追加] をクリックします。 VNet がテーブルに追加され、初期状態は [ 進行中] になります。ピアリングが正常に完了すると、[ステータス] が [ 完了] に変わります。
  5. [完了] をクリックします。
  6. 構成を続行します。「 ステップ 1: アダプティブ認証のプロビジョニング」を参照してください。

    重要:

    • Citrixが管理するVNetとオンプレミスネットワークの間でトラフィックを流すには、トラフィックをCitrix Managed VNetに転送するようにファイアウォールとルーティングのルールをオンプレミスで変更することがあります。
    • 一度に追加できる VNet ピアは 1 つだけです。現在、複数の VNet ピアリングは許可されていません。VNet ピアリングを削除するか、必要に応じて作成できます。

プロビジョニングが完了しました

その他の関連構成

authadmin パスワードを変更する

次の手順を使用して、インスタンスと ADM デバイスプロファイルの両方で、 authadmin ユーザーのパスワードを変更できます。

  1. [ システム] > [ユーザー管理] > [ユーザー] に移動し、ユーザーを作成します。詳細については、「 ユーザーアカウントを構成する」を参照してください。
  2. 構成を保存します。
  3. Citrix Application Delivery Management サービスで、次の操作を行います。
    • ネットワーク > インスタンス > Citrix ADCに移動します。
    • [プロファイル] をクリックし、Gateway-Hosted というプレフィックスが付いたプロファイルを選択します。
    • [ パスワードの変更 ] を選択し、手順 2 で使用したパスワードを設定します。
    • [ 戻る] をクリックします。
    • Citrix ADC > アクションの選択 > 再検出に移動します

詳しくは、「 Citrix ADC MPXおよびVPX rootパスワードを変更する方法」を参照してください。

カスタムワークスペース URL またはバニティ URL

カスタムワークスペース URL またはバニティ URL には、現在のクライアント ID、シークレット、およびオーディエンスと同じで、リダイレクト URL がhttps://your.company.com/core/login-cipである新しい OAuthIdP プロファイルを設定します。この例では、 your.company.com はドメインに対応するカスタムワークスペース URL です。たとえば、nssvctesting.netはドメインで、カスタムワークスペース URL はws1.nssvctesting.netです。 新しい OAuthIdP ポリシーを作成し、認証および承認仮想サーバーにバインドします。

注:

両方の OAuthIdP ポリシーは共存でき、ユーザーはデフォルトのワークスペース URL またはカスタムワークスペース URL、あるいはその両方を使用して Workspace にアクセスできます。

構成のバックアップと復元

アプリケーション配信管理サービスは、Adaptive Authentication インスタンスのバックアップ管理を実行します。詳しくは、「 Citrix ADC インスタンスのバックアップと復元」を参照してください。

  1. [アプリケーション配信管理] タイルで、[ 管理] をクリックします。
  2. インフラストラクチャ > インスタンスに移動し 、バックアップにアクセスします。

注意:

オンボードされたサービスが表示されない場合は、アプリケーション配信管理サービスをオンボーディングしてください。詳細については、「 はじめに」を参照してください。

トラブルシューティング

問題は、設定のさまざまな段階に基づいて分類されます。

  • プロビジョニング — アダプティブ認証インスタンスのプロビジョニング中の問題
  • インスタンスのアクセシビリティの問題:インスタンスはプロビジョニングされているが、管理者はアクセスできない
  • AD/RADIUSの接続と認証の問題:認証ポリシーがオンプレミス用に設定されているが、機能しない
  • 認証に関する問題
  • EPA/デバイスポスチャ関連の問題
  • スマートタグ関連の問題
  • ログ収集

アダプティブ認証 CLI を使用して問題のトラブルシューティングを行うこともできます。CLI に接続するには、次の操作を行います。

  • putty/securecrt などの SSH クライアントをマシンにダウンロードします。
  • 管理 IP (プライマリ) アドレスを使用してアダプティブ認証インスタンスにアクセスします。
  • 認証情報でログインします。

詳しくは、「 Citrix ADCアプライアンスへのアクセス」を参照してください。

アダプティブ認証ログのロギングを有効にする

アダプティブ認証ログをキャプチャするには、必ずログレベルを有効にしてください。

CLI を使用してログを有効にする:

  1. 適応型認証インスタンス CLI にログインします。
  2. PuTTY を使用して、管理認証情報を入力します。
  3. エラーが発生したコンピューター上で set audit syslogParams logLevel ALL

GUI を使用してログを有効にする:

  1. ブラウザを使用して適応型認証インスタンスにログインします。
  2. [ 構成] > [システム] > [監査]に移動します。
  3. [監査] ページの [ 設定] で、[ 監査 Syslog 設定の変更] をクリックします。
  4. ログレベル」で「 すべて」を選択します。

プロビジョニングに関する問題

  • アダプティブ認証 UI にアクセスできません

    顧客 ID/テナントでエンタイトルメントが有効になっているかどうかを確認します。

  • プロビジョニングページで45分以上動かなくなる

    エラーのスクリーンショットを収集し、Citrix サポートにお問い合わせください。

  • VNet ピアがダウンしています

    • このピアリングに対応するアラートが Azure Portal にあるかどうかを確認し、推奨されるアクションを実行します。
    • ピアリングを削除し、アダプティブ認証 UI から再度追加します。
  • プロビジョニング解除は完了していません

    Citrixサポートに連絡してください。

インスタンスのアクセシビリティ問題

  • インスタンスの管理 IP アドレスにアクセスできない

    • アクセスに使用されるクライアントのパブリックIPアドレスが、許可された送信元IPアドレスに含まれているかどうかを確認します。

    • クライアントの送信元 IP アドレスを変更するプロキシがあるかどうかを検証します。

  • インスタンスにログインできません

    プロビジョニング中に入力した認証情報で、管理者アクセスが正常に機能していることを確認します。

  • エンドユーザーには完全な権限がない

    ユーザーを追加するときに、アクセスに適したコマンドポリシーをバインドしていることを確認してください。詳しくは、「 ユーザー、ユーザーグループ、およびコマンドポリシー」を参照してください。

AD または RADIUS 接続の問題

Azure Vnet ピアリング接続タイプの問題:

  • 顧客管理の Azure VNet がアダプティブ認証インスタンスから到達可能かどうかを確認します。
  • 顧客が管理する Azure VNet から AD への接続/到達可能性が機能しているかどうかを確認します。
  • オンプレミスから Azure VNet にトラフィックを誘導するための適切なルートが追加されていることを確認します。

Windows ベースのコネクタ:

  • すべてのログはディレクトリ /var/log/ns.log で利用でき、各ログには [NS_AAUTH_TUNNEL] という接頭辞が付いています。
  • ログの ConnectionId を使用して、さまざまなトランザクションを相互に関連付けることができます。
  • コネクタ仮想マシンのプライベート IP アドレスが RADIUS サーバの RADIUS クライアントの 1 つとして追加されていることを確認します。その IP アドレスはコネクタのソース IP アドレスだからです。

    認証要求ごとに、アダプティブ認証インスタンス(NS-AAAD プロセス)と認証サーバの間にトンネルが確立されます。トンネルが正常に確立されると、認証が行われます。

    コネクタ仮想マシンがアダプティブ認証 FQDN を解決できることを確認します。

  • コネクタはインストールされているが、オンプレミス接続が失敗する。

    NSAUT-TUNNEL が確立されているかどうかを検証します。

    Cat ns.log | grep -I “tunnel”

    次のサンプルログが認証要求の ns.log ファイルに出力されない場合は、トンネルの確立中に問題が発生しているか、コネクタ側から何らかの問題がある可能性があります。

     LDAP:
     [NS_AAUTH_TUNNEL] Entering bitpump for
     Connection1 => Src : 192.168.0.7:28098, Dst : 10.106.103.60:636 , Connection2 => Src : 10.106.103.70:2271, Dst : 10.106.103.80:443"
     RADIUS:
     [NS_AAUTH_UDP_TUNNEL] MUX channel established"
     <!--NeedCopy-->
    

    ログの詳細を確認し、適切なアクションを実行してください。

    ログの詳細 修正アクション
    接頭辞[NS_AAUTH_TUNNEL]の付いたログはログファイルに含まれません show cloudtunnel vserverコマンドを実行します。このコマンドは、状態が UP の両方 (TCP と UDP) のクラウドトンネル仮想サーバーを一覧表示する必要があります。
    [NS_AAUTH_TUNNEL] Waiting for outbound from connector このログで、次の応答が受信されなかった場合: [NS-AAUTH-TUNNEL] Received connect command from connector and client connection lookupsucceeded" コネクタマシンがアダプティブ認証 FQDN に到達できるかどうかを確認するか、またはコネクタ側のファイアウォールでアダプティブ認証 FQDN へのアウトバウンド接続を確認します。
    [NS_AAUTH_TUNNEL] Server is down or couldn't create connection to ip 0.0.0.0および[NS_AAUTH_TUNNEL] Connect response code 401 is not 200 OK, bailing out" Citrix サポートに連絡してください。

コネクタから応答がありません:

  • アダプティブ認証 FQDN がコネクタ仮想マシンから到達可能であることを確認します。
  • Adaptive Authentication インスタンス上のサーバー証明書にバインドされ、リンクされた中間証明書があることを確認します。

LDAP/RADIUS設定が正しくありません:

AD/RADIUSサーバーのIPアドレスがパブリックIPアドレスの場合は、Citrix ADCアプライアンスの式にサブネットまたはIPアドレスを追加する必要があります。既存の範囲は編集しないでください。

  • CLI を使用してサブネットまたは IP アドレスを追加するには、次の手順を実行します。

     set policy expression aauth_allow_rfc1918_subnets "(CLIENT.IP.DST.BETWEEN(10.0.0.0,10.255.255.255) || CLIENT.IP.DST.BETWEEN(172.16.0.0,172.31.255.255) || CLIENT.IP.DST.BETWEEN(192.168.0.0, 192.168.255.255) || CLIENT.IP.DST.BETWEEN(13.14.0.0, 13.14.255.255)||CLIENT.IP.DST.EQ(1.2.5.4))"
     <!--NeedCopy-->
    
  • GUI を使用してサブネットまたは IP アドレスを追加するには、次の手順を実行します。

    [ Appexpert] > [式]に移動します。 Add expressionaauth_allow_rfc1918_subnets

トンネルが確立されても認証に失敗する場合は、次の手順を使用して問題のトラブルシューティングを行います。

LDAP:

  • バインド DN の詳細を検証します。
  • 接続テストを使用してエラーを確認します。
  • aaad debug を使用してエラーを検証します。
  • CLI を使用してアダプティブ認証インスタンスにログインします。

     shell
     cd /tmp
     cat aaad.debug
     <!--NeedCopy-->
    

一般的な LDAP エラー:

  • サーバータイムアウト — LDAP クエリに対するコネクタからの応答がありません。
  • その他の LDAP エラーについては、https://support.citrix.com/article/CTX138663を参照してください。

Radius:

  • コネクタIPアドレスは、RADIUSサーバ構成でRADIUSクライアントの送信元IPアドレスとして追加する必要があります。

認証に関する問題

  • OAuth のアサーションエラーを投稿する

    • すべてのクレームがADによって提供されていることを確認してください。これを成功させるには7件のクレームが必要です。

    • var/log ns.log ファイル内のログを検証して、OAuth エラーのエラーを特定します。

    • OAuth プロファイルパラメータを検証します。

  • Azure AD 認証がアサーション後にスタックする

    認証をオフに設定して、次の要素として AD 認証を追加します。これは、認証を成功させるために必要なすべての要求を取得するためです。

EPA 関連の問題

  • プラグインは既に存在していますが、プラグインをダウンロードするように求めるプロンプトがユーザーに表示されます。

    考えられる原因:バージョンの不一致またはファイルの破損

    • 開発者ツールを実行し、プラグインリストファイルにCitrix ADCおよびクライアントマシンのバージョンと同じバージョンが含まれているかどうかを検証します。

    • Citrix ADC のクライアントバージョンが、クライアントマシンのクライアントバージョンと同じであることを確認します。

      Citrix ADC のクライアントを更新します。

      アダプティブ認証インスタンスで、[ Citrix Gateway]>[グローバル設定]>[クライアントライブラリの更新]に移動します。

      Citrix ダウンロードのEPAプラグインライブラリページには、詳細情報が表示されます。

    • バージョンが更新されても、要求がCitrix ADCにキャッシュされることがあります。

      show cache objectはキャッシュされたプラグインの詳細を表示します。コマンドを使用して削除できます。

      flush cache object -locator 0x00000023345600000007

    EPA ログ収集の詳細については、「https://support.citrix.com/article/CTX209148」を参照してください。

  • ユーザーがオプションを選択した後に EPA の設定 ([常に]、[はい]、[いいえ]) を元に戻す方法はありますか。

    現在、EPA 設定の復元は手動で行われています。

    • クライアントマシンで、C:\Users<user_name>\ AppData\ Local\ Citrix\ AGEE に移動します。
    • config.js ファイルを開き、trustAlways を null に設定します- "trustAlways":null

スマートアクセスタグの問題

  • スマートアクセスを設定した後、アプリケーションは利用できません

    アダプティブ認証インスタンスとCitrix VDAデリバリーグループの両方でタグが定義されていることを確認します。

    Workspaceデリバリーグループにタグがすべて大文字で追加されていることを確認します。

    これが機能しない場合は、ns.log を収集し、Citrix サポートに連絡することができます。

アダプティブ認証インスタンスの一般的なログ収集

ガイダンスについては、Citrix サポートにお問い合わせください。

認証設定の例

顧客は、任意の認証ポリシーを構成し、それを認証仮想サーバーにバインドできます。認証プロファイルのバインディングは、認証仮想サーバーには必要ありません。構成できるのは認証ポリシーだけです。以下はユースケースの一部です。

重要:

認証の構成は、プライマリノードでのみ行う必要があります。

条件付き認証による多要素認証

マルチファクタ認証によるサードパーティ統合

デバイスのポスチャスキャン (EPA)

その他のシナリオ

セキュリティ責任の共有

顧客から必要なアクション

以下は、セキュリティのベストプラクティスの一環としての顧客からのアクションの一部です。

  • アダプティブ認証 UI にアクセスするための認証情報:お客様は、アダプティブ認証 UI にアクセスするための認証情報を作成し、管理する責任があります。顧客がCitrix サポートと協力して問題を解決している場合、これらの資格情報をサポート担当者と共有する必要がある場合があります。
  • authadmin パスワードの変更:プロビジョニングの一環として、CitrixはCitrix Application Delivery Managementサービスおよびアダプティブ認証インスタンスにauthadminと呼ばれる初期ユーザーと対応するデバイスプロファイルを作成します。顧客は、プライマリノードと ADM のデバイスプロファイルでこのユーザーのパスワードを変更する必要があります。 Citrix Gateway にログオンし、ユーザー名とパスワードを変更します。詳しくは、「 authadmin パスワードの変更」を参照してください。

  • リモートCLIアクセスのセキュリティ:Citrix は、顧客にリモートCLIアクセスを提供します。ただし、顧客は、実行時にインスタンスのセキュリティを維持する責任があります。

  • SSL秘密鍵:Citrix ADCはお客様の管理下にあるため、Citrixはファイルシステムにアクセスできません。顧客は、Citrix ADCインスタンスでホストしている証明書とキーを確実に保護する必要があります。

  • データバックアップ:構成、証明書、キー、ポータルのカスタマイズ、およびその他のファイルシステムの変更をバックアップします。

  • ADCインスタンスのディスクイメージ:Citrix ADC ディスク容量とディスククリーンアップを維持および管理します。顧客は、これらのタスクを安全かつ確実に実行する責任があります。
  • アップグレード:アダプティブ認証インスタンスのアップグレードをスケジュールします。詳細については、「 アダプティブ認証インスタンスのアップグレードをスケジュールする」を参照してください。

顧客とCitrix 双方から必要なアクション

  • ディザスタリカバリ:サポートされているAzureリージョンでは、Citrix ADC高可用性インスタンスは、データ損失から保護するために別々のアベイラビリティゾーンにプロビジョニングされます。Azureのデータ損失が発生した場合、Citrix はCitrixが管理するAzureサブスクリプション内のできるだけ多くのリソースを回復します。

    Azure リージョン全体が失われた場合、顧客は、顧客が管理する仮想ネットワークを新しいリージョンに再構築し、新しい VNet ピアリングを作成する責任があります。

  • パブリック管理 IP アドレスによる安全なアクセス:

    割り当てられたパブリック IP アドレスによって管理インターフェイスへのアクセスを保護し、インターネットへのアウトバウンド接続を許可します。

制限事項

  • 負荷分散仮想サーバーによる認証はサポートされていません。
  • 証明書バンドルのアップロードはサポートされていません。
  • RADIUS 要求を処理するコネクタがダウンすると、RADIUS 認証が数分間影響を受けます。この場合、ユーザーは再認証する必要があります。
  • DNS トンネリングはサポートされていません。お客様のオンプレミスデータセンターの認証サーバーの認証ポリシー/プロファイル(LDAP/RADIUS)で使用されるFQDNの静的レコードをCitrix ADCアプライアンスに追加する必要があります。 DNS 静的レコードの追加の詳細については、「 ドメイン名のアドレスレコードの作成」を参照してください。

  • LDAPプロファイルのネットワーク接続をテストすると 、LDAP サーバーへの接続が確立されていない場合でも、「サーバーに到達可能」として誤った結果が表示される場合があります。「ポートが開いていません」や「サーバーがLDAPではありません」などのエラーメッセージが表示され、失敗を示す場合があります。Citrix では、このシナリオでトレースを収集し、さらにトラブルシューティングを行うことをお勧めします。
  • EPA スキャンを macOS で機能させるには、[ECC カーブ] オプションを [ すべて ] として選択して、デフォルトの ECC カーブを認証および承認仮想サーバーにバインドする必要があります

サービス品質

アダプティブ認証は、高可用性 (アクティブ/スタンバイ) サービスです。