cancel
Showing results for 
Search instead for 
Did you mean: 

VMware View HTML (Blast) and SSO

Highlighted
Occasional Contributor

VMware View HTML (Blast) and SSO

I'm just wondering if anyone has been able to configure SSO with VMware View HTML using Blast? We've successfully configured a bookmark and are able to connect to the View Security Server Blast Gateway and use the view clients via HTML access perfectly, however we have not been able to successfully configure SSO so we are required to enter our credentials at the Security Server login page.

 

We're using an SA4500 and View 5.2 in case that helps. We've logged a job with Juniper but I was wondering if someone in the community has already figured this out?

8 REPLIES 8
Highlighted
Respected Contributor

Re: VMware View HTML (Blast) and SSO

I haven't seen blast, but some queries on this I have are:
Does it use POST?
Does it use basic auth?
What does your policy trace show?
What does your dsrecord show?
Highlighted
Occasional Contributor

Re: VMware View HTML (Blast) and SSO

Hi,

 

Thanks for the reply. I feel I should clarify that I do not know what is required to set up SSO, I've been trying to figure it out but have failed and there is no documentation for this. The security server is designed to be externally facing, so there may not even be a way to get SSO working with the blast gateway but I was hoping that perhaps someone else might've been using blast with an SA device and has some insights that would help me get SSO working.

 

Also, I have logged a job with VMware regarding this and also posted on their forums to see if anyone in that community has any insights.

 

Onto your questions...

 

Does it use POST?

 

By this I am guessing your asking does the Blast Gateway login page use POST? Yes, but from my investigations it appears to be POSTING in xml not HTML, which is something I could not work out on the SA4500. Additionally, the POST does not seem to be sufficient, as when I have sent the POST from the login page (using developer tools in Firefox and in Chrome) it has not logged me in. It does authenticate, as pressing the login button after performing the POST logs you in regardless of what is entered in the username and password fields, however the POST alone doesn't seem to log me in.

 

Additionally to this, the page doesn't seem to be a straight forward log-in page. There appears to be a lot of scripts going on and it's drawing content from different pages/sources to generate the log-in page. Once you log in, the next page comes up where you can select the pool to connect to, however the URL remains the same (/portal/webclient/views/mainUI.html). This leads me to believe that the SSO stuff should actually be directed to/from different resources, however I haven't figured out what. (hence posting here, hoping maybe someone else who understands webpages and SSO and this stuff better then I has figured it out)

 

No matter what I do in the HTTP POST configuration for SSO, the same thing happens when I log in. I get redirected to the View Blast login page and I am required to enter my username and password. When I get to this page I cannot press login get passed like I can when using developer tools, which indicates to me the HTTP POST settings are not working (which I expect since I know this page is using xml POST)

 

Does it use basic auth?

 

Do you mean does it work if I use basic auth as the SSO method? Simple answer is no. I get the exact same as if I am using HTTP POST or even No SSO, I just get redirected to the login page for Blast and am required to enter my credentials to login.

 

What does your policy trace show?

 

The policy trace shows the HTTP POST is being performed, I can't really see anything in it to indicate that the SA thinks there has been any errors, however I believe this is not working due to incorrect setup (because of lack of knowledge/understanding of correct way to do this) so I wouldn't expect to see errors in any of the logs. I have attached sanatised excerpts of the log where I saw POST action was successful. There is quite a few as it appears to be POST'ing whenever a url that matches the resource is loaded.

 

What does your dsrecord show?

 

Again, it shows the connection as I would expect it to show. It looks like the POST is occuring successfully and with the correct login details (username and password) and there are no apparent errors, however it doesn't appear to be having any effect.

 

It would help if you could advise what it is that I am looking for specifically in the logs?

 

Again I feel like I should clarify: I do not know how SSO should be configured for Blast, nor if it's even possible? However I was hoping that someone would have experiance with it and be able to tell me how they got it working, or if they discovered that it was just not possible? My feeling is that if it is possible, then the URL to post to is not the mainUI.html URL but something else, I just haven't yet figured out what it is.

 

Thanks for the assistance! I am looking forward to your next response.

 

Cheers,

Matt Keelan

Highlighted
Occasional Contributor

Re: VMware View HTML (Blast) and SSO

 

