Netscalerの探索にはHOSTSを使用しドメインコントローラの探索にはDNSを使用することで理屈上はなんだかイケそうな気がします。

端末起動とVPN確立のタイミングによっては、ローカルキャッシュで端末ログオンされその後VPNが確立することでドメインコントローラと通信することになります。一般的なドメイン認証が必要なシステムは(ファイルサーバとか)は問題ないかと推測されます。

1点わかったことがあります。
StoreFrontへのログインユーザをドメイン管理者にすることで
VMへもログインでき、利用することができました。
ただ、デリバリグループ作成時に任意のユーザが使えるようにしているので
なぜこのようになるかが分かりません。

以下URLに記載、「ログオン間隔」の問題でした。
https://docs.citrix.com/ja-jp/xenapp-and-xendesktop/7-7/manage-deployment/sessions.html

IE以外のブラウザーからだと接続できたりするのでしょうか。

公開アプリの推奨ブラウザがIEなのですが、Firefoxなどで試してみます。

推奨ブラウザーという話で、おっしゃられている現象が発生しているポイントがわからなくなってきました。

StoreFrontに接続出来ないのかと思っていましたが、StoreFrontまで接続できるものの、公開APを起動した後で表示されたIEのページに申告された現象が発生しているということでしょうか。

あと、Receiverが古すぎると思いますので、バージョンが関係あるのかわかりませんが、
LTSR版の4.4かCRの最新版で違いが出るかみていただいても良い気がします。

他には切り分けとして端末なのかユーザなのか確認するぐらいですね。
問題ないユーザで該当の端末から接続してみてどうかとか逆に問題ない端末から
該当のユーザで接続してどうかなど。

↓こんな情報もあります。
https://121ware.com/qasearch/1007/app/servlet/relatedqa?QID=016945

アドバイスありがとうございます。
説明不十分で申し訳ありませんでした。
URLにStoreFrontのアドレスを入れた時点で表示できないので、StoreFrontに接続出来ていない状態でした。
Firefoxでも「サーバが見つかりません」となります。
セキュリティ設定を見直してみます。

状況理解しました。Edgeは設定などでくせがあるので避けたほうが良いと思いますが、それ以外のブラウザーは特に悪い印象はないですね。

IE、FireFox、Chromeあたりは普通に使っています。

StoreFront側が利用できないのであれば、皆さん使えなくなると思いますので、端末側の問題のように思いますが、あと思い当たることがあるとすれば、接続用のURLが信頼済みサイトに登録されているかぐらいですね。

原因判明しました。
DNSにドメインサーバのIPアドレスがありませんでした。
なぜこうなったのかというと、
本来無線LANで運用していたのですが調子が悪くなり、
エンドユーザが有線LANに切り替えて設定をしていました。
この時に、優先DNSをローカルのルータIPアドレスにしていました。
（どうりでインターネットは使えるはずです）

大変お騒がせいたしました。

Citrixで不具合に遭遇しエラーが表示されるなら
それを程よく英訳して検索すると色々知見が得られます（唐突）
今回の場合「xenapp protocol driver error 6.5」とかです。
そうすると次のようなナレッジがでます。

https://support.citrix.com/article/CTX128115
https://support.citrix.com/article/CTX136826

特に、CTX128115に書かれている内容はよく理解して問題ないか
確認する必要があります。この辺りは確認されましたか？

また、特定のユーザーは問題が出ない、ということは
多くの場合、厳密にテストを繰り返すと、条件がぼんやりとでも
見えてくることが多いので、あきらめずにその辺を追いましょう。

例えば、今回の場合「給与システム」と「給与システム（特権用）」で
挙動が違う場合がある、とありますが、
そうであればAP11～AP13にユーザーが振り分けられ接続する分には問題なく、
AP14に振り分けられると問題が出る、といった推測などもできます。

まぁ、まずは前述のナレッジを追ってください。

Sさん、ありがとうございます。

>それを程よく英訳して検索すると色々知見が得られます
こういう探し方は考えたことがありませんでした。
今後の参考にさせていただきます。


ここからは現状報告です。

いただいたURL確認しました。
英文のため翻訳サイトと合わせて確認しましたが、
無知のためか確認できた事項が少なく、
あまり前進していません。

