Some options: 1) If the NAS puts an Acct-Session-Id in the Access-Request packets, use this to link auth to subsequent accounting. (Many NASes don't support doing this.) 2) Use a Class attribute to link auth to subsequent accounting. (Requires that the NAS support this, some have trouble where there is more than one Class attribute.) 3) Return a User-Name attribute in the Access-Accept containing the inner identity. (Requires that the NAS support this, and this partially compromises identity privacy.)

On 4 Feb 2017, at 21:45, Selahattin Cilek <selahattin_cilek@hotmail.com> wrote:

Yes, I know. I know I can't prevent them from configuring their own machines as they like. That is not what I am asking.

I'm not sure what you're asking then. The username is logged as "anonymous" because the user has typed in "anonymous". FreeRADIUS logs what the NAS and the client send. If you don't accounting packets to contain "anonymous" you can: * reject their authentication. * configure your NAS to send something more meaningful There's no secret SQL query - if the user sends "anonymous", and your NAS is configured to use that "anonymous" in accounting, then FreeRADIUS will log "anonymous", and any SQL query will return "anonymous". If explain your problem further (e.g. why is correlating the Calling-Station-ID in accounting logs to the one in your auth log insufficient) people can probably help further - but you've given precious little information. Regards, Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.

Hi, If you only have one type of quota you could use MAC addresses (most likely Calling-Station-Id, but confirm with the NAS/AP docs) to identify subscribers. This approach has a number of issues (one user with multiple devices will be treated as multiple users, you can't have multiple plans - all users are treated the same way, MAC address can be spoofed) but it might be just enough to deliver what you're after. kind regards Pshem On Sun, 5 Feb 2017 at 17:18 Selahattin Cilek <selahattin_cilek@hotmail.com> wrote:

On 05.02.2017 01:44, Adam Bishop wrote:

...

On 4 Feb 2017, at 21:45, Selahattin Cilek <selahattin_cilek@hotmail.com> wrote:

...

Yes, I know. I know I can't prevent them from configuring their own machines as they like. That is not what I am asking. I'm not sure what you're asking then. The username is logged as "anonymous" because the user has typed in "anonymous". FreeRADIUS logs what the NAS and the client send.

If you don't accounting packets to contain "anonymous" you can: * reject their authentication. * configure your NAS to send something more meaningful

There's no secret SQL query - if the user sends "anonymous", and your NAS is configured to use that "anonymous" in accounting, then FreeRADIUS will log "anonymous", and any SQL query will return "anonymous". That is what I wanted to know, thank you. The NAS is a Unifi AP and does not let me configure EAP behaviour. It is not very successful in RADIUS accounting. Since I can't make the NAS behave the way I want, my only option is to configure RADIUS to the best of my ability.

If explain your problem further (e.g. why is correlating the Calling-Station-ID in accounting logs to the one in your auth log insufficient) people can probably help further - but you've given precious little information. The problem is that if RADIUS does not know who is using how much, it wont be able to keep track of network usage and therefore enforce quotas. Somehow, I need to find out what the true user name is. What can I do with a packet labelled "anonymous"? I made a promise to the owner of the site, but have failed to deliver because of the NAS.

Regards,

Adam Bishop

gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On 05/02/17 11:12, Brian Candler wrote:

It can be argued that using the outer identity in accounting packets is reasonable behaviour. After all, the whole reason the client chose "anonymous" was so that a network sniffer could not see their real identity. If the NAS included the real identity in accounting packets, then a sniffer would see it.

Sort of. There are really two use-cases AFAICT: 1. "anonymous" in the EAP packet on the wired/wireless LAN to hide your identity from passive sniffers outside the network e.g. someone sitting in the same coffee shop with a wifi sniffer. 2. "anonymous" in the RADIUS packets and accounting to hide your identity from the NAS (the latter particularly in a federated network like eduroam where SP and IdP are different entities) I don't think "anonymous" was ever really intended to protect against sniffing of the accounting packets between NAS & radius server - if you have attacks at that level, you have bigger problems and should be using IPSec or RADSEC.

As it happens, it *is* possible to keep track of true user identity using the MAC address. I understand that FreeRADIUS always uses the true identity in the "post-auth" phase. So if we log the post-auth packets, we will have some valuable information about the user: post-auth { sql } Calling-Station-Id is the most valuable piece of information we can obtain from the post-auth logs. Using a simple MySQL synchronisation table and a stored procedure, we can trace users' current MAC addresses: CREATE TABLE `raddb`.`users_macs` (`id` INT NOT NULL AUTO_INCREMENT, `username` VARCHAR(32) NOT NULL, `mac` CHAR(17) NOT NULL, PRIMARY KEY (`id`)); CREATE DEFINER=`root`@`localhost` PROCEDURE `synchronise_macs`(IN in_user_name VARCHAR(32), IN in_calling_station_id CHAR(17)) BEGIN SET @normalised_mac = LOWER(REPLACE(in_calling_station_id, '-', ':')); SET @user_name_count = (SELECT COUNT(username) FROM radreply WHERE username = in_user_name); -- Does the user name exist in our database? IF @user_name_count > 0 -- Yes, it does. THEN -- Does the user name exist in the user_macs table? SET @user_mac_count = (SELECT COUNT(username) FROM user_macs WHERE username = in_user_name); IF @user_mac_count = 0 THEN -- No, it does not. INSERT INTO user_macs (username, mac) VALUES (in_user_name, @normalised_mac); ELSE -- Yes, it does. UPDATE user_macs SET mac = @normalised_mac WHERE username = in_user_name; END IF; END IF; END Then, edit the dialup.conf file in the sql/mysql directory to call the stored procedure above: postauth_query = "CALL synchronise_macs('%{User-Name}','%{Calling-Station-Id}')" Now, we will always have the true identity and the current MAC address of the user. Thank you all. On 05.02.2017 01:44, Adam Bishop wrote:

On 4 Feb 2017, at 21:45, Selahattin Cilek <selahattin_cilek@hotmail.com> wrote:

...

Yes, I know. I know I can't prevent them from configuring their own machines as they like. That is not what I am asking. I'm not sure what you're asking then. The username is logged as "anonymous" because the user has typed in "anonymous". FreeRADIUS logs what the NAS and the client send.

If you don't accounting packets to contain "anonymous" you can: * reject their authentication. * configure your NAS to send something more meaningful

There's no secret SQL query - if the user sends "anonymous", and your NAS is configured to use that "anonymous" in accounting, then FreeRADIUS will log "anonymous", and any SQL query will return "anonymous".

If explain your problem further (e.g. why is correlating the Calling-Station-ID in accounting logs to the one in your auth log insufficient) people can probably help further - but you've given precious little information.

Regards,

Adam Bishop

gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

On 05.02.2017 16:10, Phil Mayers wrote:

As a couple of people have noted, if the NAS supports it you can (in order of preference):

1. Return User-Name in Access-Accept which a compliant NAS will then copy to Accounting-Requests

2. Abuse Class in Access-Accept e.g. set it to "user=<name>" then extract that in preacct{} and rewrite the received username in the accounting packets

3. If the NAS sends Acct-Session-Id in Access-Requests, cache or store these in a DB, then do a cache/SQL lookup in preacct{} to find the username from authentication, and rewrite the accounting. You could hack this with NAS-IP-Address & Calling-Station-Id if you're really desperate and the Acct-Session-Id isn't present in Access-Request.

Done it in post-auth. Thank you.

If none of these options are available, then you will need to perform offline or near-realtime analysis of your accounting to match auth to acct sessions and discover the real username. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus