On 06/15/2011 11:15 PM, cwfnetman wrote:
mac address filtering isn't my idea, so please refrain from questioning why.
It's not totally useless. We do it. MAC address is a quick, reasonable proxy for "the hardware" and since it's the hardware/OS combo that gets infected with malware etc. it's a reasonable thing to key on.
simple whitelist (several hundred mac addresses) to validate against. If the incoming mac address on the authentication request is simply somewhere on the whitelist (anywhere within those hundreds of addresses), then I next need to authenticate the Windows AD credentials, and if they're good, and in a certain AD group, and their domain member workstation PC is in a certain machine account group, etc, etc, according to the set of remote access policies in the IAS server, then go ahead and "let 'em in".
This is where I get confused; how do you expect to have both the user and workstation credentials? AFAIK there is no EAP method that provides both. You can *either* have workstation *or* user auth.
So, can FreeRadius be set up to perform a sort of two-phase, cascaded authentication such that the Cisco WiFi controller first sends the incoming authentication access-request to FreeRadius, which checks a big whitelist of pre-approved mac addresses, and if that tests good, then FreeRadius acts as a relay/proxy/radius client to pass the next ActiveDirectory authentication portion of the request off to my Windows IAS server, then if that part comes back good, to reassemble all the pieces-parts back together as a completed access-accept message and hand it back to the Cisco wireless system to let the wireless user in, and basically fool the Cisco WiFi system into thinking that one Radius server handled it all?
Sort of, but not in the way you're describing. The EAP requests contain the MAC address, so basically you just want to: 1. Receive the EAP request 2. Check against whitelist 3. if match - unconditionally proxy to IAS 4. else reject See the 1st example here: http://wiki.freeradius.org/Mac%20Auth ... except instead of doing "accept" you should forward/proxy, like so: authorize { preprocess # if cleaning up the Calling-Station-Id... rewrite_calling_station_id # now check against the authorized_macs file authorized_macs if (!ok) { reject } else { # forward to IAS update control { Proxy-To-Realm := IAS } } } You can extend the whitelist to live in SQL, a passwd-style file or whatever. You'll need to create appropriate realm & home server definitions in proxy.conf - see the examples there, but something like: home_server IAS { type = auth+acct ipaddr = x.x.x.x port = 1812 secret = XXXX } home_server_pool IAS { type = client-port-balance home_server = IAS } realm IAS { auth_pool = IAS }
-- View this message in context: http://freeradius.1045715.n5.nabble.com/Two-phase-pass-thru-authentication-p... Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html