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.