help required - freerdius 3 - accounting to fortigate - user group name not received on fortigate

[Eby Mani]

 Many thanks Alan for detailed explanation, really appreciate.

Changing "inner-tunnel" value to "if (1) {" did the trick.

Two questions for my understanding, Would "use_tunneled_reply = yes" in peap section of eap.conf, do the same without changing values in "inner-tunnel" "if (0) {" ?.

Are there any other mechanisms for wireless 802.1x that don't require "inner-tunnel' ?.

Thanks,
     On Saturday, 11 March, 2023, 06:56:52 pm IST, Alan DeKok <aland at deployingradius.com> wrote:  
 
 On Mar 11, 2023, at 12:42 AM, Eby Mani via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> Sorry about that, i followed https://wiki.freeradius.org/guide/Users-Mailing-List, and don't have a clue what is useless packets that need to be removed when submitting.

  The point is that you give relevant information.  We've seen people run the server for 15 minutes, and post a 10M debug output.

>> So... you didn't configure the server to to add the Fortigate attributes?
>> If you had done that, the debug log would show it adding the Fortigate attributes.
> 
> No, fortigare specific attributes were not configured on FR2.

  It helps to describe what you're doing.  Your first message was little more than "I did stuff and it didn't work".  This message is much better,

> Wireless system does 802.1x auth against freeradius, freeradius sends accounting packets to fortigate lan port, fortigate is configured for RSSO, read user-name, client ip and user group(Class) from radius accounting packets.

  OK, that's clear.

> On mysql, radgroupreply table have the following values.
> +----+------------------+-----------+----+------------------+
> | id | groupname | attribute | op | value |
> +----+------------------+-----------+----+------------------+
> | 1 | PG_Management | Class | = | pg_management |
> | 2 | PG_Support | Class | = | support_team |
> | 3 | Managers | Class | = | full_access |
> | 4 | Employees | Class | = | medium_access |
> | 5 | Projects | Class | = | res_access |
> | 6 | Temp_Workers | Class | = | low_access |
> | 7 | devices | Class | = | servers_only |
> +----+------------------+-----------+----+------------------+
> 
> My understanding is FR3 should send attributes, values, etc.. in radgroupreply, back / to other accounting servers by default. i don't know if this is happening or not.

  First: No, that isn't what FreeRADIUS is supposed to do, ever.  And you can read the debug output to see what FreeRADIUS is actually doing.  While the debug output has a lot of information, you can generally ignore most of it, and look for the pieces you're interested in:

* is the SQL module being run?

* is the radgroupreply being used?

* does the Access-Accept contain the correct Class attribute?

  That's what's supposed to happen.

  Then, the NAS is supposed to echo that Class into an Accounting-Request packet for that user.  So...

* when FreeRADIUS receives an Accounting-Request packet for that user, does it contain the same Class as was sent in the Access-Accept?

  So you don't need to read the entire debug output.  The https://wiki.freeradius.org/guide/radiusd-X page also describes this.

  Instead, load the debug output into a text editor, and search for keywords.  Look for "Access-Accept", and then look in the attributes listed there for "Class".  It's that easy,

  From the debug log you posted earlier:

(1) sql: EXPAND SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = '%{SQL-Group}' ORDER BY id
(1) sql: --> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'PG_Support' ORDER BY id
(1) sql: Executing select query: SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'PG_Support' ORDER BY id
(1) sql: Group "PG_Support": Merging reply items
(1) sql: Class = 0x737570706f72745f7465616d

  So that's good.

(9) Sent Access-Accept Id 19 from 172.16.2.214:1812 to 10.225.251.10:64545 length 0
(9) MS-MPPE-Recv-Key = 0x0f229aef6322ceca75f6735555c314608b6e198cdfbdf1326b5e71f9da77fb8c
(9) MS-MPPE-Send-Key = 0x28ddede674364b53a7782a458a36d399c3f819beac51c8c5e7b296975ff731e3
(9) EAP-Message = 0x030a0004
(9) Message-Authenticator = 0x00000000000000000000000000000000
(9) User-Name = "wireless_admin"

  And the Class is missing.  So don't bother looking at the accounting packets until it returns Class in the Access-Accept.

  So why is Class missing?  Look earlier in the debug log for Class...

(8) } # server inner-tunnel
(8) Virtual server sending reply
(8) Class = 0x737570706f72745f7465616d
...
(8) User-Name = "wireless_admin"

  So the Class is present in the "inner-tunnel" virtual server.  The solution then is to get the Class from the inner-tunnel to the final Access-Accept.  And reading the "inner-tunnel" virtual server gets you this:

    #
    #  Instead of "use_tunneled_reply", change this "if (0)" to an
    #  "if (1)".
    #
    if (0) {

  Change that (and read the rest of the comments to understand why), and it should work.

  Alan DeKok.