パッケージソフトのログを確認すると、
AP11・AP12・AP13・AP14全てで起動していたので、
振り分けに問題があるようには思えません。
「給与システム」と「給与システム（特権用）」の公開アプリの設定も念のため比較してみましたが、
サーバー・ユーザー以外に違いはありませんでした。
この状況が私の中で原因が整理できない部分でもあります。

今後も調査を進め、改めてこの場でご報告させていただきます。

技術資料は機械翻訳とかではうまく翻訳できないですし
CTX128115の日本語訳は下手くそパターン（上手い奴もあるんですが）のようなので
頑張って読むしかないです。

>「給与システム」と「給与システム（特権用）」の公開アプリの設定も念のため比較してみましたが、
>サーバー・ユーザー以外に違いはありませんでした。
ということが間違いないのであれば、調べるべきは各XenAppサーバー自体の構成です
特定のサーバーだけに効かせてるCitrix/ドメイングループポリシーがあれば
それも疑わしいのですが

まぁ、概ねXenAppサーバー上のネットワーク周りの動作に問題が
あると考えられます。CTX128115で特に重要なのは

・Citrixのコンピュータポリシー（通常はUnfiltered）で
　License Server Host、License Server Port
　XenApp Product Edition、XML Service Port を適切に設定する。
・XenAppサーバーで、RDセッションホストの構成を開き、
　RDP Listenerのプロパティの「network adapters」」で
　all network adaptersを選ぶ
・All Programs > Citrix > Administrative Tools > ICA Listener Configuration
　で、「ICA-TCP」のプロパティでも同様にall network adapters的なのを選ぶ
・XenAppサーバーとクライアント間で、2598ポート通信は解放されているか

辺り。XenAppサーバーのイベントログなんかも確認するといいですよ。

Sさん、解決しました。
原因は私の勘違い（無知？）でした。

既述のとおりサーバーは全部で4台ですが、WebInterfaceをインストールしたのは1台のみです。
クライアントのIE設定で「プロキシを使用しない」の例外設定を追加するのは
WebInterfaceをインストールしたサーバーのIPアドレスのみでいいと思っていましたが、
これが間違いでした。

「プロキシを使用しない」の例外設定でサーバー4台のIPアドレスに変更したところ、
メッセージは表示されることがなくなりました。


調査を進める中でユーザーの状況をいろいろ聞くと、
・公開アプリをクリックした際にメッセージが表示される場合とされない場合がある。
・メッセージが表示される場合でも何回か繰り返すとアプリが起動する。
・ただし特権用アプリは何回繰り返してもダメ。
とのことでした。

つまり特権用ではない公開アプリをクリックした時に、
WebInterfaceをインストールしたサーバーに接続されればメッセージは表示されず、
このサーバー以外に接続されればメッセージが表示され起動しない、
という現象のようでした。


Sさんからいただいた情報はサーバーの設定をいろいろ見る、
そしてじっくりと見るいい機会になりました。

本当にありがとうございました。

WebInterfaceでしたか。ふーむ。
あんまり納得はいかないですね。なんでだろう。
WebInterfaceサーバーの方でプロキシが設定してあると問題が
起こるといった事象はあるのですが。

解決したという情報をBBSへ投稿下さるのは非常に有意義です。
感謝いたします。

サーバー名、IPアドレス等を引き継ぐ場合、どうしても運用停止期間が生じます。
何かあった場合に、元の2008環境に戻すことも若干面倒です。
私はお勧めしません。

コストはかかりますが、やり方によっては運用停止期間も生じなくなるため、
サーバー名、IPなどの引継ぎは諦めて、2012環境を新設して、
問題なく使用できることを検証。
その後、旧環境と新環境の並行期間を設けて、クライアント側からは接続先を
変更するように通達して促し、移行するよう提案するべきです。

見積り(値段)たけーよボッタくりか！＞( ﾟ⊿ﾟ)

と言われるのを恐れるなら、旧サーバー落として同じ名前で立ててCitrixの方は
SQLDBエクスポートしてインポートすると実は簡単に旧環境と
同じXenAppファームが作れたりはしますが……まぁまぁ怖いですね。私はやりたくない。

早々のアドバイスありがとうございます。
PDC込みだったら事前にある程度構築できるのですが・・・
運用停止は事前に通知していて、なるべく短くしてねとの事なので。
クライアントが５０台ほどあるので、（しかも遠隔地１０個所）
できればReceiverの再インストールはしたくないです。

