Selectively use RSA

[esnmb]

Is it possible to force RSA authentication only to users over the internet but but when on the local LAN/WAN?  Right now it seems like it's all or nothing.

Thanks.

[BearHuntr]

From my experience, no, it's pretty much all or nothing.  If you use 2 connection broker servers, one for internal only with RSA disabled and one for External only with RSA enabled and a paired Security server, that works.  But that would require more infrastructure in place.

[markbenson]

Yes. This is a common requirement. You want to have local LAN users do just AD password authentication but require remote access users to also do RSA SecurID authentication.

To do this, simply have one or more Connection Servers dedicated to remote access, and one or more Connection Servers dedicated to local access.

Check out the diagram 5-3 on page 59 here http://www.vmware.com/pdf/view-46-architecture-planning.pdf

All four Connection Servers are part of the same View Cluster. Just configure the two on the right for SecurID Authentication. The 2 on the left will just use AD password authentication. If you don't have load balancing, you can do the same with just 2 Connection Servers.

From a security perspective, you can even go a step further and use "tags" for restricted entitlements. This allows you to define at a pool level which VMs can be accessed locally and which remotely. This is useful if you have specific sensitive pools that you only want to grant access to local users.

Mark.

[esnmb]

So does this mean that internally users would use a different URL?

I currently have the same URL internally and externally so there is little to no thought involved for end users...

[SDO1]

you can use the same url with no probs  - just configere your internal DNS to point to the "non-RSA"-CS on the internal network, and the public DNS with the url to your "RAS"-CS

[esnmb]

So I should have a connection server in my DMZ as well as my current security server?  The DMZ connection server would be set to RSA, but the single internal connection server wouldn't?

[SDO1]

no -- security servers in DMZ - connection servers on lan.

ofc you point your public url to your SS in dmz which is paired with your RSA-CS on lan. (well you point it to the Load Balancer if the setup is according to best practices :-))

[esnmb]

So if I create another internal connection server, it would need another URL for internal access.  I am trying to make it so users don't have to think about what URL to use when in or out of the office ya know?  I'm not sure now if I can have it both ways...

[markbenson]

You can use the same URL. Just make sure your internal DNS resolves it to the internal Connection Server and external DNS resolves it to the external VIP of your Security Server in your DMZ.

Mark.

[esnmb]

But the connection server is where you set RSA settings. Wouldn't that have us in the same situation?

[markbenson]

No. It would be like the diagram I referenced earlier (which actually showed 4 Connection Servers - 2 for local and 2 for remote).

If you don't have load balancers but want remote access users to SecurID authenticate, you'd have 2 Connection Servers. CS1 would be for remote access users and would have a Security Server in the DMZ connected to it (SS1). CS2 would be for internal users and would have no Security Server. You'd just configure CS1 for SecurID.

In this set up, you could also make sure local users using CS2 do PCoIP direct whereas remote users would gateway PCoIP through SS1.

Remote users would connect to SS1 local users would connect to CS2. Nobody would connect directly to CS1.

Mark.

[esnmb]

I see.  We were concerned that by having internal name resolution pointing to internal CS1 and the same DNS name on the internet pointing to the SS1 that external clients connections would have bizarre resolution happening.  Since PCoIP connection are two way, we figure client comes in from internet using one IP for SC1, then once on the network, View desktops see that URL but using a different ip address.  So we were concerned that the PCoIP traffic wouldn't know where to go.

[markbenson]

What I've suggested works well. The diagram showing 4 Connection Servers on the internal network and 2 Security Servers in the DMZ is a very common View deployment. It supports local and remote access, supports high availability and allows you to have specific policy settings to support the different requirements you often need for local vs remote users.

Doing it with half the number of servers works well too - i.e. CS1, CS2 and SS1 as discussed. There won't be a problem with PCoIP routing (if you configure it properly :-)).

Mark.

[esnmb]

Ok cool.  We are still trying to get PCoIP working.  We see traffic coming in from the security server to our desktops, but not the other way so it fails...

I'll try to get another connection server up internally and assign our common View URL to it and see how it work.

Thanks for all the help!

[esnmb]

So I have installed the connection server on my new server for the non-RSA instance.  Is this completely seperate from my current View instance?  I don't see where I can add an additional connection server to my environment.

[markbenson]

When you install your second Connection Server you install it as a "replica" instance. Not a standard instance. During the replica install you will then be asked for the hostname (or IP address) of an existing Connection Server. The two then become two Connection Servers within the same group (sometimes called a View Cluster or POD). You can later add further replicas to this View cluster if you want.

Any configuration change on one Connection Server in a group is immediately and automatically replicated to the others in the cluster.

When you go into View Administrators, youll see a list of all Connection Servers and Security Servers within your View cluster.

Mark.

[esnmb]

Oh. I thought a replica was the same copy of the original.  Since one is using RSA, I thought the other would be forced to use it.

In internal DNS I point the URL to the replica then?

[esnmb]

I installed it in Replica mode, but it doesn't show up in the primary admin console.  Is this by design?

[esnmb]

Ok, so it seems that when I first installed my replica, I did it as a standard connection server.  Then after reading your post about setting it as a replica, I uninstalled, then reinstalled as a replica.  But the LDAP components stayed.  I found another article about having to remove those components.  I did that and now it all looks good.

Thanks again!

[justinsmith]

I actually have 4 security servers (based on best practices) and Im looking to have a specific pool ONLY use RSA. Even when they're internal to our company.

Basically regardless if they're internal or external, they'll have to have 2-factor authentication. Is this possible? I've looked into the tags and setting resitrictions on the actual pool, but testing it out internal doesnt seem to do anything other than remove my access to that specific pool.

On a side note, our DNS entry for the VDI infrastructure has an INTERNAL IP address when accessing it internally, this would obviously redirect me to the internal stuff but i want to bypass that and go externally.