This blogpost is the second part in the series about publishing your RDS environment with Azure AD Application Proxy. In the first part of the series I’ve described the improvements made to RDS 2016 and the basic configuration of Azure AD Application Proxy for publishing both the RDWeb and RD Gateway role. In the first part we’ve configured pass-through authentication, this blogpost will cover all the changes needed to configure pre-authentication with Azure AD. When configured users will be redirected to the AzureAD login form and after a successful logon you will get the logged-in RDWeb feed.
Let’s first look into Azure AD pre-authentication compared to pass-through authentication. With both types of authentication the RD Web/Gateway role can be placed in your internal network (LAN). Conclusion: no difference regarding security. Then looking to the authentication part, with pre-authentication you can authenticate against your Azure AD or against your local AD with ADFS. If you have a federated domain configured in Azure AD your ADFS environment will be used for authentication. If federation is not configured your Azure AD will be used for authentication. For both authentication options your local Active Directory need to be synchronized to Azure AD with Azure AD Connect. Also the UPN of your users should be the same on premise and in Azure AD.
The last thing to discuss before we dive into the configuration is Single-Sign-On. With pass-through authentication you will have Single-Sign-On from the moment the user logs in to the RD Web page. With pre-authentication based on Azure AD/ADFS you will lose the Web SSO if you were utilizing Internet Explorer. Each user will get a second login prompt when starting a RemoteApp or Session Desktop. The reason behind this is that with pass-through authentication the SSO ActiveX component utilized by RD Web will be used and with pre-authentication this ActiveX component will not be used. Instead, the Application Proxy connector will automatically log the user into the RD Web feed using delegation, landing users immediately to their feed after they perform pre-authentication. If you want more information about this, please let me know. Let’s now dive into the configuration of pre-authentication. I advise you to first follow the steps of part 1 and then continue with the steps below:
- First we need to configure a SPN on the VM where you’ve installed the Azure AD Application Proxy. Go to the Computer in the Active Directory Users and Computers tool and go to the Attribute tab. Add the SPN:
- Now go to the Delegation tab and add the SPN to list of services:
- Next step is to configure the SPN and activate pre-authentication in Azure AD Proxy. Go to https://manage.windowsazure.com. Open your Azure Active Directory and go to the Applications Tab. Open the properties of your RD Web application which you’ve created in the first part of my series.
- Now select ‘Azure Active Directory’ as preauthentication method:
- Now select and fill in the information needed for Azure Active Directory authentication:
- Save your Application by clicking save in the bar below.
- If you now go to the URL of your RD web page you the redirection to the Azure AD login should be active.
- The next and last step is to activate Windows Authentication on the RD Web. Open the IIS console on your RD Web server
- Active Windows Authentication in the IIS Console:
- Edit the file %SYSTEMROOT%\Web\RDWeb\Pages\web.config. Change the following sections:
<!-- <authentication mode="Forms"> <forms loginUrl="default.aspx" name="TSWAAuthHttpOnlyCookie" protection="All" requireSSL="true" /> </authentication> -->
<!-- <modules runAllManagedModulesForAllRequests="true"> <remove name="FormsAuthentication" /> <add name="RDWAFormsAuthenticationModule" type="Microsoft.TerminalServices.Publishing.Portal.FormAuthentication.TSDomainFormsAuthentication" /> </modules> -->
<security> <authentication> <windowsAuthentication enabled="true" /> <anonymousAuthentication enabled="false" /> </authentication> </security>
- Save and close the file and now edit the file %SYSTEMROOT%\Web\RDWeb\Pages\en-us\Default.aspx
public bool bShowPublicCheckBox = false, bPrivateMode = true, bRTL = false;
Save and close this file.
Everything should now be in place so let’s test the scenario:
When I enter the URL of my RD Web page I’m send to the Azure AD Login Page:
When I enter my username I’m send to my ADFS environment:
When I enter my credentials and click on Login I’m logged in to my RD Web feed:
When I now click on my Desktop I need to enter my credentials:
When my credentials are entered a connection to my desktop is made:
Personally I think using pre-authentication using Azure AD/ADFS is the preferred way because it will give you all the powerful functionality which we can do with Azure AD applications like Conditional Access and Multi-Factor authentication (RD Web). The following functionality need to be fixed to make it the ultimate solution:
- Support for this authentication in the clients apps (iOS and Android). Currently performing this ADAL login doesn’t work in the Remote Desktop client applications, but works well when using desktops/web browsers.
- Single-Sign-On is needs to be solved in the future, when that’s fixed it’s the ultimate solution to publish your RD Web and RD gateway.
In the next part of the series I want to look into making this solution high available and sharing some excellent content published by Microsoft about setting up Azure AD Application Proxy.
36 thoughts on “Publish your RDS environment with Azure AD Application Proxy – Part 2”
Thank you for this amazing blogpost.
Just one question. Is it possible to get more information on why each user gets a second login prompt when starting a RemoteApp or Session Desktop? Why with AAD pre-authentication does the SSO ActiveX component not get used?
Thanks for your comment. The reason that each user gets a second login prompt when using Pre-Authentication is that the ActiveX Components is not able to provide the SSO. The Reason why this ActiveX component is not used is that AzureAD Pre-authentication is doing a SSO based on Windows Authentication (Kerberos Constrained Delegation) and not using form based authentication of the RDS Web Access. This is the same when using on premise ADFS to publish your RDS environment.
Hope this answers your questions.
Thanks for the post, it really helps a lot! Access via Passthrough is working fine, but when I enable pre-authentication, I get an access denied error directly after login in Azure. I confirmed that my login has rights in Azure to access the app, what else should I check? Does the RPC app in Azure also need to be changed to pre-authentication too? Thanks again for your help!
I think I’ve solved the issue; I created SPNs for both the internal and external names of the RDS server, and made sure both were on the delegation tab of the Proxy Server. Now it’s working! Thanks again!
Hi Tim, apologies as this is an old comment so suspect I’m far too late but when you say both on the delegration tab of the proxy server , is that the proxy connector server , as in you had it on a different server than the RD web and RD Gateway . I have it all on the one server and I am seeing this behaviour but I can’t add the http Internal FQDN as it says the value already exists (since it’s already itself I don’t think it needs to delegate any creds?) thanks
Hi, This has been a great help however, I seem to be having an isse when the internal RDWeb site loads. As it fails to display all the images. An ideas on what may be causing this?
I get this as well. Did you ever resolve this?
The answer is to ensure that ‘Translate URL headers’ is set to ‘No’
I’ve been working on setting this up but I noticed something that was not apparent at first glance. This setup is only using Azure AD pre-authentication for the RD Web Access website and using passthrough authentication for the remote desktop application. If someone were to open up Remote Desktop and manually type in the gateway server all Azure authentication (including 2 factor) is bypassed.
You can force pre-authentication by adding the following settings in your RDS Collections:
pre-authentication server address:s:https://externalfqdn/rdweb/
Is there any similar setting for the DefaultTSGateway?
Hi does this stop someone from entering the address directly as the gateway address .. in my test this passed all pre authentication …
Indeed, it should stop users from getting access by entering the GW adress in directly.
Great guide, just used it to set up RDS via Azure AD Application Proxy at my workplace. The only issue is the lack of support for the ADAL login on the Remote Desktop mobile apps, which is really disappointing.
Is it the Gateway credentials it’s not passing through? Seems odd it doesn’t work as the .rdp file prompts for credentials before connecting (as you’d expect without the RDWeb ActiveX control).
FYI I’ve submitted feature requests in both the iOS and Android User Voice forums for ADAL support, please vote to get them bumped up the list for the developers to take a look at:
Very informative! Can I ask if you eventually got the “signout” link to work? I can’t seem to signout from RDWeb?
I haven’t tested that but it should work, do you receive an errors when logging out?
Thanks for the write-up, This is working for me. I just would like to skip the part where we need to fill in the credentials after RDWeb SSO. Would it be possible to fix that using GPO setting “Allow Delegating Default Credentials” like described here:
provided we use domain joined clients
No, this is not possible. I’ve confirmed this by the Product Team and this extra login cannot be skipped.
We are trying to set this up right now and cannot get it working. We have SPN setup on RD GW. We have two AADAP servers both have delegation to this SPN. The internal and external DNS name is the same. The RPC and RDWEB apps are configured exactly to your specifications. The GW has the web role on it. Seperate CB and then multiple RDS collections. When the user hits the outside dns name they get Azure AD preauth and MFA which is good. After logging in they see the list of RDS remoteapps and desktops available to them. When they click on the app it tries to launch and a logon prompt appears with the users UPN and it says logon failed. We tried manually typing in credentials but each type is just says logon failed and cannot make the connection to the app. Any ideas for what we should be looking at and why the GW cannot launch the apps?
Did you tried to set-up a session from the RD Gateway server? I’ve seen this during my testing. After setting up an RDS Session from the GW server it started to work through AAD Proxy.
Let me know,
Can you explain what you mean by set-up a session from the RD GW server?
Login through RDP on your Gateway server, start a session to your RD Web interface and start a RDS session as user. If this session is started without any issues then try to do it from a client through the AAD App proxy.
Users already can access the RDGW on the internet network and access the web interface and launch apps just fine. They just can’t do this from outside using AADAP. They are unable to launch the app in the web page and just get logon failed errors. They are able to log on and see the list of apps on the page.
Have you tested this setup on 2016? For some reason the RDweb pages keeps prompting for credentials.
I haven’t tested this with RDS 2016 final release. But I’ve got it working with the latest TP5 and based on my information nothing is changed from TP5 to final release. Probably something is changed in AzureAD App Proxy. Currently I don’t have an active demo environment with this configuration. Do you see the failed logins on your RD Web server in the eventlogs?
Useful post thanks. We’re trying this with RDS 2016 as well but credentials aren’t working when launching an app, any ideas? RDWeb works great for single signon but looks like the RPC side of things isn’t happy and I can’t find any sign of authentications failures internally.
I haven’t tested this with RDS 2016 final release. But I’ve got it working with the latest TP5 and based on my information nothing is changed from TP5 to final release. Probably something is changes in AzureAD App Proxy. Based on your comment logging in to RDWeb is working but when connecting to a desktop or app it fails?
Yes thats correct. I have pre-authentication set to Azure Active Directory for the /RPC Azure application and I’ve now noticed you aren’t doing this. Using passthrough does work for me but leaves a direct path open if you manually use app proxy url as the gateway in your RDP connection as discussed above. I think using the “pre-authentication server address:s:https://externalfqdn/rdweb/…..” will only enforce if using an RDP file generated by RDWEB. I’m looking at potentially using the same URL for external and internal so I can publish from the root, perhaps pre-authentication may work better that way?
Anyone get this working? I have the same issue, i get to the RDP published and then my credentials are never accepted?
Does this only work within your network like the WAP, ADFS and RDWeb combination?
I ask because we are looking for a solution to have SAML 2.0 authentication (Possible in ADFS) to be able to logon into RDWeb.
The RDWeb Windows Authentication method only works within your domain, but not from external sources.
It worked from external locations. Since my environment was hosted on Azure and I tested it from my home network. All Server roles need to be part of the same AD and possible network. Please drop me a note through the contact form to discuss this via mail if you want more information.
Hi Arjan, great post. Everything works fine for me until I put in my credentials for my app. I log in to Azure successfully and then it automatically logs me into to RDWEB. I then click my app and put in my credentials but the app doesn’t load and the connection times out. Any suggestions would be appreciated. Thanks!
Are you able to connect from the server hosting the AzureAD App Proxy connector?
No, I was not able to connect. I ended up switching everything back the way it was because it was working, just with multiple password prompts. Is true SSO even currently possible? Log on to Azure -> redirects to rdweb, click my app -> app opens, no prompting? From the previous comments it doesn’t seem like it is possible. Thanks for your quick response.
Hi, for anyone coming across this post, I found you can have a single Azure app for both RD Web and Gateway (on same box), enforcing Azure pre-auth for both. This disallows bypassing using RDP connection with gateway set. But you must use IE with the active x plugin to provide the SSO from web to gateway. I followed the steps below, works perfectly. Although you have to authenticate again on the RDWeb page, it does achieve the goal of enforcing MFA.