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 !
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 !
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 !!
Bon clic à tous,
Aucun commentaire:
Enregistrer un commentaire