As of NetScaler 12.0 build 51.24 authentication to NetScaler Gateway virtual servers can be performed by StoreFront rather than LDAP.
To send authentication requests to StoreFront, we must use an AAA virtual server which requires NetScaler Enterprise licensing.
You must also have StoreFront 3.11 or above, and use Citrix Receiver 4.4 and above if not authenticating via Receiver for Web.
Impersonation is used by StoreFront to log on the user connecting through NetScaler Gateway. NetScaler sends credentials to StoreFront in JSON format.
When running through the XenApp and XenDesktop or Unified Gateway wizards on NetScaler, you are presented with the option to automate configuration by checking Use this StoreFront for Authentication. Otherwise, for manual configuration read on.
To get started navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Actions -> StoreFrontAuth -> Add.
Enter a name and the URL to your StoreFront server. Click Retrieve Auth Enabled Stores and use the drop-down to select the specific Store you wish to use. For domain, enter your domain NETBIOS name. Click Create.
Navigate to Security -> AAA – Application Traffic -> Policies -> Authentication -> Advanced Policies -> Authentication Policies -> Add. 
Enter a name, choose Action Type StoreFrontAuth and use the drop-down to select your recently created StoreFront authentication action. Enter an appropriate expression and click Create.
Next create an AAA Virtual Server. The server does not need an IP so use Non Addressable as the IP type and click OK. 
The virtual server does need a certificate, but it can be any certificate. This is just to mark the Virtual Server as UP. Bind a certificate and click Continue. 
Click on No Authentication Policy. 
Select your StoreFront authentication policy and click Bind. Finish creating the AAA vServer. 
Next navigate to Security -> AAA – Application Traffic -> Authentication Profile -> Add. 
Enter a name and choose your AAA vServer under Authentication Virtual Server. Under Authentication Host enter anything. Click Create. 
Bind the Authentication Profile to your NetScaler Gateway virtual server. Click OK -> Done. 
Now test logons by browing to the NetScaler Gateway URL. The logon screen is rendered by NetScaler using RfWebUI or whichever theme you use.
Once you click log on, the security logs of StoreFront show the new logon as below. 
At an HTTP level, NetScaler sends a POST to StoreFront. 
The credentials are sent via JSON with masked credentials.
Afterwards NetScaler sends the normal GET request for Receiver for Web UI. 
StoreFront should reply with a 200 OK. 
Pingback: NetScaler Gateway 12 – StoreFrontAuth, and XenDesktop Wizard – Carl Stalhood
George
August 10, 2017thats pretty interesting. does this work for the entire storefront authentication configuration? including 2 factor? i have a custom 2 factor installed on our storefront server. i’m also trying to see if i can have the 2 factor checked before the username/password
George Spiers
August 10, 2017You have 2 factor for internal direct connections to StoreFront or 2 factor for connections via NetScaler Gateway? As far as NetScaler is concerned, it can use direct authentication as described in this post and any other supported authentication type. You can also place each factor in any order you wish.
George
October 8, 2017hmm. tested this out today with little luck. what was your storefront auth config?
George
October 8, 2017tested this out today with little luck. what was your storefront auth config?
George Spiers
October 8, 2017What version of StoreFront are you using? Anything in Event Logs? Check the Security Event Logs on your StoreFront server.
Kal
October 16, 2017Managed to get this working with the Wizard method, but when running through with manual method and then attempting to login I keep getting “Cannot complete your request”
Any ideas?
It seems that the Wizard method is only useable on existing NS gateways if the NS Gateway was also setup with the wizard. Doesn’t seem to recognise the Gateways I created manually.
George Spiers
October 16, 2017When you are running through my manual steps, bind a certificate to the AAA Virtual Server. It can be any certificate, this is just to mark the Virtual Server as UP. The steps originally stated that no certificate was needed, which is incorrect. The steps are updated to reflect this correction.
Kal
October 23, 2017Hello, sorry for late reply. I have checked this and I do have the same certificate applied to both the NS gateway and AAA virtual servers
George Spiers
October 23, 2017Something is not correct in your configuration. If you take a note of your current configuration, compare that to what the XA/XD wizard creates which is a working config. Maybe that way you will identify what is missing.
Matheen
November 6, 2017Hi George, Thanks for your article.
I have an existing PoC setup where users are connecting directly to Storefront with Pass-through authentication turned on.
In new setup, we have AG setup for internal users (to force all traffic through SNIP). This means users need to type their credentials to authenticate at NetScaler.
Users want to be able to use Pass-through authentication. If I configure Storefront-auth as described, will it let users to login without typing their credentials? (pass-through?)
*I have enabled the Pre-reqs for Passthrough to work already*
George Spiers
November 6, 2017Nope – have you looked at Optimal Gateway Routing? You can have users browse directly to the StoreFront URL, use SSO to auth, and then when they launch a resource the connection is routed through your Gateway. https://jgspiers.com/storefront-high-availability-optimal-routing/#Internal-HDX-NetScaler
Matheen
November 7, 2017That is cool. I will try that next week and update you.
Keith
March 1, 2018Thanks for this post George! I have a question in regards to an additional chained nFactor policy.
I have the first factor setup to use StoreFront authentication, as described above. This is then passed on to the next policy that uses RADIUS. The username and password are sent to the RADUIS server and a grid challenge is returned. I have set the schema for the RADIUS policy to NOSCHEMA. This all works great, and I can authenticate as expected.
This is what I would like to know. Since it is using NOSCHEMA, I can’t find a way to modify the Grid Label, and Response box that is returned. Is there a way to make a custom login schema for this type of RADIUS response, or is there some location that I can modify within my theme or LogonPoint to achieve desired results?
George Spiers
March 1, 2018Hi Keith – If you are using noschema, how is a grid response returned via GUI?
So you have StoreFront auth as first factor with an LDAP Login Schema, which is then passed to a next factor Policy Label that uses noschema and a RADIUS policy?
Anonymous
March 1, 2018That is a good question. The storefront auth is using the SingleAuth.xml login schema. The RADIUS policy is indeed bound to the Policy label that uses noschema.
My understanding is that noschema is used when no other information is required, as I already have the required formation from the first factor. That info is passed to the radius server and the response comes back asking for a grid entries to a challenge. But I still don’t know where the grid response input box is coming from.
George Spiers
March 2, 2018Yes noschema can be used to just pass information to a backend server, without having to display another logon form/GUI to the user.
The grid response input box must be coming direct from the RADIUS server, so it would need reconfigured there. I still don’t know how NetScaler is presenting it though!
Srini
August 8, 2018HI Goerge,
I am going through this below article to configure authentication at storefront. can i add multiple domains here . both has trust configured.
the requirement is : login to Citrix URL with one domain and launch resource with another domain account.
we have 2 factor RSA policy is bound to NS VIP
https://support.citrix.com/article/CTX223874 or does this below works for stopping sson.
https://support.citrix.com/article/CTX223785
Thank you!
Keith
March 1, 2018That is a good question. The storefront auth is using the SingleAuth.xml login schema. The RADIUS policy is indeed bound to the Policy label that uses noschema.
My understanding is that noschema is used when no other information is required, as I already have the required formation from the first factor. That info is passed to the radius server and the response comes back asking for a grid entries to a challenge. But I still don’t know where the grid response input box is coming from.
Kari Ruissalo
October 17, 2018Is it possible to allow passthrough authentication for GW using this feature? I have a very specific use case where we would like to get all the traffic flowing via the GW IP and allow HTML5 Receiver experience without direct connections or WebSockets stuff to the published apps.
I set this up according to your instructions and got the authentication working. However, if I add the GW url to the Local intranet zone on IE, I’m still seeing the authentication dialog.
George Spiers
October 18, 2018No that would not be possible. Connecting to StoreFront via an LB VIP and using Optimal Routing should keep everything going through NetScaler? https://jgspiers.com/storefront-high-availability-optimal-routing/
Andrew
October 22, 2018Anyone know if it’s possible to “restrict” specific groups access to the NetScaler Gateway using perhaps some authorization policies now that the AAA vserver is in play?
Also is there any option to “customize the NetScaler Gateway” login page like was done back in 10.5 days?
George Spiers
October 23, 2018Yes you could create Authorization policies and bind them to a AAA Groups that match your AD group names that should have no access to NS Gateway. Alternatively you can edit the Session Profile to deny users from certain groups the ability to login.
NetScaler offers the ability to customise the GUI via the management console -> https://jgspiers.com/customizing-gui-themes-citrix-netscaler-11/
Anything beyond that will require some scripting.
Manu
November 6, 2020HI George,
To put things into perspective, what use case is there to performing LDAP using SF instead of NS?
Is it better in any shape or form than performing LDAP authentication on the Netscaler?
Thank you!
Neil cavendish
June 15, 2021George got a weird one. We are using Storefront auth and through the web everything is working fine. When we use the Workspace it launches, authenticates then disappears. No feed back or anything but does not work. Citrix seem stumped too.
Any thoughts?
Neil cavendish
June 15, 2021I should add that the storefront auth is going through a virtual loadbalancer too on the netscaler. Just incase it makes a diffrence.
Neil
June 15, 2021George got a weird one. We are using Storefront auth and through the web everything is working fine. When we use the Workspace it launches, authenticates then disappears. No feed back or anything but does not work. Citrix seem stumped too.
Any thoughts?
Frank
October 25, 2021Receiver clients do not authenticate if authentication is not enabled at the Citrix Gateway VIP. See https://docs.citrix.com/en-us/storefront/1912-ltsr/integrate-with-citrix-gateway-and-citrix-adc.html
Frank
October 24, 2021Log on to StoreFront when authentication is disabled on Citrix Gateway VIP. This procedure works in two scenarios: Internal networks. App launch fails from remote locations because STAs cannot be used when authentication is disabled on the Citrix Gateway if the X-Citrix-Gateway header is getting passed to StoreFront. Citrix Receiver for Web. Receiver clients do not authenticate if authentication is not enabled at the Citrix Gateway VIP.