VLT-Website-Heading

How to set up SSO to Microsoft Remote Desktop Web Access (RD Web) with Okta

Sep 5, 2021 12:59:00 AM / by Vu Long Tran

This is a step by step guide on how to set up SSO for Microsoft Remote Desktop Web Access (RD Web) on Okta.

How to set up SSO to Microsoft Remote Desktop Web Access (RD Web) with Okta

to set up Single Sign On (SSO) to Microsoft Remote Desktop Web Access (RD Web) with Okta we need to configure RD Web Access with Okta. 

What is Microsoft Remote Desktop Web Access (RD Web)?

Remote Desktop web client (also known as RD Web or now Remote Desktop Services), allows users to access an organisation's Remote Desktop infrastructure through a compatible web browser. They will be able to access remote apps and/or virtual desktops (VDIs) as they would if they were on the local PC.  

The key steps we will be going through will be:

 

Prerequisites

Before you can start setting up Single Sign On (SSO) for Microsoft Remote Desktop Web Access (RD Web) and Okta, we need to check the following:

  • Access to Windows Server - Confirm that you have administrator access to your Windows Server
  • Access to Okta Admin Console - Confirm that you have administrator access to Okta's Admin Console. If you do not have an Okta account, you can create a free Okta Trial account or Okta Developer account.
 

1. Add Microsoft Remote Desktop Web Access (RD Web) app to your Okta instance

To configure the Microsoft Remote Desktop Web Access (RD Web) application in Okta we will set up the application in Okta. 

Log in to your Okta account as an administrator (with administrator access).

Under Applications> Applications, search for the Template WS-Fed (WS-Federation Template) app in the Okta Integration Network (App Integration Catalog). 

Add Template WS-Fed app in.

Fill in the Template WS-Fed > Add Template WS-Fed options and click Done.

  • Application label - Name your Template WS-Fed app. Let's call it "Remote Desktop Web (RD Web)".
  • Web Application URL - https://<your RD Web domain>/rdweb/pages/. For example https://sync.vulongtran.local/rdweb/pages/. This is the launch URL for the Web Application.
  • (Optional) Realm - Leave blank. If we leave it blank, a generated realm will be provided in the WS-Federation setup instructions which we will use later.
  • ReplyTo URL - https://<your RD Web domain>/rdweb/pages/. For example https://sync.vulongtran.local/rdweb/pages/
  • Enter the ReplyTo URL to which responses are directed.
  • Allow ReplyTo Override - Unchecked
  • Name ID Format - Unspecified
  • Audience Restriction - urn:microsoft:rdweb. The assertion containing a bearer subject confirmation must contain an Audience Restriction including the service provider's unique identifier as an Audience
  • Assertion Authentication Context - PasswordProtected Transport
  • Group Attribute Value - windowsDomainQualifiedName
  • (Optional) Group Attribute Name - Leave blank
  • Username Attribute Statements - UPN. Make sure this matches the User Attribute setting type that you have for your users in Active Directory (AD).
  • Custom Attribute Statements - Leave blank
  • Signature Algorithm - RSA_SHA1
  • Digest Algorithm - SHA1

Click Done.

Click on the "Sign On" tab.  

Scroll down on the page and click on "View Setup Instructions". 

Click on "View Setup Instructions". 

Please take note of the details on this "View Setup Instructions", we will need this later on. 

Copy or Download WS-Federation Certificate details

We will need our "Public certificate: Download certificate" details. As this is our x509 certificate.

You can save a copy of this certificate temporarily on your computer by right clicking the link and using the "Save Link As..." option. 

You can drag and drop into your web browser if you want to see what is inside the document. Later we will need this X509 certificate details. 

(Optional) Download WS-Federation Metadata Document file

We can do the same with the "WS-Federation Metadata Document" which is our FederationMetadata.xml if we want to get our raw WS-Fed metadata xml file. 

Save a copy by right clicking the link and using the "Save Link As..." option. 

Save the file as your preferred file name, I will just leave it as "FederationMetadata.xml".

You can drag and drop the "FederationMetadata.xml" file into your web browser if you want to see what is inside the document. It is presenting the same details we saw earlier, so just showing you the other way of seeing these details in a more raw way if you prefer working with the raw metadata xml files. 

At any point of time we need to update our Remote Desktop Web (RD Web) app details in Okta. We can find it when we go to:

Okta> Applications > Applications > Remote Desktop Web (RD Web) > General tab.

There you will be able to see the settings that you have configured that you can update. 

 

2. Set up SSO settings on Windows Server

