allow WLAN-access in certain offices only
radius.pkoch at dfgh.net
radius.pkoch at dfgh.net
Wed Apr 21 13:38:44 CEST 2021
Dear Alan DeKok,
Thanks for the quick reply
Am 20.04.2021 um 21:46 schrieb Alan DeKok - aland at deployingradius.com:
> On Apr 20, 2021, at 1:04 PM, radius.pkoch at dfgh.net wrote:
>> I have just compiled Freeradius from source and red some of the
>> WPA2-EAP works with username bob and password hello.
>> radiusd -X shows no errors.
> That's good.
>> Now here's what I would like to achive and maybe some of you can point me
>> into the right direction:
>> We have equipped all of our offices (approx 100) with seperate WLAN
>> access points.
>> Every employee should be able to access the access point in its own
>> office and
>> in some of our conference rooms. Every employee owns an OAuth token that
>> generates a 6digit one time password.
> That's nice, but you really don't want to use OAuth with Wifi. I
> don't even know how that would work.
> i.e. WiFi is bad enough that devices end up re-authenticating
> multiple times a day. And you definitely don't want users to be asked
> 5-10 times a day for a new one-time password.
> Just use a password. Or, use EAP-TLS and client certificates.
We are planning to use our time-based one time password OATH tokens just
in the same way we are already doing this for IMAP authentication. When
a user authenticates for the first time, he must generate a 6digit value
with his token, append his own password to that value and use that
combination. The IMAP server (and I was hoping the radius server could
do as well) will send the password to our authentication server for
We do not use OAuth.
Once a password was used successfully, the same value can be used again
for a certain period of time that depends on the username. With our
IMAP-server this period is 30 days, for a WiFi-guest account this would
be 12 hours.
The passwords we generate with our OATH-token are not used as ONE time
passwords. Hence they must be kept secret and must not be sent over the
network in clear.
>> Whenever a user tries to access a WLAN access point with his username
>> and his one time password the following should happen:
> Scratch all that.
> First, you should figure out how WiFi works. Then, figure out if
> your suggested process fits into that.
> If it doesn't, throw away your requirements about what "should
> happen", and go with something which is realistic.
So here's what I figured out so far about how WiFi works:
- accesspoint is configured for WPA-Enterprise
- hence the supplicant is asked for a user / password combination or has
to provide a client certificate
- the accesspoint receives additional informations from the supplicant
(i.e. its mac-address)
- the accesspoint sends all the information it has received from the
supplicant together with informations about itself to the radius server
- the radius server decides wether to allow or deny access and answers
In our case the radius server will get - among other informations - the
username and password of the supplicant plus the IP-address of the
accesspoint. This is all that is needed to decide wether the password is
correct and wether the accesspoint is located within the office of the
person with the given username.
But the radius server cannot do this decision on its own. It cannot
verify the password but has to delegate that decision. And it cannot
query our central oracle database on its own about what accesspoint has
the given IP-address and wether this accesspoint is physically located
in the office of the person with the given username.
I was hoping that the radius server could delegate this decisions to a
script. And it seems to me, that there are (at least) the following two
- use a php-script via rlm_exec
- use a perl-script via rlm_perl
I don't like the rlm_exec option since it seems to have security issues
(password is visible within the environment of the process) and might be
slow since for every authentication the php-interpreter has to be
started and a new oracle-database connection has to be created. But this
is the easiest way to go.
I don't like the rlm_perl option as well. I have never written a perl
script, nor have I connected an oracle database from within a perl
script. Performace would be a lot better since the perl-interpreter must
not be started on every authentication. But it seems to me that maybe a
database connection must be created on every authentication request.
With oracle databases that is a lengthy process and takes more time than
starting an interpreter.
>> 1) if the password is wrong access should be denied
> So... password checking like normal. But if this is for passwords
> which change multiple times a day, then it just won't work.
see above - password is token generated but will not change until it expires
>> 2) if the access point is not located in the office of the employee
>> or in one
>> of the conference rooms of the employees department access should be
>> So... check the source AP to see if it's allowed. How do you
>> check that? Read the debug output to see what each AP sends, and
>> then write rules to match those.
wether an accesspoint is allowed or not depends on the data within our
central oracle database. If an employee moves to a new office (which
happens a lot lately due to corona) our hotline changes the information
within the oracle database. This should give the employee immediate
access to the accesspoint in his new office without changing
configuration data at additional places (neither manually nor
>> Our central oracle database has information about the ip-address and
>> of every access point and the office rooms of every employee.
> Location is irrelevant. The only thing that matters is what's in
> the RADIUS packets, and what's shown in the debug logs.
> Does the term "Conference room 5" appear in the RADIUS packet?
> No? Then you'll have to figure out some other way which access point
> is which. Maybe by looking at host names (if they show up in the
> RADIUS packet), or IP addresses (if they should up in the RADIUS
> packet), or by MAC (well, you get the idea by now).
"Conference room 5" does not appear in the RADIUS packet but so does the
IP-Adress of the accesspoint. And our central database has all the
information that is needed to deduce the room number from that
ip-address and wether the conference room belongs to the same department
as the user.
>> My first idea was to write a php-script (because that's the scripting
>> I'm familiar with) and use that via rlm_exec. I will do this as a
>> proof of concept.
> To do... what? You haven't said.
see above. The idea was to let the script verify the password and
compare the physical location of the accesspoint with the office of the
user, based on the information that the script got from the radius
packet (username, password, ip-address).
>> Since neither I nor any of my colleagues have perl-experience I'd
>> rather write
>> a new module in C than use perl.
>> Is there a module that will send all parameters to a unix or inet
>> socket and
>> receives the results from that socket? How abount rlm_socket?
> To do... what?
> How is any token going to be checked? REST API? What?
> Your last comments here are really "how do I write a script to do
> stuff". The only answer is "I dunno, it depends on what stuff you
> want to do".
I'm not asking how a script should be written. This is our business and
from Freeradiuses point of view it should make no difference wether the
script uses a REST API to talk with our authentication server or connect
an oracle database or do whatever is needed to allow or reject a request.
My current understanding is that freeradius will feed a list of
key-value pairs into such a script and will receive at least a status
and maybe additional key-value pairs.
Right now my plans are:
1: Create a php-script that will receive key-value data from Freeradius
via evironment-variables and will return data via exit-code. This script
has to create a database connection for every authentication request.
This will be slow (approx 2 seconds) but my hope is, that Freeradius
will start processes in parallel.
2: Create a perl-script with identical functionality. Maybe the first
invocation of such a perl script can create a database connection that
can be reused by future requests. That would improve performance. I have
no idea wether Freeradiuses builtin perl-interpreter allows to store a
database connection in a global variable and what happens if multiple
invocations of such a perl sript are running in parallel.
Any feedback on these ideas is welcome.
More information about the Freeradius-Users