samedi 9 août 2014

WEBVpn, SSL/TLS et certificat tiers

Bonjour,

Dans l'article WEBVpn, SSL/TLS en action, nous avons traité de la configuration d'un tunnel VPN entre une station et un routeur grâce aux protocoles SSL/TLS. Le certificat servant à authentifier le routeur vis à vis du client était un self-signed stocké sur le routeur.

Cette fois-ci nous allons utiliser un serveur de PKI tiers qui va fournir les certificats au routeur.
L'utilisateur qui va se connecter via le portail VPN ne sera plus authentifié via la base de données internes au routeur mais via AD. Pas d'inquiétude, le principe est le même que quand on configure l'authentification au routeur via Radius.

Dans une deuxième partie, (et donc dans un article qui arrivera plus tard) nous pousserons le vis plus loin. Nous custumiserons l'interface web et nous utiliserons des attributs radius pour une page web différente par groupe de clients.

Haut les cœurs !!

Présentation de la plate forme.




Attention, elle ne me sert pas que pour ce lab est pas mal d'autres choses sont configurées qui n'ont aucun rapport ; Toutefois, si vous êtes intéressés pour un aperçu de BGP, elle peut être aussi un bon point de départ.

A tous ceux qui téléchargerons la topology, je vous invite à tout d'abord régler l'heure sur R1, R10 et R8. Les routeurs sont connectés via BGP, attention la redistribution au niveau du LAN se fait via R4, penser bien à l'allumer !

Nous avons un client Admin qui va se connecter via un tunnel SSL/TLS au routeur R10. A savoir que l'on pourrait utiliser les protocole HSRP sur R10 et R8 pour offrir un minimum de redondance au système. Le but étant de pouvoir surfer sur une page du serveur 2012_01 dans le domaine lanwan.com.
Le serveur SRV2-CA est notre serveur PKI dans le domaine xavon.com.


Configuration du serveur PKI.


Première chose à faire, installation du rôle Active Directory Domain Services (nouveau DC promo). Configuration, redémarrage et nous voilà prêt.
On peur maintenant créer un utilisateur et le mettre dans le groupe IIS_IUSRS et dans Domain Admins.
Vient ensuite l'installation du rôle Active Directory Certificate Services. En fait, même si ça paraît différent aux premiers abords, la configuration est quasi la même que Serveur 2008 (voir ici). Pour ceux qui auraient besoin de plus de détails, n'hésitez pas à demander.
Ici j'ai galérer, et je misère encore. Si l'on s'en tient là, on va pouvoir pousser un certificat à notre routeur. Le problème est que quand je vais vouloir me connecter avec mon client, je vais avoir une erreur du type CERTIFICATE MAL-FORMED. Ma solution (qui marche mais mal) et de créer un template de certificat à partir de l'IPSEC.

Mise à jour : ça fonctionne, le reste du blog a été mis à jour !

Pour cela, allez dans Action et Manage. Cliquez ensuite sur le certificat IPSEC et dupliquer le.
J'ai nommé mon certificat XavonSec, ceux qui me connaissent seront pas surpris …
Pour la configuration de celui-ci :

Onglet CRYPTOGRAPHY.


Onglet Security

Attention à bien ajouter votre utilisateur !!!


Onglet Subject Name



Alors j'imagine qu'il a des tas d'autres possibilités pour rendre la chose plus sécurisée, En attendant de m'acheter un bouquin sur les certificats sous Windows 2012, faites preuve d'un peu de patience !!!

Le certificat est terminé, ne pas oublier de l'ajouter aux templates actifs.


On passe au registre.

En effet, si l'on veut utiliser notre template nous devons modifier quelques clefs.


Attention à bien donner les droits à votre utilisateur sur le dossier MSCEP.

Et voilà pour le serveur !

Quand est-il du routeur ?

Petit rappel sur le trustpoint à configurer :

crypto pki trustpoint SRV2-CA
enrollment mode ra
enrollment url http://80.12.10.2:80/certsrv/mscep/mscep.dll
fqdn none
subject-name CN=r10.lanwan.com, OU=lanwan, C=FR
revocation-check none
source interface Loopback2
rsakeypair VPN

L'option  none du fqdn permet de ne pas générer d'erreur au niveau du certificat.
Attention au subject-name, c'est sensible à la casse !

Au niveau de passerelle VPN, rien de neuf sous le soleil mais on utilise le trustpoint SRV2-CA :

webvpn gateway Wg
hostname Wg
ip address 2.2.2.2 port 443
ssl encryption rc4-md5
ssl trustpoint SRV2-CA
logging enable
inservice


Passons maintenant à l'authentification du client via AD.

On commence par créer une méthode d'accès AAA :

aaa authentication login ACCdistant group radius

On pourrait spécifier local après radius, en cas de pépins du serveur par exemple mais je trouve pas ça glop.

On configure la partie radius de l'affaire :

radius server AccDistant
address ipv4 219.42.36.1 auth-port 1645 acct-port 1646
key radius

Rien de bien complexe ici, attention à la clef qui devra être identique dans le serveur.

La source :

ip radius source-interface Loopback2

Pourquoi cette commande ?

Elle me simplifie grandement la vie !! En effet, entre les tunnels configurés, les interfaces sources BGP, … je trouve beaucoup plus facile d'utiliser une même et seule adresse pour toutes les tâches administratives du routeur.

On est pas mal au niveau du routeur, terminons la configuration de notre serveur 2012_01.

Idem que pour le serveur de certificats, on commence par promulguer notre serveur en tant que domaine contrôleur.

On installe ensuite le rôle Network Policy and Access Services



On configure ensuite notre client radius, qui sera le routeur :



Petit rappel pour les mous du bulbe : la clef est la même que celle configurée sur le routeur !

Vient ensuite une network policy :

J'utilise ici un groupe de sécurité configuré précédemment.



Attention à bien spécifier la méthode Unencrypted pour l'authentification.

Au niveau de la station, on installe le certificat de SRV2-CA dans les trusted machin choses. (via http://80.12.10.2/certsrv/ pour notre exemple)


Il ne reste plus qu'à tester à partir de notre station cliente !!


Liens externes :

Horizon du Web



Bon clic à tous,
















Aucun commentaire:

Enregistrer un commentaire