Forum Discussion
APM as an RDP Proxy but still get to RD Web Access page?
- Dec 06, 2016
In v13.0, APM can read items from a RemoteApp feed and SSO + proxy them to your APM users in an APM webtop. This would be quite difficult to implement on prior versions, so I’d recommend you wait for that release. v13.0 is going to be released within a few months.
This new version can publish RemoteApps (app virtualization) and also publish native RDP Resources (desktop virtualization) to IOS, Android, Mac, and Windows using the native Microsoft client. This requires installation of the Microsoft RD app.
You can also request access to the beta program here on DevCentral if you'd like to test it out in a non production environment.
Edit: the iOS part only works correctly in the case that you don't use RD Broker.
This thread has been very helpful in getting us up and running in a sandbox environment. We've run into a dead end though in trying to apply this to our production environment.
In both environments we have separate boxes for APM and LTM, but we have only been using APM for now in both. The major difference between our two environments would be licensing: in sandbox we have APM running with a Lab license, and in production we have APM licensed with limited LTM licensing (no load balancing). Webtop is populating properly with all the Remote Apps but when opening the downloaded *.rdp files we get a fairly generic "Your computer can't connect to the remote computer because and error occurred". One thing we see different in the APM logs is it looks like even though we have a Kerberos SSO profile assigned to the Remote Desktop profile, we are only seeing NTLM attempts server-side. Both production and sandbox are using the default/unmodified "vdi" profile. We are seeing entries in APM logs like the following after launching *.rdp:
Apr 27 15:04:48 F5-APM-V2 err tmm[11517]: 019cffff:3: /Common/RDITAccessPolicy:Common:00000000: VDI profile on /Common/RDIT does not have associated NTLM Auth profile or ECA profile is missing
Apr 27 15:04:48 F5-APM-V2 debug tmm[11517]: 019cffff:7: /Common/RDITAccessPolicy:Common:00000000: RD: [C] XXX.XXX.XXX.XXX.53685 i XXX.XXX.XXX.XXX.443: server-side connection was reset, reason: iRule execution (reject command)
Has anyone else encountered this, or have any thoughts? Thanks!
- Lucas_Thompson_Apr 28, 2017Historic F5 Account
This ECA error indicates that VDI is falling back from the protocol used by newer clients to the older protocol. The older one requires NTLM credentials from the client. How to set that up is documented here, it's somewhat different than the newer implementation:
To make sure it uses the newer protocol, use a newer client. You're probably testing with Windows 7. Install this:
https://support.microsoft.com/en-us/help/2923545/update-for-rdp-8.1-is-available-for-windows-7-sp1
Windows 8.1, Mac (updated from the app store), or Windows 10 will contain the newer client.
- LeeHApr 28, 2017Nimbostratus
Thanks Lucas. We are definitely testing with Windows 10 clients in production. In sandbox we had joined and created the NTLM account and tested and it worked with Windows 7. In production we just started simple with no NTLM and ONLY using Win10.
- Ed_Caswell_1704Apr 28, 2017Historic F5 Account
What version are you running?
- LeeHApr 28, 2017Nimbostratus
BIG-IP 13.0.0 Build 0.0.1645 Final RDS on 2012 R2 RDP Client 10.0.10240
- LeeHApr 28, 2017Nimbostratus
I should also mention that I think the RDP client is being classified properly. The line before the 2 log lines I pasted is this:
Apr 27 15:04:48 F5-APM-V2 debug tmm[11517]: 019cffff:7: /Common/RDITAccessPolicy:Common:00000000: Client-type (rdg-http)
Another thing I have noticed in our production APM logs which may or may not be related is we are seeing F5 cookie info from our LTM showing up in the logs. The only thing running on our APM box at the moment is our Remote Desktop related stuff. Not sure if that extra stuff in the cookie might be confusing things. That would be something else that is different in production.
- LeeHMay 02, 2017Nimbostratus
We've found this post as well, which sounds like what we are experiencing:
https://devcentral.f5.com/questions/f5-apm-seems-to-be-choosing-ntlm-over-kerberos-cache-issue
The solutions there don't apply in our case unfortunately. Are there any other reasons why NTLM would prioritize over Kerberos for SSO?
- LeeHMay 08, 2017Nimbostratus
We were finally able to track down our issue to a Domain GPO:
User Configuration-->Administrative Templates-->Windows Components-->Remote Desktop Services--> RD Gateway-->Set RD Gateway authentication method
This policy was "Enabled" which was forcing NTLM.
- Lucas_Thompson_May 08, 2017Historic F5 Account
Thanks so much for replying to the thread with your results! I'll make sure this is added to the troubleshooting procedures for this feature.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com