localzuk Posted June 14, 2021 Posted June 14, 2021 Has anyone successfully got this working? I have followed the instructions here - https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-integrate-with-remote-desktop-services We use the web client. I can log in to the site, and can see the published desktop/applications to click on. However if I click on them, I just get the error below.
TechMonkey Posted June 14, 2021 Posted June 14, 2021 I got it working. I think I had this issue. Check the event logs, probably the Remote Desktop Services built in to the Server Manager will be most useful.
localzuk Posted June 14, 2021 Author Posted June 14, 2021 I got it working. I think I had this issue. Check the event logs, probably the Remote Desktop Services built in to the Server Manager will be most useful. Which logs, on which server? There's pretty much nothing in Server Manager if I go through the various servers and look under Events.
TechMonkey Posted June 14, 2021 Posted June 14, 2021 In Server Manger on the Gateway go to Remote Desktop Services, then Servers and it will show you the relevant Event Viewer entries to RDP.
localzuk Posted June 14, 2021 Author Posted June 14, 2021 There is a single warning listed. From 9:50am this morning when I restarted. Nothing else listed at all for the Gateway server.
cw222 Posted June 14, 2021 Posted June 14, 2021 Are you using custom domains or msappproxy.net? We had initial trouble getting the certs working and had this error message, but once redeployed as our domain.com address it sorted it with our own certs.
localzuk Posted June 14, 2021 Author Posted June 14, 2021 A custom domain, using our wildcard cert. I went through the servers in the deployment settings window, and added the new certificate to the 4 options, plus updated the certificate on the RDWeb client as well.
BKGarry Posted June 14, 2021 Posted June 14, 2021 I take it that there isn't a Web Application Proxy in the middle anywhere, as where the HTML5 client uses websockets over port 443 the WAP server cannot forward them on. Although I am imagining this is not the case here.
Remiel Posted June 14, 2021 Posted June 14, 2021 (edited) Are the apps failing when you login internally from your own network or just when you login via the appproxy.net link? I've had it working via Azure App Proxy since March, works very well in Chrome, Edge, Safari etc. How have you setup your internal hosts? Are you running RDWeb and Gateway on the same server? I'd recommend having a look at this guide, it's a bit better than the official one - https://parveensingh.com/publish-rds-environment-with-azure-ad-application-proxy/ Just one caveat to the guide above - his section on publishing RDWeb and RPC as two separate on-premise applications in app proxy is wrong and caused me huge issues. It was essentially stopping the gateway and RDWeb from communicating with each other when accessed outside of our network. The solution (which I've posted to his guide but he's not taken into account) is to ensure RDWeb and the Gateway are both on the same host (the guide even suggests this), then publish one on-premise application with no trailing /rdweb/ or /rpc/ on either the internal or external URLs. You can then just manually add /rdweb/ (or /rdweb/webclient/ for the updated interface that works in newer browsers) to the URL when you distribute it to your users and it should work correctly with Azure SSO. The only issue with this is if users try to click the published application from within office365 as the URL will be missing the /rdweb/webclient/ and throw an IIS error page. We get around this by hiding the published application from the gallery then simply distributing the URL directly to staff via guide email etc. Edited June 14, 2021 by Remiel 1
localzuk Posted June 15, 2021 Author Posted June 15, 2021 "Are the apps failing when you login internally from your own network or just when you login via the appproxy.net link?" Our users only go to one link internally or externally, I need this to remain the same. So, users need to go to the external URL of the app wherever they are (the appproxy.net link, though we use a custom domain). RD Web and Gateway are on the same server. They were previously working just fine via application publishing on our Sophos XG. I have a single Application Proxy set up in Azure. Internal URL is to the base of the RDWeb server (no /rdweb or /rtc). External URL is a subdomain on our domain, with our wildcard certificate uploaded and working. I've gone back through the certificate on the deployment also - removed the existing one from the certificates MMC entirely on the gateway and CB servers, and then re-added to the CB, and then re-used that one to all the other 3 roles. I've exported a cer from that same certificate and imported it into the web client also. So the certificate is all set as it should be. I still get the same error I got earlier. If I log in via the "old" interface (RDWeb) and not the web client, and run an RDP file I see this: I get the same issue internally or externally. Also, that article is missing multiple aspects of setting this process up that I can see? It doesn't mention running the powershell script to deal with the pre-auth, it doesn't deal with the RD Web Client either (and the author even says he's not tried it with the Web client in his comments at the bottom)?
Remiel Posted June 15, 2021 Posted June 15, 2021 (edited) Our users only go to one link internally or externally, I need this to remain the same. So, users need to go to the external URL of the app wherever they are (the appproxy.net link, though we use a custom domain). That should be fine, a DNS redirect to the msappproxy.net link (or your custom domain one as you said) on your internal DNS would force everyone through Azure SSO so they receive the same experience internally and externally. Also may be worth testing the app proxy application using the default *.msappproxy.net address to see if there's any difference. RD Web and Gateway are on the same server. They were previously working just fine via application publishing on our Sophos XG. I have a single Application Proxy set up in Azure. Internal URL is to the base of the RDWeb server (no /rdweb or /rtc). External URL is a subdomain on our domain, with our wildcard certificate uploaded and working. Might be a silly question by how many subdomains deep is the external URL? I had an issue where one of our internal services that needed the SSL cert was one subdomain too deep and needed it's own cert purchasing (SSL cert was for *.schoolname.county.sch.uk while the internal service was *.domain.schoolname.county.sch.uk - hence wildcard having an issue). I've gone back through the certificate on the deployment also - removed the existing one from the certificates MMC entirely on the gateway and CB servers, and then re-added to the CB, and then re-used that one to all the other 3 roles. I've exported a cer from that same certificate and imported it into the web client also. So the certificate is all set as it should be. I still get the same error I got earlier. If I log in via the "old" interface (RDWeb) and not the web client, and run an RDP file I see this: [ATTACH=CONFIG]62157[/ATTACH] I get the same issue internally or externally. Just to clarify, by internally do you mean you're using the /RDWeb/ URL of your internal server? If you're getting the firewall error shown above when accessed within your network you can (for now) rule out Azure App Proxy being the cause. Have you missed any steps such as adding user/groups to your remote app collection and also the session host's remote desktop list? Also, that article is missing multiple aspects of setting this process up that I can see? It doesn't mention running the powershell script to deal with the pre-auth, it doesn't deal with the RD Web Client either (and the author even says he's not tried it with the Web client in his comments at the bottom)? Yeah apologies should have clarified that the guide has some useful bits but isn't a complete experience. When I was setting up my system in March I honestly couldn't find one complete, perfect guide on the process. Each one I found either missed a step or simply didn't work. This wasn't helped by the fact that the HTML5 client and App Proxy SSO are still relatively 'new' features that previous weren't compatible meaning numerous guides don't cater to both being used in the same environment. It definitely does work though, so you'll get there in the end! Edit: If you'd like to chat about it over the phone PM me, happy to help as it was such a nightmare setup! Edited June 15, 2021 by Remiel
localzuk Posted June 15, 2021 Author Posted June 15, 2021 That should be fine, a DNS redirect to the msappproxy.net link (or your custom domain one as you said) on your internal DNS would force everyone through Azure SSO so they receive the same experience internally and externally. Also may be worth testing the app proxy application using the default *.msappproxy.net address to see if there's any difference. Right, sorted my internal DNS. So it works internally now. Might be a silly question by how many subdomains deep is the external URL? I had an issue where one of our internal services that needed the SSL cert was one subdomain too deep and needed it's own cert purchasing (SSL cert was for *.schoolname.county.sch.uk while the internal service was *.domain.schoolname.county.sch.uk - hence wildcard having an issue). Just the one. remote.ourdomain.org Just to clarify, by internally do you mean you're using the /RDWeb/ URL of your internal server? If you're getting the firewall error shown above when accessed within your network you can (for now) rule out Azure App Proxy being the cause. Have you missed any steps such as adding user/groups to your remote app collection and also the session host's remote desktop list? Internal is now working without any Azure involvement now (might change this to push people to the Azure App proxy address once I have it working). Added a DNS zone/A record for internal use. So it is just the external access that isn't working.
Remiel Posted June 15, 2021 Posted June 15, 2021 (edited) Internal is now working without any Azure involvement now (might change this to push people to the Azure App proxy address once I have it working). Added a DNS zone/A record for internal use. So it is just the external access that isn't working. That's grand, try testing the app proxy using the pre-generated external *.msappproxy.net URL so it won't rely on your SSL cert. It may be worth deleting and recreating the enterprise application app when you do this so you know it's defaulted all settings. Just add your user groups, change authentication to Azure Active Directory then turn off URL translation for headers and body (this is under the Application Proxy section of the enterprise application within Azure portal). See if that works or if the error message changes for the /rdweb/webclient/ page and the /rdweb/ .RDP file? Edited June 15, 2021 by Remiel
localzuk Posted June 15, 2021 Author Posted June 15, 2021 (edited) OK. I deleted and added a new app using the default domain. Same result (though I don't see how this would ever work, as the RDS servers themselves have the wildcard certificate in place, so you'd have a mismatch at that point anyway). I have gathered the below log from trying to connect via the webclient also (same result with th: 2021-06-15T11:09:38.406Z Exception: Possibly unhandled rejection: backdrop click Cause: undefinedat Object.Logger.a.error (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/client.63d2b224.js:1:3060),at https://remoteaccess.ourdomain.org/RDWeb/webclient/js/client.63d2b224.js:7:11374,at j (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/components.d10295be.js:6:289),at n.$digest (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/components.d10295be.js:6:6299),at https://remoteaccess.ourdomain.org/RDWeb/webclient/js/components.d10295be.js:6:8087,at Uc.b [as completeTask] (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/components.d10295be.js:6:14224),at https://remoteaccess.ourdomain.org/RDWeb/webclient/js/components.d10295be.js:4:164812021-06-15T11:09:39.068Z RdpFileParser(NORM): Setting "redirectclipboard" = "1"2021-06-15T11:09:39.069Z RdpFileParser(NORM): Setting "redirectprinters" = "1"2021-06-15T11:09:39.069Z RdpFileParser(NORM): Setting "redirectcomports" = "0"2021-06-15T11:09:39.070Z RdpFileParser(NORM): Setting "redirectsmartcards" = "1"2021-06-15T11:09:39.071Z RdpFileParser(NORM): Setting "devicestoredirect" = "*"2021-06-15T11:09:39.071Z RdpFileParser(NORM): Setting "drivestoredirect" = "*"2021-06-15T11:09:39.072Z RdpFileParser(NORM): Setting "redirectdrives" = "1"2021-06-15T11:09:39.072Z RdpFileParser(NORM): Setting "session bpp" = "32"2021-06-15T11:09:39.073Z RdpFileParser(NORM): Setting "prompt for credentials on client" = "1"2021-06-15T11:09:39.074Z RdpFileParser(NORM): Setting "server port" = "3389"2021-06-15T11:09:39.074Z RdpFileParser(NORM): Setting "allow font smoothing" = "1"2021-06-15T11:09:39.075Z RdpFileParser(NORM): Setting "promptcredentialonce" = "1"2021-06-15T11:09:39.076Z RdpFileParser(NORM): Setting "require pre-authentication" = "1"2021-06-15T11:09:39.076Z RdpFileParser(NORM): Setting "videoplaybackmode" = "1"2021-06-15T11:09:39.076Z RdpFileParser(NORM): Setting "audiocapturemode" = "1"2021-06-15T11:09:39.077Z RdpFileParser(NORM): Setting "gatewayusagemethod" = "1"2021-06-15T11:09:39.077Z RdpFileParser(NORM): Setting "gatewayprofileusagemethod" = "1"2021-06-15T11:09:39.078Z RdpFileParser(NORM): Setting "gatewaycredentialssource" = "0"2021-06-15T11:09:39.078Z RdpFileParser(NORM): Setting "full address" = "CENT-RDCB-01.interldomain.ourdomain.tech"2021-06-15T11:09:39.079Z RdpFileParser(NORM): Setting "gatewayhostname" = "remoteaccess.ourdomain.org"2021-06-15T11:09:39.079Z RdpFileParser(NORM): Setting "pre-authentication server address" = "https://remoteaccess.ourdomain.org/"2021-06-15T11:09:39.080Z RdpFileParser(NORM): Setting "workspace id" = "CENT-RDCB-01.interldomain.ourdomain.tech"2021-06-15T11:09:39.080Z RdpFileParser(NORM): Setting "use redirection server name" = "1"2021-06-15T11:09:39.080Z RdpFileParser(NORM): Setting "loadbalanceinfo" = "tsv://MS Terminal Services Plugin.1.Staff"2021-06-15T11:09:39.081Z RdpFileParser(NORM): Setting "use multimon" = "1"2021-06-15T11:09:39.082Z RdpFileParser(NORM): Setting "alternate full address" = "CENT-RDCB-01.interldomain.ourdomain.tech"2021-06-15T11:09:39.082Z RdpFileParser(NORM): Setting "signscope" = "Full Address,Alternate Full Address,Use Redirection Server Name,Server Port,GatewayHostname,GatewayUsageMethod,GatewayProfileUsageMethod,GatewayCredentialsSource,PromptCredentialOnce,Require pre-authentication,Pre-authentication server address,RedirectDrives,RedirectPrinters,RedirectCOMPorts,RedirectSmartCards,RedirectClipboard,DevicesToRedirect,DrivesToRedirect,LoadBalanceInfo"2021-06-15T11:09:39.083Z RdpFileParser(NORM): Setting "signature" = "signaturehere"2021-06-15T11:09:39.085Z [sessionFactory] Redirections request2021-06-15T11:09:40.701Z [ConnectionFactory] Creating connection to: 2021-06-15T11:09:40.701Z [object Object]2021-06-15T11:09:40.707Z RdClientConnectionProxy::Create(NORM): loading webworkers from path: https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js2021-06-15T11:09:40.718Z WebWorker(NORM): Created Webworker with path: https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js onMessage: HandleConnectionMessage2021-06-15T11:09:40.740Z [sessionProvider] Connection created event received.2021-06-15T11:09:40.741Z [sessionProvider] Session created received in provider2021-06-15T11:09:40.741Z [sessionViewModel] Session destroy event received for: 81529a98-410e-468a-8b92-e28aeb4fbca22021-06-15T11:09:40.742Z [sessionViewModel] Session created event received for: 819edbe5-450b-42a0-a815-94d8c42ff1bc2021-06-15T11:09:40.742Z [Connection] Connection.connect called2021-06-15T11:09:40.742Z [sessionViewModel] Received monitorBound event on UI layer2021-06-15T11:09:40.747Z [Connection] Initializing AudioInputControler2021-06-15T11:09:40.753Z [session] Session focus changed to false id:81529a98-410e-468a-8b92-e28aeb4fbca2 window id:null2021-06-15T11:09:40.754Z [Connection] Graphics sink not set yet, cannot set focus to: false2021-06-15T11:09:40.755Z [session] Session focus changed to true id:819edbe5-450b-42a0-a815-94d8c42ff1bc window id:null2021-06-15T11:09:40.755Z [sessionViewModel] Session focused event received in view model session id: 819edbe5-450b-42a0-a815-94d8c42ff1bc2021-06-15T11:09:46.266Z Connection(NORM): Connection created with correlation ID={519db359-745a-44cc-b6f1-cd6275bc0000}2021-06-15T11:09:46.615Z DVCManager(NORM): Registered plugin AudioInputPlugin2021-06-15T11:09:46.623Z DVCManager(NORM): Registered plugin DisplayControlGraphicsPlugin2021-06-15T11:09:46.625Z DVCManager(NORM): Registered plugin InputPlugin2021-06-15T11:09:46.628Z DVCManager(NORM): Registered plugin GfxChannelGraphicsPlugin2021-06-15T11:09:47.246Z DVCManager(NORM): Creating plugin AudioInputPlugin2021-06-15T11:09:47.305Z DVCManager(NORM): Registering a listener for DVC AUDIO_INPUT2021-06-15T11:09:47.308Z DVCManager(NORM): Creating plugin DisplayControlGraphicsPlugin2021-06-15T11:09:47.313Z DVCManager(NORM): Registering a listener for DVC Microsoft::Windows::RDS::DisplayControl2021-06-15T11:09:47.314Z DVCManager(NORM): Creating plugin GfxChannelGraphicsPlugin2021-06-15T11:09:47.507Z DVCManager(NORM): Registering a listener for DVC Microsoft::Windows::RDS::Graphics2021-06-15T11:09:47.535Z DVCManager(NORM): Creating plugin InputPlugin2021-06-15T11:09:47.560Z DVCManager(NORM): Registering a listener for DVC Microsoft::Windows::RDS::Input2021-06-15T11:09:47.573Z GatewayTransport(NORM): Using the Gateway protocol variation for RD Gateway (on-prem)...2021-06-15T11:09:47.607Z BaseTransportConnectState(NORM): Entering Gateway connection state BaseTransportConnectState2021-06-15T11:09:47.676Z WebSocketTransport(NORM): Connection process begun for url=wss://remoteaccess.ourdomain.org:443/remoteDesktopGateway?CorId=%7B519db359-745a-44cc-b6f1-cd6275bc0000%7D&ConId=%7B34862272-e44c-4464-9e29-02f2ba9fc48c%7D&ClGen=HTML%3D1&ClBld=Type%3DRdClient%3B%20Build%3Dprivate&AuthS=SSPI_NTLM2021-06-15T11:09:47.678Z GatewayTransport(NORM): GatewayTransport connecting...2021-06-15T11:09:47.690Z [Connection] Connection state changed to: Opening remote port2021-06-15T11:09:48.885Z WebSocketTransport(ERR): WebSocket error received for url=wss://remoteaccess.ourdomain.org:443/remoteDesktopGateway?CorId=%7B519db359-745a-44cc-b6f1-cd6275bc0000%7D&ConId=%7B34862272-e44c-4464-9e29-02f2ba9fc48c%7D&ClGen=HTML%3D1&ClBld=Type%3DRdClient%3B%20Build%3Dprivate&AuthS=SSPI_NTLM websockettransport.cpp(304): OnErrorFromJS()at Object.Logger.a.errorWithoutTimestamp (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/client.63d2b224.js:1:2848),at Function. (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/client.63d2b224.js:7:12475),at methodCaller_emscripten$$val_$emscripten$$val_emscripten$$val$ (eval at new_ (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1523312), :6:26),at __emval_call_method (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1544846),at p6a (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:106:347219),at Frd (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:113:178492),at invoke_viiiii (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1596903),at o6a (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:106:345632),at Drd (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:113:178326),at invoke_viii (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1596493),at e7a (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:108:3123),at Cmb (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:112:256611),at Brd (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:113:178195),at invoke_vii (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1596104),at $7a (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:108:40322),at Brd (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:113:178195),at invoke_vii (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1596104),at a8a (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:108:41134),at Drd (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:113:178326),at dynCall_viii_497 (eval at makeDynCaller (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1519459), :4:12),at OnMessageCallback$Invoke [as Invoke] (eval at new_ (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1523312), :9:1),at Worker. (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:106254)2021-06-15T11:09:48.965Z WebSocketTransport(NORM): WebSocket closed, url=wss://remoteaccess.ourdomain.org:443/remoteDesktopGateway?CorId=%7B519db359-745a-44cc-b6f1-cd6275bc0000%7D&ConId=%7B34862272-e44c-4464-9e29-02f2ba9fc48c%7D&ClGen=HTML%3D1&ClBld=Type%3DRdClient%3B%20Build%3Dprivate&AuthS=SSPI_NTLM, wasClean=false, code=1006, reason=""2021-06-15T11:09:49.161Z Connection(ERR): The connection generated an internal exception with disconnect code=ConnectionBroken(8), extended code=, reason=WebSocket closed with code: 1006 reason: Thrown in thread 402956 at: websockettransport.cpp(335)Call Stack: at ktb at htb at Tp at double restrict connection.cpp(1395): OnException()at Object.Logger.a.errorWithoutTimestamp (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/client.63d2b224.js:1:2848),at Function. (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/client.63d2b224.js:7:12475),at methodCaller_emscripten$$val_$emscripten$$val_emscripten$$val$ (eval at new_ (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1523312), :6:26),at __emval_call_method (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1544846),at p6a (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:106:347219),at Frd (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:113:178492),at invoke_viiiii (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1596903),at o6a (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:106:345632),at Drd (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:113:178326),at invoke_viii (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1596493),at e7a (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:108:3123),at Cmb (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:112:256611),at Brd (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:113:178195),at invoke_vii (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1596104),at $7a (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:108:40322),at Brd (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:113:178195),at invoke_vii (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1596104),at a8a (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:108:41134),at Drd (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:113:178326),at dynCall_viii_497 (eval at makeDynCaller (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1519459), :4:12),at OnMessageCallback$Invoke [as Invoke] (eval at new_ (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:1523312), :9:1),at Worker. (https://remoteaccess.ourdomain.org/RDWeb/webclient/js/rdcore.a66f6cf2.js:86:106254)2021-06-15T11:09:49.215Z [Connection] Disconnecting2021-06-15T11:09:49.248Z WebSocketTransport(NORM): Connection close initiated for url=wss://remoteaccess.ourdomain.org:443/remoteDesktopGateway?CorId=%7B519db359-745a-44cc-b6f1-cd6275bc0000%7D&ConId=%7B34862272-e44c-4464-9e29-02f2ba9fc48c%7D&ClGen=HTML%3D1&ClBld=Type%3DRdClient%3B%20Build%3Dprivate&AuthS=SSPI_NTLM, code=1000, reason="NormalClosure(1000)"2021-06-15T11:09:49.249Z GatewayTransport(NORM): GatewayTransport closed.2021-06-15T11:09:49.255Z [Connection] Disconnected2021-06-15T11:09:49.262Z [sessionViewModel] Received retireCanvas event on UI layer, connectionID=519db359-745a-44cc-b6f1-cd6275bc00002021-06-15T11:09:49.262Z [sessionProvider] Session disconnect received in provider2021-06-15T11:09:49.263Z [sessionViewModel] Received That's the console log from the web client. (With domains and signature changed obviously). Same errors with the new msappproxy.net app too. Annoyingly can't get the log to format itself properly. Edited June 15, 2021 by localzuk
Remiel Posted June 15, 2021 Posted June 15, 2021 11:09:48.965Z WebSocketTransport(NORM): WebSocket closed, url=wss://remoteaccess.ourdomain.org:443/remoteDesktopGateway?CorId=%7B519db359-745a-44cc-b6f1-cd6275bc0000%7D&ConId=%7B34862272-e44c-4464-9e29-02f2ba9fc48c%7D&ClGen=HTML%3D1&ClBld=Type%3DRdClie nt%3B%20Build%3Dprivate&AuthS=SSPI_NTLM, wasClean=false, code=1006, reason="" 2021-06-15T11:09:49.161Z Connection(ERR): The connection generated an internal exception with disconnect code=ConnectionBroken(8), extended code=, reason=WebSocket closed with code: 1006 reason: Thrown in thread 402956 at: websockettransport.cpp(335)Call Stack: at ktb at htb at Tp at double restrict connection.cpp(1395): OnException()at Object.Logger.a.errorWithoutTimestamp I'd start here with code 1006 although it's pretty generic. Are you using separate hosts for licensing, connection broker and session host? Would be worth looking at the logs there too.
localzuk Posted June 15, 2021 Author Posted June 15, 2021 Yes, those roles are separate. We have: 1. GW/WA 2. CB 3. Licensing 4-8. RDSH Which logs? As there's nothing relevant in the event logs on any of them, going by the "Events" part under "Servers" in Server Manager.
Remiel Posted June 15, 2021 Posted June 15, 2021 Look for the TerminalServices logs under Applications and Services Logs > Microsoft
localzuk Posted June 15, 2021 Author Posted June 15, 2021 (edited) Nothing is being logged that I can see. I just tried again, marking the time I did it, and then looked on the CB and there's no new events in TerminalServices-SessionBroker -> Admin, or Operational, and nothing in TerminalServices-SessionBroker-Client -> Operational. On the GW/WA server, there's no new logged events in TerminalServices-Gateway -> Admin or Operational. It looks like the traffic is never getting to the gateway server or CB at all. The Application Proxy connector is installed on the GW/WA server also. Edited June 15, 2021 by localzuk
Remiel Posted June 15, 2021 Posted June 15, 2021 (edited) Nothing is being logged that I can see. I just tried again, marking the time I did it, and then looked on the CB and there's no new events in TerminalServices-SessionBroker -> Admin, or Operational, and nothing in TerminalServices-SessionBroker-Client -> Operational. On the GW/WA server, there's no new logged events in TerminalServices-Gateway -> Admin or Operational. It looks like the traffic is never getting to the gateway server or CB at all. The Application Proxy connector is installed on the GW/WA server also. If you can try logging into RDS using the internal URL and running an app / remote session via the /rdweb/webclient/ page and then via an /rdweb/ RDS file then check the SessionBroker and SessionBroker Client logs on the Connection Broker Host it may help narrow down the stage at which the external connection is failing. Just need to prove it's working and logging correctly when used internally. The application proxy is installed in the right place, if you manage to login and see the app collection on the /rdweb/webclient/ page then you've already hit the RD Web Access service so it's at least partially working. Edited June 15, 2021 by Remiel
localzuk Posted June 15, 2021 Author Posted June 15, 2021 So, for webclient: On SessionBroker Operational, there are event 800, 801, 787 and 818 with a successful login. SessionBroker-Client Operational, there is a 1301, 1307 with a successful login. RDWeb RDP file doesn't work. Comes up with the error from post 10 (which is to be expected internally, as the RDP file is expecting to pre-auth and internally that doesn't happen, and pre-auth only works via IE for RDP files anyway from what I've read).
robk Posted June 15, 2021 Posted June 15, 2021 Could anyone confirm if they have RDP gateway set up via Azure application proxy with 2FA. I was hoping to switch over as a "quick fix" but it seems once you have a RDP file you can bypass the 2fa which is of course a major hole in the armour.
localzuk Posted June 16, 2021 Author Posted June 16, 2021 My understanding is that if you are using Azure AD for the pre-auth, then you don't bypass anything - as the file contains a requirement to go through pre-auth via the web? It would only bypass it if you're using passthrough auth I believe.
TechMonkey Posted June 16, 2021 Posted June 16, 2021 Could anyone confirm if they have RDP gateway set up via Azure application proxy with 2FA. I was hoping to switch over as a "quick fix" but it seems once you have a RDP file you can bypass the 2fa which is of course a major hole in the armour. Have you closed the firewall ports? Everything goes via Azure and the Proxy server so there shouldn't be a route to the RDP Gateway. Also I seem to recall having to change the binding for the gateway so it shouldn't respond to the old file.
robk Posted June 16, 2021 Posted June 16, 2021 Have you closed the firewall ports? Everything goes via Azure and the Proxy server so there shouldn't be a route to the RDP Gateway. Also I seem to recall having to change the binding for the gateway so it shouldn't respond to the old file. Thanks Both, I have not tried this as yet. However we have just moved over to hosted SIMS which seems to act strangely, but that could just be a SIMS thing. So a follow up question to those that have got this working. Can you still do the RDP Gateway experience (so connect to an individual desktop etc) via the App proxy route or are you fixed to a web published TS server? Many thanks!
Remiel Posted June 16, 2021 Posted June 16, 2021 (edited) Thanks Both, I have not tried this as yet. However we have just moved over to hosted SIMS which seems to act strangely, but that could just be a SIMS thing. So a follow up question to those that have got this working. Can you still do the RDP Gateway experience (so connect to an individual desktop etc) via the App proxy route or are you fixed to a web published TS server? Many thanks! Yes you can still connect to individual desktops via the HTML5 experience in the browser, you can achieve it via an RDP file for terminal services since the HTML5 page doesn't have a 'connect to my PC' tab anymore. I do it as a remoteapp mstsc.exe shortcut. Edited June 16, 2021 by Remiel
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now