Problem by Anonymous Identity.

[Phil Mayers]

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 at 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.