Last call for 2.1.10

[John Horne]

On Wed, 2010-09-22 at 18:02 +0100, John Horne wrote:
> 
> The failed login has no MS-CHAP2-Success attribute being sent back.
> 
Okay. The problem is to do with attribute filtering, but that in turn
seems to be caused by freeradius doing something unexpected when it
receives the HUP.

We define the file /etc/raddb/attrs.post-proxy which contains the
following:

    plymouth.ac.uk
        MS-CHAP2-Success =* ANY,
        Fall-Through = Yes

    NULL
        MS-CHAP2-Success =* ANY,
        Fall-Through = Yes

    DEFAULT
        Service-Type == Framed-User,
        Service-Type == Login-User,
        Login-Service == Telnet,
        ... (other attributes/values)

We also have the file /etc/raddb/modules-local/attr_filter which
contains:

    attr_filter attr_filter.post-proxy {
          attrsfile = ${confdir}/attrs.post-proxy
    }

So when freeradius starts up it reads this file, and uses the defined
module in preference to the one in the
file /etc/raddb/modules/attr_filter. Running 'radiusd -X' shows:

===================================================================
Starting - reading configuration files ...
...
including configuration file /etc/raddb/modules-local/attr_filter
...
including configuration file /etc/raddb/modules/attr_filter

...

 Module: Checking post-proxy {...} for more modules to load
 Module: Instantiating module "attr_filter.post-proxy" from
file /etc/raddb/modules-local/attr_filter
  attr_filter attr_filter.post-proxy {
        attrsfile = "/etc/raddb/attrs.post-proxy"
        key = "%{Realm}"
  }
===================================================================


As can be seen the correct module file is used. Now lets do a HUP:


===================================================================
 ... new connection request on command socket.
Listening on command file /var/run/radiusd/radiusd.sock
Ready to process requests.
radmin> hup
Ready to process requests.
Received HUP signal.
HUP - Re-reading configuration files
...
including configuration file /etc/raddb/modules-local/attr_filter
...
including configuration file /etc/raddb/modules/attr_filter

...

Module: Trying to reload module "attr_filter.post-proxy"
  attr_filter attr_filter.post-proxy {
        attrsfile = "/etc/raddb/attrs.post-proxy"
        key = "%{Realm}"
  }
 Module: Reloaded module "attr_filter.post-proxy"
...
Module: Trying to reload module "attr_filter.post-proxy"
  attr_filter attr_filter.post-proxy {
        attrsfile = "/etc/raddb/attrs"
        key = "%{Realm}"
  }
 Module: Reloaded module "attr_filter.post-proxy"
===================================================================


As can be seen, after the HUP freeradius loads the original file, but
then reloads the default one (/etc/raddb/modules/attr_filter which uses
"/etc/raddb/attrs"). This default filter file has no MS-CHAP2-Success
entry, so that attribute would be filtered out.

Looking at the processing of the access accept packet shows this too:

===================================================================
rad_recv: Access-Accept packet from host 141.163.195.250 port 1812,
id=137, length=194
        Framed-IP-Address = 141.163.192.64
        MS-MPPE-Encryption-Types = 0x00000004
        MS-MPPE-Encryption-Policy = 0x00000002
        MS-CHAP2-Success =
0x8c533d32373939374535323141364234394141453336314337343341313436383936323043393032433045
        Reply-Message = "Yes"
        MS-MPPE-Recv-Key = 0xf6ee626fa0a9ceea0c565916916e4a5a
        MS-MPPE-Send-Key = 0x12c24a8d04f33b97b786c120f155aa4f
        Proxy-State = 0x3338
# Executing section post-proxy from
file /etc/raddb/sites-enabled/default
+- entering group post-proxy {...}
[eap] No pre-existing handler found
++[eap] returns noop
[files] users: Matched entry jhorne at line 213
[files]         expand: %{User-Name} -> jhorne
[files]         expand: %{User-Name} -> jhorne
[files]         expand: %{User-Name} -> jhorne
[files]         expand: %{Calling-Station-Id} -> 141.163.60.243
[files] users: Matched entry DEFAULT at line 269
++[files.authorize] returns ok
[attr_filter.post-proxy]        expand: %{Realm} -> NULL
 attr_filter: Matched entry DEFAULT at line 103
++[attr_filter.post-proxy] returns updated
===================================================================


The 'Matched entry DEFAULT at line 103' is from the
file /etc/raddb/attrs, and so the MS-CHAP2-Success attribute is removed
and the client see a failure/reject rather than a success.

The 'radiusd -X' output when a HUP hasn't been given shows:

===================================================================
    [attr_filter.post-proxy]        expand: %{Realm} -> NULL
     attr_filter: Matched entry NULL at line 5
     attr_filter: Matched entry DEFAULT at line 9
    ++[attr_filter.post-proxy] returns updated
===================================================================

And the lines 5 and 9 correspond to our defined file which allow for the
MS-CHAP2-Success attribute.


So, I guess the question is why is freeradius reloading the post-proxy
filter a second time after the HUP?




John.

-- 
John Horne, University of Plymouth, UK
Tel: +44 (0)1752 587287    Fax: +44 (0)1752 587001