Inscrire un utilisateur VPN : trouvez d’abord le propriétaire de l’identité

Quelqu’un demande un accès VPN, et le premier réflexe est d’exécuter adduser sur le serveur. Ce réflexe n’est correct que dans un ensemble étroit de déploiements. Avant de créer quoi que ce soit, ouvrez la configuration du serveur et déterminez quel produit y tourne et où il valide les identifiants, car le compte peut vivre dans une base de données du produit, chez un fournisseur d’identité ou dans la pile d’authentification de l’hôte. Créer le mauvais type de compte laisse la personne avec une connexion qui fonctionne et sans tunnel.

Un profil client qui indique OpenVPN décrit le protocole, pas le système d’identité derrière lui.

Partez du serveur, pas d’adduser

Identifiez d’abord le produit. Community OpenVPN est le démon plus toute authentification que vous y avez branchée, tandis qu’Access Server est un produit avec sa propre couche utilisateurs. Demandez la configuration, le nom de l’unité et la liste des paquets, et vérifiez s’il existe une interface web de gestion des utilisateurs. Regardez ensuite comment le profil déployé attend que les clients prouvent qui ils sont : un certificat, un nom d’utilisateur et un mot de passe, ou les deux. Cette réponse nomme le système qui possède le compte.

Ce n’est qu’après que l’expression créer l’utilisateur veut dire quelque chose. Dans un déploiement par certificats uniquement, cela signifie émettre une identité d’appareil via le processus approuvé, et une connexion Unix ne change rien. Dans un déploiement par mot de passe, cela signifie le backend qui valide réellement le mot de passe.

Quatre backends, quatre endroits où créer le compte

L’authentification locale d’Access Server conserve les comptes dans sa propre base de données, donc l’interface pour les créer appartient au produit et non à l’hôte. PAM délègue la validation à la pile du système d’exploitation, et c’est pourquoi un compte Unix local peut faire partie de l’inscription lorsque cette pile est celle que le service a choisie. LDAP, RADIUS et SAML déplacent la validation vers un service externe, où vivent le provisionnement, la politique de mots de passe et le MFA. Access Server peut encore conserver des certificats et des permissions par utilisateur dans les quatre cas, et c’est ce qui rend la séparation déroutante.

Vérifiez la méthode effective pour cet utilisateur précis plutôt que la valeur par défaut globale. Access Server 2.10 et versions ultérieures peuvent appliquer des méthodes d’authentification différentes par groupe ou par utilisateur, donc une valeur par défaut locale ne prouve pas que le compte devant vous est validé localement.

Le droit est une décision distincte

L’authentification répond qui est la personne ; le droit répond à quoi elle peut accéder. Gardez-les comme deux étapes, car une connexion réussie n’est pas une autorisation. Attribuez délibérément les routes prévues, les permissions de ressources et les droits administratifs, et confirmez que l’accès non lié reste refusé. Là où le déploiement prend en charge des identités individuelles, émettez-en une par personne au lieu de transmettre le profil de quelqu’un d’autre, car un profil partagé ne peut pas être retiré pour une seule personne.

Le matériel client compte aussi. Un profil à connexion automatique et une connexion utilisateur interactive représentent des relations d’authentification différentes, et échanger l’un contre l’autre change ce que le serveur vérifie réellement.

Retirer l’accès fait partie de l’inscription

Notez trois propriétaires pendant que l’utilisateur est créé : qui valide le compte, qui autorise l’accès VPN et quel appareil ou profil représente la connexion. Il peut s’agir de trois systèmes différents, et un plan de révocation qui n’en nomme qu’un seul laisse un chemin ouvert. Quand la personne part, retirez le droit de son propriétaire et révoquez chaque identifiant émis auprès de son propriétaire. Supprimer un fichier téléchargé n’est pas une révocation, et supprimer une entrée locale non plus si une identité externe s’authentifie encore.

Testez ensuite l’inscription comme le ferait un attaquant : connectez-vous une fois avec la nouvelle identité, confirmez l’accès à la ressource prévue et confirmez qu’une ressource non liée refuse encore. Une première connexion qui fonctionne plus un test négatif, c’est une inscription terminée.

Conservez l’enregistrement avec le profil auquel il appartient. Le prochain auditeur demandera qui pouvait se connecter pendant un mois donné, et la réponse vit dans ces trois propriétaires.