Log into your Windows Server as administrator, we will install and configure components required for Single Sign On (SSO) to operate. 

 

Steps:

Step A - Check your current settings

Step B - Install "Remote Desktop Services" 

Step C - Install "Windows Identity Federation (WIF)"

Step D - Configure Remote Desktop Services

Step A - Check your current settings

On a server that running Windows Server 2012, open and to go:

Server Manager > Add Roles and Features

We will be looking to enable each of the features (if not enabled already):

  • Remote Desktop Services (RDS)
  • Windows Identity Federation (WIF)
  • Internet Information Services (IIS) 

Check that the checkbox for each is checked.

We will walkthrough installing Remote Desktop Services (RDS) and Windows Identity Federation (WIF), as the required Internet Information Services (IIS) will be installed as part of the process of installing RDS and WIF. 

 

Step 1 - Install "Remote Desktop Services" 

Let's install Remote Desktop Services (RD Services) if we have not already. As part the steps, we will be installing Remote Desktop Services subcomponents such as RD Web, etc.

On a server that running Windows Server 2012, open and to go:

Server Manager > Add Roles and Features

Click on "Add Roles and Features"

install-remote-desktop-services (1)

Click Next.

install-remote-desktop-services (2)

Make sure "Role-based or feature-based installation" is selected. Click Next.

install-remote-desktop-services (3)

Select your preferred Windows server. Click Next.

install-remote-desktop-services (4)

Tick the "Remote Desktop Services" checkbox and make sure it is selected. Click Next.

install-remote-desktop-services (5)

Leave thee

install-remote-desktop-services (6)

Click Next

Click Next

Select the following as a minimum and then click Next

  • Remote Desktop Gateway
  • Remote Desktop Web Access

Click Add Features

Click Add Features

You will then see the key services you have selected ticked. Click Next

Click Next

Click Next

Click Next

Click Next

Click Install

Wait for it to install. 

 

Step C - Install Windows Identity Foundation 3.5

Windows Identity Foundation (WIF) is a new extension to the Microsoft .NET Framework that makes it easy for developers to enable advanced identity capabilities in the .NET Framework applications. It is a core component in configuring RD Web for Single Sign On.

The Windows Identity Foundation uses a claims-based identity model and can be used to enable single sign-on (SSO), personalization, federation, strong authentication, identity delegation, and other identity capabilities in ASP.NET and Windows Communication Foundation (WCF) applications that run on-premises or in the cloud.


Open Server Manager > Add Role> Features

Check that the checkbox for "Windows Identity Foundation 3.5" is checked.

If the "Windows Identity Foundation 3.5" option is not there, you may need to install Windows Identity Foundation manually for what Microsoft refers to as your "Windows Core". The easiest way to install this is to run a PowerShell/ cmd command with Administrator permissions on your Windows Core on your Windows 2012 R2 server:

install-windowsfeature windows-identity-foundation

Here are some step by steps:

Open PowerShell with "Run as Administrator".

Copy and paste the command (or type the command).

install-windowsfeature windows-identity-foundation

Watch it run.

When it is done, it will tell you to restart your Windows Server 2012 R2. 

 

Step C - Configure Microsoft Remote Desktop Services

Modify the C2WTShost.exe.config File for Windows Identity Foundation 3.5

Go to:

C:\Program Files\Windows Identity Foundation\v3.5\c2wtshost.exe.config

modify-wif-config-file

Open a text editor such as Notepad with elevated permissions (Run as Administrator) and open the c2wtshost.exe.config file.

modify-wif-config-file2modify-wif-config-file3

Add this Application Pools to your config file, as it will set RD Web application pool access as an allowed caller:

<add value="IIS APPPOOL\RDWebAccess"/>

 

The full c2wtshost.exe.config file looks like the following with this line included in it:

<?xml version="1.0"?>

<configuration>
<configSections>
<section name="windowsTokenService" type="Microsoft.IdentityModel.WindowsTokenService.Configuration.WindowsTokenServiceSection, Microsoft.IdentityModel.WindowsTokenService, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</configSections>

<startup>
<supportedRuntime version="v4.0"/>
<supportedRuntime version="v2.0.50727"/>
</startup>

<windowsTokenService>
<!--
By default no callers are allowed to use the Windows Identity Foundation Claims To NT Token Service.
Add the identities you wish to allow below.
-->
<allowedCallers>
<clear/>
<!-- <add value="NT AUTHORITY\Network Service" /> -->
<!-- <add value="NT AUTHORITY\Local Service" /> -->
<!-- <add value="NT AUTHORITY\System" /> -->
<!-- <add value="NT AUTHORITY\Authenticated Users" /> -->

