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-possible-tp4492840p4492840.html
Sent from the FreeRadius - User mailing list archive at Nabble.com.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
