Use 2 modules to auth together.
luckydog xf
luckydogxf at gmail.com
Tue Nov 27 05:57:47 CET 2018
Hi, here is my access-request from radiusd -fX
Only an extra State is added comparing to the 1st auth.
# Access-Challenge
Ready to process requests
(6) Received Access-Request Id 13 from 172.30.240.130:7460 to
172.16.237.52:1812 length 205
(6) NAS-Identifier = "Artisan_FW"
(6) State = 0x654e6c7472756d474c576c6a61584b37
(6) User-Name = "someone"
(6) MS-CHAP2-Response =
0x0f003132333435363638393035398846f8ca00000000000000000ac4b98d3afb9b42a0e1a1def464b78e5f6b13033d6a6e7c
(6) MS-CHAP-Challenge = 0x680d6e49baa9e6f4b4f622042f0917f6
(6) NAS-IP-Address = 172.30.240.130
(6) NAS-Port-Type = Virtual
(6) Called-Station-Id = "172.30.240.130"
(6) Acct-Session-Id = "033ac507"
(6) Connect-Info = "admin-login"
(6) Fortinet-Vdom-Name = "root"
(6) session-state: No cached attributes
(6) # Executing section authorize from file /etc/raddb/sites-enabled/default
As you can see there is NO User-Password attribute, which is OTP. It
seems that it's caused by mschap authentication, there is no such
attribute in mschap.
Is there any way to input User-Password( in other words, OTP)? or my
own auth method would fail to auth as there is no OTP.
Thanks.
On Nov 26, 2018, at 8:42 AM, luckydog xf <luckydogxf at gmail.com
<http://lists.freeradius.org/mailman/listinfo/freeradius-users>>
wrote:
Find a challenge-support Device and test it out. Let me answer it.
1. Not every NAS supports Access-Challenge, they may just ignore it
and treat it as access-reject. According to my test.
2. my way of raise challeng is correct, it's built-in way of FreeRADIUS.
3. else part seesm correct, too, though I haven't hanle my own auth
method, it's just a fake one.
Thank Alan again.
On Nov 26, 2018, at 12:42 AM, luckydog xf <luckydogxf at gmail.com
<http://lists.freeradius.org/mailman/listinfo/freeradius-users>>
wrote:
Thank, Alan, you enlighten me.
Turns out NAS( my VPN) does not support Access-Challenge. Googled and
found that Challenge seems to be a speical access-request packet with the
Code field set to 11. So can I make the conclusion that it would send an
access-quest again? in other words, start a new authentication process
like another normal request with an exception that State attribute exists.
Let me suppose my VPN supports Access-Challenge, so my configuation is
something like:
-------------------------------
authorize {
# The first auth does not have any State attribute.
if (!State) {
# MS-CHAP has no User-Password, so it's true.
if (!User-Password ) {
# If !State and User-Password is null, then
goes to MS-CHAP:
update {
&control:Auth-Type := MS-CHAP
}
}
else { reject }
# Make sure it does not contain any other attributes except State.
else {
update {
# IS THIS PART CORRECT ? I think so, as a new request is
issued by challage, so it would start over from top to buttom to walk
throught the entire process.
&control:Auth-Type := MY_OWN_OTP_AUTH
}
}
}
authentication {
Auth-Type MS-CHAP {
mschap
if (ok) {
update reply {
# Create a random State attribute:
State := "%{randstr:XXXXXXXXXXXXX}"
Reply-Message := "Please type your OTP:"
}
# Return Access-Challenge, goes to the 2nd auth.
# IS IT the correct way to raise a challange?
challenge
}
Please help me to take a look at configuration above, two questions:
1. Is else part correct? which will use my own python auth module
2. Is it correct to raise a challenge using 'challenge' filter of
FreeRADIUS?
Thanks again.
On Mon, Nov 26, 2018 at 8:10 PM Alan DeKok <aland atdeployingradius.com
<http://lists.freeradius.org/mailman/listinfo/freeradius-users>>
wrote:
>** On Nov 26, 2018, at 2:42 AM, luckydog xf <luckydogxf at gmail.com <http://gmail.com> <http://lists.freeradius.org/mailman/listinfo/freeradius-users <http://lists.freeradius.org/mailman/listinfo/freeradius-users>>> wrote:
**>* > Our user is in AD and VPN will do an MSCHAP authentication first and
*>* > filter property of User-Name from access request, then call an
*>* > access-challenge to verify against the other module whose logic is as
*>* > simple as starting a http request via http://XXX/check/username=
<http://xxx/check/username=>
<http://xxx/check/username=>
*>* > <http://xxx/check/username=
<http://xxx/check/username=>><USER-NAME>&OTP=<xxxxxx>, if return 200,
*>* it's
*>* > ok.
*>>* That's really just more authorization.
*>>* > Basically, I want to auth a single login against two modules, only both
*>* > of them are successful, the auth could be deemed as OK.
*>>* That's possible, subject to certain caveats.
*>>* > # ### authentication #####
*>* > authentication {
*>* > Auth-Type MS-CHAP {
*>* > mschap
*>* > if (ok) {
*>* > update reply {
*>* > # Create a random State attribute:
*>* > State := "%{randstr:XXXXXXXXXXXXX}"
*>* > Reply-Message := "Please type your OTP:"
*>* > }
*>* > # Return Access-Challenge, goes to the 2nd auth.
*>* > challenge
*>>* That's good, but it likely won't work due to the NAS. Doing OTP like
*>* that requires support from the NAS. Does the NAS support doing MS-CHAP and
*>* then receiving an Access-Challenge?
*>>* If it does, then your next step is to write down what you want to
*>* happen, like this:
*>>* 1) packet 1 contains MS-CHAP
*>* 2) it authenticates agains MS-CHAP
*>* 3) if MS-CHAP is successful, it returns a State, challenge, and reply
*>* message
*>* 4) when the next packet comes in with a state attribute, authenticate the
*>* OTP
*>>* Note that the packet in step 4 *should not* contain any MS-CHAP
*>* attributes. It should just contain the response to the OTP.
*>>* So your freeradius configuration is:
*>>* 1) run MS-CHAP like normal
*>* 2) do state / reply-message / challenge in "Auth-Type MS-CHAP"
*>>* As a *separate* item:
*>>* 3) if packet contains State
*>* 4) do OTP verification
*>>* The only thing tying the two packets together is the State attribute.
*>* They are otherwise completely independent.
*>>* Alan DeKok.
*>>>>* -
*>* List info/subscribe/unsubscribe? See
*>* http://www.freeradius.org/list/users.html
<http://www.freeradius.org/list/users.html>*
More information about the Freeradius-Users
mailing list