<add value="IIS APPPOOL\RDWebAccess"/>
</allowedCallers>
</windowsTokenService>
</configuration>

modify-wif-config-file4

Enable and set Claims to Windows Token Service (C2WTS)

We will now need to enable and set the Claims to Windows Token Service (C2WTS).

Search and open services.msc.

In the list of services, locate Claims to Windows Token Service.

Right-click it, then click Properties.

Set the Startup type is set to Automatic.

Click Start to begin the service.

(Optional) Click on Dependencies tab and take note that there is no dependencies listed. We will change that in the next step. 

When you are ready, click Done.

 

Configure the Claims to Windows Token Service (C2WTS) to start after the Cryptographic Services Service

Claims To Windows Token Service (c2WTS) has a dependency on Cryptographic Services service. So we want to make sure that Cryptographic Services Service will start before C2WTS, by explicitly adding the following dependency in the service definition:

Open PowerShell 7 with "Run as Administrator".

Copy and paste the command (or type the command) and press Enter

sc config c2wts depend= CryptSvc

Now let's go back to the "Claims to Windows Token Service" service settings. 

Search and open services.msc.

In the list of services, locate Claims to Windows Token Service.

Right-click it, then click Properties.

Click on the Dependencies tab, ensure that "Cryptographic Services" (also known as CryptSvc) is listed.

Click OK.


 

Step D - Configure Microsoft Remote Desktop Services RDWeb access

Update the RD Web AccessApplication Pool

In Server Manager > IIS > Internet Information Services (IIS) Manager.

You should then see the Internet Information Services (IIS) Manager.

Click on your Windows Server (where you have installed Remote Desktop Web) and it expand out. 

Click on "Application Pools".

Click on "RDWebAccess" application pool.

Right-click the "RDWebAccess" application pool, then select Advanced Settings.

Scroll down on the "Advanced Settings".

Select True from the Load User Profile options, then click OK.

In your Internet Information Services (IIS) Manager (Server Manager > IIS > Internet Information Services (IIS) Manager). 

Go to:

RDWeb Server > Sites > Default Web Site > RDWeb > Pages

Essentially it will be along this path: WINDOWS-SERVER-\Sites\Default Web Site\RDWeb\Pages

Look for "Configuration Editor". Under the "Management" section.

Open the "Configuration Editor".

You are then presented with the "Configuration Editor".

Now click on the dropdown box at the top of the screen and navigate to system.web > authentication.

You are then presented with the system.web > authentication options

Let's expand the system.web > authentication options

Confirm that both defaultUrl and loginUrl are set to default.aspx, and as required, click "Apply".

That is:

  • defaultUrl - default.aspx
  • loginUrl - default.aspx

As required, click "Apply". It will be greyed out if there are no changes to Apply.

 

Backup and modify the web.config File for RDWeb

We will now modify the web.config File for RDWeb. 

We will also make a backup of the existing web.config file before making any modifications in case we need it in the future.
 

Go to:

C:\Windows\Web\RDWeb\Pages\

Open a text editor such as Notepad with elevated permissions (Run as Administrator) and open the web.config file.

C:\Windows\Web\RDWeb\Pages\web.config

Here is a default web.config file. 

Let's make a copy of the web.config file. 

We can do that easily by right clicking the web.config file, selecting "Copy" and "Paste". 

Now we have two web.config files. 

Let's make changes to our web.config file now. 

For our web.config file edit, we will be updating the following sections:

  • <configuration>
  • <system.web>
  • <authentication> and <authorization>
  • <modules>
  • Under the </runtime>

<configuration>

At the top of the file, after <configuration> add the following lines:
<configSections>
<section name="microsoft.identityModel" type="Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</configSections>

<system.web>

Add the following lines immediately after the <system.web> tag:

<httpRuntime targetFramework= "4.5" requestValidationMode="2.0"/>
<pages validateRequest="false"/>

Before the <system.web> tag we also need to remove the httpruntime reference.

<httpRuntime targetFramework= "4.5"/>

<authentication> and <authorization>

Modify the <authorization> and <authentication> tags below the <system.web> tag to reflect the following lines:

<authorization><deny users="?" /></authorization>
<authentication mode="None" />

<authorization><deny users="?" /></authorization>
<authentication mode="Windows" />

edit-web-config-file3

<modules>

In the <system.webServer> section, add the following lines immediately after the <modules runAllManagedModulesForAllRequests=”true”> tag.

