NEW Package: freeRADIUS 2.x
-
(warning ahead I'm not used to configuring FreeRADIUS on pfSense/GUI but rather in plain configs)
Anyway: It means that your FreeRADIUS server is trying to connect to a (likely to be) remote MySQL server (172.16.10.19) which it can't connect to.
Since you must have configured it for SQL user authentication, it can't start correctly as it can't read a valid list of users from your MySQL server.Try to fix the connection to the MySQL server or disable MySQL authentication/authorization (for test) and try to use local authentication.
Are you positive about using SQL for authentication? I only use it for RADIUS accounting and thereafter limiting concurrent access - so
that's my real-world use with (Postgre)SQL. -
Hi ,
i tried the package with otp and it work's but if client is behind server time (my mobile provider is 30 sec in the past !) i am not able to login (tested with radtest) .
worked like a charme with online mtop calculator but never with DroidOTP and "TIME OFFSET 30 or -30 "
Maybe i am doing something wrong but i do not know what.
The OTP Passcode from the mobile phone is 30 sec. later the same as the online calc did.Maybe someone can give a hint or maybe minus offset is not possible ….
regards
max
-
Hi ,
i tried the package with otp and it work's but if client is behind server time (my mobile provider is 30 sec in the past !) i am not able to login (tested with radtest) .
worked like a charme with online mtop calculator but never with DroidOTP and "TIME OFFSET 30 or -30 "
Maybe i am doing something wrong but i do not know what.
The OTP Passcode from the mobile phone is 30 sec. later the same as the online calc did.Maybe someone can give a hint or maybe minus offset is not possible ….
regards
max
Hi,
Did you calculate the Epoch-Time?
1. Write down the first 9 digits of the Epoch-Time on the client.
2. Check with date +%s the Epoch-Time on your FreeRADIUS server and write down the first 9 digits.
3. Subtract both values, multiply the result with 10 and enter the value in this field. (Default: 0)But in general it should not neccessary to change this if your mobile device changes its timezone automatically.
Further you can try increasing the "OTP Lifetime" in freeradius –> settings.
You can set it to 6 which means 60s. Even if the mobile clients always generate new keys every 30s it should be possible to use a generated key 60s instead of just 30s.The more you increase this time the more "insecure" OTP will become. Probably noone will get access with a key (without PIN) which has a lifetime of a few minutes.
---- edit ----
You are right. The script does not accept negative values. You could modify the script here:
freeradius.inc
line 4027
replace:EPOCHTIME=`expr \$EPOCHTIME + \$OFFSET`with
EPOCHTIME=`expr \$EPOCHTIME - \$OFFSET`Could be something what should be added to the GUI.
-
Hi,
yes i calc the epoch time like descript on the web interface:
(9digits (from left client time) - 9digit (from left server time)) *10 = -30date +%s = 10digits, so why the hell not taking (10digits (from left client time) - 10digits (from left server time)) = 30 ?? (or if 39 nearer 40 than 30 !!)
It's not a problem of the timezone it's a mobile provider problem; the android is 30 sec in the past.
(Is the offset 1 equal 1 hour, i hope not.)If i set the lifetime on server side higher than on the client (DroidOTP is fixed to 10 sec lifetime) than i had guess/try 6 keys maybe on is working not a good idea.
I know to solve the problem with manual set the client time but i want to find out how it work with time offset and maybe there is a bug or a wrong hint on the webinterface
regards max
–----edit----
The Gui save the Offset in the right way:/usr/pbi/freeradius-i386/etc/users
"otpuser" Auth-Type = motp
MOTP-Init-Secret = 912ae1361854139e,
MOTP-PIN = 1234,
MOTP-Offset = -30Use Freeradius teh otpverify.sh script ? If yes then there is the faulty part
OFFSET=
echo -n "$5" | sed 's/[^0-9]/0/g'
[[/sub]
-10 is then 010….
should beOFFSET=
echo -n "$5" | sed 's/[^0-9-]/0/g'but is a little be dirty could also be 1-0 …..
-
Hi,
yes i calc the epoch time like descript on the web interface:
(9digits (from left client time) - 9digit (from left server time)) *10 = -30date +%s = 10digits, so why the hell not taking (10digits (from left client time) - 10digits (from left server time)) = 30 ?? (or if 39 nearer 40 than 30 !!)
It's not a problem of the timezone it's a mobile provider problem; the android is 30 sec in the past.
(Is the offset 1 equal 1 hour, i hope not.)If i set the lifetime on server side higher than on the client (DroidOTP is fixed to 10 sec lifetime) than i had guess/try 6 keys maybe on is working not a good idea.
I know to solve the problem with manual set the client time but i want to find out how it work with time offset and maybe there is a bug or a wrong hint on the webinterface
regards max
–----edit----
The Gui save the Offset in the right way:/usr/pbi/freeradius-i386/etc/users
"otpuser" Auth-Type = motp
MOTP-Init-Secret = 912ae1361854139e,
MOTP-PIN = 1234,
MOTP-Offset = -30Use Freeradius teh otpverify.sh script ? If yes then there is the faulty part
OFFSET=
echo -n "$5" | sed 's/[^0-9]/0/g'
[[/sub]
-10 is then 010….
should beOFFSET=
echo -n "$5" | sed 's/[^0-9-]/0/g'but is a little be dirty could also be 1-0 …..
Did you read what I wrote about the part on the freeradius.inc ?
-
Yes i did.
But if i do it like you said then the offset is always minus.
In freeradius.inc
there is the same 'sed' in line 4006:OFFSET=
echo -n "\$5" | sed 's/[^0-9]/0/g'regards max
-
Yes i did.
But if i do it like you said then the offset is always minus.
In freeradius.inc
there is the same 'sed' in line 4006:OFFSET=
echo -n "\$5" | sed 's/[^0-9]/0/g'regards max
Hi max,
can you please replace the following two files and try again if it works now?
You now have to enter + 30 oder - 30
It is described on the GUI. -
Hi,
sorry for the long delay. Your scripts are not working. I did some investigation on EPOCHTIME and extend the freeradius.inc with some logs.
I found out that the Offset 1 is equal to 10 sec (not like descripted on the webif) because the use of 9 digit and not 10.
I changed only
OFFSET=echo -n "\$5" | sed 's/[^0-9-]/0/g'and add 2 logging lines
Jun 14 16:11:10 root: FreeRADIUS:Server - Client EPOCHTIME: 137121900
Jun 14 16:11:10 root: FreeRADIUS:Server EPOCHTIME: 137121905 ClientOffSet:-5 oder -5regards Max
-
Hi,
(…)
I found out that the Offset 1 is equal to 10 sec (not like descripted on the webif) because the use of 9 digit and not 10.
(...)I think you are wrong:
3. Subtract both values, multiply the result with 10 and enter the value in this field.
If your result is 2 then you need to multiply with 10 (2*10=20) and then you get the seconds.
But you are right, the script is not working. adding "+" or "-" in the freeradius users file causes problems.
At the moment I do not have an idea how to solve the problem with negatgive offset.
Perhaps starting with a negative offset of -11h as default value so that the user needs to add +11h to get the actual default offset of 0.The script is based on this:
http://motp.sourceforge.net/–-- edit ----
Ok, I changed the script to start per default with an offset of -12h. If someone is in a timezone which is -12h then the GUI value will be 0.
If someone is on timezone 0h then the GUI value must be 720.You can try with the two config files.
PS: You need to re-enable m-OTP on settings first after adding the new files so that otpverify.sh will be rubuild.
-
Hmpf - again new files. Please try these ;-)
-
Hi Nachtfalke,
i think you misunderstood me; it works with my 'patch'
i have to set offset to -5 because of 50 sec time diff (not -50 like suggest in on the webIF)see motp.sourceforge.net
Enter "date +%s" on the server to display the current time in epoch notation. Write down the first 9 digits of the output.
Subtract both values. The result is the offset in 10s of seconds, i.e. an hour would be 360, two hours 720, etc.
The offset has to be configured in the "users" file of the RADIUS server for the specific user (Offset-Attribute).sorry for my english, my german is better….
I have some idea to add more security to the radius otp: motp+yourpassword (without plus-:) would be great to have (like professional token have).
regards max
-
Hi max,
I talked to the developer of the motp script. He told me that almost nobody uses offset because most devices change their timezone automatically. Further he agreed with me that the script wasn't tested with negative offset values.
Like you told me in some older posts it looks like it is enough to change the "sed" command. I did this in this comment and it should now be available for everyone:
https://github.com/pfsense/pfsense-packages/commit/355ebce27aeb941f949f26f9c70d08150f37a7dbYour suggestion about "more" security:
The "youpassword" part is the PIN. A different PIN on the mobile device will generate a different OTP. So there is no difference between professional tokes and this. The only difference is that freeradius server does not offer a possibility for the user to change its PIN on his own.If you are using a mysql database as user store - instead of the users file - then you can code a php or HTML page which allows a user to change its PIN or his own.
But of course - if you have any suggestions and patches - please commit them. Every improvement is appreciated :)
-
Hi Nachtfalke,
thank you very much for add this in the package.
My suggestion was to extend the 'password' so it is not possible to know how long it is. I idea was to use the password field and if there is a password and otp configured use both.
If it is not possible don't worry
regards max
-
I know what you mean. I thought about that in the past but I didn't found a way to do so. The problem for me was that the variables/passwords are passing so many scripts and files and I didn't know how to realize that. This is probably more a problem of my poor coding skills than something else ;-)
Another "limitation" is that most mobile OTP generators just use the first 6 characters as password. FreeRADIUS allows to select you a higher range of used characters but then you must have a possibility on the client OTP generator to change this.
freeradius –> settings --> Token Password length
-
Hi nachtfalke,
i made some extension so i am able to handle the combination of mOtp+Userpassword. (without + :-)
It works with a cleartext + md5 password.If you want to give it a try…
Be careful you have to set the OTP length from 1-6 to only 6!!(Descript in Webif, Maybe the default setting have to adapt to 6 only)regards
-
file seems to be corrupted. 43kb is to small when including the complete freeradius.inc.
Please pay attention:
the "OTP length from 1-6" does not mean you can use 1 or 2 or 6 characters it means it uses the first until the 6th character.
if you type 10-12 it uses the 10th till 12th character of the hash which was build. -
Hi Nachtfalke,
there are 3 files in a zip container!Oh i see the zip is corrupt, sorry
I know that 1-6 means from 1 digit to 6 digits.
It make no sense that you can choose the start point, all mobile otp solution i know start with the first digit, only the lenght of the OTP password is changeable. It could be dangerious if you set the start point higher than the lenght of your hash.
But if it is a no go i change this behavor back.regards
max
freeradius.inc.txt
freeradius.xml.txt
freeradiussettings.xml.txt -
Hi Nachtfalke,
there are 3 files in a zip container!Oh i see the zip is corrupt, sorry
I know that 1-6 means from 1 digit to 6 digits.
It make no sense that you can choose the start point, all mobile otp solution i know start with the first digit, only the lenght of the OTP password is changeable. It could be dangerious if you set the start point higher than the lenght of your hash.
But if it is a no go i change this behavor back.regards
max
It is not a "no go" it just adds flexibility. If someone writes an own OTP generator which add the ability to chose different digits then the GUI is able to do so. And the default behaviour shows "1-6" so no need to change anything for the first time user.
I will try if I find some time on the weekend to check the files you added. :)
-
Hi Nachtfalke
I also think abought the "OTP Lifetime "
If you insert 18 (3min) than the server calculate every otp from currenttime - 180 sec to currenttime +180sec that are 36 OTP Passwords.This timeframe is fixed set in the original script (..do # 3 minutes before and after..) so it's much better in pfsense; able to set the range.
But going into the future is senseless, for both version.
Client has the same time as the server and users need time to insert the OTP so the otpverify.sh script is always in the future. (Ok for some weired situation like timedrift calc one otp in the future would be ok)
Also build in my version…but with no future :-)
regards max
-
Hi Nachtfalke,
did your try my mod ?
Are there any inputs/whishes from your side, or do you deny completly this mod.regards max