Convertir une connection WPA2-EDUROAM Enterprise dans NetworkManager en une connection système

Je suis étudiant dans une université qui possède eduroam, un réseau sans fil WPA2-Enterprise. Sur mon count, ceci est configuré à l'aide de NetworkManager. Voici l'aperçu de nm-connection-editor :

entrer la description de l'image ici entrer la description de l'image ici

J'ai marqué qu'il s'agit d'une connection système en disant «Tous les users peuvent se connecter à ce réseau». En pratique cela ne fonctionne pas:

Je pense donc qu'il y a deux problèmes potentiels ici:

  1. Le file de certificate se trouve dans mon directory personnel. Les autres counts d'users ne peuvent pas lire mon directory personnel. Si je transférais ce certificate à un endroit central (comme /usr/share/ je suppose?), D'autres counts pourraient l'utiliser car le certificate ne serait plus manquant.

  2. Le mot de passe est stocké dans mon trousseau de keys local dans mon directory personnel. Le mot de passe devrait être stocké dans tout le système.

Je ne vois pas de files de configuration de toute façon. D'après ce que je lis , NetworkManager stocke ses données dans un service avec lequel il communique via D-Bus. Par conséquent, datatables sont stockées quelque part .

Comment puis-je en faire une configuration à l'échelle du système qui fonctionne automatiquement pour chaque user du système?


Si cela vous préoccupe, la dissortingbution est Fedora 24.

Pour vous connecter à EDUROAM (une confédération académique mondiale de réseaux Wifi avec itinérance d'users entre institutions / fédérations) sous Linux, vous devrez configurer wpa_supplicant .

Les instructions et les files peuvent souvent être un peu spécifiques à la faculté et / ou au premier niveau du pays EDUROAM. Je vais donc faire un lien vers une page en allemand avec la configuration EDUROAM pour 802.1X dans la fédération DE.

Votre /etc/wpa_supplicant.conf devrait ressembler à ceci:

réseau = {
ssid = "eduroam"
key_mgmt = WPA-EAP
eap = TTLS
identity = "[email protected]" # votre identifiant
domain_suffix_match = "radius.lrz.de" # votre server RADIUS local
subject_match = "radius.lrz.de" # votre server RADIUS local
anonymous_identity = "[email protected]" # votre identifiant, ou un identifiant générique anonyme
password = "XXXX" # votre mot de passe ca_cert = "/ etc / ssl / certs / Deutsche_Telekom_Root_CA_2.pem"
phase2 = "auth = PAP"
}

domain_suffix_match et subject_match sont là pour des raisons de security – pour vous assurer de vous connecter au vrai server RADIUS, et non à un server spoofé. Si vous ne connaissez pas le nom de votre server RADIUS local, essayez de mettre wpa_supplicant au travail sans ces deux directives.

Vous pouvez également avoir un installateur automatisé dans la configuration de votre faculté, qui peut ou non vous être utile. (à condition que la faculté ait créé une page CAT)

Consultez votre expert local RADIUS / EDUROAM de votre faculté pour plus de détails.

Disclaimer: Je suis le mainteneur de RADIUS / EDUROAM d'une faculté, et le conseiller de FreeRadius pour la fédération de PT .

En ce qui concerne "tous les users peuvent se connecter à ce réseau"

Cela définit l'option "connection.permissions" dans les man nm-settings . Il contrôle que seul votre user du système peut modifier, voir et utiliser la connection. Cela signifie également que la connection ne se connecte automatiquement que si l'user est connecté. Sur un système mono-user habituel, le paramètre n'a pas beaucoup d'importance (sauf si vous souhaitez que la connection se connecte automatiquement avant de vous connecter).

Concernant les passwords

Pour chaque propriété de mot de passe (par exemple, WPA PSK, secrets VPN, etc.), NetworkManager supporte un atsortingbut "flags" qui permet de stocker le mot de passe du système (en clair, dans un file accessible uniquement par root) , ou pas nécessaire. Voir la section secrets dans man nm-setttings . Dans tous les cas, lorsque NM a besoin d'un mot de passe qu'il n'a pas, il doit requestr à un autre programme de l'get. Ce programme est un soi-disant "agent secret" qui peut soit requestr l'user pour le mot de passe ou le récupérer à partir du trousseau de keys, ou autre chose. Un tel programme est par exemple nm-applet , nmcli , gnome-shell , plama-nm . Donc, généralement lorsque vous exécutez une session graphique comme KDE ou Gnome, un tel agent est en cours d'exécution. Cela signifie également que si vous voulez vous connecter avant de vous connecter, vous devez soit stocker le mot de passe système (en clair), soit vous devez configurer un agent secret qui récupère le code secret pour pirater quelque chose vous-même, mais de toute façon, on ne sait pas où vous obtiendrez le mot de passe car personne n'est connecté).

En ce qui concerne la configuration des indicateurs de mot de passe, et donc l'location du mot de passe, vous pouvez le faire avec différents clients NM. Si vous utilisez nm-connection-editor comme dans la capture d'écran ci-dessus, vous verrez une petite icône dans le champ de saisie du mot de passe. Cliquez dessus et select ce que vous voulez.

Notez que par exemple sur Gnome3, si vous configurez votre trousseau avec le même mot de passe que votre mot de passe user, le trousseau de keys peut être automatiquement ignoré lorsque l'user se connecte. Une telle configuration vous permet de stocker le mot de passe dans le trousseau de keys et de se connecter automatiquement lors du démarrage de votre session gnome. Les détails peuvent varier et probablement quelque chose de similaire fonctionne aussi avec KDE.

Observe les files de certificate

Tous les certificates dans NetworkManager peuvent être stockés en ligne ou en tant que path d'access. Inline n'est pas génial, et en fait, nm-connection-editor vous permet uniquement de spécifier un path. L'utilisation de paths d'access est également problématique, car NetworkManager (et wpa-supplicant et les plugins VPN) s'exécutent en tant qu'user différent, vous devez donc vous assurer que les files sont accessibles à NetworkManager. En pratique, cela signifie par exemple que l'étiquetage SELinux est correct, ce qui signifie à son tour copyr les certificates dans ~/.cert . Cela sera un jour amélioré grâce à un gestionnaire de certificates (en dehors de NetworkManager) et au lieu de contourner le file (path), en utilisant les URL pkcs11 pour referencer les certificates dans le magasin.

Quant à l'endroit où vos connections sont stockées

Cela dépend de votre plugin de parameters configurés (voir plugins dans man NetworkManager.conf ). Sur fedora, cela signifie ifcfg-rh,keyfile par défaut. Donc, de preference, les connections sont au format ifcfg-rh (voir man nm-settings-ifcfg-rh , /etc/sysconfig/networking-scripts/ifcfg-rh* ) et deuxièmement au format de file key (voir man nm-settings-keyfile , /etc/NetworkManager/system-connections ).

Quant à savoir pourquoi KDE se comporterait différemment de Gnome n'est pas clair. Probablement quelque chose avec l'agent secret ( gnome-shell vs plasma-nm ) et la configuration du porte-keys.