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