Mark Minasi's Tech Forum
Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
Michael Pietrzak

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 71
Reply with quote  #1 
Hi folks,

We have been pretty happy with our MS RemoteApp infrastructure and will probably be moving forward with it again when we need to upgrade the server.

With increased security a priority on my campus, everything is now firewalled to the hilt. I have been tasked with looking at options to make RemoteApp published applications available via the web.

I realize that RemoteApp has a browser based landing page but that simply opens of 3389 to the server.

I understand I need to run a RemoteApp Gateway (in addition to some other stuff) if I want an application published via 443.

Does anyone have a recommendation for performing\completing this type of task? I see a company called Cameyo but not much else besides that.

We want to eliminate the need to VPN into our network for RemoteApp access.

Thanks in advanced if anyone has any thoughts!

Regards,
Michael 


0
Pieter

Avatar / Picture

Senior Member
Registered:
Posts: 269
Reply with quote  #2 
Hi, my advice : go for it !
You should not publish RDP (TCP/3389) on the Internet, but instead use Remote Desktop Gateway.
It's a role in the MS Remote Desktop Services Suite. RD Gateway encapsulates TCP/3389 in a HTTPS (TCP/443) packet.  No need for third party stuff (unless you extra have requirements of course).

External RDP Client (over Internet) --443--> Firewall --443--> RDGateway server --3389--> RD Session Host server (full desktop or app).

Here is a good tutorial for RDS : https://nedimmehic.org/2017/01/21/deploying-remote-desktop-services-2016-step-by-step/
Part 13 is about the Gateway, but I advise you to read it all.

Good luck!

__________________
Pieter Demeulemeester
0
cj_berlin

Avatar / Picture

Senior Member
Registered:
Posts: 337
Reply with quote  #3 
+1 on RDG and you can also offer a HTML5 Client if you implement that. In fact, your powers that be might just be a little happier if you ONLY publish the HTML5 client to the Internet. It has a somewhat limited functionality but in your scenario, it could actually be viewed as an advantage ;-)
__________________
Evgenij Smirnov

My personal blog (German): http://www.it-pro-berlin.de/
My stuff on PSGallery: https://www.powershellgallery.com/profiles/it-pro-berlin.de/
0
Michael Pietrzak

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 71
Reply with quote  #4 
Sounds good everyone. I will take a shot at it this week!

Are there issues anyone knows about if I run all the services on a single machine?
0
Pieter

Avatar / Picture

Senior Member
Registered:
Posts: 269
Reply with quote  #5 
It is possible tot run all RDS files on one single server. In fact it's one of the default scenario's in the installation wizard.
__________________
Pieter Demeulemeester
0
cj_berlin

Avatar / Picture

Senior Member
Registered:
Posts: 337
Reply with quote  #6 
Quote:
Originally Posted by Michael Pietrzak
Are there issues anyone knows about if I run all the services on a single machine?


If "no redundancy" isn't an issue per se, think about security. You would be putting a domain joined system on the perimeter which, in my world, boils down to opening your LAN to the world.

Within the Microsoft product portfolio, you can do one of two things:
  1. utilize WAP to publish both RDG and RDWeb
  2. create a DMZ forest with a one way trust to production and put RDG in that. You still need a reverse proxy for RDWeb, though.

__________________
Evgenij Smirnov

My personal blog (German): http://www.it-pro-berlin.de/
My stuff on PSGallery: https://www.powershellgallery.com/profiles/it-pro-berlin.de/
0
Michael Pietrzak

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 71
Reply with quote  #7 
Ahhh, great tip about the web application proxy. I will definitely look into that. I really miss the days of good ol ISA Server.

Thanks again everyone! Hope to have this up in the next week or so!

Regards,
Michael
0
Michael Pietrzak

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 71
Reply with quote  #8 
Quote:
Originally Posted by cj_berlin
+1 on RDG and you can also offer a HTML5 Client if you implement that. In fact, your powers that be might just be a little happier if you ONLY publish the HTML5 client to the Internet. It has a somewhat limited functionality but in your scenario, it could actually be viewed as an advantage ;-)


Well...I have all the pieces in place (self signed cert though) and also the Remote App Web Client pieces installed.

The standard RemoteApp stuff is working. No problem there.

The problem I am receiving is with the web client. I hit the web client landing page, click on my test app, then things launch as if they are working properly.

Sadly, after the dialog box that states..."Connecting and Launching Calculator"...."Opening Remote Port"....I receive...."Opps, we couldn't connect to Calculator, The connection to the remote PC was lost".

This happens on both the local server browser as well as if I connect from my workstation.

There seems to be a number of people having this issue but no one offers a solution. I take that back, one person said they had to register their NPS server in Active Directory.

Beyond that, nothing. Anyone have any thoughts?


Regards,
Michael Pietrzak
0
cj_berlin

Avatar / Picture

Senior Member
Registered:
Posts: 337
Reply with quote  #9 
Hi,

