Download - Windows Server 2008 VPN SSTP
Windows Server 2008
VPN SSTP Après les connexions d’accès distant par numérotation pour accéder au réseau interne de
l’entreprise depuis l’extérieur, le VPN ou RPV (pour Virtual Private Network ou Réseau Privé Virtuel)
s’est aujourd’hui imposé comme la solution de référence, que ce soit pour ce type d’accès comme
pour les liaisons site à site. Cette technologie permet de réduire les coûts liés à la mise en place des
équipements nécessaires, à la complexité de son installation, et accroît la sécurité par un chiffrage
des communications. En fait, une liaison VPN peut être représentée par un câble direct tiré entre
l’utilisateur et le serveur distant.
La mise en place d’un VPN d’entreprise peut prendre plusieurs formes : appliances dédiées, routeurs
comprenant la fonctionnalité VPN, ou encore serveur. Jusqu’alors, 2 protocoles étaient utilisés : PPTP
et L2TP/IPsec. PPTP est connu pour sa simplicité de mise en place et la garantie de la confidentialité
des communications, L2TP/IPSec pour sa sécurité optimale et sa complexité d’installation.
Depuis quelques années apparaît une autre sorte de VPN, le SSL VPN. Déjà disponible sur des
solutions tierces telles qu’OpenVPN ou des appliances CISCO, SonicWall…, le SSL VPN a été
implémenté par Microsoft également sous le nom de SSTP.
Quelles sont les différences majeures qui séparent ces protocoles ? Comment mettre en place cette
nouvelle solution sur un serveur Windows Server 2008 ? Deux questions auxquelles nous allons
essayer de répondre dans la suite cet article.
Généralités et rappels sur les protocoles
VPN
PPTP (Point to Point Tunneling Protocol)
PPTP est probablement le plus répandu en ce qui concerne l’accès distant des nomades. Facile
à mettre en place (quelques clics à peine pour une installation basique sur Windows Server), il
convient parfaitement aux infrastructures ne nécessitant pas de sécurité particulière et
nécessite peu de maintenance. Il comblera néanmoins les obligations de chiffrage du trafic
avec le protocole Microsoft Point-to-Point Encryption (MPPE). Sa simplicité de mise en place
se couple avec le très large support des systèmes d’exploitation clients et l’aisance de
configuration d’une connexion PPTP sur ceux-ci qui, pour la plupart, ne nécessiteront pas de
client logiciel tiers.
On notera néanmoins des désavantages. L’établissement et le maintien de la session se fait en
fait via 2 liens persistants : 1 session GRE (Generic Routing Encapsulation) encapsulant une
session PPP et 1 session TCP vers le port 1723 du serveur servant à gérer la session GRE.
Utilisant le protocole d’encapsulation GRE, il n’est pas évident qu’il puisse être mis en place
partout. En effet, nombre de matériels ne gère pas GRE ce qui rend impossible son
implémentation, et notamment les routeurs basiques et les fameuses Box des différents FAI.
Autre point faible, l’authentification de l’utilisateur avant l’établissement de la session. Bien
qu’utilisant couramment le protocole MS-CHAPv2, cela laisse une place aux mots de passe
faibles des utilisateurs, lacune qui peut être comblée par l’emploi de certificats avec EAP-
TLS.
L2TP (Layer 2 Tunneling Protocol)
On peut considérer L2TP comme une évolution de PPTP puisqu’il est issu de celui-ci et du
L2F de Cisco. Sa RFC ayant été publiée en 1999, c’est un protocole relativement récent. Il est
très peu utilisé seul du fait de son absence de sécurité, ce qui fait qu’il est presque toujours
utilisé avec IPSec ; il est alors nommé L2TP/IPSec. Celui-ci garantit l’établissement d’un
canal sécurisé entre le client et le serveur. Le protocole IKE (Internet Key Exchange) est
chargé de négocier l’association de sécurité qui emploie des certificats ou une clé pré-partagée
des 2 côtés du canal. Ceci a lieu vers le port UDP 500. Le protocole ESP (Encapsulation
Security Payload, protocole n°50) encapsule alors le tunnel L2TP et lui procure
confidentialité et authenticité des paquets.
Mais si L2TP/IPSec offre une sécurité accrue, il est difficile à mettre en place et peut
rencontrer des problèmes de compatibilité avec des pare-feux. C’est d’ailleurs pour ces
raisons qu’il est à l’origine prévu pour établir des liaisons site à site. En effet, il sera souvent
utilisé avec des certificats des 2 côtés du canal, ce qui nécessiterait une infrastructure à clés
publiques importantes pour des connexions nomades.
SSTP (Secure Socket Tunneling Protocol)
SSTP est aujourd’hui la solution en vogue pour les liaisons VPN. Les appliances dédiées et
solutions logicielles se multiplient avec plus ou moins de succès.
SSTP est basé sur le protocole SSL ou TLS et donc sur l’authentification du serveur par
certificat et établissement d’une liaison chiffrée entre les 2 hôtes. Cette base lui confère en
outre une très large compatibilité avec les équipements réseau, la connexion s’établissant via
le protocole TCP vers le port 443. Cette solution de SSL VPN est implémentée nativement sur
Windows Server 2008 depuis sa RC0 ce qui évite tout investissement dans une solution tierce.
Prévue pour une utilisation des clients nomades uniquement, son support est uniquement
fourni par Windows Vista SP1 ; on regrettera son absence dans le Service Pack 3 de Windows
XP.
A la fin de la négociation de la session, un paquet IPv4 transitant dans le tunnel SSTP est
encapsulé dans un en-tête PPP puis SSTP le tout chiffré avec la clé de session SSL. Sont
ajoutés ensuite un en-tête TCP puis IPv4.
Configuration du serveur
Configuration initiale
Configuration matérielle
La configuration matérielle nécessite un ordinateur supportant Windows Server 2008 et une
capacité de montée en charge si le nombre de clients nomades est élevé. On peut également
imaginer la virtualisation du système d’exploitation par le biais d’Hyper-V ou de Windows
Virtual Server 2005 R2.
Il devra être équipé d’au moins 2 cartes réseau, une orientée vers Internet, l’autre vers le
réseau local de l’entreprise.
Configuration logicielle
SSTP nécessite Windows Server 2008. Doivent y être installés les Active Directory Domain
Services (AD CS). Un utilisateur de test dont on aura autorisé l’accès distant dans ses
propriétés est également requis.
Mise en place d'AD CS
SSTP étant basé sur SSL et à fortiori sur l’authentification du serveur par certificat, nous
préférons, pour la suite, créer notre propre autorité de certification (CA) plutôt que d’engager
des frais dans l’obtention d’un certificat validé par une entité reconnue.
Dans le Server Manager, ajoutez un rôle. Après l’écran de bienvenue, choisissez Active
Directory Certificate Services. A l’écran suivant, sélectionnez le Web Enrollment. Ceci
nécessite IIS (Internet Information Service) sur le serveur hébergeant l’autorité de
certification, les composants requis vous sont donc proposés. Laissez les éléments par défaut.
Suivez l’assistant en choisissant une autorité Standalone racine et en validant les options par défaut.
L’autorité de certification est désormais en place. Néanmoins, le certificat associé est de la
forme « [nom de votre serveur]-DC-CA ». Pour l’établissement de la connexion SSTP, il est
nécessaire que le certificat ait été délivré au nom employé lors de la demande de connexion.
Nous devons donc en générer un qui correspondra au FQDN (Fully Qualified Domain Name)
utilisé lors de la configuration du client.
Ouvrez Internet Explorer 7 en tant qu’Administrateur. Allez dans les Options Internet et
abaissez au maximum le niveau de sécurité de la zone Intranet. En effet, lors de la procédure,
la page permettant de personnaliser le certificat contient des contrôles ActiveX qui ne
pourraient pas s’exécuter par défaut. Remplissez le formulaire en n’oubliant pas que le 1er
champ doit être le FQDN du serveur utilisé par les clients ! Choisissez « Server
Authentication Certificate » dans la liste qui suite. Marquez la clé comme exportable et
donnez un nom familier et explicite au certificat.
Dans la console de l’Autorité de certification, délivrez le certificat en attente. Retournez à l’accueil de
l’interface Web, allez pour regarder les certificats en attente et installez celui que vous avez
demandé. Ouvrez une MMC et ajoutez-y le composant logiciel enfichable « Certificats » pointant vers
l’ordinateur local, puis le même mais pointant vers l’utilisateur courant. Dans le magasin personnel
de l’utilisateur, exportez le certificat et sa clé privée. Allez dans le magasin personnel de l’ordinateur
local et importez le fichier PFX que vous avez sauvé juste avant. Exportez le certificat «
nomduserveur-DC-CA » et supprimez-le du magasin.
Mise en place du service VPN
Installez le rôle Network Policy and Access Services mais ne sélectionnez que les composants
de routage et d’accès distant ainsi que Network Policy Server.
Ouvrez la console associée, faites un clic droit sur le nom de votre serveur et choisissez de
configurer le service. Sélectionnez l’option « Remote access (dial-up or VPN) » puis VPN
uniquement. Choisissez l’interface qui connecte le serveur à Internet, puis, si ce serveur est
dédié à l’accès VPN uniquement, laissez la case cochée ; sinon décochez-la. Cette étape est
importante : en effet, si la sécurisation de l’interface est activée, tout le trafic étranger au trafic
VPN sera stoppé par les filtres d’entrée de la carte réseau. Choisissez ensuite la méthode
d’attribution des IP : soit par un serveur DHCP, soit par un pool d’adresses IP que vous
pouvez définir et qui sera géré directement par RRAS (Routing and Remote Access Services).
Cela fonctionnerait en l’état. Néanmoins pour des raisons de sécurité, il est recommandé de
fermer les ports PPTP et L2TP : cela se passe dans les propriétés du sous-nœud Ports.
Remarque : le nombre de ports PPTP ne peut pas être nul !
Contrôle de l'accès distant par NPS
Network Policy Server est le nouveau nom donné à « feu » IAS, présent sous Windows Server
2003.
Lorsqu’il est installé sur le même serveur que les services de routage et d’accès distant,
l’authentification des clients distants passe obligatoirement par lui. On note également que ces
services n’ont pas à être identifiés explicitement comme clients RADIUS puisqu’ils sont
hébergés sur la même machine.
Afin de sécuriser et restreindre l’accès VPN, on peut mettre en place une stratégie réseau,
anciennement appelée stratégie d’accès distant. Cela se fait dans la console Network Policy Server
sous le nœud Stratégies puis Stratégies réseau. Sont ici spécifiées des contraintes cumulables que la
tentative de connexion devra respecter comme les horaires de connexion, l’appartenance à un
groupe pour l’ordinateur et/ou l’utilisateur, l’exécution d’un système d’exploitation spécifique ou
encore le respect des exigences de sécurité avec la technologie NAP (Network Access Protection).
Suivant le souhait ou non de faire passer les propriétés d’accès distant du compte de l’utilisateur
avant ces restrictions, il faudra indiquer dans lesdites propriétés que son accès est soumis aux règles
définies dans NPS.
3. Configuration du client
Installation du certificat de l'autorité racine
Comme nous l’avons vu précédemment, SSL est basé sur l’authentification du serveur. Celui-
ci envoie donc son certificat lors de la négociation de la connexion ; dès lors, comment
garantir que ce certificat est valable ? En faisant rentrer en jeu l’autorité de certification racine
de confiance que l’on suppose intègre. L’ordinateur doit faire confiance à cette autorité et
pour cela posséder son certificat dans son magasin d’autorité racine de confiance. Nativement,
seules des autorités reconnues internationalement sont présentes. Il faut donc intégrer à ce
magasin le certificat de l’autorité racine que nous avons installée dans le point précédent. Pour
se faire, deux solutions s’offrent à nous : soit par téléchargement et installation du certificat
via l’interface Web, soit par déploiement via GPO.
Via l'interface Web CertEnroll
Accédez à l’interface web de l’autorité de certification depuis le client et choisissez de
télécharger un certificat d’autorité de certification.
Créez une MMC avec le composant Certificats pointant sur l’ordinateur local, choisissez le
magasin d’autorités racines de confiance et importez certificat suscité.
Via GPO
Dans la GPO souhaitée (du domaine par exemple), développez Configuration Ordinateur,
Stratégies, Paramètres Windows, Stratégies de sécurité, Stratégies de clés publiques et enfin
Autorités de confiance. Importez le certificat de l’autorité racine.
Attendez le cycle de réactualisation des stratégies de groupe ou forcez-la sur le client par «
gpupdate /target:computer /force ».
Configuration de la connexion VPN
Cliquez sur l’icône du Centre Réseau et Partage et Se connecter à. Créez une nouvelle
connexion vers votre lieu de travail, choisissez VPN, entrez le FQDN du serveur, un nom
pour la connexion, puis les identifiants de l’utilisateur. Editez maintenant les propriétés de la
connexion et dans l’onglet Réseau, choisissez SSTP à la place de « Automatique ».
3. Considérations notables et dépannage
Les enregistrements DNS
Il est recommandé d’employer une URL dédiée au service SSTP par soucis de lisibilité et de
compréhension. Aussi, une adresse de VPN « sstp.votredomaine.com » n’est pas du plus
mauvais genre. Attention néanmoins à indiquer à votre serveur DNS un alias vers votre
serveur VPN qui ne porte pas forcément ce FQDN.
La CRL, un élément à ne pas négliger
La CRL, ou Certificate Revocation List, est comme son nom l’indique un élément regroupant
les certificats ayant été révoqués, en d’autres mots qui ne sont plus valides.
Dès lors, pour vérifier que le certificat du serveur est toujours valable, l’ordinateur client doit
avoir accès à l’emplacement de stockage de la CRL. Pour les clients distants, c’est le plus
souvent une URL vers un serveur Web de l’entreprise. Par défaut, l’URL de la CRL est de la
forme http://nomdevotreserveur.votredomaine/... alors que ce nom n’est pas forcément
accessible depuis Internet. Il est alors intéressant de changer cette adresse et de la mettre sous
la forme http://sstp.votredomaine/... pour correspondre avec l’URL du VPN par exemple.
Cette modification doit être faite si possible avant l’émission du 1er certificat du serveur
directement dans les propriétés de l’autorité de certification. Après avoir indiqué que les
certificats doivent intégrés cette nouvelle donnée, puis après avoir forcé la publication de la
1ère CRL, les problèmes liés devraient disparaître.
Le changement de certificat du serveur
Il peut arriver d’avoir à changer de certificat au niveau serveur. On citera notamment la
corruption de l’autorité de certification, ou plus simplement le changement du FQDN d’accès
au serveur, ou encore la modification de l’URL de publication de la CRL. Si vous devez
procéder à son remplacement, faites comme suit :
Supprimez l’ancien certificat du magasin et importez le nouveau.
Ouvrez un invite de commande en tant qu’administrateur et entrez ces commandes :
Netsh http delete ssl 0.0.0.0:443 #ceci enlève le lien entre le certificat et le port 443
Netsh http delete ssl [::]:443 #idem pour IPv6
Reg delete HKLM\system\currentcontrolset\services\sstpsvc\parameters /v
SHA256CertificateHash /f
Si vous avez plusieurs certificats d’authentification de serveur dans le magasin, entrez ces
deux commandes :
Netsh http add sslcert ipport 0.0.0.0:443 certhash=[Thumbprint du certificate sans espaces]
appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY
Netsh http add sslcert ipport [::]:443 certhash=[Thumbprint du certificat] appid={ba195980-
cd49-458b-9e23-c84ee0adcd75} certstorename=MY
Net stop sstpsvc /y
Net start remoteaccess
3. Conclusion
Le SSL VPN de Microsoft, SSTP, est donc une solution fiable et sécurisée. Basé sur des
certificats et la technologie SSL, il améliorera la sécurité des données sans pour autant
introduire la complexité de mise en place d’une solution L2TP/IPSec. En outre, il permettra
de contourner la non-gestion des protocoles ESP ou GRE par certains équipements des autres
technologies VPN.
On regrettera néanmoins l’absence de compatibilité de ce protocole avec Windows XP SP3,
encore massivement utilisé en entreprise.
Bibliographie
Article relatif au SSTP
Blog TechNet de la team RRAS
Plus des Cours : Club Tutoriel Informatique