OpenVPN et Active Directory (Kerberos sans certificats utilisateur)

De nombreux guides ont été écrits sur OpenVPN, y compris l'autorisation via Active Directory. La plupart d'entre eux se résument à l'utilisation de LDAP; je n'ai trouvé aucune approche utilisant Kerberos, qui est écrite dans un article à part entière. Cependant, quelque chose de nouveau ne sera pas inventé ici, je viens de compiler ce qui a déjà été fait avant moi, PAM fonctionne bien avec Kerberos et OpenVPN a un plugin PAM natif. J'ai également décidé d'abandonner les certificats et les conseils des utilisateurs, où ils recommandent simplement que tous les utilisateurs émettent un certificat, ils ne me convenaient pas, alors une autre solution a été trouvée qui fonctionnait sur tous les clients.

Un peu sur NSS

Dans mon cas, j'ai utilisé Centos 7 en conjonction avec sssd. Cependant, rien n'empêche d'utiliser winbind. L'essentiel est d'avoir une voiture dans le domaine et un ticket Kerberos. Je n'écrirai pas comment cela se fait, car Je ne dirai rien de nouveau, il y a beaucoup de bons manuels sur le réseau.

Il sera nécessaire de modifier les paramètres de /etc/nsswitch.conf si cela n'a pas été fait auparavant. Selon le module utilisé, vous devez saisir respectivement sss ou winbind au lieu de module_name. Les descriptions des paramètres peuvent être lues à l'aide de man nsswitch.conf .

Les paramètres suivants devraient être suffisants:

 passwd: files module_name shadow: files module_name group: files module_name 

Dans le cas de sssd, nous n'oublions pas, entre autres, que dans /etc/sssd/sssd.conf dans le bloc [sssd], nss doit être mentionné:

 services = nss, pam 

Quant à winbind, j'ai du mal à dire quelque chose, je ne l'ai pas utilisé.

Le but ultime est d'obtenir le bon résultat de getent. Vérifiez que la machine peut recevoir des informations sur les utilisateurs et les groupes du domaine:

 > getent passwd kanlas kanlas:*:14123583:1257570:Kanlas Kanlasovich:/home/kanlas@example.com:/bin/bash > getent group VPN vpn:*:13821391:kanlas,igor,marina 

Configurer PAM

Vous devez maintenant créer votre propre module PAM. Afin de ne pas utiliser le système access.conf, nous allons créer un fichier séparé d'où le groupe d'accès sera lu. Je ne suis pas si bon en modules PAM, donc je ne peux pas dire si toutes les lignes sont nécessaires dans l'exemple ci-dessous. En général, nous ne sommes intéressés que par le account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/openvpn/auth/access-groups ligne account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/openvpn/auth/access-groups .

L'option la plus simple consiste à prendre, par exemple, le module de connexion et à y ajouter la ligne souhaitée. Ce qui a été fait.

Nous obtenons:

 #%PAM-1.0 auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so auth substack system-auth auth include postlogin account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/openvpn/auth/access-groups account include system-auth password include system-auth session required pam_selinux.so close session required pam_loginuid.so session optional pam_console.so session required pam_selinux.so open session required pam_namespace.so session optional pam_keyinit.so force revoke session include system-auth session include postlogin -session optional pam_ck_connector.so 

Nous l'avons mis dans /etc/pam.d , en le nommant à notre discrétion.

Dans /etc/openvpn/auth/access-groups , spécifié dans le module, le groupe d'accès sera écrit ici, vous pouvez spécifier votre chemin si vous le souhaitez. Vous devrez spécifier le nom du groupe (Common Name) avec le domaine. Dans mon cas, j'ai écrit VPN@example.com là-bas.

Il reste à expliquer à OpenVPN qu'il doit utiliser PAM. Nous mettons les lignes suivantes dans la configuration du serveur:

 plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so __pam username-as-common-name 

Différentes distributions peuvent avoir des chemins différents! Recherchez un fichier par chemin ou utilisez find.

L'utilisation du paramètre username-as-common-name est due au fait qu'autrement, après que le client a authentifié l'utilisateur-pass, le nom spécifié dans le certificat sera envoyé au serveur.

Dans la configuration client, ajoutez la ligne

 auth-user-pass 

Une fois cette configuration terminée, vous pouvez tester.

Nous supprimons le certificat utilisateur

Nous avons maintenant une autorisation via le domaine et le certificat utilisateur est inutile, l'abandonner semble être une décision logique. Mais les clients mobiles ont des problèmes avec cela, n'acceptant tout simplement pas une telle configuration, et les ordinateurs de bureau, bien qu'ils fonctionnent, maudissent malicieusement. Tout d'abord, nous allons reconfigurer le serveur afin qu'il ne nécessite plus de certificat.

 verify-client-cert none 

Ensuite, nous ajoutons à la configuration du client

 setenv CLIENT_CERT 0 

Voilà, maintenant les clients ne jureront pas sur un certificat. C'est drôle que cette option soit cachée dans la section des questions et réponses pour iOS . Je n'ai pas testé sur iOS, mais Android, ainsi que MacOS ( client bêta ) et Windows acceptent ces paramètres en un clin d'œil. Seul un client OpenVPN tiers sur Android ne peut pas encore le faire (au moment de la rédaction de cet article, il pouvait déjà le corriger).