can you please describe in some more detail what exactly you built and what you mean by 
Quote:
The standard RemoteApp stuff is working. No problem there.
. Have you built a separate collection where you enforce RDG? Because if RDG is not enforced, the clients, including the HTML5 client, will not try to connect through it. MSTSC will succeed if there is network connectivity on port 3389, while the HTML5 client will fail because it can ONLY go through RDG.

A selfsigned cert should be OK as long as everybody trusts it. And by "trusting" I mean that it has been put into the Trusted Root on any and all component of your RDS deployment and on the client(s) trying to access it.

__________________
Evgenij Smirnov

My personal blog (German): http://www.it-pro-berlin.de/
My stuff on PSGallery: https://www.powershellgallery.com/profiles/it-pro-berlin.de/
0
Michael Pietrzak

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 71
Reply with quote  #10 
Hi Evgenij,

Well, I have been battling this thing for almost a week now.

I am using Server 2019. All roles are on a single server. This server will be publicly facing so I am using RD Gateway.

All certificates have been obtained from InCommon and imported into the machine. When navigating to the webpage for the HTML5 client, the browser is showing the cert as being valid.

When I navigate to...

https://myserver.com/rdweb

....They get the authentication screen and after logging in, they get access to the published apps.

When I navigate to...

https://myserver.com/rdweb/webclient

I can reach the page, I authenticate successfully, click on an app...I says it's opening port, establishing connection...then boom, error message....


From what I read, the thumprint is just legacy stuff and will always be there.

Also, in Deployment Services properties, all Role Services are showing the cert as "Trusted" and OK.

Not really sure what to look for here?

Regards,
Michael Pietrzak

0
Michael Pietrzak

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 71
Reply with quote  #11 
This is the error when I run Chrome in developer mode...

2019-05-13T17:22:25.555Z Connection(ERR): The connection generated an internal exception with disconnect code=CertMismatch(7), extended code=<null>, reason=The cert from the remote server did not match the expected certificate (length mismatch).
Thrown in thread 396952 at:
tls/ossltransport.cpp(511)
Call Stack:
at Rjb
at Ojb
at Ip
at Vgd

0
Michael Pietrzak

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 71
Reply with quote  #12 
GOT IT!!

After that cert issue, i had to take a couple days away from this project.

I restored my vm to a previous checkpoint and decided to just start fresh.

This time, I had my certs ready to go, and was ready to give it another go.

This time though, when I was importing my cert, I decided to place the certs into the Trusted Root Certificate Authority.

I don't know if something was screwed up in the certs I downloaded from InCommon or if it was getting the certs into the correct store...but it's now working!

I am super pleased and glad I could get this going. Staff thinks it's great that they can now access our apps via a web browser.

The only thing I wish I could modify would be the consent screen to redirect local resources. I really don't need clipboard or printers and would prefer to just remove that screen but alas, after a cursory search, I cannot seem to find a way to do it.

Thanks for all the help everyone!!!

Have a great weekend!
0
cj_berlin

Avatar / Picture

Senior Member
Registered:
Posts: 337
Reply with quote  #13 
Michael,

glad you got it working, BUT:

Placing leaf certs in the Trusted Roots store on windows will lead to unexpected behaviour somewhere down the road. It is a known "feature" that all kinds of TLS-related things stop working if a leaf cert (i.e. one that is not signed by itself) is present in the Root store.

As to the consent screen. If you disallow resource redirection at the collection level, RDWeb will reflect that in the .RDP files so that the clients won't attempt it. If that is not an option, you can still get rid of that by placing the SHA-1 thumbprint of the connection signing certificate into the following policy setting on the clients: https://getadmx.com/?Category=Windows_10_2016&Policy=Microsoft.Policies.TerminalServer::TS_CLIENT_TRUSTED_CERTIFICATE_THUMBPRINTS_2  and enabling the following setting: https://getadmx.com/?Category=Windows_10_2016&Policy=Microsoft.Policies.TerminalServer::TS_CLIENT_ALLOW_SIGNED_FILES_1

BTW: This is completely unconnected to whether the clients trust the cert and/or can validate its revocation - which they still have to for other reasons.

__________________
Evgenij Smirnov

My personal blog (German): http://www.it-pro-berlin.de/
My stuff on PSGallery: https://www.powershellgallery.com/profiles/it-pro-berlin.de/
0
Michael Pietrzak

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 71
Reply with quote  #14 
Hi  Evgenij,

Thanks for all your help! I will look into the cert issue in the coming days. I am happy to have got things working though.

The deal with the cert confuses me though. I could not get it working when I was placing them in the personal store. I am not sure why it worked when I put them in the Trusted Root.

I hate PKI stuff though. My eyes always roll into the back of my head when I start researching certs and the related technology.

Well, I am 99% done with this project now as I also got the resource redirection prompt to no longer show. That was actually pretty easy.

On to my Azure Backup vs Azure Storage Blob project!

Regards,
Michael
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.