Receiverの再インストールなんて大した作業じゃないし
お客様（エンドユーザー）にお願いできないんです？
管理者権限がないとできないとかあるのかもですが。

とりあえず有りえそうな魔法っぽい方法は先に書いたように

1．旧環境でSQL DBをエクスポートする
2．旧環境を殺す
3．新環境を綺麗に1から作る（旧環境の構成を諸々丁寧に引き継ぐ）
4．SQL DBをインポートしてファームをリカバリする

ですが、結局3の手順は必要になるわけで、
リスクに見合うほど工数減らないですよきっと。

エンドユーザおっちゃんおばちゃんなので手順書作っても電話問い合わせが殺到します。（経験済み）
クライアントは人海戦術で乗り切ります。
魔法はやめときます。
かかる工数は想定済なので最初のアドバイス通り事を進めようと思います。
ありがとうございました。

Receiver側のXA登録はIPアドレスなんでしょうか。
FQDNなのであれば、同一FQDNとする事で変更作業は必要なくなりませんかね。

名前解決が絡んでくるんで上手いことDNSとかと連携してやらんと
めんどっちいことになりますぞい。

現行サーバと短期間併設させて、タイミングを見計らい夜間にデータ移行し翌朝から新サーバでの運用を行うよう方針変更しましたが、少々気になる事があります。

XenAppサーバはMSのRDライセンスとCitrixライセンスを１台で兼任しています。
サーバ名とIPアドレスを新たに設けた新サーバを併設させるとき、移行期間のライセンス重複は問題なかったと記憶していますが、どうでしょうか？

またクライアント側ですが、XenAppサーバのバージョンは同じ7.5（OSが2008R2から2012R2に変わる）
なのでReceiverの再インストールは必要なく、新サーバへの接続設定だけでいいと思われるのですが？

何か肝心なことを見落としている気がしてなりません。

＞サーバ名とIPアドレスを新たに設けた新サーバを併設させるとき、移行期間のライセンス重複は問題なか
＞ったと記憶していますが、どうでしょうか？

Citrixであれば、以下の内容が公開されています。

https://support.citrix.com/article/CTX209010#P173_22689

Q バージョンアップをしたのですがしばらくの間旧バージョンの新しいバージョンを並行稼働期間が発生します。問題はありますか？


A バージョンアップ前のライセンスと後のライセンスを同時に稼働した場合通常はライセンス使用の違反とみなされますが、バージョンアップなどやむを得ない事情によるものである場合には30日程度はライセンス違反としてはみなしません。なるべく重複運用期間を短くする形での運用を心掛け、その状態をなくしていただけますようお願いいたします。

MSも似たり寄ったりかもしれませんが、ライセンス関係の窓口はいくつかありますが、
マイクロソフト パートナーコールセンターなどへ確認されてはいかがでしょうか。

＞またクライアント側ですが、XenAppサーバのバージョンは同じ7.5（OSが2008R2から2012R2に変わる）
＞なのでReceiverの再インストールは必要なく、新サーバへの接続設定だけでいいと思われるのですが？

バージョンが変わらなければ、特に気にする必要は無いですね。もし、何か問題が起こっているようであれば、この機会に新しいReceiverへのアップデートをお勧めしますが、特に問題も無いのであれば、設定変更
だけで利用可能かと思います。

＞何か肝心なことを見落としている気がしてなりません。

XenAppのOSが変わるとプロファイルの互換性がなくなるので、V2(2008R2)からV4(2012R2)移動プロファイルを利用しているのであればその点注意ですね。

いろいろとありがとうございます。
ライセンスは念のため関係するところに確認します。

留意点をすべて挙げるのは大変なのです。
ドメインコントローラーの構成やGPOやネットワークポートだとか色々。

少しずつでも切り分けを行ってください。

「初回ログイン時にパスワード変更を要求」を外してログオンはできますか？
同様に、手動でパスワードは変更できますか？
SFでユーザーID/パスワードを入力してからの流れで
具体的に、正確にどういうメッセージが表示してログインが蹴られますか？

S様

たびたびお世話になります。

AD側で「初回ログイン時のパスワード変更を要求」を外した場合はログインできます。
VDAに対して、RDPで「初回ログイン時のパスワード変更を要求」をONにした状態でも入れます。

SFでID/PWを入力し、パスワード変更を求める画面が出力されます。
その後、現在のパスワードを一回、変更後のパスワードを二回入力し、ログインを押すと
パスワード変更ができませんとポップがあがり、SFにログインできません。

