Archives de catégorie : Terminal Server Gateway

Prise de tête avec la Terminal Server Gateway (re-publication)

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2008. Lors de la migration du blog vers la nouvelle plateforme, il y a eu du déchet que je corrige peu à peu. Selon l’importance des corrections, ça peut aller jusqu’à la republication du billet. A l’époque, il y avait encore de l’ISA/TMG au programme Clignement d'œil.

Voilà une fonctionnalité de Windows Server 2008 qui mérite qu’on creuse un peu plus le sujet. Avec Windows Server 2003, on pouvait déjà encapsuler le protocole RPC de Microsoft Outlook dans un flux HTTP. Avec Windows Server 2008, Microsoft a étendu l’utilisation de l’encapsulation au protocole RDP.

Cette approche permet de sécuriser l’utilisation du protocole RDP sur un réseau LAN ou depuis le réseau extérieur. Tous les flux HTTPS arrivent sur un serveur dit « passerelle » qui se charge de de décapsuler le flux HTTPS pour ressortir sous la forme du protocole RDP. Le principal avantage de cette approche est de pouvoir faire passer tous les flux RDP sous un même port (443) pour de multiples destinations. On évite donc les multiples ouvertures de port sur le pare-feu extérieur.

De l’extérieur, l’accès à la Terminal Server Gateway est contrôlé par les « Connection Authorization Polices (CAP) ». Après, l’accès aux serveurs Terminal Serveurs ou aux clients Remote Desktop s’effectue selon les conditions dictées par les « Ressource Authorization Policies (RAP) ».

En terme d’implémentation, on distingue trois scénarios :

  • Le Terminal Server Gateway sur le réseau interne
  • Le Terminal Server Gateway sur le réseau périmétrique
  • Le Terminal Server Gateway publié par un ISA Server

 

Le Terminal Server Gateway sur le réseau interne

clip_image001

Ce scénario peut être difficile à implémenter dans la mesure où cela nécessitera de mettre en œuvre un pare-feu sur le réseau interne qui non seulement laisse passer le flux 3389 sur le port TCP (tout à fait normal )mais aussi les flux liés à l’ annuaire Active Directory car la CAP impose de sélectionner au minimum un groupe d’ utilisateurs, idéalement, un groupe de domaine si on ne veut pas fournir deux authentifications distinctes (Compte local sur la TS Gateway puis compte Active Directory). Techniquement, c’est possible à condition d’utiliser ISA Server 2006 avec le filtrage de protocole RCP sur les UUID. C’est un peu long à mettre en œuvre mais c’est réalisable. Il est possible d’envisager une version allégée de ce scénario en supprimant le pare-feu sur le réseau interne même si ce n’est pas le meilleur choix.

Le Terminal Server Gateway sur le réseau périmétrique

clip_image002

 

Le second scénario pose le même problème. Là il est obligatoire d’utiliser ISA Server 2006 pour le mettre en œuvre. Reste tout de même à convaincre le client d’accepter ISA Server comme pare-feu même de bas niveau (au plus proche du LAN). Bon nombre de personnes y sont encore réticentes pour des raisons historiques qui n’ont plus vraiment lieu d’être aujourd’***…

Le Terminal Server Gateway publié par un ISA Server / TMG

clip_image003

 

Pour le troisième, c’est un scénario « full ISA Server/TMG », ce qui en matière de sécurité n’est pas une bonne pratique (ISA en DMZ et ISA comme pare-feu de bas niveau). On préfèrera différencier les fournisseurs à ce niveau.

Globalement, c’est le premier scénario qui sera le plus utilisé.

 

Le Nœud du problème

Maintenant rentrons dans le nœud du problème : les certificats. Ayant eu la chance de participer au Tech-Ed 2008 à Barcelone (Merci patron !). J’ai assisté à la conférence « Windows Server 2008 Terminal Services Deep Dive – Gateway Security and certificates » d’Alex Balcanquall, Senior Product Manager chez Microsoft de son état. Au terme de sa présentation, j’ai posé une question toute simple : La TS Gateway n’accepte qu’un seul certificat, donc qu’un seul nom (selon l’interface). Comment peut-on faire pour utiliser un nom pour la TS Gateway interne qui est différent de celui utilisé en externe ? D’un point de vue purement « paranoïaque » de la sécurité, cela se tiens. Techniquement, le plus simple consiste à utiliser ISA Server pour publier sous un autre nom. Mais c’est contourner le problème.

