.. snip ...
Wed Feb 13 15:17:00 2008 : Debug: rlm_sql (sql): Released sql socket id: 4
Wed Feb 13 15:17:00 2008 : Debug: modsingle[accounting]: returned from sql (rlm_sql) for request 0
Wed Feb 13 15:17:00 2008 : Debug: ++[sql] returns ok
Wed Feb 13 15:17:00 2008 : Debug: modsingle[accounting]: calling attr_filter.accounting_response (rlm_attr_filter) for request 0
Wed Feb 13 15:17:00 2008 : Debug: expand: %{User-Name} -> user1@dsl.realm1.co.uk
Wed Feb 13 15:17:00 2008 : Debug: attr_filter: Matched entry DEFAULT at line 12
Wed Feb 13 15:17:00 2008 : Debug: modsingle[accounting]: returned from attr_filter.accounting_response (rlm_attr_filter) for request 0
---
Wed Feb 13 15:17:00 2008 : Debug: ++[attr_filter.accounting_response] returns updated
--- Accounting response filter is stripping out required attributes before the accounting packet is proxied. It's a small oversight in the default config. The reason why the cisco attributes are getting through, is because VSAs are allowed in the accounting response. As accounting packets don't pose much of a risk, I leave them unfiltered... # If request is being proxied, don't filter the accounting packet through accounting_response. accounting { ... if(!"%{control:Proxy-To-Realm}"){ attr_filter.accounting_response } } # Accounting requests are exempt from the pre-proxy filter pre-proxy { ... if("%{Packet-Type}" != 'Accounting-Request'){ attr_filter.pre-proxy } } It's not perfect, but it'll work for now. Can always apply the accounting_response filter in post-proxy if you were worried about it... something like post-proxy { ... if("%{Packet-Type}" == 'Accounting-Response'){ attr_filter.accounting_response } else { attr_filter.post-proxy } }
-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900