※windowsアプリケーション接続です。
そもそも、アプリ起動の場合でパスワードを変更する場合は、有効期限が切れた場合のみパスワードの変更が可能なのでしょうか。

XenApp(ServerOSによるアプリケーション/デスクトップ公開)であろうと
XenDesktop(クライアントOSによるデスクトップ公開)であろうと
StoreFrontからADにパスワード変更/認証をかける話ですので
あまり関係がありません。可能です。

>同様に、手動でパスワードは変更できますか？
にご回答がないようですが、どうですか？
次回ログオン時に変更のチェックを外し、StoreFrontにログオンし
「アプリケーションを起動せず」StoreFront（Receiver for Web）の画面の
右上から、パスワード変更できますか？


念のため、↓に記載がありますが
http://docs.citrix.com/ja-ja/storefront/3-8/configure-authentication-and-delegation/configure-authentication-service.html#par_richtext_5
通常は、StoreFrontの管理画面で、対象となるストアを選択し、
「認証方法の管理」から、「ユーザ名とパスワード」等の設定で
「パスワードオプションの管理」を開いて、「ユーザーにパスワードの変更を許可する」とし
「常時」可能なようにすれば、有効期限に関係なくパスワード変更が可能です。

もしほかに非常に面倒な理由を考えるならば、私の経験の一例では
ドメインコントローラーが複数ある場合のレプリケーションラグの影響です。

特定のドメインコントローラー上でユーザーアカウントに「次回ログオン時にパス云々」を
設定しても、それがほかのドメインコントローラにレプリケートされるのにラグがあります。

レプリケートが完了したドメインコントローラに対して認証が行くと、問題ありませんが、
レプリケートが完了していないドメインコントローラーに対して認証が行くと、
変な状態になることがあります。

S様

申し訳ありませんが、手動での変更箇所見当たりません。

今回はPNAgent接続であります。
ご教授頂きました、URLを拝見すると"Windows"での接続では有効期限が切れている
場合のみパスワード変更が可能と見受けられます。
ここでの"windows"とはPNAgent接続のことと理解しております。

そういうことは最初に言ってほしい。
PNAgent（XenApp Serivicesサイト）でReceiverの認証をしているのなら
SFの機能で任意のタイミングでパスワード変更させることはできません。

できるのは、eDcosに記載の通りReceiver for Webを使っている場合のみです。

S様
ご返信、ありがとうございます。

理解が深まりました。

スナップショットなら
http://サーバー名/director/

サーバー名は、デリバリコントローラの役割を持つサーバー名
ログインが必要で、デリバリコントローラで管理者権限を持つドメインユーザーで。

単純にデリバリコントローラにログオンして、
プログラムの一覧の中に「Citrix Director」が居るのでそれを起動すればよいでしょう。

ログオンについては既出の通りです。

上の「フィルター」から「すべての接続」を選んで、
表示：接続
期間：任意
フィルター基準：対象の2012R2サーバーを含むデリバリーグループ名を指定

と条件付けすると良いです。

デフォルトだと、物理端末ホスト名が表示されないと思うので
「列の選択」で「エンドポイント名」を追加する必要があると思う。

御教示頂きありがとうございました。

Directorで確認することができました。

説明だけ読むとCitrixと殆ど関係ないトラブルに見えます。
XenAppサーバーにRDS使ってDomainAdminsでログオンできないって話であれば板違いでしょう。

サーバーOSにVDA入れただけでRDS接続できなくなるなんてことは普通ありません。
単にRDS接続の権限がないだけじゃないですか？
システム管理者であればそのぐらいはご自分でお調べの上、ご相談ください。

Sさんの言うとおりそもそもRDPでログオンできないのであれば、Windows側の設定やポリシーなどを確認されたほうがいいかと思いますが、そういった切り分けも難しいのであれば、該当の機器へリモートでログオンしなくても作業用のクライアントへStudioを導入すれば利用できないでしょうか？

通常はAdministratorsに属していれば気にすることなくRDPで接続できるはずです。
Administratorでログインできないとなると、ポリシーでドメインのAdministratorを
拒否しているとか。一度管理者の方に問い合わせてみてはいかがでしょうか。

Studioを利用したいのであればRDPで接続しなくても公開アプリとしてStudioを登録
したり、RDPで接続しなくても公開デスクトップで接続するとか色々と方法があると
思います。

