- Le raccordement se fait dans le fichier web.config du portail, situé dans C:\Windows\Web\RDWeb\Pages.
- Le portail passe de l’authentification par formulaire à une authentification déléguée, en refusant les accès anonymes.
- Les sections modifiées sont repérées par des commentaires dans le fichier ; le reste correspond à la configuration d’origine.
- En ferme RDWeb, une machineKey identique sur tous les serveurs est indispensable.
- Public
- Administrateurs systèmes et identités
- Niveau
- Avancé
- Environnement
- Remote Desktop Services, IIS, Okta
- Précaution
- Sauvegarder le web.config d’origine
Le contexte#
Okta est une plateforme cloud de gestion des identités et des accès : authentification unique, authentification multifacteur, détection d’anomalies, gestion des accès par rôles. Une fois Okta adopté, les utilisateurs s’attendent à ce que toutes leurs applications en profitent, y compris le portail RDWeb qui publie les bureaux et applications distants.
L’enjeu est double : simplifier la connexion des utilisateurs et appliquer à RDWeb les mêmes politiques de sécurité que pour le reste, notamment l’authentification multifacteur.
Avant de commencer#
- sauvegardez le fichier
web.configd’origine, pour pouvoir revenir en arrière ; - travaillez d’abord sur un serveur de test ou en dehors des heures d’utilisation ;
- vérifiez que l’application correspondante est configurée côté Okta, avec les groupes d’utilisateurs autorisés ;
- si plusieurs serveurs RDWeb fonctionnent en ferme, préparez une
machineKeycommune.
Le fichier web.config#
Le fichier se trouve dans C:\Windows\Web\RDWeb\Pages. Les blocs encadrés par des commentaires marquent les sections ajoutées ou modifiées par rapport au fichier d’origine :
<?xml version="1.0" encoding="UTF-8"?><!-- Note: As an alternative to hand editing this file you can use the web admin tool to configure settings for your application. Use the Website->Asp.Net Configuration option in Visual Studio. A full list of settings and comments can be found in machine.config.comments usually located in \Windows\Microsoft.Net\Framework\v2.x\Config--><configuration><!-- Idaptive --><configSections> <section name="microsoft.identityModel" type="Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection,Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral,PublicKeyToken=31bf3856ad364e35" /></configSections><!-- /Idaptive --> <!-- Admin Defined settings --> <appSettings> <!-- PasswordChangeEnabled: Provides password change page for users. Value must be "true" or "false" --> <add key="PasswordChangeEnabled" value="false" /> <!-- LocalHelp: Displays local help for users, instead of the web-based help. Value must be "true" or "false" --> <add key="LocalHelp" value="false" /> <!-- ShowDesktops: Displays or hides the Remote Desktops tab. Value must be "true" or "false" --> <add key="ShowDesktops" value="true" /> <!-- DefaultTSGateway: Admin can preset this to a given Gateway name, or set to "" for no gateway. --> <add key="DefaultTSGateway" value="" /> <!-- GatewayCredentialsSource: TS Gateway Authentication Type. Admins can preset this. 0 = User Password 1 = Smartcard 4 = "Ask me later" --> <add key="GatewayCredentialsSource" value="4" /> <!-- Devices and resources: Preset the Checkbox values to either true or false --> <add key="xPrinterRedirection" value="true" /> <add key="xClipboard" value="true" /> <add key="xDriveRedirection" value="false" /> <add key="xPnPRedirection" value="false" /> <add key="xPortRedirection" value="false" /> <!-- Public/Private Mode Timeout for FBA --> <add key="PublicModeSessionTimeoutInMinutes" value="20" /> <add key="PrivateModeSessionTimeoutInMinutes" value="240" /> <!-- Checkbox to opt for optimized LAN experience --> <add key="ShowOptimizeExperience" value="false" /> <add key="OptimizeExperienceState" value="false" /> <add key="AuthenticationContext" value="pages" /> </appSettings> <connectionStrings /> <system.web> <!-- Idaptive --> <httpRuntime targetFramework="4.5" requestValidationMode= "2.0"/> <pages validateRequest= "false"/> <!-- /Idaptive --> <!-- The <authentication> section enables configuration of the security authentication mode used by ASP.NET to identify an incoming user. --> <!-- To turn on Windows Authentication: - uncomment <authentication mode="Windows"/> section - and comment out: 1) <authentication mode="Forms"> section. 2) <modules> and <security> sections in <system.webServer> section at the end of the file. 3) Optional: Windows Authentication will work in https. However, to turn off https, disable 'Require SSL' for both RDWeb and RDWeb/Pages VDIR. Launch IIS Manager UI, click on RDWeb VDIR, double click on SSL Settings in the middle pane, uncheck 'Require SSL' and click Apply in the top right in the right pane. Repeat the steps for RDWeb/Pages VDIR. --> <!-- Idaptive --> <authorization><deny users="?" /></authorization> <authentication mode="Windows"> <forms defaultUrl="default.aspx" loginUrl="default.aspx" name="TSWAAuthHttpOnlyCookie" protection="All" requireSSL="true" /> </authentication> <!-- /Idaptive --> <webParts> <personalization defaultProvider="TSPortalProvider"> <providers> <add name="TSPortalProvider" type="Microsoft.TerminalServices.Publishing.Portal.TSPortalProvider" /> </providers> <authorization><deny users="?" /></authorization> </personalization> </webParts> <!-- machineKey attribute allows you to have a RDWeb cluster for high availability. You will have to generate valid decryptionKey and validationKey --> <machineKey decryption="Auto" decryptionKey="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" validationKey="BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB" /> </system.web> <system.webServer> <handlers> <add name="PagesWebFeedHandler" path="WebFeed.aspx" verb="*" type="Microsoft.TerminalServices.Publishing.Portal.PagesWebFeedHandler" preCondition="integratedMode" /> </handlers> <modules runAllManagedModulesForAllRequests="true"> <remove name="FormsAuthentication" /> <add name="RDWAFormsAuthenticationModule" type="Microsoft.TerminalServices.Publishing.Portal.FormAuthentication.TSDomainFormsAuthentication" /> <add name="SessionAuthenticationModule" type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" /> <add name="WSFederationAuthenticationModule" type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" /> </modules> <security> <authentication> <windowsAuthentication enabled="true" useKernelMode="false"> <extendedProtection tokenChecking="None" /> <providers> <clear /> <add value="NTLM" /> <add value="Negotiate" /> <add value="Negotiate:Kerberos" /> </providers> </windowsAuthentication> <anonymousAuthentication enabled="false" /> </authentication> </security> <httpRedirect enabled="false" /> </system.webServer> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="TSPortalWebPart" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="6.0.0.0" newVersion="6.1.0.0" /> </dependentAssembly> </assemblyBinding> </runtime> <microsoft.identityModel> <service> <certificateValidation certificateValidationMode="None" /> <!-- Replace urn:okta:app:cccccccccccccccccccc with correct app urn from Okta --> <audienceUris> <add value="urn:microsoft:rdweb" /> <add value="urn:okta:app:cccccccccccccccccccc" /> </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> <!-- Replace thumbprint="..." with certificate thumbprint and urn:okta:app:... with correct app urn from Okta --> <add thumbprint="dddddddddddddddddddddddddddddddddddddddd" name="urn:okta:app:cccccccccccccccccccc" /> </trustedIssuers> </issuerNameRegistry> <federatedAuthentication> <!-- Replace issuer="https://..." with correct Okta URL thumbprint and urn:okta:app:... with correct app urn from Okta --> <wsFederation passiveRedirectEnabled="true" issuer="https://id.client.com/app/template_wsfed/sso/wsfed/passive" realm="urn:okta:app:cccccccccccccccccccc" requireHttps="true" /> <cookieHandler requireSsl="false" /> </federatedAuthentication> </service> </microsoft.identityModel> <location path="rdp"> <system.web> <authorization> <deny users="?" /> </authorization> </system.web> <system.webServer> <handlers> <add name="RDWAResourceFileHandler" path="rdp" verb="*" type="Microsoft.TerminalServices.Publishing.Portal.ResourceFileHandler" preCondition="integratedMode" allowPathInfo="true" /> </handlers> </system.webServer> </location></configuration>Les points d’attention#
- Authentification : le mode Windows remplace l’authentification par formulaire, et les utilisateurs anonymes sont refusés.
- Validation des requêtes : le mode de validation est assoupli pour accepter les réponses du fournisseur d’identité.
- machineKey : dans une ferme, remplacez les valeurs d’exemple par des clés générées et identiques sur tous les serveurs ; ne réutilisez jamais les valeurs du modèle.
- Passerelle : la passerelle Bureau à distance (RD Gateway) doit rester protégée ; le SSO du portail ne la remplace pas.
- Mises à jour : certaines mises à jour de Windows Server peuvent rétablir le fichier d’origine ; vérifiez la configuration après chaque maintenance.
Vérifier le fonctionnement#
- Ouvrez le portail RDWeb depuis un poste de test : vous devez être redirigé vers Okta.
- Authentifiez-vous, avec le facteur supplémentaire si votre politique l’exige.
- Vérifiez l’affichage des ressources publiées et le lancement d’une session.
- Testez avec un compte non autorisé : l’accès doit être refusé.
- Contrôlez les journaux IIS et Okta pour confirmer le parcours d’authentification.
Questions fréquentes#
Le SSO s’applique-t-il aussi à l’ouverture de la session distante ?
Le SSO porte sur l’accès au portail RDWeb. L’ouverture de la session sur l’hôte de session peut encore demander une authentification selon votre configuration de passerelle et de délégation.
Cette configuration fonctionne-t-elle avec un autre fournisseur d’identité ?
Le principe est similaire, mais les sections spécifiques au fournisseur doivent être adaptées à sa documentation.
Que faire si le portail ne s’affiche plus ?
Restaurez le web.config d’origine, puis réappliquez les modifications une à une en contrôlant les journaux IIS.