Jump to content

Recommended Posts

Posted

Microsoft explicitly say you cannot do the "connect to desktop" via the Azure App proxy route, only published apps/desktops.

 

For the Azure AD pre-authentication flow, users can only connect to resources published to them in the RemoteApp and Desktops pane. Users can't connect to a desktop using the Connect to a remote PC pane.

 

From here - https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-integrate-with-remote-desktop-services

  • Thanks 1
Posted
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).

 

So that's positive, it's logging correctly for connections made internally. Can you post a screenshot of your on-premise application App Proxy settings page from the Azure Portal? Blank out the addresses etc.

Posted
So that's positive, it's logging correctly for connections made internally. Can you post a screenshot of your on-premise application App Proxy settings page from the Azure Portal? Blank out the addresses etc.

 

I've given up on this now. I've spent 3 days on something that only has a dozen different settings. I'll look at it again during summer. Or move us over to AoVPN instead.

Posted

I've just tried to implement and ran into the same firewall issue as @localzuk

 

Followed the Microsoft guide exactly.

 

Could browse to the Azure app page, login, see remote apps but then clicking remote brought up the firewall error.

 

I've had to revert back the changes as only had a few hours downtime to try and get this sorted so will have to have another go one day.

Guest Guest
Posted

I had the same issue, followed the YouTube video below and now it's working fine

 

Posted
"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:

[ATTACH=CONFIG]62157[/ATTACH]

 

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)?

I had this both external and internal. I think it was to do with the Connection Broker being able to reach the RDSH bearing in mind from the server with the Azure App Proxy installed. I'll have a look tomorrow as it's in a testing domain.
Posted
I had the same issue, followed the YouTube video below and now it's working fine

 

Thanks will check it out, a quick scan this link says you need a min of 3 servers. The Microsoft links says only 1 is needed?
Posted
Thanks will check it out, a quick scan this link says you need a min of 3 servers. The Microsoft links says only 1 is needed?

 

Simplest setup would be RDWeb and Gateway on one server (with app proxy connector), Broker and Licensing on a 2nd then use the 3rd as your session host.

Posted

I'd put the app proxy on 2 dedicated servers.

Don't proxy the domains it uses. AV exceptions for the processes.

I think I ended up with a SCCM Compliance Item to make sure the service didn't restarted if memory usage was too high.

Guest Guest
Posted
Thanks will check it out, a quick scan this link says you need a min of 3 servers. The Microsoft links says only 1 is needed?
We've got all the roles on a single server
Posted

To prevent he Firewall Authentication Method error.

 

Set-RDSessionCollectionConfiguration -CollectionName "collection" -CustomRdpProperty "pre-authentication server address:s:https:///rdweb/n require pre-authentication:i:1"

 

I'm now getting authentication issues when using the non HTML5 client. Password is wrong but it is correct.

Guest Guest
Posted
Yeah we have too, have you got Azure app working with that?
Yes we have
Posted
To prevent he Firewall Authentication Method error.

 

Set-RDSessionCollectionConfiguration -CollectionName "collection" -CustomRdpProperty "pre-authentication server address:s:https:///rdweb/n require pre-authentication:i:1"

 

I'm now getting authentication issues when using the non HTML5 client. Password is wrong but it is correct.

 

That's exactly where I got up to before I gave up.

 

My issue was I was working on our prod RDS server so I had to roll back the changes.

 

Am going to spin up a new RDS server and break that. I stupidly thought I'd get it working easily following the MS guides which make it sound really easy.

Posted
That's exactly where I got up to before I gave up.

 

My issue was I was working on our prod RDS server so I had to roll back the changes.

 

Am going to spin up a new RDS server and break that. I stupidly thought I'd get it working easily following the MS guides which make it sound really easy.

 

Its unclear if you can have the old RDWEB Page functioning along side the webclient one. If Microsoft just added a webview for login to mstsc (and on windows logon page) with support for SSO in Windows it would solve a lot of the issues. The legacy of username/password means it takes a long time to get this working.

 

I did use the Password SSO option. Where the password is stored in the browser extension for the webclient, which worked before the app proxy was supported.

 

Understand password-based single sign-on (SSO) for apps in Azure Active Directory | Microsoft Docs

 

If the user changes their password it doesn't work.

Posted

So as I see it we will lose the ability to use mstsc to connect to devices?

 

You'd have to login to a desktop session and then remote from within that?

 

We made good use of mstsc for our admin staff to remote on their PCs during lockdown.

 

We don't use the html web client currently.

  • 2 weeks later...
Posted

Sorry being doing some testing and found

 

If I follow Parveen Singh's guide of adding RDS and the Gateway as separate proxy apps we can get past the firewall error, but it seems there is nothing stopping someone saving the .RDP file and running it and bypassing MFA for future logins. So this isn't an option.

 

Ref https://parveensingh.com/publish-rds-environment-with-azure-ad-application-proxy/

 

If you use IE you can run the .RDP file, not useful as IE is no longer used.

 

In the end we are just going to use the web client, it's not great but it ticks the box to use MFA and in the current climate that is a must.

Posted
Yeah we have too, have you got Azure app working with that?

 

We have all rolls installed on a single sever and trying to configure azure app proxy.

 

Can you share the document/guide you followed.

 

Thanks

Posted
We have all rolls installed on a single sever and trying to configure azure app proxy.

 

Can you share the document/guide you followed.

 

Thanks

 

Hi I just followed the standard Microsoft one

 

https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-integrate-with-remote-desktop-services

 

The gotchas to look out for are

 

This only works if you use the HTML5 Web Client, if you try and use the normal RDweb and run the .rdp file it will fail with the firewall error we've mentioned. It's a hit we are going to have to take to secure our remote server.

 

If you get stuck let me know as I've recently done this so might be able to help. I created a new RDS server as you don't need to any extra firewall/dns changes with the proxy app.

  • Thanks 1
Posted
Best is a wildcard (It will only last 398 days). *.domain.co.uk means you can use it for rdp and the web server connections.

That wasn't the question I was asking though, it was what they had used :)

 

I do not want to have to go to the added trouble and expense of trying to get wildcard certificates, especially as using the default msappproxy.net domain has one, but of course it throws errors on the local servers if they don't have that value in it as well.

Posted

I've used our external remote.school SSL certificate currently. All seems to be working, and then changed the DNS record to point to the new server address internally.

 

Externally works fine as it using the Azure proxy app connector.

Posted
Hi I just followed the standard Microsoft one

 

https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-integrate-with-remote-desktop-services

 

The gotchas to look out for are

 

This only works if you use the HTML5 Web Client, if you try and use the normal RDweb and run the .rdp file it will fail with the firewall error we've mentioned. It's a hit we are going to have to take to secure our remote server.

 

If you get stuck let me know as I've recently done this so might be able to help. I created a new RDS server as you don't need to any extra firewall/dns changes with the proxy app.

 

Thanks

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 account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...