WiFi with WSSO using Windows NPS and FortiGate Groups

Facebooktwittergoogle_plusredditpinterestlinkedinFacebooktwittergoogle_plusredditpinterestlinkedin

This is an example of wireless single sign-on (WSSO) with a FortiGate. The WiFi users are students at a school. These users belong to a Windows Active Directory (AD) group called WiFiAccess. When users enter their WiFi username and password, the FortiGate checks the local group WiFi. Since the group has been set up with remote RADIUS server, the FortiGate performs user authentication against the Network Policy Server (NPS) or RADIUS server. If the user is authenticated successfully, the FortiGate will check for a policy that allows the WiFi group access.

There is an alternative way to setup WiFi with WSSO. To learn more about it, see WiFi with WSSO using Windows NPS and Attributes

1. Registering the FortiGate as a RADIUS client on NPS

From the NPS, right click on RADIUS Clients,  and create an entry for the FortiGate. Enter the FortiGate’s IP address. Enter the Shared secret (password).

2. Creating a Connection Request Policy

Right click Connection Request Policies under Policies and select New. Leave default values for Overview and Settings tab. Under Conditions tab, enter Client IPv4 Address as the FortiGate’s IP address.

3. Creating a Network Policy

Right click Network Policies under Policies and select New to create a new policy. Leave default values in Overview tab. In Conditions tab, click on Add, select Windows Group, then select Add. Finally Add Groups, then enter WiFiAccess, and select OK.
In Constraints tab, under Authentication Methods, click Add, then select Microsoft: Protected EAP (PEAP) then OK. Next select Microsoft Encrypted Authentication version 2 (MS-CHAP-v2), and finally select User can change password after it has expired and select OK.

4. Configuring FortiGate to use the RADIUS server

On the FortiGate, go to User & Device > RADIUS Servers. Select Create New DC-RADIUS. Enter the Domain Controller IP address and the Server Secret that you entered on NPS. Optionally, you can click Test Connectivity. Enter a RADIUS user’s ID and password. The result should be “Successful”.

5. Configuring a user group on the FortiGate

Go to User & Device > User Groups. Create a group named WiFi. Click on Create New under Remote groups, then enter DC-RADIUS for Remote Server, and Any for Groups. Select OK, and OK again.

6. Creating an SSID with RADIUS authentication

Go to WiFi & Switch Controller > SSID. Create an SSID and set up DHCP for clients.
Set WPA2-Enterprise with Local authentication, and choose the local group WiFi.

7. Creating a security policy

Go to Policy & Objects > IPv4 Policy. Create a WiFi-to-Internet policy. Use WiFi group as the Source.

8. Results

Connect to the WiFi network, authenticate, and browse the Internet. Try this with a user that belongs to the WiFiAccess Windows AD Group.
Go to Monitor > Firewall User Monitor. You can see the User Name, User Group and verify that WSSO authentication Method was used.
Juan Parra

Juan Parra

Network Support Engineer at Fortinet
Juan Parra is part of the Technical Assistance Center (TAC) team in Vancouver. He has a M.Sc. in Electrical Engineering: Digital Communications from Laval University. He also holds CCNA and CWNA certifications.
Juan Parra
  • Was this helpful?
  • Yes   No
  • Javier

    Hello Juan,

    I have tried to follow your post but I am unable to get users correctly authenticated.

    The only different thing I have used is that when I define RADIUS server in step 4, I have specified that RADIUS request are coming from fortigate Lopback IP address (also defined in NPS server)

    I see in the NPS logs (Windows Server 2012) that customer is Granted Access and also seen in the firewall with sniffer packets the RADIUS Accept Messages but client is not authenticated only the get typical Windows error (RADIUS certificate validation is unchecked in client side)

    Enable station logs and RADIUS logs I only see the following logs

    [866] find_matched_usr_grps-Skipped group matching
    [180] fnbamd_comm_send_result-Sending result 0 (error 0) for req 998970747
    [606] destroy_auth_session-delete session 998970747
    91960.600 CLIENT-MAC-ADDRESS RADIUS message (type=0) <== RADIUS Server code=11 (Access-Challenge) id=97 len=190
    91960.601 CLIENT-MAC-ADDRESS send IEEE 802.1X ver=2 type=0 (EAP_PACKET) data len=144
    91960.601 CLIENT-MAC-ADDRESS IEEE 802.1X (EAPOL 148B) ==> CLIENT-MAC-ADDRESS ws (0-AP_IP-ADDRESS:15246) rId 0 wId 4 AP-MAC-ADDRESS
    24658.609 CLIENT-MAC-ADDRESS cwAcProcInputLocalMsg: cwAcKernDataDelSta failed CLIENT-MAC-ADDRESS rId 0 wId 4

    Thanks in advanced

    Javi

  • Ryan Tanjuakio

    Hi Juan,

    Just have some questions, hope you already encountered this scenario.. 1.) What if I have a core switch (Cisco 3850) where all the VLANS are assigned? 2.) We want FortiAP to broadcast only 1 SSID, but specific users shall obtain per department VLAN assignments? could this will work? Thanks in advance!

  • Mariano Sanchez Z.

    Hello Juan!

    Nice post! congratulations!

    I just have 2 questions regarding this cook recipe:

    1. If I use NPS to authenticate AD users from the wireless network:

    * Do I need to install a certificate on each wifi client??

    * What happens with computers which are not part of the AD environment but they want to authenticate to the wireless network with valid AD credentials?

    2. What happens if I have mixed technology; multiple FortiAPs aswell third party vendors APs??

    * Could I manage to accomplish on both types of APs throuhg Windows NPS and FortiGate policys?

    Thanks in advance!

    • Juan Parra

      Hi Mariano

      1a. You don’t need to install a certificate for each computer if you use the AD local certificate.
      1b. You may use a different SSID with WPA2 personal as authentication for those users.
      2. You can only manage FortiAPs with the FortiGate, but other vendors cannot be managed. Remember the authentication is managed through the SSID.

      Best regards,

      Juan