Highlighted
Enthusiast
Enthusiast

View Client for Windows Security Problem - Login without password

Hi,

I am starting this thread to get VMware to put focus om the security problem they have with the Windows View Client.

The problem discription:

When a costumer starts using View 4, they often have a lot og old machines. They can be converted to "thin" client, by installing a Windows XP, with nothing else than a View Client. To avoid multiple logins for the user, the machines can be installed as stand-alone (Not part of the domain) with autologin, that means no password, or a predefined password that the user dont know, or all users know.

Then when a user starts the computer the View client starts automatically, and the user is prompet for his credentials, for the first and only time. When he connects to a View Desktop, single sing on connects him, and logs him in.

The users now decides that it is time for a coffee break. And he locks Windows in his Virtual Desktop witch is in full screen mode, but the "thin" physical windows client is not locked. And there is no need to lock it since the user don't know that password.

Now while he is gone another user comes along, and he goes to the top of the screen where the View Client toolbar is, and presses OPTIONS -> Switch Desktop -> Other Desktop

This brings up the VMware View Connections. Now insted a choosing a VM to start, he closes the lock View Desktop in the background. Now he is able to connect to the same machine again, and Single sign on now logs him in, even though it is not the connect user, and he does not have the password.

I am unable to see how to solve this without putting the "thin" Windows machines in the domain, and that means multiple logons for the user.

Wise clients have a solution to this, where the lock the View client. That is a good solution, but VMware has not thought this through.

Does anyone have some solutions that I have not seen? I had come up with a solution to use the Web Portal, and have iexplore killed after logon to the machine, but View does not support PCoIP when using Web Portal. Another solution is to remove the View Toolbar in the top of the screen, but then users are unable to start more then one machine. Very Annoying. Smiley Happy

Please Help

Regards Mnemonic

0 Kudos
5 Replies
Highlighted
Immortal
Immortal

Why not just disable SSO?

WP

0 Kudos
Highlighted
Enthusiast
Enthusiast

Because it is very annoying for the users, that they have to login to every Virtual Desktop. Some of them have 4 different machines.

It would be better if VMware used 2 hours to implement a View Client Lock feature like the Wise terminals have. They already have the authentication implemented. It should not be such a big task. I am just trying to put some focus on it.

0 Kudos
Highlighted
Contributor
Contributor

I was happy to find this thread as we discovered this exact issue last week. We have thin clients that we chose not to join to the domain (just treat them like appliances) and trained users to lock their workstations with Window+L (which works great in PCoIP). However, since everyone is entitled to more than one desktop, it is easy to walk up, switch desktop, and then close and reconnect to the original desktop and SSO gets you in without every typing the user's password. I am curious, what security measures did you implement to mitigate this problem? We are trying to decide if we want to join the thin clients to the domain or disable SSO. A way to lock the View Client itself would be optimal, but doesn't seem like an available option at this point.

0 Kudos
Highlighted
Enthusiast
Enthusiast

I have two workarounds, one is to disable sso ofcourse. This was what we chose to do. Another would be to create a launcher for internet explorer and then use the webinterface to connect. That way you could kill internet explorer after a short amount of time, and thereby eliminate the users posibility to connect to another machine. I dont think this solution works in View 4.5 though, since the connection is established in the same way both from the client and the webinterface.

0 Kudos
Highlighted
Contributor
Contributor

I apologize for resurrecting this old thread, but I just discovered this vulnerability in our systems. Is there any way to stop this outside of disabling SSO or joining the machines to the domain? We currently use View Client 5.4.0 1219906

0 Kudos