VMware Workspace ONE Community
access360
Enthusiast
Enthusiast
Jump to solution

The page you were looking for is not available. You may need to contact your administrator with this error: 404 Page Not Found.

I'm at a loss.  I've set up a root CA to sign all my Horizon Workspace servers, SAML is in the green, and after loads of reading a troubleshooting also synced time on all of my ESXi hosts and guests.

Basically what I've done is the following:

Set up VMware View Horizon 5.2 connection server - created various pools and can connect via the different platform clients. (a couple of times to eliminate any possible setup errors along the way)

Setup VMware View Horizon Workspace 1.0 (a few times now) with both self signed and CA signed certs.  My workspace shows up fine, the files sync, apps work, and view pools show up.  When I attempt to launch a desktop from inside of Horizon Workspace I get this error:

The page you were looking for is not available. You may need to contact your administrator with this error: 404 Page Not Found.

Now I think I've tracked it down to something to do with the SAML connection - which to my understanding it to pass tokens between workspace and view.  On the connection server I see this in the Windows event log:

BROKER_USER_AUTHFAILED_SAML_ACCESS_REQUIRED

SAML access required but not attempted by client

Attributes:

    Source=com.vmware.vdi.broker.filters.SamlAuthFilter

    Time=Mon May 20 16:06:41 MDT 2013

    Severity=AUDIT_FAIL

    Node=ViewConnection.access360.ca

    Module=Broker

    Acknowledged=true

Something is not passing through to allow me to access my View desktops from the Horizon Workspace.  If I remove the requirement of SAML on the View Connection Server, when I attempt to log into a desktop from the view connection server I get promoted for and can re-enter my login credentials & domain and have full access with View clients, as well as HTML blast - just can't get there with Horizon Workspace.  It has to be something I'm missing with SAML... 

As I said, I'm at a loss here as to what is not working between the Horizon Workspace and the SAML connection to the View Connection server.  There is no security server, no transfer server, and firewalls are all off, so I don't believe it's a networking issue.  Simple as possible.  As the Windows Event log shows the connection server shows the error is: SAML access required but not attempted by client.  I've got all my servers synced within a couple of seconds - so I don't think the documented time sync sensitivity of the Horizon Workspace vApp is responsible here.  I'm packing it in for the night, but will be doing the exact same thing with a client tomorrow - hopefully without the same result!

Any ideas?

A

Labels (1)
1 Solution

Accepted Solutions
access360
Enthusiast
Enthusiast
Jump to solution

So I re-deployed the vApp (again!) paying close attention as I went.  As per usual, the initial database setup failed because I entered my FQDN for the gateway, so it didn't match.  Following the helpful posts already out there for this (Workspace install fails with Error Creating admin user) I used the connfigurator-va wizardssl.hzn to recreate a rootca for the environment based on my FQDN instead of gateway-va and then let it push it all out to the other vApps.  I then logged into each and pulled down my private rootca and ran c_rehash, etc (another helpful post! - Adding MS signed Certs to Horizon Workspace « Carlos' Corner) I am actually using my UNIX background and openssl to be my own private CA and signing all my certs.  I created the SAN cert and added it to the SSL setup on Configurator-va and Connector-va.  Oddly, both of those server don't seem to be accepting the SAN cert that includes their FDQN, but that's for another day... My Horizon Workspace FQDN does show as trusted by by installed private RootCA (which does show the other DNS names for the service-va, configurator-va, data-va and connector-va, but like I said - a battle for another day) so that's a good thing.  I joined my workspace to my domain - so far so good!  Activated the View Pools in configurator-va - sync'd  - good.  Accepted my view connection server's crt and set up the SAML trust.  Still good.  Sync'd my AD View Users Group which already had a couple of linked clone pools entitled to them.  Good.  Logged into the FQDN of my Workspace and clicked on the Computers - saw my 3 pools.  Clicked on one and after a few seconds launched into a new blast window.  Success!  I logged out and logged in on a different machine, and something I was seeing before but didn't pay much attention to was the connector-va setting of 'use windows authentication'  I couldn't figure why whenever I browsed to my Horizon Workspace a non-vmware window pops up asking for access my FQDN:443 with a user and pass.  It's that setting - duh.  I'm not yet sure what that gives me, so it's off for now.

Thanks for all the input - it's good to know there are others with some of the same issues.  This is still v1.0, so there is bound to be some of those gotchas.  It's finicky with time drift even less than 10 seconds seems to have a negative impact.  Had to ensure my ESXi servers were solid (never worried much in the past with MS AD being pretty tolerant with small drifts)  I tired setting my vApps to a NTP, but they seemed to like being left to the default of syncing to the ESXi host.  See how that pans out.  Certs are a bit finicky depending on your deployment.  Obviously the connector-va and configurator-va don't need to be signed by a CA as they are internal, but still be nice to have then internally signed...

