Jump to content
Welcome to our new Citrix community!

HTML5 Receiver with passthrough authentication


Kari Ruissalo

Recommended Posts

We're setting up HTML5 Receiver for a customer. They require that all traffic should flow secure and avoid any changes in their Citrix control plane and workers.

 

We got the HTML5 Receiver working neatly using Unified Gateway, but the customer would like to enable SSO for the StoreFront. I have built this sort of setup leveraging the Optimal HDX Routing feature in StoreFront. In this setup the user experience is as follows:

 

  1. User browses to the StoreFront address (LB VIP on NetScaler), something like https://sf.corp.com
  2. User gets passthrough authentication to the StoreFront web
  3. When the user launches application the HDX routing is set up so that the ICA is proxied through a GW (sth like https://gw.corp.com)

 

This gives the user a seamless feel and this is what we're aiming for here, but with HTML 5 client. I can't wrap my head around how to pull this one of.

 

I'm well aware of the WebSockets stuff (we're not able to allow any other ports than TCP/443) and also that if you install certificates to the workers, you can use TCP/443 for these comms also (we're not able to change the workers).

 

Is there a "think-outside-the-box" solution for this, something like leveraging nFactor or AAA to authenticate the users using Kerberos initially and then passthrough authentication for the Gateway?

Link to comment
Share on other sites

Wouldn't it work to use NSGW completely instead of mixing Storefront LB + ICA routing? I'm guessing you don't do this because then you lose the automatic SSO that happens when the internal user, in your scenario, browses to the Storefront LB VIP?

 

Perhaps you could configure a Negotiate Policy (kerberos) on your VPN vServer (or AAA vServer and have the VPN vServer point to the AAA through an authnProfile) to resolve SSO to Netscaler?

Link to comment
Share on other sites

On 10/12/2018 at 2:15 PM, Rasmus Kindberg said:

Perhaps you could configure a Negotiate Policy (kerberos) on your VPN vServer (or AAA vServer and have the VPN vServer point to the AAA through an authnProfile) to resolve SSO to Netscaler?

 

This is exactly what I started thinking of myself also. Initially I tried to use StoreFront authentication (https://www.jgspiers.com/netscaler-gateway-authentication-direct-storefront/#comment-18022) to circumvent this, but that didn't seem to help. I'll look in to the authNprofile, but I'll need to lab this first. I'll get back with the results :)

Link to comment
Share on other sites

I got the AAA vServer working with Negotiate (tried both with and without NTLM fallback to be sure). After the user is authenticated on AAA the session just lands on to the GW logon page that has nothing else but text "Log On" on it.

 

I have previously used nFactor for one SAML IdP solution for attribute extraction with an LDAP policy that has authentication disabled and when I checked, the logs show that the group memberships and attributes are properly extracted for the user. However, I cannot seem to get through from the GW. Ideas?

Link to comment
Share on other sites

It seems to me that when I'm using the AAA vServer via authnprofile it almost works.

 

I'm seeing in the ns.log:

Oct 19 15:11:27 <local0.info> 10.0.0.15 10/19/2018:12:11:27 GMT compingns 0-PPE-0 : default AAATM Message 15649 0 :  "NS kerberos: Successfully verified negotiate data, username from ticket is kari.ruissalo@COMPING.LAB: "
Oct 19 15:11:27 <local0.info> 10.0.0.15 10/19/2018:12:11:27 GMT compingns 0-PPE-0 : default SSLVPN Message 15650 0 :  "marking authv2 session for user: <kari.ruissalo@COMPING.LAB>"
Oct 19 15:11:27 <local0.info> 10.0.0.15 10/19/2018:12:11:27 GMT compingns 0-PPE-0 : default SSLVPN Message 15651 0 :  "epaqs_session_report: Done initializing session; client_type 1, authv2 200000, flags2 200000, flags3 78068"
Oct 19 15:11:27 <local0.info> 10.0.0.15 10/19/2018:12:11:27 GMT compingns 0-PPE-0 : default AAA Message 15652 0 :  "NFactor: Successfully completed Negotiate Auth for user kari.ruissalo@comping.lab at ip bc00000a"

 

So this means that the negotiate succeeds. However, the browser shows the following (with RfWebUI):

x1-fail.thumb.png.34451f4c5ed81d128dddd699ce707630.png

 

If I switch to X1 or DEFAULT theme, the browser just keeps on looping and doesn't go anywhere (the rows above keep on generating in to the ns.log).

 

I did a packet capture and in here I can see that the NetScaler VIP responds with HTTP/1.1 500 Internal Server Error:

pcap.thumb.png.5c45649b8df2fd87a4adcf387a06693e.png

 

I have configured the Session policy so that client choices are disabled and the session should go to StoreFront.

Link to comment
Share on other sites

  • 7 months later...
  • 3 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...