I am trying to use a two factor authentication solution. I have set up Horizon View to use radius and it is working fine. A little too fine. My solution I am using allows for a IP whitelist however in order for that to happen, I need to pass RADIUS attribute 66 (tunnel endpoint). This way when my users are in the office, they will not get the second factor authentication. In the admin console I have not seen where I can specify what RADIUS attributes I can pass as part of the request. Is this possible? If so, how would I go about configuring this?
Any assistance around this would be greatly appreciated.
This isn't something that's supported with the product today. To achieve something similar, you would need to set up another replica server (or servers) to service internal clients only, which does not have RADIUS enabled. Internal clients should point to these servers, while external clients point to security servers paired with the RADIUS-enabled connection servers. This is covered in the "Best Practices for Security Server Deployments" section of the architecture & planning guide.
Does someone know if this missing Radius attribute (Tunnel-client-endpoint) - is still missing in the latest release(s)? Hopefully this will be fixed soon.
The recommendation in all cases is to use different View Connection Servers for internal vs remote access users. There's a good diagram showing this on page 81 here Horizon 6 with View - Architecture and Planning Guide
The other advantage of using separate View Connection Servers this way is that you can ensure that only remote users have their PCoIP sessions directed via the PCoIP Secure Gateway and so internal users can do PCoIP direct between client and virtual desktop. This makes for a better user experience for internal users.
There is an article here VMware Article on RADIUS Authentication setup with View that also describes this setup and says about the ability to have RADIUS authentication for remote users but just AD password authentication for internal users. This setup also allows for different desktop and application entitlements depending on whether the user is internal or remote. You may not have this requirement, but it is fully supported in the product.
There are limitations with just using a source IP address approach. There is nothing to fix here and there are currently no plans to change this recommendation.
Does this still apply for Horizon 7?
With Security Server and Horizon Connection Servers then the recommendation to dedicate Connection Servers for either internal or external still applies with Horizon 7.
If you are using Access Point instead of Security Server then all Connection Servers can be configured the same, just for password authentication. RADIUS authentication can then be done in the DMZ with Access Point. That way you still get internal users who go direct to Connection Server getting just password authentication, but remote access users connecting via Access Point can get RADIUS 2-FA as well. Same applies for RSA SecurID with Access Point.
See Using PowerShell to Deploy VMware Access Point and Technical Introduction to Access Point for Secure Remote Access - VMware End-User Computing Blog - V...
6 years later, is this still a limitation in Horizon? Can the gateway pass the client IP address attribute to the RADIUS server yet? My use case is different from OP's. I am not trying to apply different policies to internal and external users, I am trying to pass the actual IP of the connecting client to my identity provider for logging and alerting purposes and to apply geographical login restrictions dictated by our security policy. For example, to deny access from unauthorized locations or to trigger policies on suspicious location changes.
I can't understand why this feature continues to be overlooked after all these years.