Forum Discussion
Lyonell_165736
Nimbostratus
NimbostratusRemote Desktop Web Access and Remote Desktop Gateway SSO Through APM
I'm a relatively new BIG-IP admin (we purchased BIG-IP to replace our TMG 2010 solution). I'm attempting to configure Remote Desktop Web Access and Remote Desktop Gateway services (2008 R2) utilizing APM. The pre-sales engineer we spoke to indicated this should be a "simple" configuration, but it's certainly kicked me in the rear.
I've created what I assumed would be a good configuration:
1: Virtual server with a pool for the RD web access and gateway server services, and an iRule to bypass APM for /rpc/rpcproxy.dll (see below, similar to rules I've seen for Exchange clients connecting using RPC over HTTPS).
2: APM configuration with forms-based SSO to the Web Access (which works perfectly), which allows us to integrate authentication to the web access page from our primary web portal.
Now, normally using RD Web Access you login to the RD Web Access page, and it automatically connects your client to the RD Gateway, so launching a RemoteApp published application is seamless. When we apply an APM configuration to the virtual server, however, even with the rpcproxy.dll APM bypass in place, the automatic login to the RD Gateway doesn't happen. If we remove the APM config from the virtual server and publish directly without APM, it works fine, so I'm pretty sure the problem is with APM.
In short, what should happen is:
1: Client lands on BIG-IP APM login page (works) 2: Client logs into BIG-IP APM login page, which passes credentials to RD Web Access form (works) 3: On login to RD Web Access, the client should automatically login to RD Gateway using same credentials used to login to RD Web Access (does NOT work)
I haven't found anything on configuring APM SSO for RPC over HTTPS, so I'm finally at a loss and asking here. Any suggestions? Pointers?
when HTTP_REQUEST {
if {[string tolower [HTTP::uri]] contains "/rpc/rpcproxy.dll"} {
COMPRESS::disable
CACHE::disable
ACCESS::disable
pool
}
}
If you are going to 11.6, we are going to be publishing an iApp template that uses the new VDI profile to replace the RDG functionality. I've tested with RDWA publishing resources that go through this new proxy and it seems to work fine.
As far as trying to pre-auth connections to the RDG servers, I wouldn't recommend disabling APM for requests for the RPC proxy, as that leaves a giant security hole that defeats the purpose of using APM. Although I haven't tested it, it should be possible to pre-auth the RDP clients by creating an NTLM machine account (aka, joining the BIG-IP to the domain), creating an NTLM auth config that references that machine account, manually attaching an ECA profile to the APM virtual server, and creating an iRule to enable clientless mode for the RD client connections. You wouldn't be getting SSO with the credentials used in RDWA, however you shouldn't get prompted for credentials either as long as the client machines are joined to the domain.
Basically, if you are going to 11.6 anyway, I recommend going with the new VDI profile iApp, since it will take care of all the configuration for you.
Lyonell_165736Side topic: One bug I found, when tring to use an existing SSL client profile, I get the following error. If I have it create a new SSL profile using the same key, it works fine:
script did not successfully complete: (can't read "::apm_ssl__key": no such variable while executing "iapp_conf create $cssl_cmd key $::apm_ssl__key cert $::apm_ssl__cert chain none" invoked from within "subst $substa_out" invoked from within "if { [info exists [set substa_in]] } { set substa_out [subst $$substa_in] set substa_out [subst $substa_out] } else { ..." ("uplevel" body line 3) invoked from within "uplevel { append ::substa_debug "\n$substa_in" if { [info exists [set substa_in]] } { set substa_out [subst $$substa_in] ..." (procedure "iapp_substa" line 9) invoked from within "iapp_substa apm_clientssl_arr($new_client_ssl,$do_chain_cert)" (procedure "configure_apm_deployment" line 365) invoked from within "configure_apm_deployment" line:1)- I don't get that error, but there have been a couple of updates to the iApp since this thread started: https://clouddocs.f5.com/api/iapps/Microsoft-Remote-Desktop-Gateway-APM-Gateway-iApp.html?NoRedirect=1&NS=iApp
- Lyonell_165736I'm using RC3; it also happens with RC1. I'll compare the two client SSL profiles and see if there's something in the one I already have it didn't like. Not a huge deal.
- Lyonell_165736
Here's a piece that might be involved: I have a computer account, and I have it set to "Trust this computer for delegation to any service (Kerberos only)" - but I don't see any details on creating a user account for NTLM delegation?
Logs coming next.
CRITICAL Before completing this section, you must create an NTLM Machine Account object on the BIG-IP system to join this system to the Active Directory domain. Creating an NTLM Machine Account is not a part of this template, see Access Policy>> Access Profiles: NTLM: NTLM Machine Account List. You must also create a user account in the same domain that has been properly configured for NTLM delegation.- You don't need a user account for APM delegation with this config. This text need to be removed.
- Lyonell_165736
The site isn't letting me post the debug log, it keeps flagging it as spam. Is there a way I can submit a file instead of trying to post the log?
- You can try sending it to me in a DevCentral private message.
- Lyonell_165736
Nov 21 19:12:58 vddmz-px13-an debug tmm3[15203]: 01490000:7: Request (RDG_OUT_DATA /remoteDesktopGateway/ HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Accept: */* User-Agent: MS-RDGateway/1.0 RDG-Connection-Id: {F7C56261-5021-4D20-BC3A-25315AD74C1F} RDG-Correlation-Id: {C7E116F0-AC72-4FAF-8B0F-50AEE86C0500} RDG-User-Id: bABrAGUAcABsAGEAcgBAAGQAZQBtAHMAZABtAHoA Host: gate.peakrc.com Authorization: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw== ) Nov 21 19:12:58 vddmz-px13-an debug tmm3[15203]: 01490000:7: Client-type (rdg-http) Nov 21 19:12:58 vddmz-px13-an debug tmm3[15203]: 01490000: Got rdg-http OUT on tmm 0 3 ntlm_done 0 Nov 21 19:12:58 vddmz-px13-an notice tmm3[15203]: 01490517:5: 31aa13bc: User-Agent header is absent or empty Nov 21 19:12:58 vddmz-px13-an notice tmm3[15203]: 01490544:5: 31aa13bc: Received client info - Type: unknown Version: 0 Platform: unknown CPU: unknown UI Mode: Full Javascript Support: 0 ActiveX Support: 0 Plugin Support: 0 Nov 21 19:12:58 vddmz-px13-an notice tmm3[15203]: 01490500:5: 31aa13bc: New session from client IP 67.137.4.65 (ST=Washington/CC=US/C=NA) at VIP 67.137.4.78 Listener /Common/gate.peakrc.com.app/gate.peakrc.com_vs (Reputation=Unknown) Nov 21 19:12:58 vddmz-px13-an debug vdi[11866]: 01490000: {.S} Connected to 127.0.0.1:10001 Nov 21 19:12:58 vddmz-px13-an debug apd[10743]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "execute()" line: 298 Msg: Let's evaluate rules, total number of rules for this action=1 Nov 21 19:12:58 vddmz-px13-an debug apd[10743]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "execute()" line: 304 Msg: Rule to evaluate = "" Nov 21 19:12:58 vddmz-px13-an info apd[10743]: 01490006:6: 31aa13bc: Following rule 'fallback' from item 'Start' to item 'Client Type' Nov 21 19:12:58 vddmz-px13-an debug apd[10743]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "execute()" line: 298 Msg: Let's evaluate rules, total number of rules for this action=2 Nov 21 19:12:58 vddmz-px13-an debug apd[10743]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "execute()" line: 304 Msg: Rule to evaluate = "expr { [mcget {session.client.type}] == "rdg-rpc" || [mcget {session.client.type}] == "rdg-http" }" Nov 21 19:12:58 vddmz-px13-an debug apd[10743]: 01490000:7: ./AccessPolicyProcessor/Session.h func: "getSessionVar()" line: 317 Msg: variable "session.client.type" was not found in the local cache for session "31aa13bc" Nov 21 19:12:58 vddmz-px13-an debug apd[10743]: 01490000:7: ./AccessPolicyProcessor/Session.h func: "getSessionVar()" line: 324 Msg: try to get it from MEMCACHED Nov 21 19:12:58 vddmz-px13-an debug apd[10743]: 01490000:7: ./AccessPolicyProcessor/Session.h func: "getSessionVar()" line: 356 Msg: variable found, lets add it to the local cache "session.client.type"="rdg-http"(length=8) Nov 21 19:12:58 vddmz-px13-an info apd[10743]: 01490006:6: 31aa13bc: Following rule 'Successful' from item 'Client Type' to item 'NTLM Auth Result' Nov 21 19:12:58 vddmz-px13-an debug apd[10743]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "execute()" line: 298 Msg: Let's evaluate rules, total number of rules for this action=2 Nov 21 19:12:58 vddmz-px13-an debug apd[10743]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "execute()" line: 304 Msg: Rule to evaluate = "expr {[mcget {session.ntlm.last.result}] == 1}" Nov 21 19:12:58 vddmz-px13-an debug apd[10743]: 01490000:7: ./AccessPolicyProcessor/Session.h func: "getSessionVar()" line: 317 Msg: variable "session.ntlm.last.result" was not found in the local cache for session "31aa13bc" Nov 21 19:12:58 vddmz-px13-an debug apd[10743]: 01490000:7: ./AccessPolicyProcessor/Session.h func: "getSessionVar()" line: 324 Msg: try to get it from MEMCACHED Nov 21 19:12:58 vddmz-px13-an debug apd[10743]: 01490000:7: ./AccessPolicyProcessor/Session.h func: "getSessionVar()" line: 358 Msg: variable "session.ntlm.last.result" for session "31aa13bc" was not found in MEMCACHED Nov 21 19:12:58 vddmz-px13-an debug apd[10743]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "execute()" line: 304 Msg: Rule to evaluate = "" Nov 21 19:12:58 vddmz-px13-an notice apd[10743]: 01490005:5: 31aa13bc: Following rule 'fallback' from item 'NTLM Auth Result' to ending 'Deny' Nov 21 19:12:58 vddmz-px13-an notice apd[10743]: 01490102:5: 31aa13bc: Access policy result: Logon_Deny- Lyonell_165736Couldn't send it as a private message either. I cut out parts that didn't look pertinent and finally got a post to go through.
- Lyonell_165736
I hadn't opened a case yet, since this is still a release candidate. I'll go ahead and do that next.
- Great, thanks. Is it possible to test with NTLMv1 enabled?
- Lyonell_165736
Sorry, that was quite a while ago. Our final implementation used the RDG functionality that was originally made available in 11.6 in conjunction with SharePoint and the Remote Desktop webpart. This last week, we met with an engineer to go over the new Remote Desktop and RemoteApp functionality in 13.0.
13.0 will allow us to host the RemoteApp connections directly in a webtop and implement SSO to the RDG. I haven't found documentation on it yet.
Prasanta_Shee_3Too much technical stuff!! Instead, simply use tools like R-HUB remote support servers, logmein etc. for remotely accessing computers. They are easy to use.