2 Factor Authentication
Dudás Péter
peter.pdudas at gmail.com
Thu Jan 5 12:41:41 CET 2017
Dear Alan!
I*t is a timing issue.* I just forwarded the Access Request to another
radius server (Domain Controller) which replies immediately - access
accepted, VPN client logged in successfully.
If I put a 'sleep 10' in the shell script (duo2.sh) before the radtest
(please see below) to send the request to the Domain Controller
(10.101.168.3), then the VPN connection fails like with the DUO.
Details:
*/etc/freeradius/Duo2.sh
*
#!/bin/bash
sleep 10
if (/usr/bin/radtest -d /usr/share/freeradius/ -t mschap 'Peter Dudas'
'password' 10.101.168.3:1812 0 secret 0 10.148.64.67) | grep -Fq
'Access-Accept'; then
echo "Access-Accept"
else
echo "Access-Reject"
exit 1
*fi
*
*/etc/freeradius/mods-available/duo2
*
exec duo2 {
wait = yes
program = "/etc/freeradius/duo2.sh"
timeout = 30
*}
*
*/etc/freeradius/sites-available/default
*
server dafault {
listen {
type = auth
ipaddr = 10.148.64.67
port = 0
limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
}
}
listen {
type = auth
ipaddr = 127.0.0.1
port = 0
limit {
}
}
listen {
type = acct
ipaddr = 10.148.64.67
port = 0
limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
}
}
listen {
type = acct
ipaddr = 127.0.0.1
port = 0
limit {
}
}
authorize {
preprocess
auth_log
#KIPOW1 SSL-VPN Radius Request attributes checked before MS-CHAPv2
auth
if (User-Name != "" && Service-Type !* "") {
if (Packet-Type == "Access-Request" && NAS-IP-Address == "
89.212.168.xyz") {
sslvpn
if (ok) {
update control {
Auth-Type := Accept
}
update reply {
Filter-Id := "SSLVPN-Users"
}
return
}
}
}
else {
# KIPOW1 L2TP-VPN Radius Request attributes checked before
MS-CHAPv2 auth
if (MS-CHAP2-Response != "" && MS-CHAP-Challenge != "") {
if (NAS-IP-Address == "89.212.168.xyz" && Framed-Protocol
== "PPP") {
if (Service-Type == "Framed-User" && Packet-Type ==
"Access-Request" ) {
if (MS-CHAP-Challenge != "" && NAS-PORT ==
"0" ) {
mschap
if (ok) {
update reply {
Filter-Id :=
"L2TP-Users"
}
}
}
}
}
}
}
}
authenticate {
Auth-Type mschap {
mschap
}
Auth-Type sslvpn {
sslvpn
}
Auth-Type duo {
duo
}
}
preacct {
preprocess
acct_unique
suffix
files
}
accounting {
detail
radutmp
attr_filter.accounting_response
}
session {
radutmp
}
post-auth {
reply_log
duo2
exec
Post-Auth-Type REJECT {
attr_filter.access_reject
}
reply_log
}
pre-proxy {
}
post-proxy {
}
*}
*
/etc/freeradius/radiusd.conf
prefix = /usr
exec_prefix = /usr
sysconfdir = /etc
localstatedir = /var
sbindir = ${exec_prefix}/sbin
logdir = /var/log/freeradius
raddbdir = /etc/freeradius
radacctdir = ${logdir}/radacct
name = freeradius
confdir = ${raddbdir}
modconfdir = ${confdir}/mods-config
certdir = ${confdir}/certs
cadir = ${confdir}/certs
run_dir = ${localstatedir}/run/${name}
db_dir = ${raddbdir}
libdir = /usr/lib/freeradius
pidfile = ${run_dir}/${name}.pid
correct_escapes = true
max_request_time = 45
cleanup_delay = 5
max_requests = 16384
hostname_lookups = no
regular_expressions = yes
extended_expressions = yes
checkrad = ${sbindir}/checkrad
log {
destination = files
colourise = yes
file = ${logdir}/radius.log
syslog_facility = daemon
stripped_names = no
auth = yes
auth_badpass = yes
auth_goodpass = yes
}
security {
user = freerad
group = freerad
allow_core_dumps = no
max_attributes = 200
reject_delay = 1
status_server = yes
}
proxy_requests = no
$INCLUDE clients.conf
thread pool {
start_servers = 5
max_servers = 32
min_spare_servers = 3
max_spare_servers = 10
max_requests_per_server = 0
auto_limit_acct = no
}
modules {
$INCLUDE mods-enabled/
}
instantiate {
}
policy {
$INCLUDE policy.d/
}
*$INCLUDE sites-enabled/
*
/etc/freeradius/clients.conf
client localhost {
ipaddr = 127.0.0.1
proto = *
secret = bekapodafaszomhajohanemjo
require_message_authenticator = no
nas_type = other # localhost isn't usually a NAS...
# response_window = 10.0
limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
}
}
client dc1 {
ipaddr = 10.101.168.3
secret = secretofclient
response_window = 30.0
So it is not related with DUO - it is a simple timing/timeout issue.
Do you have any idea why this happens?
Thank you!
Peter Dudas
On 5 January 2017 at 01:27, Dudás Péter <peter.pdudas at gmail.com> wrote:
> Dear Alan!
>
> Working means the devices are successfully connected - so the connection
> not depending on the strenght of the tunnel encryption (if duo
> authentication disabled).
>
> Somenthing should be different - I have a feeling that Duo and Freeradius
> uses the same resources and this cause the problem.
> Tomorrow I'll move the Duo to a new server and we'll see if the problem
> stays or not.
>
>
>
>
>
> On 5 January 2017 at 00:35, Alan DeKok <aland at deployingradius.com> wrote:
>
>> On Jan 4, 2017, at 6:17 PM, Dudás Péter <peter.pdudas at gmail.com> wrote:
>> > I don't see any difference in the reply - checked the logs.
>>
>> Then the NAS should do the same thing in both cases.
>>
>> > With this I was able to login from and Android phone.
>> > MPPE encryption type I changed to Required (at module mschap) - but as
>> you
>> > can see it is working with that as well.
>>
>> Please be clear about "working". There are multiple pieces involved.
>>
>> If the Access-Accepts are the same in both cases, then the NAS should
>> behave the same in both cases.
>>
>> And there is no way that adding a simple program to be executed will
>> make the NAS misbehave.
>>
>> Something else is going wrong. Find that, and the problem will be
>> fixed.
>>
>> Alan DeKok.
>>
>>
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list
>> /users.html
>>
>
>
More information about the Freeradius-Users
mailing list