A cette question, il m’a été répondu que c’était une très bonne question mais sans avoir pour autant de réponse (ni le sac à dos promis pour les meilleures questions posées, …).

La réponse

La réponse, elle est normande, cela dépend. Selon les informations de Microsoft sur les caractéristiques du certificat à utiliser (http://technet.microsoft.com/en-us/library/cc731264.aspx) le certificat doit présenter les caractéristiques suivantes :

  • The name in the Subject line of the server certificate (certificate name, or CN) must match the DNS name that the client uses to connect to the TS Gateway server, unless you are using wildcard certificates or the SAN attributes of certificates. If your organization issues certificates from an enterprise CA, a certificate template must be configured so that the appropriate name is supplied in the certificate request. If your organization issues certificates from a stand-alone CA, you do not need to do this.
  • The certificate is a computer certificate.
  • The intended purpose of the certificate is server authentication. The Extended Key Usage (EKU) is Server Authentication (1.3.6.1.5.5.7.3.1).
  • The certificate has a corresponding private key.
  • The certificate has not expired. We recommend that the certificate be valid one year from the date of installation.
  • A certificate object identifier (also known as OID) of 2.5.29.15 is not required. However, if the certificate that you plan to use contains an object identifier of 2.5.29.15, you can only use the certificate if at least one of the following key usage values is also set: CERT_KEY_ENCIPHERMENT_KEY_USAGE, CERT_KEY_AGREEMENT_KEY_USAGE, and CERT_DATA_ENCIPHERMENT_KEY_USAGE.
  • The certificate must be trusted on clients. That is, the public certificate of the CA that signed the TS Gateway server certificate must be located in the Trusted Root Certification Authorities store on the client computer.
L’attribut SAN

C’est le premier point le plus important. Techniquement oui c’est possible, tout dépend de l’autorité de certification. Dès lors qu’on utilise une autorité de certification « Entreprise de Microsoft », c’est là que cela devient compliqué :

  • Le certificat doit être généré à l’aide du template « Computer », sinon la TS Gateway refusera le certificat
  • Les modèles de certificats de l’autorité de certification de Microsoft ne sont personnalisables que sur une autorité de certification de type « Entreprise »
  • Le modèle de certificat « Computer » utilise le FQDN de l’ordinateur pour renseigner le champ « Subject » du certificat. Cela signifie que si on désire utiliser un autre noms, l’autorité de certification ignorera le paramètre dans la demande.

 

Par défaut, l’ extension SAN, n’ est pas activée, qu’ à cela ne tienne on va l’ activer (http://support.microsoft.com/kb/931351/en-us):

clip_image004

 

Après un redémarrage, notre autorité de certification va accepter de traiter l’attribut Subject Alternative Name. Ou presque, …

 

Le modèle de certificat « Computers »

C’est la seconde étape. Oui l’autorité de certification accepte de traiter les demandes de certificats pour l’attribut Subject Alternative Name » mais elle continue obstinément à les refuser dès lors qu’on lui demande un certificat pour un ordinateur. La raison est toute simple, elle tient dans l’illustration ci-dessous :

clip_image005

 

Le modèle de certificat « Computer » prévoit de récupérer le « Subject Name » directement dans l’annuaire Active Directory, ignorant donc l’attribut SAN. La seule solution, c’est de dupliquer ce modèle de certificat. Le nouveau modèle de certificat « TS Gateway Certificate » integer:

  • La reconfiguration de l’attribut « Subject Name »

clip_image006

  • Le modèle soit « Superseeded » le modèle de certificat « Computers »

clip_image007

 

C’est très important, car la TS Gateway vérifie que le certificat qu’on lui soumet a été généré selon le modèle « Computers » ou dérivé de celui-ci.  Le modèle de certificat est alors prêt à être publié pour être utilisable immédiatement.

 

La demande de certificat en ligne (Cas Autorité de certification intégré à l’ AD)

Commençons par le cas le plus simple, une demande de certificat en ligne pour notre futur TS Gateway :

clip_image008

 

Jusque-là, je n’ai perdu personne.

clip_image009

 

Le modèle de certificat « TS Gateway certificate » est bien proposé mais pour être utilisable il est nécessaire de compléter un certain nombre d’informations en cliquant sur « More information is required to enroll for this Certificates ».

clip_image010

 

C’est là que se situe la subtilité. Il faut dans un premier temps spécifier un Subjet Name pour le compte ordinateur de notre TS Gateway mais aussi le ou les Subject Alternatives Names à utiliser. On remarquera que j’ai référencé un nom extérieur, un nom DMZ et un troisième correspondant au nom DNS sous lequel la TS Gateway sera accessible depuis le réseau LAN de l’entreprise.

Note : le dernier n’est utile que si l’on désire rendre accessible sa TS Gateway sur le réseau interne.

clip_image011

 

Pour finir, il est vivement conseillé d’utiliser l’attribut « Friendly Name » pour faciliter la suite de la demande de certificat.

clip_image012

 

La demande de certificat est maintenant complète, elle peut être soumise à l’autorité de certification intégrée à l’annuaire Active Directory et être approuvée

clip_image013

 

La demande de certificat offline (Cas autorité de certification tierce ou autonome)

C’est le même principe. Windows Server 2008 nous aide à formater la requête pour pouvoir la soumettre à une autorité de certification tierce

clip_image014

 

Je n’ai toujours jamais perdu quelqu’un à l’écran d’accueil !

clip_image015

 

On sélectionne note modèle de certificat « TS Gateway Certificate »

clip_image016

 

L’interface est quelque peu différente d’une demande en ligne mais le principe reste identique, à savoir qu’il faut compléter la demande avant de pouvoir la soumettre.

clip_image017

 

Toujours les mêmes informations, à savoir un Subject Nme représenté par le « Full DN » du compte ordinateur puis les « Subject Alternatives names » ajoutés sous formes de noms DNS.

clip_image018

 

La demande ainsi préparée peut-être soumise à une autorité de certification.

 

Le certificat dans la console « Terminal Server Gateway

Dès lors que le certificat a été installé sur le serveur de la TS Gateway et associé à celle-ci, l’interface d’administration indique uniquement le « Subject name » dans le champ « Issued To ».

clip_image019

 

Si on vérifie avec des clients, on peut valider que la TS Gateway répond bien à tous les noms positionnés SAN positionnés dans la demande de certificat.

Conclusion

En conclusion, oui, c’est possible, sauf que ce n’est pas le scénario le mieux documenté. L’interface d’administration n’a pas été prévu pour afficher l’éventuel attribut SAN. Une TS Gateway peut donc répondre à plusieurs noms (interne, externe, nom pour chaque partenaire, …). C’est juste un petit peu plus complexe à mettre en œuvre. Le premier avantage de ce scénario est de pouvoir utiliser la même TS Gateway pour plusieurs usages et non en dédier une par usage. Le second avantage et non des moindre est de pouvoir affiner les stratégies de filtrage CAP par défaut pour différencier les accès internes des accès Externes (aller faire un tour dans la console du NPS installé sur la TS Gateway dans le noeud « Network Policies »).

Note à certains lecteurs : Je mérite encore plus mon sac à dos pour avoir trouvé moi-même la solution au problème posé!

Prise de tête avec la Terminal Server Gateway Suite

Après avoir publié mon précédent billet, l’ équipe en charge du développement de Terminal Server a posté un billet "Introduction to TS Gateway Certificates". Quelle ne fut pas ma surprise de découvrir une section dédiée à la question des certificats Wildcard et SAN Certificates.

 

La bonne nouvelle, c’ est que les certificats SAN et Wildcard sont supportés à condition de disposer du bon client et de la bonne version de ISA Server (si on publie notre TS Gateway avec). Le tableau suivant indique comment sont supportés les différents types de certificats selon les types de clients :

 

Type de certificat Client RDC 6.0

Client RDC 6.1

Publication via ISA Server
Auto-généré Oui Oui Oui
CA publique Oui Oui Oui
CA privée Oui Oui Oui
Certificat Wildcard Non Oui Oui à partir de ISA Server 2006
Certificat SAN Non Oui Oui avec ISA 2006Server SP1

 

Globalement, la mise à jour du client RDC vers la version 6.1 est plus que recommandée. Donc Windows XP SP3, Windows VISTA SP1. Ceci complète mon précédent post.

Note : Sauf erreur de ma part, il n’ y a pas encore de client RDC 6.1 pour Windows Server 2003.

 

Benoît – Simple and Secure bu Design (J’insiste sur le Secure)