Lorsqu’on utilise un Cisco ASA comme concentrateur VPN, une problématique se pose : la gestion des utilisateurs autorisés.
Soit vous créez vos utilisateurs sur le Cisco, ce qui mène à une gestion bancale de vos utilisateurs, soit vous utilisez votre service d’annuaire comme source de données. C’est bien évidemment la seconde solution qui a ma préférence. Ainsi la gestion des utilisateurs et de leurs droits est consolidée, tout s’administre d’un seul et même endroit. Lorsque vous désactivez un utilisateur, il est désactivé de partout.
Pour utiliser cet annuaire centralisé depuis le Cisco ASA, nous avons deux options :
- une connexion LDAP ;
- une connexion Radius.
Si votre annuaire est hébergé par un serveur Microsoft, autant dire que les choses sont simples. Vous pouvez utiliser le très puissant serveur Radius de Microsoft pour faire à peu près tout ce que vous souhaitez (autorisation, assignation à des groupes d’accès spécifique, plage horaire, etc.).
Si vous utilisez autre chose, vous allez généralement finir sur du FreeRadius, qui n’est pas forcément des plus simple à utiliser. Et si vous êtes sur un OS X Server, vous aurez un problème : le FreeRadius d’Apple est extrêmement pauvre et ne vous permettra de faire que du oui / non sur les demandes d’authentification. Vous ne pourrez même pas gérer des listes d’accès différentes en fonction de la source. Une honte…
Il vous reste donc l’option du serveur LDAP. Encore une fois, si vous avez un serveur Microsoft, c’est parfait, Cisco a fait le travail d’intégration correctement et les groupes AD sont gérés. Par contre, si vous avez autre chose (OpenLDAP, Novell, OpenDirectory…), Cisco ne propose aucun outil évident de configuration.
Pour autant, et en y regardant bien, il est tout à fait possible de se servir d’une source LDAP standard comme source d’autorisation en plus des sources d’authentification.
La première chose à faire est de définir une source pour l’authentification et de l’appliquer au profil de configuration VPN souhaité.
Configuration d’une source d’authentification LDAP pour le VPN
Commençons par nous rendre dans la partie Configuration > AAA/Local Users > AAA Server Groups de l’outil ASDM puis ajoutons un serveur de type LDAP qui permettra l’authentification de tous les utilisateurs de l’annuaire.
Puis, il est nécessaire d’ajouter au moins un serveur dans ce groupe. Si vous disposez de réplique de votre serveur Open Directory, ajoutez une entrée par serveur.
Comme vous pouvez le remarquer, à partir du moment où vous sélectionnez une source de serveur autre qu’un serveur Microsoft, le champ de configuration des groupes devient inutilisable.
Le groupe AAA ainsi configuré va permettre d’autoriser et d’authentifier l’ensemble des utilisateurs présent dans le conteneur « users » de l’Open Directory, en recherchant les entrées ayant pour uid le nom de l’utilisateur testé.
N’oubliez pas d’appliquer vos changements.
Vous pouvez, depuis ASDM, utiliser la fonction de test sur vos serveurs pour vérifier que l’autorisation ainsi que l’authentification fonctionnent correctement avec vos utilisateurs.
La source étant fonctionnelle, rendez-vous dans Configuration > Network (Client) Access > AnyConnect Connection Profiles. Si vous n’utilisez pas le service de VPN SSL AnyConnect mais le système basé sur IPSec, la procédure est la même en vous rendant dans al section IPSec(IKEv1) Connection Profiles.
De là, éditez le profil souhaité, celui par défaut étant le DefaultWEBVPNGroup. Pour configurer la source d’authentification pour ce profil, il vous suffit de vous rendre dans les options de base puis de changer la source « AAA Server Group » pour celle nouvellement ajoutée.
Si ce n’est pas déjà fait, profiter d’être ici pour configurer vos informations DNS. Si vous éditez pour la première fois le groupe par défaut, assurez-vous également que les services VPN souhaités (SSL / IPSec) sont actifs et qu’une plage d’adresse IP est configurée pour vos clients.
Votre service est maintenant configuré. Si vous tentez une connexion depuis un client, elle réussira.
Ajout d’une source s’autorisation LDAP pour le VPN
Vient maintenant la partie la plus intéressante. Comment faire en sorte de filtrer les utilisateurs ayant accès à ce service ?
Cela se passe par l’ajout d’un nouveau groupe AAA, toujours de type LDAP. Là où le groupe d’authentification cherchait dans l’arbre des utilisateurs, celui-ci cherchera dans un groupe spécifique.
Lorsque l’on configure un serveur LDAP, la base de recherche indiquée est le point d’entrée pour la recherche exécuté. Cette recherche sera envoyée avec comme filtre, l’attribut de nom spécifié ainsi que le nom de l’utilisateur.
Si l’on active le journal des requêtes LDAP sur le ASA on pourrait voir passer ceci :
[35] LDAP Search:
Base DN = [cn=users,dc=office,dc=inig-services,dc=com]
Filter = [uid=yoanngini]
Scope = [SUBTREE]
Qui demande au serveur de renvoyer toutes les entrées contenues sous le nœud cn=users,dc=office,dc=inig-services,dc=com et ayant l’attribut uid égal à yoanngini.
Lors d’une requête d’authentification, un seul item doit être retourné et il sera utilisé pour tester le mot de passe de l’utilisateur. Lors d’une requête d’autorisation, il faut qu’il y ait au moins un résultat de retourné par la requête pour que celle-ci soit valide.
De fait, il est possible de détourner le fonctionnement de la recherche LDAP en ajoutant un nouveau groupe AAA de type LDAP (nommé ici OD_autho_network) et utilisant comme base de recherche le groupe cible.
Ce réglage va déclencher une recherche retournant un résultat uniquement si le groupe vpnnetwork dispose d’un attribut memberUid égal à yoanngini. Si le groupe ciblé ne dispose pas de cette valeur, aucun résultat ne sera renvoyé et l’autorisation sera refusée.
La source d’autorisation étant ajoutée, il reste à la configurer du côté de notre service VPN. Au même endroit que précédemment (Configuration > Network (Client) Access > AnyConnect Connection Profiles), nous allons modifier les réglages avancés d’autorisation pour aller sélectionner notre nouvelle source.
Attention à une chose, lors de la configuration, il est impératif de cocher la case « user must exist in the authorization database to connect ». Sans quoi l’astuce présentée ici ne fonctionnera pas.
N’oubliez pas d’appliquer vos changements et de sauvegarder votre configuration.
Faites vos essais, votre accès au service VPN est maintenant filtré.