If block in authenticate statement

[Franks Andy (IT Technical Architecture Manager)]

Hi,
  Sorry I didn't complete this email the other day..
  I didn't realise you could set the EAP-Type to force the inner, that's great - thanks, it seems there are a good few better ways than an IF .. in the auth section.

As for the authenticate bit, just for learning sake, and theory, should the below work?
It seems daft putting if (ok) { ok } in there , but putting the explicit ok in anywhere else didn't seem to work, but this doesn't either.

The mschap auth seems to be called from the Auth-Type inner-eap as a "sub-auth", and here I have a module catch for other failures, but not for ok :

It's still doing a noop (I've edited the mschap script call out, which complete ok, just to keep the mail shorter):

if (( control:SSID == "RSH_WiFi_2" ) || ( control:SSID == "Another_WiFi" )) {
(12) eap_mschapv2:     if (( control:SSID == "RSH_WiFi_2" ) || ( control:SSID == "Another_WiFi" ))  -> TRUE
(12) eap_mschapv2:     if (( control:SSID == "RSH_WiFi_2" ) || ( control:SSID == "Another_WiFi" ))  {
..
..
mschap: Adding MS-CHAPv2 MPPE keys
(12)       [mschap] = ok
(12)       if ok {
(12)       if ok  -> TRUE
(12)       if ok  {
(12)         [ok] = ok
(12)       } # if ok  = ok
(12)       ... skipping else for request 12: Preceding "if" was taken
(12)     } # if (( control:SSID == "RSH_WiFi_2" ) || ( control:SSID == "Another_WiFi" ))  = ok
(12)     ... skipping else for request 12: Preceding "if" was taken
(12)   } # Auth-Type MS-CHAP = noop
(12) inner-eap: Freeing handler
(12)       [inner-eap] = reject

Auth-Type inner-eap {
                inner-eap {
                        reject = 1
                        invalid = 1
                }
                if (!ok) {
...

Auth-Type MS-CHAP {
                # get ssid so we can check against mschapv2 allowed ssids
                get_ssid

                # allowed ssids. Commented out 06-11-2015 due to return status issues.
                if (( control:SSID == "RSH_WiFi_2" ) || ( control:SSID == "Another_WiFi" )) {
                        mschap {
                                reject = 1
                                invalid = 1
                        }
                        if ok {
                          ok
                        } else {
                                if (Module-Failure-Message) {   # Could be that we've got a failure message or just debug information, depending on whether mschap i$
                                                        # seems sometimes that the failure goes straight to reject, sometimes via the outer tunnel which is $
                                                        # tunnel (above in mschap), and the outer anyway, so should be ok.
                                        update outer.control {
                                                Debug-RejectInformation := "%{Module-Failure-Message}"
                                        }
                                }
                                reject
                        }
                }
                else {
                        update control {
                                Debug-RejectInformation := "PEAP - EAP - MSCHAPv2 not allowed!"
                        }
                        reject
                }
        }



  

  

-----Original Message-----
From: Freeradius-Users [mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk at lists.freeradius.org] On Behalf Of Alan DeKok
Sent: 09 November 2015 13:45
To: FreeRadius users mailing list
Subject: Re: If block in authenticate statement

On Nov 9, 2015, at 8:28 AM, Franks Andy (IT Technical Architecture Manager) <Andy.Franks at sath.nhs.uk> wrote:
>  I did try the OK bit at the end of the module, but it still returns noop, which is what confuses me.

  What was the exact configuration you tried?

> Whether I did the ok bit in the correct place is debateable but I did try it in the logical places. Does the ok placement need to be after an "else" statement?

  It needs to be wherever you want to set the return code to be "ok".

> Anyway, onto why - I don't want to flat reject people using that SSID, just people who use PEAP and use mschapv2 (instead of TLS) on certain SSIDs. In certain circumstances I might want them to be allowed if they bring me sweets at Christmas for example.

  Then configure that...

authorize {
	...
	eap
	...

	if ((SSID == "no-peap") && (EAP-Type == PEAP)) {
		reject
	}
	...
}

  Or, you can do the same thing in the inner tunnel.

  But realistically, why ban certain configurations?  Why not configure the client correctly?  And then configure the server to use only one authentication method?

>  The problem is we (afaik) don't find out what the auth type is until the authorize stage where that module (eap in this case) sets it, and the inner auth type here is a few layers into the onion, that's why it sort of made sense to me to do it at "final" authenticate stage. I could probably also do it post-auth too I guess, pass it then check and reject..

  That would work, too.

 Or, you could just set EAP-Type for particular users.

server inner-tunnel {
authorize {
	...
	if (WiFi == "no-inner-mschap") {
		update control {
			EAP-Type := TLS	# force outer PEAP, inner TLS
		}
	}
	...

	eap

	...

}
}

> The custom debug message was an "overall" delivery message to the indicate why failure had occurred at any point in the chain. Module-Failure-Message only works on certain modules afaik (or did when I last asked) so failures in certain areas would yield blanks. I'd quite happily ditch that if all modules do it now!

  Most should... more do in v3.1.x.

> I also think (from unreliable memory) that I had issues copying some of the attributes from inner to outer, some worked and some didn't - does the module-failure-message get automatically copied now from inner to outer layer?

  No.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html