Ted Hyde (RSI)
2018-11-24 14:59:46 UTC
I am migrating from older FR2 instances up to FR3 (finally, yes, I know) and am hoping that some could assist with some details on multiple EAP instances (base system is Debian with multiple revs of FR2, migrating to FR3 current).
Currently I have a number of Cisco AP's in autonomous mode with mixed authentication - some local to the AP, but one SSID that is EAP-TLS. Other SSIDs are on other VLANs, but only the one VLAN/SSID has .1X involved. The clients have the certificate installed, and the system works. Of course that cert is not unique to any device, thus any device that has that cert can authenticate against that SSID. That is by design for this SSID and is intended to remain as such.
I want to turn a separate "House" SSID that *was* strictly WPA2-PSK into one that is MAC auth based, so I don't have to worry about changing and re-issuing WPA passwords when one user has to be de-auth'd. However there are limitations on mixed config on the Cisco APs where PSK + MAC just doesn't work. (It makes sense that encryption + no encryption isn't a viable transaction concept, so I'm not too sad about it.) I have been able to get MAC + EAP-TLS to work really well, so my concession is to use a cert in EAP-TLS along with the MAC restriction. I am fine with distributing a cert to the "house" users; in this instance, the cert provides the framework for encryption, the MAC list provides the authorization. This whole exercise isn't about making it easier to turn a specific user on or off, it's about how the other users are handled when that event occurs. In test right now, I can distribute the same certificate to any client, and tell them to associate against the house ssid (the non-restricted SSID is for a special purpose, not roaming users) and it works, because eap just runs regardless.
This sounds amazing at first go, however I need to retain that one SSID that has NO MAC restrictions alongside an SSID (same AP group of course) that DOES have MAC restrictions. With the ordering of auth's, if a client had the one certificate, but was de-auth'd from the house SSID, all they would have to figure out is to try and associate with the non-restricted SSID and they're back in (albeit on a different VLAN). This I know from testing. It is not the situation I am looking for.
So my next trick would be to try and set up multiple EAP instances, with separate certificates and FR listening for some discerning data during the EAP request packet to limit which SSID can authenticate with which certificate. Then it wouldn't matter if a deauth'd house client had the house-only certificate; it would/must fail if they try to associate with the non-restricted SSID. This is where I am lost. I followed a couple google'd options, and they all came down to the CSID containing the SSID or Vlan tag; that only happens if you are using a WLC apparently, where I am using autonomous APs. However, with an extra vsa option in my Cisco configs, I can get an AV-pair in the request such as from a "freeradius -X" debug output:
Called-Station-Id = "0021.d849.a671"
Calling-Station-Id = "e458.b8d0.6455" <----- note there is no suffixed SSID here (sad)
Cisco-AVPair = "ssid=MIWIFI-HSE" <----- a source of potential magic!
Service-Type = Login-User
Cisco-AVPair = "service-type=Login" <----- but caution, an additional AV-pair tag here, so how to handle?
I have [hackingly] messed around with replicating eap instances inside mods-enabled/eap, as well as including the statements for Auth-Types in the default virtual server, but I then get lost on how to use the ssid=xxxx to make decisions for which module to use.
I am testing on baseline debian stretch with FR3 (3.0.12+dfsg-5+deb9u1) and text files (clients.conf and users) as data sources. Aside from mods-enabled/eap being modified to have multiple instances and sites-enabled/default to include multiple Auth-Types, all files are default.
List info/subscribe/unsubscribe? See http://www.freeradius.org/l