Now I'm onto integrating ThinApps to Desktops as well as the web interface.

I banged my head against the wall with my first Citrix XA and XD setup (before there was VDI in a box!) and it was the best way to learn.

I'm sure I'll stumble along as I finish my PoC, but I'm very happy with the results from today.  I'm still planning on comparing my successful logs with the logs I pulled from my old vApp deployment and seeing what it was that was broke.  I think it was that I was missing a PTR record for my FQDN in MS DNS.  I think I just had the forward lookup for both the original gateway-va and the FQDN, but only a reverse for gateway-va.  Would explain why I was never able to connect BACK to the gateway when accessing a desktop.  Oops.

A

View solution in original post

Reply
0 Kudos
12 Replies
kpelt
Contributor
Contributor
Jump to solution

I only say this because you didn't mention doing it and that is enabling the pools for HTML access.  You need to go into each pool settings and checkmark "enable html access".

If so you might also need to go into the connector-va (port 8443) and under User Attributes you need to checkmark the userPrincipalName required box.  Without this, you will not be able to get to the desktops through workspace.

Reply
0 Kudos
access360
Enthusiast
Enthusiast
Jump to solution

Ah, if only it was that!  I was pretty sure that was all done right - but I double checked it just to be sure.  The Blast gateway works fine when I access it via the FQDN of the View Connection Server with the SAML authentication option set to either not-required or off.  It quickly tries to do what looks like a Single Sign On, then pops up the View Connection server authentication window - asking for windows username, pass and domain.  When I enter that, all is well.  But if I require SAML on the view connection server, it hits the web page that has the orange screen PC monitor with the 'connect to <FQDN>' which is correct for my View Connection Server.

There has to be a trust issue somewhere that I'm just not seeing...

Still banging away at it here, so if I figure it out, I'll be sure to share - and if anyone has any ideas, I'm more than willing to check even the most ridiculous suggestions at this point.

A

Reply
0 Kudos
peterbrown05
VMware Employee
VMware Employee
Jump to solution

so let's check a few basics first... (I dont think this will solve it based on your comments, but lets start here...)

in view, under each connection server, have you configured the SAML Authenticator? and does that point at your horizon gateway?

- on the View Admin Dashboard, the Saml Authenticator health should be showing a Green light.

In Horizon Connector, under the View Pools tab, you should have configured the first connection server. (I am sure this bit is done since you say the desktop icons show in your workspace). However, for each of the connection servers listed, have you Accepted the certificates? and, most importantly, having Accepted the certs, you need to click save to ensure they are saved down to Horizon. If in doubt, please just go back and re-accept those certs and click save again.

Note that you should be able to set SAML as "allowed", which means that launching view should work from the native client directly, AND also from the horizon workspace. Setting to required, means that you can only launch view from horizon workspace.

Further analysis of the problem, then getting a copy of the debug log file from the connection server(s) would be most useful.

cheers

peterB

Reply
0 Kudos
access360
Enthusiast
Enthusiast
Jump to solution

Yes, back to basics.  Removing the Horizon Workspace component from the equation and concentrating on what looks to be just a View Horizon 5.2 issue.

peterbrown05 wrote:

so let's check a few basics first... (I dont think this will solve it based on your comments, but lets start here...)

in view, under each connection server, have you configured the SAML Authenticator? and does that point at your horizon gateway?

- on the View Admin Dashboard, the Saml Authenticator health should be showing a Green light.

Yes - the single connection server I'm using is showing a green light and the cert is trusted.  No issue there.

In Horizon Connector, under the View Pools tab, you should have configured the first connection server. (I am sure this bit is done since you say the desktop icons show in your workspace). However, for each of the connection servers listed, have you Accepted the certificates? and, most importantly, having Accepted the certs, you need to click save to ensure they are saved down to Horizon. If in doubt, please just go back and re-accept those certs and click save again.

Yes, the connection server shows valid and accepted certificates and are saved down into Horizon.  As you sugested I did re-do it to eliminate that as a possible issue.

Note that you should be able to set SAML as "allowed", which means that launching view should work from the native client directly, AND also from the horizon workspace. Setting to required, means that you can only launch view from horizon workspace.