<modules runAllManagedModulesForAllRequests="true">
<add name="WSFederationAuthenticationModule"type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"preCondition="managedHandler"/>
<add name="SessionAuthenticationModule"type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"preCondition="managedHandler"/>

edit-web-config-file4

Note - If you only see <modules>, you will need update it to have "<modules runAllManagedModulesForAllRequests=”true”> config code, and then end with </modules>.

 

Under the </runtime>

In this section we will need to leverage the details that we have from our Okta Template WS-Fed configuration details in Okta. That is leveraging:

  • Settings displayed in our General tab (via Okta> Applications > Applications > Remote Desktop Web (RD Web) app> General tab). 
  • View Setup Instructions and/or FederationMetadata.xml metadata file.

As we will need to add in four of our customer specific configurations here. 

To help you visualise where these details are, here is an easy reference of where you could find the details to here. 

Audience Restriction/ audienceUris value

Audience Restriction/ audienceUris value from our General tab (via Okta> Applications > Applications > Remote Desktop Web (RD Web) app> General tab)

View Setup Instructions and/or FederationMetadata.xml

From our FederationMetadata.xml metadata file and/or View Setup Instructions. (via Okta> Applications > Applications > Remote Desktop Web (RD Web) app> Sign On tab> View Setup Instructions).



Once you have these details, we can go to the web.config file and add these lines "after/ under" the </runtime> section.

<microsoft.identityModel>
<service>
<certificateValidation certificateValidationMode="None"/>
<audienceUris>
<add value="urn:microsoft:rdweb"/>
<add value="urn:okta:app:oktaentityid"/>
</audienceUris>
<securityTokenHandlers>
<add type="Microsoft.IdentityModel.Tokens.Saml2.Saml2SecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<samlSecurityTokenRequirement mapToWindows="true" useWindowsTokenService="true" />
</add>
</securityTokenHandlers>
<applicationService>
<claimTypeRequired>
<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" optional="true" />
</claimTypeRequired>
</applicationService>
<issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<trustedIssuers>
<add thumbprint="thumbprint-here" name="urn:okta:app:oktaentityid"/>
</trustedIssuers>
</issuerNameRegistry>
<federatedAuthentication>
<wsFederation passiveRedirectEnabled="true" issuer="https://youroktadomain.okta.com/app/template_wsfed/sso/wsfed/passive" realm="urn:okta:app:oktaentityid" requireHttps="false" />
<!-- The requireSsl="false" setting is insecure and used for testing. This setting should not be used in production deployments. -->
<cookieHandler requireSsl="false" />
</federatedAuthentication>
</service>
</microsoft.identityModel>

Here is an example:

Save the web.config file.

 

Change the RDWeb/Pages Application to use Kerberos

In your Internet Information Services (IIS) Manager (Server Manager > IIS > Internet Information Services (IIS) Manager). 

Go to:

RDWeb Server > Sites > Default Web Site > RDWeb > Pages

Essentially it will be along this path: WINDOWS-SERVER-\Sites\Default Web Site\RDWeb\Pages

Look for "Authentication". Under the "IIS" section.

Double click on Authentication to open it.

Right-click on "Windows Authentication", then "Providers".

Click Providers.

 

From the drop down menu of "Available Providers", select Negotiate: Kerberos.

Click Add and click OK.

You will see see the "Windows Authentication" status as "Enabled".

We will now load a PowerShell ("Run as Administrator") and run a iisreset. 

iisreset /noforce

 

4. Test that SSO is working with Microsoft Remote Desktop Web (RD Web)

When you are ready, let's test that it works.

In Okta Admin Console, let's assign a user to the application. (Applications> Applications>Microsoft Remote Desktop Web (RD Web) app)

