Re: 802.1x wired authentication

[Michael Butash <michael butash net>]

This sounds pretty consistent with my question about machine auth 
inclusion, as this works almost exactly like what you're trying to 
accomplish.

We do the same on the windoze side, where if there isn't a user 
authenticated, it should fall back to machine auth vlan, where your user 
is essentially quarantined, but for windows and mac allow AD for 
GPO/AV/other or JAMF access to sterilize the system.

There would be two keyfiles for dot1x auth, one for the machine, or one 
for the user, with nm managing the transition back and forth.  We also 
do Radius COA (change of authorization) on the controllers, that if 
posture changes, it'll flip them to a quarantine/machine auth vlan again 
to be mitigated, but needs to be made aware of the transition to re-dhcp 
(windoze has issues with this too, macs we gave up on machine auth 
working properly entirely to accomplish this).  Linux/NM still requires 
some fallback/fallforward behavior to accomplish this.

We're looking at actually using wlan controller features to transition 
them to a guest network should they fail auth entirely, still letting 
them on without a hard disconnect as you're seeing and having to rely on 
(absent) client features.  Wired won't leave this option so much I 
think, but possibly depending on your policy engine upstream (aruba 
clearpass or cisco ise *can* in theory [or any rfc3576 server], just 
feeding a role/vlan response).

Windows has been doing and evolving dot1x behavior since xp, and mac has 
gotten with it since mid 10.7, it would be nice to see the dot1x 
behavior in nm catch up.

-mb


On 08/30/2013 09:43 AM, Alec Warner wrote:
> Hello,
>
> I am currently considering deploying NetworkManager on my 802.1x
> authenticated wired network. I seem to be hitting a few roadblocks, and
> I'd prefer some feedback.
>
> My network is configured to place the client on a different VLAN
> depending on authentication. So if authentication succeeds, you end up
> on the auth VLAN, it fails, you end up on the un-auth VLAN. This works
> great if I use two separate Connections in NetworkManager, however I
> want to avoid this and just use 1 Connection.
>
> When I attempt to use 1 connection, NM detects that wpa_supplicant
> failed to authorize the interface, and instead of running DHCP client
> anyway (which would get it an IP on the un-auth'd VLAN) NM just decides
> to disable the interface.
>
> I've attached a log of this. Note that in this instance I've broken the
> authentication on purpose to see what would happen. So instead of
> disabling the interface, I want NM to try to DHCP anyway. The evening
> spent looking at the code seems to imply this is not possible (I am on
> Networkmanager on Ubuntu Precise network-manager-0.9.4.0-0ubuntu4.2.)
>
> I'm curious if you would take a patch for this behavior?
>
> If not, I could use the 2 different connections (which work fairly well
> for the majority of my use cases.) However there are some minor issues
> with that set up that I need to address. One is how to switch between
> the connections. If I presume I have 2 connections (A for Auth and U for
> UnAuth) how do I get NM to always try A first? My understanding is that
> NM will try the 'last successful' connection first. Is there any sort of
> API to specify priorities, such that when the interface is toggled, A
> will always be tried before U?
>
> Another problem is lets presume that authentication failed and my host
> utilizing the U connection. Will NM ever retry using the A connection
> (since again, it is 'preferred'?)
>
>
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list