New RDP client for Android/IOS/Mac doesn't work with RaWeb

[sashaqwert]

Introduction

Until yesterday, I was using "Microsoft RD Client 8". It works well so far. But in the description of the last update it was written that an improved version was released and I went to try it. The new application offered to import all settings from the old one, but the feed was not working.

How I tried to solve the problem

1. I noticed that my feed address has changed to "https://server.example.com/webfeed.asp/RDWeb/feed/webfeed.aspx".
2. Tried to remove the weird part at the end (so that it ends with webfeed.asp), but it didn't help.
3. Opened the RaWeb GitHub repository and saw the ASPX version. Added files with replacement. Partially helped!
4. Specified the feed "https://server.example.com/webfeed.aspx". The channel passed validation, but gives the error "The remote resoursesserver could not be contacted."

Screenshots

Old version New version

Additional Information

The old version works correctly with both ASP and ASPX versions. Old version: https://play.google.com/store/apps/details?id=com.microsoft.rdc.android New version: https://play.google.com/store/apps/details?id=com.microsoft.rdc.androidx

[DFC1990]

The same Problem with Mac and the Remote Desktop Application

[sashaqwert]

@DFC1990 Everything is logical. The fact is that the Android client has been transferred to the same code base as the iOS and MacOS clients. this is now becoming of little use RaWeb on mobile devices (until there is a solution to this problem)

[sashaqwert]

Today I came across an RDP file for new clients. Its content can be found in issure to another project https://github.com/FreeRDP/FreeRDP/issues/6979#issue-868154151 Perhaps this will help in solving the problem...

Pay attention to the parameter

workspace id:s:someid.somewhere.org

Perhaps - something like this is missing in webfeed.aspx

[sashaqwert]

As it turned out, my assumption from the previous comment is correct.