後はVNCをローカルのAdministratorで導入してクライアントから接続するとか。
これだと直接コンソールへログインできますから。

いろいろとありがとうございました。
確かにCitrixに直接関係ないトラブルでした。

要はStudioの操作が出来ればよいので、
ご意見を参考にさせて頂きます。

連投すいません。具体的なご質問事項を記載しておりませんでした。

・NetScaler上でシングルサインオンを設定しているにも関わらず、
　StoreFrontのログオン画面が表示されてしまう原因として、
　何が考えられるのでしょうか。

・「ログオンの有効期限が切れました。続行するには、もう一度ログオン
　してください。」というメッセージ表示を回避し、StoreFrontに
　ログオンするためには、どのような設定が必要なのでしょうか。

再びの連投すいません。また、長文すいません。

色々と調査を進めたところ、状況が以下の通り変わりました。

　①NetScalerにドメインのユーザー名とパスワードを入力し「ログオン」をクリック
　②StoreFrontのログオン画面が表示
　③ログオンをクリック
　④「要求を完了できません。」というメッセージが表示

さらに、StoreFrontサーバのイベントログにて、上記④を実施したタイミングで
以下エラーイベントが出力されることを確認しました。

ログの名前：Citrix Delivery Services
ソース：Citrix Authentication Service
イベントID：3
レベル：エラー
説明：

[NetScaler Gateway URL]/CitrixAuthService/AuthService.asmx の AG Web Service で以下のエラーが発生しました。このエンドポイントは、2016/04/27 11:22:14 まで無視されます。
Citrix.DeliveryServices.Authentication.CitrixAGBasic.Exceptions.AGCommunicationException, Citrix.DeliveryServices.Authentication.CitrixAGBasic, Version=3.5.0.0, Culture=neutral, PublicKeyToken=null
[NetScaler Gateway URL]/CitrixAuthService/AuthService.asmx の NetScaler Gateway 認証サービスへの通信でエラーが発生しました。認証サービスが実行されていることを確認してください。
場所 Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.AGClient.GetAccessInfo(String sessionId, String username, String domain)
場所 Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.CitrixAGBasicWebService.GetAccessInfo(String sessionId, String username, String domain)

System.Net.WebException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
基礎になる接続が閉じられました: SSL/TLS のセキュリティで保護されているチャネルに対する信頼関係を確立できませんでした
場所 System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
場所 System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
場所 System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
場所 Citrix.DeliveryServices.Authentication.CitrixAGBasic.AGAuthService.AuthenticationServiceSoap.GetAccessInformation(String sessionId, String username, String domain)
場所 Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.AGClient.GetAccessInfo(String sessionId, String username, String domain)

System.Security.Authentication.AuthenticationException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
検証プロシージャによると、リモート証明書は無効です。
場所 System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
場所 System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
場所 System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
場所 System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
場所 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
場所 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
場所 System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
場所 System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
場所 System.Net.ConnectStream.WriteHeaders(Boolean async)

NetScalerの方は切り分けのハードル高いので一旦無視しますが
StoreFrontの方でひとまず「認証」とか「ストア」とか「Receiver for Web」とか
「NetScaler Gateway」の設定を色々再確認してください。

以下サンプル。

・「認証」で認証方式「NSGからのパススルー」を有効にしていますか
・「ストア」でリモートアクセスを有効にしていますか
・同様に、適切な方式・アプライアンスが指定されていますか
・「Receiver for Web」で認証方式「NetScaler Gateway からのパススルー」を
　有効にしていますか
・「NetScaler Gateway」で、NSGのURLやサブネットIPアドレスや
　コールバックURLが適切に設定されていますか
・同様に、SSLを使っているならSTAの設定は適切に設定されていますか

辺り。

Sさん、ご連絡が遅くなりましたが、ご回答ありがとうございました。
以下の通り「NetScaler Gateway」の設定を色々と確認しましたが、
事象の解決には至りませんでした。

・「認証」で認証方式「NSGからのパススルー」を有効にしていますか
　→有効にしています
・「ストア」でリモートアクセスを有効にしていますか
　→有効にしています
・同様に、適切な方式・アプライアンスが指定されていますか
　→「VPNトンネルなし」方式で適切なアプライアンスをしています。
・「Receiver for Web」で認証方式「NetScaler Gateway からのパススルー」を
　有効にしていますか
　→有効にしています
・「NetScaler Gateway」で、NSGのURLやサブネットIPアドレスや
　コールバックURLが適切に設定されていますか
　→サブネットIPはNetScalerがStoreFrontサーバと通信するためのIPを、
　 コールバックURLはNetScaler Gateway URLを指定しています。
・同様に、SSLを使っているならSTAの設定は適切に設定されていますか
　→STAはStoreFrontサーバを指定しています。

