.. 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} ->
[EMAIL PROTECTED]
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 ([EMAIL PROTECTED])
Authentication, Authorisation and Accounting Officer
Infrastructure Services | ENG1 E1-1-08
University Of Sussex, Brighton
EXT:01273 873900 | INT: 3900
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
