Many thanks, Running debug is not possible as this user "anonymous" connect to wireless randomly in a remote office. I have enabled following in, default & inner-tunnel, But specific user still showing as anonymous. Am i missing any config part ?. Should i modify policy.d/filter to prevent users loggin in as "anonymous" as this only occur for only one user and still don't know how or what is causing this . ******************************** 1, sites-enabled/default authorize { filter-username } 2, sites-enabled/inner-tunnel authorize { filter_username filter_inner_identity } post-auth { reply_log } ******************************** ~# cat /var/log/freeradius/radius.log | grep anon Wed Oct 23 10:13:15 2024 : Auth: (4568) Login OK: [anonymous/<via Auth-Type = eap>] (from client Aruba Cluster port 0 cli <mac-address>) WHERE (radpostauth.username LIKE 'anon%%') AND (authdate >='2024-01-01' AND authdate <='2024-10-31') ~# ******************************** ~# cat /var/log/freeradius/radius.log | grep <username_removed> Wed Oct 23 10:13:15 2024 : Auth: (4567) Login OK: [username_removed/<via Auth-Type = eap>] (from client Aruba Cluster port 0 cli <mac-address> via TLS tunnel) ~# ******************************** Thanks, On Friday 18 October, 2024 at 05:36:21 pm IST, Alan DeKok <aland@deployingradius.com> wrote: On Oct 18, 2024, at 7:29 AM, Eby Mani via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I'm having a strange problem, for one specific user, wireless system dashboard and radius accounting db show connected username as "anonymous".
That is the User-Name in the RADIUS packets.
User credentials are stored in database and Calling-Station-Id is used to prevent unauthorized devices from connecting. FreeRADIUS authentication logs are not enabled.
You're likely using PEAP / TTLS, and authenticating the user via the *inner* User-Name. Read the debug logs to see more.
On DB, user "anonymous" do not exist. The wireless system is configured to authenticate only with FreeRADIUS server. Changing Calling-Station-Id on radius db prevents this system from connecting.
I'm wondering how this is possible and where to check what is causing this.
It's how the protocols work. You will need to log the inner User-Name for the authentication session. Or, update the Access-Accept to contain Chargeable-User-Identity. See raddb/policy.d/cui Alan DeKok.