RADIUS Wifi authentication for both domain (PC) and non-domain (smartphone) devices

[Eaux_de_Vienne]

Hello,

We're setting up RADIUS authentication for wireless network connections through a Windows Server 2012 R2 (NPS).

We have to allow both domain computers (registered in Active directory) and non-domain devices, typically Android smartphones.

Following this official documentation, the behaviour is as excepted and working fine for domain computers.

Now, we would like to set up mac address authentication for Android devices, also based on Active directory. Following several posts on this subject (like this one), we have created AD users with name and password being the mac address without colons or blank spaces (ie: bc4101d16900). We have then created another network policy within NPS configuration relative to the AD Security group containing the 'Android users'. This new policy differs from the computers policy in making reference to the 'Android users' Windows Group and not the computers Windows Group.

I'm eventually wondering if such a double authentication system is possible with a Fortigate firewall (mac-address for Android devices and computer name for domain PCs). I attach a picture showing both an overview of NPS configuration for Android devices and a smartphone screenshot when attempting to connect to the SSID.

Thanks for help or ideas!

Thomas Williamson

[xsilver_FTNT]

I'm not sure I do understand the role of FGT here. Is it WLC (wireless controller) or even AP (access point) ? Is the FGT in role on NAS (network access server) so the one who originates authentication towards NPS (Windows) ? If you authenticate users on some 3rd party WLC, and FGT is just network gateway and firewall,  then how about to utilize FSSO ? For example via standalone Collector Agent installed on DC, which will gather all the domain user logons. And that same Collector can read, or FGT itself can read, RADIUS Accounting requests from NAS (alternatively if NPS is set to send accounting, but NAS as WLC is supposed to send accounting), and make those to user logons transformed to FSSO records (usually is this called RSSO as RADIUS based SSO) and based on those data (especially source IP and group membership) you can drive/govern access to protected resources.