なるほど。

現象を単純に見ますと、NSGからSFに対して認証情報が
パススルーする処理がコケてるように見えるわけです。
レス内容を拝見する限り、StoreFront側での設定は概ね適切なようですし
NSG側で何か設定が間違っている/不足しているのだと思います。

で、前レスでも書いたんですが、私はNSGについてはそこまで詳しくなくてですね。
エラー見る限りAuthenticationかCertification Authorityという単語周りな
気はするのですが、これ以上のアドバイスはちょっと難しいです。

可能なら正式なヘルプサポートを受けるなどご検討ください。

NetScakerを利用する場合の認証には2通りあります。
1つはNetScalerの認証画面よりログインしてアプリケーションを利用する方法と、NetScalerの認証画面
ではなくStoreFront側の認証画面で認証した後アプリケーションを利用する方法の2通りあります。
NetScalerの認証画面を利用する場合、ADサーバとLDAPによる認証が必要となり、SNIPよりtcp:389
の通信等が発生します。
エラー発生フローを見る限り、NetScalerにLDAPの設定がされていないように見受けられるのですが、
こちらの設定は大丈夫でしょうか。
NetScalerの認証画面を利用せずに直接StoreFrontでの認証を利用する場合にはLDAPの設定は必要なく
代わりに次の設定が必要です。
1.Virtual ServersのVIPで「Enable Authentication」を無効化
2.StoreFrontでStoreWebの認証設定で「NetScaler Gatewayからのパススルー」を無効化
3.C:\inetpub\wwwroot\Citrix\Store\web.configをメモ帳で開き編集する。
　<resourcesGateways requireTokenConsistency="true">
　を
　<resourcesGateways requireTokenConsistency="false">
　に変更。
　
NetScaler Gatewayとして利用する場合ですが、色々と癖があるので設定が少しややこしいかと。

しげっちさん、コメントありがとうございます。

今回は「NetScalerの認証画面よりログインしてアプリケーションを利用する方法」を
利用したいと考えております。アドバイスいただいたLDAP連携の件ですが、
実はすでに設定済みです。NetScalerのns.logを確認するにLDAP連携関連の
エラーは見当たらないため、設定としては問題ないように思えます。

追加情報となりますが、私の方で調査を進めた結果、StoreFront側で設定する
「コールバックURL」を設定しない（空欄にする）ことでNetScaler経由の
StoreFrontログオンが成功することを確認しました。ただし、社内アクセスと
社外アクセスで適用するCitrixポリシーを分けたいという要件があるため、
「コールバックURL」の指定は必須という認識です。

というのも、上記要件は「SmartAccess」により実現可能と考えており、
「SmartAccess」を利用するためには「コールバックURL」の指定が
必要という認識があります。

上記の考察は間違っておりますでしょうか。また、「SmartAccess」を
利用しない場合、別の方法で上記要件を満たすことは可能でしょうか。

NetScaler経由で制限する場合にはSmartAccessで設定する必要があります（SNIPでも制限できそうですが）。

コールバックURLを登録する場合、2点注意が必要です。

コールバックURLに登録するFQDNですが、NetScalerに割り当てているVIPのIPアドレスを解決する必要が
ありますが、こちらの名前解決はHosts等で既に実施済みでしょうか。
あと、サーバ証明書をプライベート認証局より発行している場合、ルート証明書をStoreFrontサーバに
登録する必要があります。

サーバのログに一部証明書関係のエラーが出ているのでこの2点を確認してください。
SmartAccessですが、ポリシーで指定するファーム名やアクセス条件に「*」以外を利用して細かく制限
する場合には別途ライセンスが必要になった記憶があります。

しげっちさん、返信が遅くなり申し訳ありません。

しげっちさんからのご回答を元に色々と検証を進めたところ、サーバ証明書の箇所でエラーが
発生していたらしく、再度サーバ証明書をNetScalerにバインドし直したところ、
今回の要件を満たす動作を確認しました。しげっちさん、Sさん、ご支援ありがとうございました。