This is how most users are expecting to use it, with (sadly) windoze
being the golden example for "seamless" integration. Every wireless
vendor just expects there to be integration on the backend with
AD/LDAP or some upstream directory provider if you're doing
user/pass-based auth of some form and not certs. With wired ports
in an enterprise dot1x deployment, almost assuredly there will be a
directory provider and/or kerberos. With nm *not* doing this, it used to lead to account lockouts with kerberized installs after a password change, and was a royal pain having to get in and change each time. Or simply annoying users making them have to manage that as well. Maybe something like pam automount when kerberized, doing the same for nm using pam instead of keyring? Most times when using this sort of behavior, likewise/kerberos is involved anyways. This ties back to some of my prior commentary of mine on the list needing better system integration for dot1x, and doing things like machine authentication (switching between local credentials, machine credentials [gotten from likewise] then user). -mb On 09/22/2014 09:54 AM, Thomas Haller
wrote:
On Sun, 2014-08-31 at 16:20 +0200, Jérémie Vandeville wrote:I'm currently testing 802.1x with freeradius and networkmanager. It's working very well but I've a question : Is it possible to use gnome credentials (login/password) with eap-ttls or peap (or even with md5) ? For the moment, it seems necessary to manually configure the credentials in networkmanager and it's problematic when you have multiple users on the same system. The purpose of the operation is to push different restrictions according to the user currently loggedNetworkManager supports that secrets are provided by a "secret-agent". Such a secret agent is a program that communicates with NM via DBUS. NM will ask all running secret agents for the passwords it needs. Such secret agents are for example nm-applet, plasma-nm and gnome3 control center. They all store and retrieve the password from the user keyring/kwallet. What you ask for currently does not exist (to my knowledge). I guess, it would be possible to implement such a password provider. But anyway, isn't it a security issue to use the login credentials to authenticate to a network? That doesn't sound like a good idea to me. Thomas. |