On 16/07/12 16:57, guillermo wrote:
Hello friends:
I wanted to help me solve a problem on my server freeradius criteria. To
the point, what I need is to deny the use by clients of the option
Anonymous Identity, for in the accounting server I recorded this and not
This is a bad idea. But, if you really want to do this:
authorize {
...
if (User-Name =~ /^@/) {
reject
}
...
}
the actual user hindering Trace connections.
Much better is to fix your RADIUS server so that it puts the correct
User-Name in the REPLY, and your NAS should (if it complies with the
RFCs) then use that User-Name in accounting packets.
The EAP methods should do this automatically, however you might have
problems if you are doing EAP-TTLS/PAP or EAP-TTLS/MSCHAP because the
inner method is not EAP.
We do this:
sites-enabled/inner-tunnel:
post-auth {
if (!reply:User-Name) {
update reply {
User-Name := "%{User-Name}"
}
}
}
sites-enabled/default:
post-auth {
...
if (reply:User-Name =~ /^(.+)@(.+)$/) {
# reply contains user@realm
# overwrite the realm with the one in the request
# in case the far end has changed realm. This forces
# routing symmetry
update reply {
User-Name := "%{1}@%{Realm}"
}
}
elsif (reply:User-Name) {
# reply contains bare user, no realm - add one
update reply {
User-Name := "%{reply:User-Name}@%{Realm}"
}
}
else {
# no reply username, use the one from the request
update reply {
User-Name := "%{User-Name}"
}
}
...
}
...ensure you have:
use_tunneled_reply = yes
...in your eap.conf for this to work properly.
If your NAS doesn't send the reply User-Name back in accounting, throw
it away and get a new one.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