Go to "Assignments" tab. (Applications> Applications> Microsoft Remote Desktop Web (RD Web) app> "Assignments)

Select "Assign" and "Assign to People".

assign-test-user

Select our test user, click "Assign" and then "Done".

We can now test the configuration, by either by:

1. Testing by accessing the RD Web Access Server page URL directly OR

2. Testing by accessing the RD Web Access Server page URL via Okta.

Testing by accessing the RD Web Access Server page URL directly

Go to your RD Web Access Server page URL. In my example it is https://sync.vulongtran.local/rdweb/pages/.

You are redirected to Okta for authenticate. 

This includes a multifactor authentication (MFA) check if you have created a policy to challenge the user for MFA. 

Once authenticated, the user should automatically be redirected to your RD Web Access dashboard, which displays your application icons. The the user will then be able to view and launch available applications as per usual.This indicates a successful access into the RD Web Access application.

Testing by accessing the RD Web Access Server page URL via Okta

For testing via Okta, let's log into our Okta instance as a test user. You may need to refresh your browser if you had the browser window already open.

  • Log into Okta instance as a test user. 
  • Click on "Microsoft Remote Desktop Web (RD Web)" application icon (chiclet).
  • Once authenticated, the user should automatically be redirected to your RD Web Access dashboard, which displays your application icons. The the user will then be able to view and launch available applications as per usual.This indicates a successful access into the RD Web Access application.

Success, you will be logged in successfully to your Microsoft Remote Desktop Web (RD Web) account!

 

Tips and troubleshooting

Web Application Proxy not supported for Microsoft Remote Desktop Services (after Windows 2016)

Please note that Remote Desktop Services does not support using Web Application Proxy, which is included in Windows Server 2016 and earlier versions.

https://docs.microsoft.com/en-gb/windows-server/remote/remote-access/web-application-proxy/web-application-proxy-windows-server

 

Error 1075 - Claims to Windows Token service service 

Windows could not start the Claims to Windows Token Service service on Local Computer.

Error 1075: The dependency service does not exist or has been marked for deletion.

Solution:

Try re-running the command to add "Cryptographic Services" (also known as CryptSvc) as a dependency for your "Claims to Windows Token Service".

Open PowerShell 7 with "Run as Administrator".

Copy and paste the command (or type the command) and press Enter

sc config c2wts depend= CryptSvc

Make sure you remove the extra httpruntime reference

Make sure you remove the extra httpruntime reference, as we have added a new httpruntime reference. 

Solution:

In the web.config file, before the <system.web> tag we also need to remove the httpruntime reference.

<httpRuntime targetFramework= "4.5"/>

 

 

ID4175 Error message

"Server Error in '/RDWeb/Pages' Application.

ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer."

Solution:

  • Re-enter thumbprint - Check your RD Web Access web.config(C:\Windows\Web\RDWeb\Pages\Web.config) and make sure the thumbprint is correct. Try manually typing the certificate thumbprint rather of copying and pasting this certificate thumbprint.
  • Re-generate your thumbprint - You can do this, by copying and pasting the X509Data details into a new text file and save it as a .cer file, let's say "rds-wsfed.cer" as the file name. 

For example,

Go to FederationMetadata.xml. Copy the X509Data details. 

In your "rds-wsfed.cer" text file using Notepad or in my example Visual Studio Code editor, enter the following details and save it. 

-----BEGIN CERTIFICATE-----
EnteryourX509Datahere
-----END CERTIFICATE-----

On your computer, then doubleclick it to open the View Thumbprint details.

Then you will see options, click on "View Certificates".

Click on "Details" to expand it. 

Scroll down until you see these details. (Please note that I have blurred out my certificate details). 

checkthumbprint2

 

Trusted delegation for current account user error

The computer must be trusted for delegation and the current user account must be configured to allow delegation. 

"Server Error in '/RDWeb/Pages' Application

The requested operation cannot be completed. The computer must be trusted for delegation and the current user account must be configured to allow delegation.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Security.Cryptography.CryptographicException: The requested operation cannot be completed. The computer must be trusted for delegation and the current user account must be configured to allow delegation."

 

 

Solution:

You have tried setting delegation access on the computer and/or user account and it seems to make no difference.

To resolve this issue we can create the following registry key on the Windows 10 computer:

HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb

That is:

Right Click, create new Dword (32bit) Value, name it 'ProtectionPolicy'

Edit it to the value of 1.

This should then solve the issue immediately, no restart is required.

 

Unable to cast object type of Microsoft Claims Identity

Server Error in '/RDWeb/Pages' Application.

Unable to cast object of type 'Microsoft.IdentityModel.Claims.ClaimsIdentity' to type 'System.Security.Principal.WindowsIdentity'.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.InvalidCastException: Unable to cast object of type 'Microsoft.IdentityModel.Claims.ClaimsIdentity' to type 'System.Security.Principal.WindowsIdentity'.

Solution:

Check in your IIS manager that the services has authentication enabled, else user will not be prompted for authentication. 

We then need to reset our IIS Manager. So we will load a PowerShell ("Run as Administrator") and run a iisreset. 

iisreset /noforce

iis-enable-windows-authentication3

 

 

Resources

Topics: sso

Vu Long Tran

Written by Vu Long Tran

Solutions Engineer APAC. ex-@Forrester consultant. Writing on #cloud #howto guides and #tech tinkering!