Controlling External Access

[BISGInc]

Hello-

Interesting question from the field yesterday.   We have a client that has both an internal and external facing view servers.   They would like to restrict which users can login remotely via the external view server, while still allowing ALL users to connect internally.

Sure this could be done by requiring a client VPN connection & login process, but that is messy considering the external VCS w/security gateway allows for PCoIP without a VPN connection.

Any thoughts on how best to accomplish this?   The official response from VMware tech support was "at this point we do not have a way to restrict some users access through the security server."   Surely there must be a "creative" way, no?

Rick

[pcerda]

From the View Administration Guide:

"You can configure the restricted entitlements feature to restrict View desktop access based on the View

Connection Server instance that users connect to when they select desktops.

With restricted entitlements, you assign one or more tags to a View Connection Server instance. Then, when

configuring a desktop pool, you select the tags of the View Connection Server instances that you want to be

able to access the desktop pool."

Check out from page 116:

http://www.vmware.com/pdf/view-46-administration.pdf

Best Regards

Patricio Cerda

[markbenson]

This depends on how your pools are structured. There is a feature called "restricted entitlements" or "tag based entitlements" where access to a pool can be restricted depending on the location of the user. This is quite common for certain classes of sensitive pools where an organisation may want to ensure that certain pools can only be accessed from inside the corporate network. This is quite a common requirement.

Imagine that you have two AD user groups Group A and Group B. Group A users are free to access their pool(s) from the internal network or the external network, but Group B users must be on the internal network.

Group A users have entitlements to Pool 1 and Pool 2.

Group B users have entitlements to Pool 3 and Pool 4.

On the Connection Servers set a tag of "External" on the Internet supporting Connection Servers (that have Security Servers attached), and a tag of "Internal" for the Connection Servers used for internal access.

When you entitle pools, simply set a tag of "Internal" for Pool 3 and Pool 4. This way when anyone in Group B tries to log in to View through a Security Server, they'll get a failure indicating they have no entitlements. It will only work when Group B users attempt to access them when on the internal network. It is only Pools 1 and 2 that can be accessed from external and internal.

Another option is to configure the external Connection Servers to require SecurID authentication. Then just give Group A users a token.

There are several variations on all this in terms how you structure and entitle pools, but hopefully this gives you some ideas on how to set this up.

Mark.

[markbenson]

Ah! beaten to it - must type faster!

[pcerda]

:smileycool:

[wframe]

We are running into a same issue.  For now, we would like to restrict access to the security server to a specific subset of users.  Our last resort will be to create duplicate pools that are allowed access to this communication server, and restrict on the other pools, but this seems like a bit of a messy solution.  Is there a way to control this through local or domain access via a security group?  Haven't had much luck yet, but would much prefer that over deploying a new pool solely for this access.

[chillware1]

I'm in the exact same boat as you, been looking for a solution for a while now.. only options that seem to work at this point are either setting up SSL VPN and controlling external access thru that (lame), handing out secureID keys (expensive), or external have two seperate desktops on internal one external (also lame) there is no other useful way i've found to accomplish this.

Its seems soo easy to me, all vmware needs to do is add a simple option to the view security server settings "Allow only members of this AD group to connect to this security server" .. done.. ugh :s

[gunnarb]

Okay so based on these posts it sounds like this is not currently doable.  If I'm hearing this right then what we need is some way to do this which means outside the box thinking.

Here is my suggestion and I think it work work however, it would allow everyone to log in remotely but woudl immeidately kill the session if the user isn't allowed to connect remotely.  Not perfect but a start.

• Create a group in AD and call it "View WAN Access" (or something like that)
• Create a script and have this script look at the HKCU\Volatile Environment\ViewClient_IP_Address
• This IP is either going ot be the Security Gateway or their actual IP, either way its not going to be an internal IP.
• IF the IP address is not an internal IP, check to see if the user is a member of "View WAN Access"
• If the user is not a member issue a kill command to the PCoIP_service, or log off, or whatever you feel comfortable with.
• If they are a member then do nothing.

Its ugly but its a start.

Gunnar

[gunnarb]

Another simple (but probably costly) option is just to buy RSA fobs for those you want to have external access.  All you'd have to do is enable RSA on the Security Server and only give Fobs to those who are allowed external access. The advantage to this is your externally faced View would be more secure.

I'm still thinking up other ways to do it.  I think there should be some way to get in the middle of the authentication process between View and AD.

Gunnar