If block in authenticate statement

[Franks Andy (IT Technical Architecture Manager)]

Hi Alan,
  Thanks for the reply.

  I did try the OK bit at the end of the module, but it still returns noop, which is what confuses me. 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? I'd put it at logical exit, i.e. after the if bit that I would want an ok returned, but if I need to specifically reject within the if/else and ok for all other eventualities at the end I didn't try that..

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.

  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..
 
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!

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?

Thanks for your help as always!
Andy

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

On Nov 5, 2015, at 7:20 PM, Franks Andy (IT Technical Architecture Manager) <Andy.Franks at sath.nhs.uk> wrote:
>  I'm doing something off-piste again probably.
> Can I get away with doing an if statement within the mschap auth block?

  Yes.

> I'm trying to allow peap-eap-mschap inner tunnel auth on certain ssids only; without the if statement, it works ok, but when I check against a control variable containing SSID, it produces this :
> 
> mschap:    --> --nt-response=10fe5a0664f0f3debffdcd61b60865947601331bdefef81c
> (9) mschap: Program returned code (0) and output 'NT_KEY: CD7018318BC2359E8A362E0557384BEC'
> (9) mschap: Adding MS-CHAPv2 MPPE keys
> (9)       [mschap] = ok
> (9)       if (!ok) {
> (9)       if (!ok)  -> FALSE
> (9)     } # if (( control:SSID == "A_WiFi" ) || ( control:SSID == "Another_WiFi" ))  = ok
> (9)   } # Auth-Type MS-CHAP = noop

  That's the issue.  You can fix it by listing "ok" as the last module in the block which should return "ok".

  But as a larger issue... why are you doing these checks in the authenticate section?  You should be doing most of them in the "authorize" section.  You want to reject users as early in the process as possible.

authorize {
	...
	if (( control:SSID != "A_WiFi" ) && ( control:SSID != "Another_WiFi" )) {
		reject
	}
	...

}

  And why are you updating Debug-RejectInformation?  Why not just use Module-Failure-Message directly?  So the authenticate section can then look like this:

authenticate {
	...
	Auth-Type MS-CHAP {
		mschap
	}
	...
}

  If you need to see why a request was rejected, use Post-Auth-Type Reject:

post-auth {
	...
	Post-Auth-Type Reject {
		# Module-Failure-Message says why the user was rejected
	}
	...
}

  Much simpler.  Much easier to understand.

  Alan DeKok.


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