Came across MSRDC client URI today and decided to add my feed via URI (Adding via GUI didn't work). When adding, a message appeared with a normal error: Failed to subscribe because there is no workspace in https://example.com/RemoteApp/webfeed.aspx. Please check the URL and try again.

Screenshot (Russian language)

Continue button does nothing

[kimmknight]

Interesting. Thank you for all the investigating you have done @sashaqwert.

My new project, rdpx, is intended to replace RAWeb.

https://github.com/kimmknight/rdpx

It's webfeed is structured the same as the RAWeb's, so I suspect it will have the same problem. Looking forward, I will need to try and find a solution.

[sashaqwert]

It's webfeed is structured the same as the RAWeb's

In this case, you can try to extract the original Webfeed from Windows Server 2016/2019/2022 The server must have the Web Access RemoteApp role installed.

[sashaqwert]

webfeed.aspx from Windows Server 2022 (Not fake):

<!-- 
    Empty page so that the IIS defaultDocument functionality will successfully redirect to WebFeed.aspx.
    The FeedWebFeedHandler HttpHandler will actually take over the request afterwards, so the contents of this file
    will never be used.
-->

It's all :)

[sashaqwert]

Found a discussion about this issue on the Microsoft site https://docs.microsoft.com/en-us/answers/questions/57891/mac-microsoft-remote-desktop-app-10-remote-feed-is.html

[kimmknight]

Perhaps - something like this is missing in webfeed.aspx

I am not convinced that the missing workspace id in the RDP file is causing this problem. The problem seems to occur before the client downloads the RDP files. The missing workspace id might be a problem, but there's another one to solve first.

I built a new Windows Server 2016 vm with some test RemoteApps. I can connect the new client (Windows Store/Android) to it successfully.

I have been logging the client connections to the server (IIS) so I can inspect the request/response etc. I have some clues but no answers yet. I think one issue is that the new RDP client expects NTLM authentication. More testing required.

[sashaqwert]

I am not convinced that the missing workspace id in the RDP file is causing this problem. The problem seems to occur before the client downloads the RDP files. The missing workspace id might be a problem, but there's another one to solve first.

Adding the workspace id fixed another issue. The taskbar now displays the real status of the remoteApp connection. Bonus: you can disconnect from the session by clicking the icon in the taskbar, provided that the workspace id matches the name of the server computer.

Connection notification and the ability to disconnect the session in the taskbar (screenshots in Russian)

I'm not sure whether the workspace id is mandatory.

[kimmknight]

I have made progress but I’m stuck. Please help if you can!

I have managed to get the latest Android RD client to authenticate and begin to load the resources!

I am using the Android client because it allows you to ignore SSL certificate errors which makes testing easy.

So far the client can:

1. Discover the feed
2. Authenticate
3. Load the workspace (as long as it contains no resources)

Feed discovery occurs when you are typing the URL of the host into the client. With each keypress, the client will attempt to connect to the URL and validate it.

This was fairly straightforward:

The client attempts to retrieve some common webfeed paths. (I am using /RDWeb/Feed/webfeed.aspx). It expects to receive a 302 redirect to a login URL (I am using /RDWeb/FeedLogin/WebFeedLogin.aspx) which must respond with a 401 requiring authentication (I am using Windows Auth). At this point, even though the client doesn’t actually authenticate, it considers the URL entered as valid and with allow you to tap NEXT.

Authentication occurs after NEXT is tapped on the client. The user will be prompted for credentials and /RDWeb/FeedLogin/WebFeedLogin.aspx will be retrieved once authenticated. The WebFeedLogin.aspx simply responds with a tracking code in the body of the response. This will be used as the .ASPXAUTH cookie for future requests from the client. I am also choosing to set the cookie in the response.

In my testing, I am just sending a static value that does not change per user/per session.

After receiving this response, the client will then go back and request webfeed.aspx.

To prevent webfeed.aspx from 302 redirecting the client back to WebFeedLogin.aspx, I have made it so that it will only redirect if the .ASPXAUTH cookie is not set. Otherwise, it will respond with the webfeed resource XML.

As .ASPXAUTH is generally used as part of Forms authentication, I’m guessing there is a much more secure and elegant way of achieving what I have done here.

The client will then attempt to Add the workspace using the given webfeed resource XML.

This is where things get a bit strange for me.

• If the resource list XML contains no <resource> (but the rest of the XML is there), then the Android client will add the workspace successfully (although empty).

• If the resource list XML contains one or more <resource> entries, IIS logs show that the client will grab the three files listed for each resource (rdp, png, and ico files), but will hang while “Preparing managed resources…”.

My IIS configuration:

Download my test site content: rdweb-research.zip

My test RDWeb folder has been added to the Default Web Site.

The RDWeb/FeedLogin folder has been converted to an Application (to allow a different auth method).

The RDWeb/Feed folder/application allows Anonymous Authentication only.

The RDWeb/Feed folder/application has a MIME type for .rdp files set to application/rdp

The RDWeb/FeedLogin application has Windows Authentication enabled only.

Any ideas/answers would be greatly appreciated! These could be about how to do the authentication better/properly, or about what's going wrong when the client is loading resources.

[thefiredragon]

I'd like to play with your investigations, but I don't have much skills with aspx sadly.

[indieshack]

Downloaded and unpacked rdweb-research.zip, but got an error on connection using the MacOS client

[kimmknight]

@indieshack - Thanks for trying. If the MacOS client is like the Windows client, it will require a valid certificate for HTTPS (in IIS) before it will allow a connection. It would be great if you could let us know if you had one or not. Cheers!

[indieshack]

Apologies, "got an error on connection" wasn't a very helpful description of the error! Yes, I have a self-signed cert on 443, and it works fine for (example) retrieving the standard webfeed on RAWeb. The error I was getting after installing your test folders was "The page cannot be displayed because an internal server error has occurred.". I (hopefully) will have time later to check the web logs to see the cause of the error. Thanks for your work on this.

[indieshack]

I think it's perhaps a mixture of permissions and config; I'm a dev but don't have much experience using .asp/x. If I get time over the weekend I'll play around with this more.