After deciding to look past the Horizon Workspace 'page not found' error and simply look at the connection - with view clients and HTML access - I did have SAML set to required.  I had overlooked the fact that when you first enter the View Connection server URL you haven't yet entered any credentials.  I was always doing this for the View admin page.  When changing it to 'allowed' the window for enter creds pop up and I am able to log into the HTML desktops without issue.  I have toggled that a few times in my journey and it did always work as expected when either disabled or set to allowed.  When I was integrating with Horizon Workspace I wanted the SSO to work and thus assumed (perhaps incorrectly) that SAML is responsible for passing the credentials from Horizon Workspace to the View Connection server.  Regardless of what the SAML requirements is set to it still gets me to the:

The page you were looking for is not available. You may need to contact your administrator with this error: 404 Page Not Found

when I attempt to click on the computer icons in my Workspace environment. When SAML is set to required I was at least getting an error in my connection server windows event log showing:

BROKER_USER_AUTHFAILED_SAML_ACCESS_REQUIRED

SAML access required but not attempted by the client.  (I assume in this case the client is Workspace SSO?)

So I believe the connection server components are working as they should.  Now I need to get the desktops to launch from the Horizon Workspace.  I'll have to collect the logs and review what the process looks like between the components in the vApp as they accept credentials and provide access to application and desktops.  The data component works without issue, so one hurdle down.  The Apps I haven't look too closely at as I was concentrating on the Desktop access first.

Further analysis of the problem, then getting a copy of the debug log file from the connection server(s) would be most useful.

cheers

peterB

Reply
0 Kudos
peterbrown05
VMware Employee
VMware Employee
Jump to solution

hi,

ok some more questions  - hopefully we can figure this out soon for you;

have you installed the VMware-Horizon-View-HTML-Acces component on your connection servers? (its part of the feature pack downloads). This component provides the html access "portal page". I wonder if this is the page that is missing.

Have you tried launching view using a native view client? (right click, select launch using pcoip).

Can you launch a blast desktop from the portal page without using horizon workspace?

When you authenticate with Horizon Workspace, then are you logging into it using your AD credentials? If so, then when it launches view then it can pass your ad credentials (via the magic of SAML) to the desktop and hence SSO you into view - and - your desktop. If you dont authenticate with workspace using AD credentials, then it will still get you into your desktop - but - Microsoft windows will prompt you for your usual ad credentials at its logon screen.

for reference, SAML is a mechanism that allows View to "trust" horizon workspace, and it will authenticate the user with view. As mentioned above, if horizon workspace knows your AD credentials then it will permit the SSO into your desktop.

Let me know about the above, and hopefully we can get your issue resolved asap,

cheers

peterB

access360
Enthusiast
Enthusiast
Jump to solution

Thanks for the reply.  Everything is working fine for View Horizon 5.2.  Both HTML and View Clients (tested iPad, OSX and Windows).  The options for SAML - Disabled, Allowed and Required - got me hung up on it being a SAML thing with View 5.2.  I knew it worked - both client and HTML access - when set to allowed or disabled.  Having entered credentials in the View Connection Admin webpage I had wrongly assumed they were my Windows creds for View Connection desktops.  So - all that is working fine now with my Test OU of View Users - both native client and HTML.

So I'm left with the 404 page not found error when after logging into Horizon Workspace and browsing to the Computers tab.  My provisioned and assigned desktop is there - with the HTML agent and latest view 5.2 agent x64.  When I click on it, it opens a new tab (in both Chrome and IE) and reports 'The Page you are looking for is not available.  You may need to contact your administrator with this error: 404 Page Not Found'  Well, as the admin, I have no idea Smiley Wink

