RADIUS authentication request must contain specific attributes

[TheOnlyJames]

Question on Radius policy,  I have a FortiGate connected to a FAC for 2 sets of users (both using the same LDAP source)  One set is using a policy, that requires chained authentication, (RSA Token server) and that policy is at the top and it works fine, 

I added a second policy, as I want WIFI users to authenticate with AD if they are in the WIFI Group, so I created a 2nd policy and placed it above, with the a matching radius attribute of SSID = "MYSSID" My question is, when someone connects to this SSID, does it send this radius attribute? or do I have to tell the gate to send this attribute ? I cant test this from the Gate, as you can add radius attributes in the "test autheserver radius etc etc"  or can you?

[ebilcari]

Yes, the RADIUS Access-Request coming from FGT/FAP will have this attribute (more details here:(
Fortinet-SSID = "A-Por"

than can be used as matching criteria in the RADIUS policy.

[TheOnlyJames]

OK, that's fine then, I am still having issue using RADIUS with WPA2 enterprise with the FAC, its constantly saying "client-disconnected-by-wtp" and "unspecified reason" I wanted to test something, the policy is fine them... i just dont know why the client wont connect using the FAC, if i send a "test authsever radius" with AD creds on the gate it authenticates no issues, but we cannot get SSID to work with WPA2 and FAC

[ebilcari]

This may be the AP disconnecting the host for a WiFi signal/roaming issue or the authentication times out. You can verify authentication results and timing through the RADIUS logs from the FAC or from the FGT by enabling the following debug:

diag debug app eap_proxy 31
diag debug console time enable

[TheOnlyJames]

The logs don't get as far as the FAC, the Gate just has:

Auth-req

Auth-resp

Assoc-req

Assoc-resp

then client disconnected.

[ebilcari]

In this case it seems like the supplicant in the end host is not properly configured. For example, if the supplicant doesn't trust the server certificate it will refuse to send the credentials and initiate the authentication.

[Toshi_Esumi]

I believe it would work as @ebilcari is saying. But in the worst case if it doesn't work, you can always create a new radius (config user radius) at the FGT then set a bogus nas-ip different from the original one for the WiFi usergroup then use it for WiFi user policy. We're using this method for different realms of SSL VPN user groups (not FAC's realm) with FAC to separate policies on the FAC side.

Toshi 

[TheOnlyJames]

The issue isnt so much the usergroups, its WPA2 and FAC, the AP never sends the RADIUS request to the FAC, and I dont know why.

[Toshi_Esumi]

Oh, are you saying your AP is not FortiAP, in which case the RADIUS requests are not sent by the controller FGT, not directly by the FAP? If that's the case, it wouldn't send the FTNT vendor-specific attribute.
But if that's the case, the source IP or nas-ip must be naturally different from the FGT's, which the FAC can separate them with the policies.

Toshi

[TheOnlyJames]

it is a FortiAP yes, controlled by the Fortigate. The policy works fine, but the WPA2 doesnt when using the FAC, PSK is fine