Re: Detect MSCHAPv2 inner-tunnel state

26 Sep 2018

      Hi Matthew,

Using the session-state list worked, thanks! Here's what I did. In the
inner-tunnel authorize section:

        eap {
                ok = return
        }

        update request {
                &Tmp-String-2 := &outer.session-state:Tmp-String-2
        }

        rlm_my_module

        update {
                &outer.session-state:Tmp-String-2 := &config:NT-Password
        }

I inspect Tmp-String-2 in rlm_my_module and, if populated, do not call the
API to get the NT hash again. I noticed, however, the following in the
post-auth section:

(9)   post-auth {
(9)     update {
(9)       &reply::Tmp-String-2 += &session-state:Tmp-String-2[*] ->
'0x3143394634423634423245394643353832433234464232444145463636393732'
(9)     } # update = noop

Any concerns or suggestions?

Thanks again,

Gary

On Sat, Sep 22, 2018 at 12:32 PM Matthew Newton <mcn@freeradius.org> wrote:
...
On 22 September 2018 18:23:00 BST, Gary Gwin <garygwin@gmail.com> wrote:
...
During the chatty inner-tunnel MSCHAPv2 negotiation, the get NT hash
API is
invoked twice in requests 7 and 8, which works, but with unnecessary
script
and API load. I can eliminate the second invocation in step 8 by
checking
the request EAP-Message for length. That feels fragile. There must be a
better way to detect state to determine we're in request 8.
Put the hash in the session-state list, but only if it's not already there?
--
Matthew