Convert a WPA2-Enterprise EDUROAM connection in NetworkManager to a system connection

Question

I am a student at an university which has eduroam, a WPA2-Enterprise wireless network. On my account this is configured using NetworkManager. This is the overview of nm-connection-editor:

I have marked that this is a system connection by saying “All users may connect to this network”. In practice this does not work:

• When I get logged into my Awesome WM session automatically, my (GNOME?) keyring is not unlocked. It asks for my password before it attempts to connect. This is annoying, my disk is encrypted anyway. So I would like to store the password as root, so to speak.

• When I log into another account with KDE, the connection does not work there.

So I think there are two potential problems here:

1. The certificate file is in my home directory. Other user accounts cannot read my home directory. If I would move that certificate to a central place (like /usr/share/ I guess?), other accounts could use this since the certificate would no longer be missing.

2. The password is stored in my local keyring in my home directory. The password would have to be stored system wide.

I don't see any configuration files anyway. From what I read, NetworkManager stores its data in some service it communicates with via D-Bus. Therefore the data is stored somewhere.

How can I make this a system wide configuration that just works automatically for every user of the system?

---

If it is of concern, the distribution is Fedora 24.

Answer 1

For connecting to EDUROAM, (a worldwide academic confederation of Wifi networks with roaming of users between institutions/federations) in Linux, you will need to setup wpa_supplicant.

The instructions and files often can be a little specific to the faculty and/or the top EDUROAM country level. So I will link to a page in german with the EDUROAM setup for 802.1X in the DE federation.

Your /etc/wpa_supplicant.conf should be something similar to this:

network={
ssid="eduroam"
key_mgmt=WPA-EAP
eap=TTLS
identity="[email protected]" # your login
domain_suffix_match="radius.lrz.de" # your local RADIUS server
subject_match="radius.lrz.de" # your local RADIUS server
anonymous_identity="[email protected]" # your login, or an anonymous generic login
password="XXXX" # your password ca_cert="/etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem"
phase2="auth=PAP"
}

domain_suffix_match and subject_match are there for security reasons -e.g. to ensure you connect to the real RADIUS server, and not to a spoofed one. If you do not know the name of your local RADIUS server, try to put wpa_supplicant to work without those two directives.

You may also have an automated installer in the CAT (eduroam Configuration Assistant Tool) setup of your faculty, that may or not be of help to you. (provided the faculty has created a CAT page)

Do consult your local RADIUS/EDUROAM resident expert of your faculty for more details.

Disclaimer: I am the RADIUS/EDUROAM maintainer of a faculty, and the FreeRadius advisor for the PT federation.

Answer 2

Regarding "all users may connect to this Network"

This sets the "connection.permissions" option in man nm-settings. It controls that only your system user can modify, see and use the connection. It also means, that the connection only auto-connects if the user is logged in. On a usual one-user system, the setting doesn't matter much (unless you want the connection to auto-connect before logging in).

Regarding passwords

For each password property (say WPA PSK, VPN secrets, etc), NetworkManager supports a “flags” attribute which allows to store the password systemwide (in plain text, in a file only accessible by root), retrieve from user session, always ask, or not needed. See secrets section in man nm-setttings. In any case, whenever NM needs a password that it doesn't have, it needs to ask another program to obtain it. That program is a so called "secret agent" which is able to either prompt the user for the password or retrieve it from keyring, or whatever. Such a program is for example nm-applet, nmcli, gnome-shell, plama-nm. So, usually when you run a graphical session like KDE or Gnome, such an agent is in fact running. It also means, if you want to autoconnect before logging in, you either have to store the password systemwide (in plain text), or you'd have to somehow setup a secret agent that retrieves the secret from somewhere (the latter would require you to hack something yourself, but anyway, it's unclear where you'd get the password from as nobody is logged in).

As for how to configure the password flags, and thus the password location, you can do that with various NM clients. If you use nm-connection-editor as in the screen shot above, you see a small icon in the password input field. Click on it and select whatever you want.

Note that for example on Gnome3, if you configure your keyring with the same password as your user-password, the keyring can be automatically unlooked when the user logs in. Such a setup allows you to store the password in the keyring and to automatically connect when starting your gnome session. The details may vary and probably something similar works with KDE too.

Regards certificate files

All certificates in NetworkManager can be either stored in-line or as a path. Inline isn't great, and in fact nm-connection-editor only allows you to specify a path. Using paths is problematic too, because NetworkManager (and wpa-supplicant and the VPN plugins) run as a different user, so you yourself must make sure that the files are accessible to NetworkManager. In practice that means for example to ensure that they have the right SELinux labeling, which in turn means, copy the certificates to ~/.cert. This will one day be improved by having a certificate manager (outside of NetworkManager) and instead of passing around file (path), using pkcs11 URLs to reference certificates in the store.

As to where your connections are stored

That depends on your configured settings plugin (see plugins in man NetworkManager.conf). On fedora that means ifcfg-rh,keyfile by default. So preferably the connections are in ifcfg-rh format (see man nm-settings-ifcfg-rh, /etc/sysconfig/networking-scripts/ifcfg-rh*) and secondly in key file format (see man nm-settings-keyfile, /etc/NetworkManager/system-connections).

As to why KDE would behave differently from Gnome is not clear. Probably something with the secret agent (gnome-shell vs. plasma-nm) and the keyring setup.