I've tried this now with a few different pools, a view user promoted to a full domain admin, re-installed agents, clean installs of windows 7 and install of agents, as well as a complete rebuild on the vApp to see if there was something there.  I've eliminated any cert errors by the looks of things with a proper SAN cert that is signed by my rootCA (self signed, but has been added to the vApps following along with this link: http://cars.lostroncos.org/2013/03/16/adding-ms-signed-certs-to-horizon-workspace/)  The rootCA is on all servers, clients and on the guest Win7 desktop I'm attempting to connect to via Horizon Workspace.

I'm not seeing anything in the Connection Server logs - or at least in the windows event log and the event database setup for View Connection Server events.

I'm going to be digging into the vApp logs next to see if there is something there.  Something isn't delivering the page for the connection to the View Connection Server from inside of the Horizon Workspace - and WOW - could VMWare made the product line any more confusing by adding Horizon to everything.

I can collect logs and whatever else if that will help diagnose my issues.  This is all basically a PoC in my rather overbuilt home lab, so nothing confidential needs to be scrubbed in logs.  BTW - I'm keeping away looking a the external access right now as I want to have everything solid on my LAN which is all running on one subnet and IP pool  (for Horizon anyway)

Thanks again,

Alex

Reply
0 Kudos
peterbrown05
VMware Employee
VMware Employee
Jump to solution

so if you can grab the logs from Horizon workspace (im not sure which one will be most useful here - so grab the connector, service and gateway logs). and please get the debug log from the view connection server.

Knowing your user name that is trying to log in would also be helpful (or an approx time when the login failed) will help us find the offending info in the logs a bit quicker.

cheers

peterB

Reply
0 Kudos
peterbrown05
VMware Employee
VMware Employee
Jump to solution

also, can you copy paste the URL that the browser is trying to access, and identify if thats a URL pointing at your connection server, or one of the horizon workspace va's?

this might help us understand what its trying to access and cant...

Reply
0 Kudos
access360
Enthusiast
Enthusiast
Jump to solution

The logs - even with archives removed at just over 5MB.  What's the best way to get them to you?  Could could tail them all, but scp was easier.

Reply
0 Kudos
peterbrown05
VMware Employee
VMware Employee
Jump to solution

ive sent you a private message with details.

can you let us know the URL that the webbrowser is trying to get to when you get the 404?

cheers

p

Reply
0 Kudos
access360
Enthusiast
Enthusiast
Jump to solution

So I re-deployed the vApp (again!) paying close attention as I went.  As per usual, the initial database setup failed because I entered my FQDN for the gateway, so it didn't match.  Following the helpful posts already out there for this (Workspace install fails with Error Creating admin user) I used the connfigurator-va wizardssl.hzn to recreate a rootca for the environment based on my FQDN instead of gateway-va and then let it push it all out to the other vApps.  I then logged into each and pulled down my private rootca and ran c_rehash, etc (another helpful post! - Adding MS signed Certs to Horizon Workspace &amp;laquo; Carlos&amp;#039; Corner) I am actually using my UNIX background and openssl to be my own private CA and signing all my certs.  I created the SAN cert and added it to the SSL setup on Configurator-va and Connector-va.  Oddly, both of those server don't seem to be accepting the SAN cert that includes their FDQN, but that's for another day... My Horizon Workspace FQDN does show as trusted by by installed private RootCA (which does show the other DNS names for the service-va, configurator-va, data-va and connector-va, but like I said - a battle for another day) so that's a good thing.  I joined my workspace to my domain - so far so good!  Activated the View Pools in configurator-va - sync'd  - good.  Accepted my view connection server's crt and set up the SAML trust.  Still good.  Sync'd my AD View Users Group which already had a couple of linked clone pools entitled to them.  Good.  Logged into the FQDN of my Workspace and clicked on the Computers - saw my 3 pools.  Clicked on one and after a few seconds launched into a new blast window.  Success!  I logged out and logged in on a different machine, and something I was seeing before but didn't pay much attention to was the connector-va setting of 'use windows authentication'  I couldn't figure why whenever I browsed to my Horizon Workspace a non-vmware window pops up asking for access my FQDN:443 with a user and pass.  It's that setting - duh.  I'm not yet sure what that gives me, so it's off for now.

Thanks for all the input - it's good to know there are others with some of the same issues.  This is still v1.0, so there is bound to be some of those gotchas.  It's finicky with time drift even less than 10 seconds seems to have a negative impact.  Had to ensure my ESXi servers were solid (never worried much in the past with MS AD being pretty tolerant with small drifts)  I tired setting my vApps to a NTP, but they seemed to like being left to the default of syncing to the ESXi host.  See how that pans out.  Certs are a bit finicky depending on your deployment.  Obviously the connector-va and configurator-va don't need to be signed by a CA as they are internal, but still be nice to have then internally signed...

Now I'm onto integrating ThinApps to Desktops as well as the web interface.

I banged my head against the wall with my first Citrix XA and XD setup (before there was VDI in a box!) and it was the best way to learn.

I'm sure I'll stumble along as I finish my PoC, but I'm very happy with the results from today.  I'm still planning on comparing my successful logs with the logs I pulled from my old vApp deployment and seeing what it was that was broke.  I think it was that I was missing a PTR record for my FQDN in MS DNS.  I think I just had the forward lookup for both the original gateway-va and the FQDN, but only a reverse for gateway-va.  Would explain why I was never able to connect BACK to the gateway when accessing a desktop.  Oops.

A

Reply
0 Kudos
peterbrown05
VMware Employee
VMware Employee
Jump to solution

cool - glad you got it going in the end.

cheers

peterB

Reply
0 Kudos