NetScaler Gateway authentication direct to StoreFront

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.


29 Comments

  • Pingback: NetScaler Gateway 12 – StoreFrontAuth, and XenDesktop Wizard – Carl Stalhood

  • George

    August 10, 2017

    thats 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

    Reply
    • George Spiers

      August 10, 2017

      You 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.

      Reply
  • George

    October 8, 2017

    hmm. tested this out today with little luck. what was your storefront auth config?

    Reply
  • George

    October 8, 2017

    tested this out today with little luck. what was your storefront auth config?

    Reply
    • George Spiers

      October 8, 2017

      What version of StoreFront are you using? Anything in Event Logs? Check the Security Event Logs on your StoreFront server.

      Reply
  • Kal

    October 16, 2017

    Managed 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.

    Reply
    • George Spiers

      October 16, 2017

      When 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.

      Reply
  • Kal

    October 23, 2017

    Hello, 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

    Reply
    • George Spiers

      October 23, 2017

      Something 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.

      Reply
  • Matheen

    November 6, 2017

    Hi 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*

    Reply
  • Matheen

    November 7, 2017

    That is cool. I will try that next week and update you.

    Reply
  • Keith

    March 1, 2018

    Thanks 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?

    Reply
    • George Spiers

      March 1, 2018

      Hi 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?

      Reply
      • Anonymous

        March 1, 2018

        That 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.

        Reply
        • George Spiers

          March 2, 2018

          Yes 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!

          Reply
          • Srini

            August 8, 2018

            HI 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, 2018

        That 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.

        Reply
  • Kari Ruissalo

    October 17, 2018

    Is 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.

    Reply
  • Andrew

    October 22, 2018

    Anyone 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?

    Reply
    • George Spiers

      October 23, 2018

      Yes 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.

      Reply
  • Manu

    November 6, 2020

    HI 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!

    Reply
  • Neil cavendish

    June 15, 2021

    George 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?

    Reply
    • Neil cavendish

      June 15, 2021

      I should add that the storefront auth is going through a virtual loadbalancer too on the netscaler. Just incase it makes a diffrence.

      Reply
  • Neil

    June 15, 2021

    George 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?

    Reply
  • Frank

    October 24, 2021

    Log 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.

    Reply

Leave a Reply to George Spiers Cancel reply