In short your observation is correct, it seems that NPS is not able to enhance Accounting-Request packets and add Class into them.
In a bit longer, and with more details from my testing:
NPS does NOT send Accounting-Request packets to FGT on it's own, but is able to resend those if set to "Forward accounting requests to this remote RADIUS server
group" in Connection Request Policies
NPS do NOT respect, or use, what's set in Connection Request Policies / Settings / RADIUS Attributes
. And those AVPs are NOT attached to forwarded accounting requests.
Those AVPs ARE USED and added to Access-Accept when NPS does accept Access-Request and validates user credentials OK.
Therefore, if your WLC (wireless controller / access point) does authenticate users against NPS, and so collect Access-Accept, WITH AVPs like Class containing right string (the one used in firewall group and sso-attribute-value on FGT).
Then this WLC should transfer Class AVP from received Access-Accept to newly formed Accounting-Request Type=Start.
Then NPS can/will forward it to FGT. However in this point I do not see any reason why not send it directly to FGT.
When I used NTRADPing tool to send crafted Accounting-Request type=start to NPS, and that one contained Class="VIP", Framed-IP-Address=10.10.10.1 + User-Name="usera".
Then this one was forwarded to set FGT with those AVPs kept intact.
Config on FGT to receive RSSO data (+ allowaccess radius-acct on port) as bellow:
config user radius
set rsso enable
set rsso-radius-response enable
set rsso-endpoint-attribute User-Name <<< to have usernames, not MAC addresses in log and SSO user list
config user group
set group-type rsso
set sso-attribute-value "VIP" <<< default sso-attribute in "RSSO" above is Class AVP
And then 'diag test app radiusd -1
Received radius accounting eventvd 0:root Add/Update auth logon for IP 10.10.10.1 for user usera
DB 0 insert [ep='usera' pg='VIP' ip='10.10.10.1/32'] success
FGT# diag test application radiusd 3
RADIUS server database [vd root]:
"index","time left","ip","endpoint","block status","log status","profile group","ref count","use default profile"
And so, forwarding works. And if WLC would copy Access-Accept Class to Accounting-Request, it would work.
Or if we will find a way how to convince NPS to add AVPs to Accounting data, or originate it's own Accounting-Request Type=Start once it sends out Access-Accept. But that is most likely by design, as NPS is RADIUS server, while Accounting should be sent from NAS which is in this case your WLC.
It seems there is not much in Accounting handling on NPS.
Latest MSFT doc I found .. https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-accounting-configure
Tried to google around, but haven't found much either.
If you have FortiAuthenticator (FAC), by any chance, then it seems to me solvable this way.
Where FAC will acct as RSSO receiver / Collector, gather Accounting data from WLC and enhance those with group membership of the user (acquired from RADIUS User-Name in Accounting) from AD via LDAP(S), and then sending those complete SSO data to FGT.
Simple RSSO can be achieved by standalone Collector Agent, but so far it sort of refuses to resolve groups for me. Not quite sure if it's intended limitation or if I made a config mistake. Both possible.