I re-ran the dsrecord.log with the SSO policy disabled (uncheck Autopolicy: Single Sign On) and logged into the blast gateway manually. Then I found the post's in the log and sanatised them so I could upload them here.

 

So the below is the POST that the blast gateway login makes when you enter your username and password and hit the login button. This is likely the POST that I need to generate from the SA4500. I attempted to upload it as a txt file but I kept getting the error "The contents of the attachment doesn't match it's file type". The formatting is much better in the text file but as I said I can't seem to upload it.

 

dsrecord.log:

-----------------------------------------------------------------------------------------------------

---- dsrecord.request.before.body:None - 13035.00224 - { 497 } ---- 20131202102259.968721 ---- <?xml version='1.0' encoding='UTF-8'?><broker version='7.0'><do-submit-authentication><screen><name>windows-password</name><params><param><name>username</name><values><value>"USERNAME"</value></values></param><param><name>domain</name><values><value>"DOMAIN"</value></values></param><param><name>password</name><values><value>"PASSWORD"</value></values></param></params></screen></do-submit-authentication><get-tunnel-connection><bypass-tunnel>true</bypass-tunnel></get-tunnel-connection></broker> ---- dsrecord.request.after.header:None - 13035.00225 - { 419 } ---- 20131202102259.969333 ---- POST /broker/xml HTTP/1.0 Host: "Security Server DN" Connection: Keep-Alive Accept: */* Content-Type: application/x-www-form-urlencoded X-Requested-With: XMLHttpRequest Referer: https://"Security Server DN"/portal/webclient/views/windowsPassword.html Accept-Language: en-AU User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0) Content-Length: 497 Cookie: JSESSIONID=73AEF1D408299CD3033F1559D9495FBB

---- dsrecord.request.after.body:None - 13035.00226 - { 497 } ---- 20131202102259.969375 ---- <?xml version='1.0' encoding='UTF-8'?><broker version='7.0'><do-submit-authentication><screen><name>windows-password</name><params><param><name>username</name><values><value>"USERNAME"</value></values></param><param><name>domain</name><values><value>"DOMAIN"</value></values></param><param><name>password</name><values><value>"PASSWORD"</value></values></param></params></screen></do-submit-authentication><get-tunnel-connection><bypass-tunnel>true</bypass-tunnel></get-tunnel-connection></broker> ---- dsrecord.response.before.header:None - 13035.00227 - { 488 } ---- 20131202102301.177571 ---- HTTP/1.1 200 OK Content-Length: 496 Set-Cookie: JSESSIONID=353B92D1116657590A08D458E4DB3965; Path=/; Secure; HttpOnly Set-Cookie: com.vmware.vdi.broker.location.id=2b1deb1f-70bb-42ba-9ed1-ddfcea61b205; Expires=Sat, 20-Dec-2081 02:37:08 GMT; Secure; HttpOnly Set-Cookie: com.vmware.vdi.broker.location.id=2773cb35-b170-4fb1-8eaf-5582f841316c; Expires=Sat, 20-Dec-2081 02:37:08 GMT; Secure; HttpOnly Content-Type: text/xml;charset=UTF-8 Strict-Transport-Security: max-age=31536000

Highlighted
Respected Contributor

Re: VMware View HTML (Blast) and SSO

Thank you for the logs. XML POST is not supported. In addition from your notes, it sounds like the POST is done inside JavaScript (also not supported).
Highlighted
New Contributor

Re: VMware View HTML (Blast) and SSO

Hello Matthew.Keelan,

 

I saw your post and I would like to ask you how did you get HTML access with blast gateway working with Juniper SA?

I configured the bookmarks with the url of my view connection server. I'm able to log in with ny user, choose the pool and after that, I have nothing.

I thing the problem is that when the connection starts after choosing pool, it uses port 8443 to connect to blast gateway so the bookmark are not able to change its url which was using port 443.
To get it working, did you used "Rewriting Options" or just the bookmark with "Web Access Control"?

 

Can you take 5 min to explain me step by step how did you do?

 

Thank you very much in advance.

Highlighted
Occasional Contributor

Re: VMware View HTML (Blast) and SSO

Hi Mizuho,

 

In our environment we have a high regard to security. We not only have the SA device but we also have numerous DMZ environments between our external facing devices and our internal devices. For this reason and to add an additional layer of security I actually install a View Security Server into one of our DMZ environments and that is what the SA device connects to.

 

When you connect to a view machine your connection server drops out of the connection so your traffic is now between your desktop and the machine instead of your desktop and the connection server. Although this shouldn't cause issue's it might be contributing to your problems getting the SA device to work.

 

Essentially in our setup with the Security server, when you first log in and authenticate and get to the screen to choose the pool, the flow is working like this:

 

Internet <-> SA <-> Security Server <-> Connection Server

 

Once you've picked a pool and the connection server does its job, the flow changes to this:

 

Internet <-> SA <-> Security Server <-> View Agent on View Machine

 

While the end device changes from the connection server to the view machine, my SA is always connected to the Security Server as it proxy's all the blast traffic through its blast gateway.

 

There is a setting on the Connection Server somewhere that I vaguely remember coming across that will tell it to proxy all the traffic as well, so your SA would still be expecting all it's traffic from the connection server. I'm pretty sure that it's the Blast Gateway Server setting if you go to View Administrator -> View Configuration -> Servers -> Connection Servers -> Select your connection server -> Edit -> Tick and configure Blast Secure Gateway.

 

That should then proxy all the blast traffic through your connection server and possible help the issue you are having.

 

The other thing to highlight though is that we had an issue with dropouts occurring, which was resolved by installing a rewriting filter that rewrote the 'keep alive' packets. Basically what was happening is that the SA passes all traffic through its rewriting filter. The View agent on the view machine sends heartbeat packets to the browser your using to connect to it. When the heartbeat packets are being delayed due to the rewriting filter, the connection server disconnects the session.

 

To fix it Juniper gave us a patch to install on the SA and we put the URL for the heartbeat packets into it and the heartbeat packets no longer get rewritten. An unfortunate side-affect of this is that VMware changed the heartbeat packets in View 5.3, so when I upgraded the filter stopped working. Juniper didn't have a new one yet as they haven't brought out support for View 5.3 yet so I have to continue to use the 5.2 Agent on the view pools which I want to be able to connect to via our SA.

 

Another thing to check of course is your firewall rules if you have firewalls. We got caught out when we first started cause I had created firewall rules between our security server and connection server but not between our security server and the view pools so after you logged in and connected to the pool, the traffic from the view machine couldn't get through because it was getting blocked. So if you have any firewalls between your SA device and your connection server and view pools, you need to make sure there are rules that will allow the traffic between the SA and connection server, and also the SA and the view pools. However if you are going to use the blast gateway feature on the connection server then you only need the rules between your SA and connection server.

 

Other then that I can only tell you that apart from the filter to allow the heartbeat traffic we use no rewriting options. If that's what you need then just log a case with Juniper support and tell them that your view sessions are dropping out and you need the rewriting filter to allow the heartbeat traffic and they get it to you.

 

In terms of config on the SA we're just using the web application resource profile with a bookmark pointing to our security server, we've added in both http and HTTPS urls with both 443 and 8443 ports in the web access control because when we first set it up we weren't sure how it was going to work, and since it does we haven't removed any sockets we didn't need.

 

To connect without the blast secure gateway you should just need to add the relevant URLs to the relevant web access policies to allow traffic to those resources (the view machines) for the user roles that are connecting. While I can't remember for certain I am fairly sure we had it working before I installed the security server, however it was more time and effort figuring out where the traffic was and what to include in the configuration etc, and then we went and installed the security server anyway so it became a lot easier from the SA point of view.

Highlighted
New Contributor

Re: VMware View HTML (Blast) and SSO

Hi Matthew.Keelan,

I'm sorry to answer only now. I just wanted to thank you for the time you took to help me. I solved the problem just after your post. My configuration on the juniper was good but the problem came from a stupid thing I forgot to configure on the firewal (I don't remember what it was exactly, but that was stupid Smiley Very Happy).

Now it's working very well without the fix of juniper.

Thank you again for your help. Even if my config was correct, it was thanks to your post I realised where the issue came from.

Highlighted
New Contributor

Re: VMware View HTML (Blast) and SSO

Hi -

Is this still the case for Horizon View HTML access and PulseSecure? Running View 6.2 and Pulse Connect Secure 8.1R7

Any way to get SSO working?

Many thanks