Technical Tip: How to use multiple groups with EAP for IKEv2 (SAML/RADIUS/local)
Description
This article describes how EAP functionality on FortiOS can match multiple groups against a remote authentication source when reading multiple groups from the firewall policy instead of the group configured under the phase 1 setting of the dial-up tunnel.
Scope
FortiGate v7.0 and later.
Solution
While configuring EAP authentication for dial-up on FortiGate, there are two ways to match the users with the proper groups:
Match the group on the phase 1 setting with the 'set authusrgrp'.
Match the groups on the firewall policy for the IPsec tunnel created.
With option one, the group is matched to the tunnel using the authusrgrp configuration:
config vpn ipsec phase1-interface
edit “EAP-Dialup”
set eap enable
set eap-identity send-request
set authusrgrp "Dialup-EAP-1"
next
end
Note:
In FortiOS v7.4 and earlier versions, the 'eap' and 'authusrgrp' settings in the phase1 configuration of IPsec VPN are only available in CLI. Starting FortiOS v7.6.1, this setting is available on the GUI.
On GUI:
VPN -> VPN Tunnels -> Under the Authentication section, enable EAP. -> Specify the User Group (authusrgrp) in the assigned field.
This forces the EAP to match only this group with the group information sent back by the authentication daemon (FNBAMD), resolved from the authentication source for this group:
ike 2:EAP-Dialup:2324: responder received AUTH msg
ike 2:EAP-Dialup:2324: processing notify type INITIAL_CONTACT
ike 2:EAP-Dialup:2324: processing notify type FORTICLIENT_CONNECT
ike 2:EAP-Dialup:2324: received FCT data len = 216, data = 'VER=1
FCTVER=7.0.8.0427
UID=229FFF9C465245AE89C50465329BAA6F
IP=172.17.98.29
MAC=00-15-5d-62-10-06;
HOST=DESKTOP-TN8MVD5
USER=test1
OSVER=Microsoft Windows 8.0 Professional Edition, 64-bit (build 9200)
REG_STATUS=0
'
ike 2:EAP-Dialup:2324: received FCT-UID = 229FFF9C465245AE89C50465329BAA6F
ike 2:EAP-Dialup:2324: peer identifier IPV4_ADDR 172.17.98.29
ike 2:EAP-Dialup:2324: re-validate gw ID
ike 2:EAP-Dialup:2324: gw validation OK
ike 2:EAP-Dialup:2324: responder preparing EAP identity request
ike 2:EAP-Dialup:2324: enc
ike 2:EAP-Dialup:2324: remote port change 500 -> 4500
ike 2:EAP-Dialup:2324: out
ike 2:EAP-Dialup:2324: sent IKE msg (AUTH_RESPONSE): 172.17.97.77:4500->172.17.98.29:4500, len=128, vrf=0, id=d86d633374d189ed/e970a9c56b9f5c28:00000001
ike 2: comes 172.17.98.29:4500->172.17.97.77:4500,ifindex=5,vrf=0....
ike 2: IKEv2 exchange=AUTH id=d86d633374d189ed/e970a9c56b9f5c28:00000002 len=80
ike 2: in ike 2:EAP-Dialup:2324: dec
ike 2:EAP-Dialup:2324: responder received EAP msg
ike 2:EAP-Dialup:2324: send EAP message to FNBAM
ike 2:EAP-Dialup:2324: initiating EAP authentication
ike 2:EAP-Dialup: EAP user "test1"
ike 2:EAP-Dialup: auth group Dialup-EAP-1
ike 2:EAP-Dialup: EAP 961302487 pending
In the highlighted sections above, it is shown how EAP sends the user information provided by the user and the group configured under the authusrgrp to the FNBAMD for authentication. After successful authentication by the FNBAMD daemon, the EAP receives this information back and initiates the mode config, and afterward, the phase 2 negotiation:
fnbamd_dbg_hex_pnt[48] EAP msg from server (4)-03 84 00 04
[1548] fnbamd_auth_handle_radius_result-->Result for radius svr 'eap_proxy' 127.0.0.1(1) is 0
[1623] fnbam_user_auth_group_match-req id: 961302487, server: eap_proxy, local auth: 0, dn match: 0
[1581] __group_match-Group 'Dialup-EAP-1' passed group matching
[1584] __group_match-Add matched group 'Dialup-EAP-1'(20)
[292] find_matched_usr_grps-Passed group matching
[209] fnbamd_comm_send_result-Sending result 0 (nid 0) for req 961302487, len=2544
[808] destroy_auth_session-delete session 961302487
ike 2:EAP-Dialup:2324 EAP 961302487 result FNBAM_SUCCESS
ike 2:EAP-Dialup: EAP succeeded for user "test1" group "Dialup-EAP-1" 2FA=no
[1086] fnbamd_ext_idps_destroy-
ike 2:EAP-Dialup:2324: responder preparing EAP pass through message
ike 2:EAP-Dialup:2324: enc 00000008038400040706050403020107
ike 2:EAP-Dialup:2324: out ike 2:EAP-Dialup:2324: sent IKE msg (AUTH_RESPONSE): 172.17.97.77:4500->172.17.98.29:4500, len=80, vrf=0, id=d86d633374d189ed/e970a9c56b9f5c28:00000004
ike 2: comes 172.17.98.29:4500->172.17.97.77:4500,ifindex=5,vrf=0....
ike 2: IKEv2 exchange=AUTH id=d86d633374d189ed/e970a9c56b9f5c28:00000005 len=112
ike 2: in ike 2:EAP-Dialup:2324: dec ike 2:EAP-Dialup:2324: responder received AUTH msg
ike 2:EAP-Dialup:2324: auth verify done
ike 2:EAP-Dialup:2324: responder AUTH continuation
ike 2:EAP-Dialup:2324: authentication succeeded
ike 2:EAP-Dialup:2324: responder creating new child
Therefore, the firewall policies matched afterward can only match one group, and, in this case, no user group on the firewall policy is needed, as the group is already matched by EAP.
Important note:
The two options are not compatible. When a user group is configured on both phase1-interface and on a firewall policy handling VPN user traffic, the policy cannot be matched and the authentication fails with the traffic being dropped by the policy 0 and the debug flow showing the 'iprope_in_check() check failed on policy 0, drop' message.
This behavior is a result of 2 authentication requirements configured.
The first authentication required is from phase 1, where the group is mapped.
The second authentication required is from the group mapped to the Firewall policy. Since the user authenticates one time, the condition of the Firewall policy is not fulfilled, FortiGate sends this session to the implicit policy.
Therefore, only one of these ways needs to be set, with the second one (authgroup set on policy) being the most flexible.
In certain designs, the requirement is to match different groups with different firewall policies. In that case, option 2 needs to be utilized. With option 2, EAP does not have any groups to match, and the authusrgp configuration is blank/not set.
In this case, the FNBAMD daemon will feed the groups to EAP to match.
Configuration:
config vpn ipsec phase1-interface
edit “EAP-Dialup”
set eap enable
set eap-identity send-request
set authusrgrp ''
next
end 
In the firewall policy, the source IP needs to be set to 'all' to trigger the authentication and successfully connect to the VPN.
As authentication takes place before IP assignment during IPsec VPN negotiation, while using EAP with IKEv2, utilizing the IPsec VPN address range can lead to a discrepancy in the firewall policy, causing it to be bypassed.
Diagnostics:
FCTVER=7.0.8.0427
UID=229FFF9C465245AE89C50465329BAA6F
IP=172.17.98.29
MAC=00-15-5d-62-10-06;
HOST=DESKTOP-TN8MVD5
USER=test1
OSVER=Microsoft Windows 8.0 Professional Edition, 64-bit (build 9200)
REG_STATUS=0
'
ike 2:EAP-Dialup:2354: received FCT-UID = 229FFF9C465245AE89C50465329BAA6F
ike 2:EAP-Dialup:2354: peer identifier IPV4_ADDR 172.17.98.29
ike 2:EAP-Dialup:2354: re-validate gw ID
ike 2:EAP-Dialup:2354: gw validation OK
ike 2:EAP-Dialup:2354: responder preparing EAP identity request
ike 2:EAP-Dialup:2354: enc ike 2:EAP-Dialup:2354: remote port change 500 -> 4500
ike 2:EAP-Dialup:2354: out ike 2:EAP-Dialup:2354: sent IKE msg (AUTH_RESPONSE): 172.17.97.77:4500->172.17.98.29:4500, len=128, vrf=0, id=957b6705876342b8/da0f7d93618c13eb:00000001
ike 2: comes 172.17.98.29:4500->172.17.97.77:4500,ifindex=5,vrf=0....
ike 2: IKEv2 exchange=AUTH id=957b6705876342b8/da0f7d93618c13eb:00000002 len=80
ike 2: in ike 2:EAP-Dialup:2354: dec
ike 2:EAP-Dialup:2354: responder received EAP msg
ike 2:EAP-Dialup:2354: send EAP message to FNBAM
ike 2:EAP-Dialup:2354: initiating EAP authentication
ike 2:EAP-Dialup: EAP user "test1"
ike 2:EAP-Dialup: auth candidate group 'Dialup-EAP-1' 20 --> candidate group received from firewall policy list
ike 2:EAP-Dialup: auth candidate group 'Dialup-EAP-2' 21 --> candidate group received from firewall policy list
ike 2:EAP-Dialup: EAP 961302496 pending
After reading each group from the firewall policy list, EAP then proceeds to send them back to FNBAMD for further authentication. After successful authentication, the FNBAMD sends back the matched group to EAP:
fnbamd_dbg_hex_pnt[48] EAP msg from server (4)-03 A6 00 04
[1548] fnbamd_auth_handle_radius_result --> Result for radius svr 'eap_proxy' 127.0.0.1(1) is 0.
[1623] fnbam_user_auth_group_match-req id: 961302496, server: eap_proxy, local auth: 0, dn match: 0
[1581] __group_match-Group 'Dialup-EAP-1' passed group matching
[1584] __group_match-Add matched group 'Dialup-EAP-1'(20)
[292] find_matched_usr_grps-Passed group matching
[209] fnbamd_comm_send_result-Sending result 0 (nid 0) for req 961302496, len=2544
[808] destroy_auth_session-delete session 961302496
[1086] fnbamd_ext_idps_destroy-
ike 2:EAP-Dialup:2354 EAP 961302496 result FNBAM_SUCCESS
ike 2:EAP-Dialup: user 'test1' authenticated group 'Dialup-EAP-1' 20
ike 2:EAP-Dialup:2354: responder preparing EAP pass through message
ike 2:EAP-Dialup:2354: enc 0000000803A600040706050403020107
ike 2:EAP-Dialup:2354: out 9
As a result of the above functionality, the multiple groups on the firewall policy can be used to separate different groups’ traffic from one another:
Here is an example of user test1 belonging to the Dialup-EAP-1 group matching policy ID 13:
Here is an example of user test2 belonging to the Dialup-EAP-2 matching policy ID 14:
In the above, local authentication using local users on FortiGate has been utilized, which simplifies the group matching. In the following sections, the two different remote authentication sources of EAP are explained and outlined. The configuration on the phase 1 setting of the Dialup server (FortiGate) is the same across. The only difference is how the group matching occurs.
RADIUS:
Using RADIUS, the RADIUS server (for example, NPS) needs to be configured with the proper VSA attributes to send back to the FortiGate for group matching. Then, different user groups on the firewall can be used to match against different attributes. Here is one example of using a Microsoft NPS server: Technical Tip: Configuring FortiGate and Microsoft NPS (Radius with AD authentication).
LDAP:
LDAP authentication with IKEv2 is supported in FortiClient v7.4.3 and later and requires specific FortiClient XML configuration as shown in the FortiClient v7.4 New Features Guide. Multiple firewall group matching configurations for LDAP are similar to RADIUS.
SAML:
Using SAML with EAP, which is supported as of FortiClient v7.2.4/v7.4.0 and FortiGate v7.2.4. The process is the same as RADIUS, with the difference that the SAMLD daemon on the firewall needs to receive the proper group attribute from the IDP and process it to FNBAMD.
The configuration for SAML and EAP is explained in the articles below.
However, if multiple group matching needs to be implemented, multiple user groups on the firewall need to be matched with different group attributes with the IDP and authusrgrp configuration needs to be blank as discussed above: SAML-based authentication for FortiClient remote access dial-up IPsec VPN clients.
Diagnostics:
diagnose vpn ike log-filter dst-addr4 x.x.x.x
diagnose debug console timestamp enable
diagnose debug application authd 60
diagnose debug application fnbamd -1
diagnose debug application ike -1
diagnose debug application samld -1
diagnose debug application eap_proxy -1
diagnose debug enable For v7.4.0 and above, there is a slight change to the command, as shown below:
diagnose vpn ike log filter rem-addr4 x.x.x.x
diagnose debug console timestamp enable
diagnose debug application authd 60
diagnose debug application fnbamd -1
diagnose debug application ike -1
diagnose debug application samld -1
diagnose debug application eap_proxy -1
diagnose debug enable
To stop the debugging:
diagnose debug disable
diagnose debug reset
Combining multiple remote authentication servers:
Configuring a RADIUS server together with other authentication sources on the same IKEv2 dial-up gateway is not supported. See Technical Tip: IKEv2 dialup gateway with RADIUS user groups does not support other authentication servers.
To support RADIUS authentication sources with SAML, LDAP, or other RADIUS servers: use a dedicated dial-up gateway for each RADIUS server and use network-id to identify the intended IKEv2 dial-up gateway. For more information on network-id, see Technical Tip: FortiGate Hub with multiple IPSec Dial-up phase1 using IKEv2 and PSK authentication.
Note:
With IKEv2, Extended authentication (XAUTH) is not available. EAP (Extensible Authentication Protocol) needs to be enabled for a similar functionality of XAUTH for IKEv2 dial-up tunnels. EAP uses many schemes for authentication i.e., CHAP, MSCHAP, MSCHAP2. The RADIUS server can easily support these schemes.
However, there is no standard for EAP and LDAP, and most LDAP servers do not support EAP. If a FortiGate uses LDAP for user authentication, neither CHAP, MSCHAP, nor MSCHAP2 can be used.
The reason is that during CHAP, MSCHAP, and MSCHAPv2 authentication, a client sends a one-way hash of the password.
However, LDAP servers expect passwords in clear text.
The FortiGate, which is acting as the LDAP client, does not have the user passwords, nor can it convert a hashed password to a clear-text password.
LDAP-based user authentication only works with XAUTH and only supports IPsec IKEv1 by design.
If it is required to use IKEv2, there are two options:
Migrate to use RADIUS-based user authentication with EAP.
Use EAP-TTLS to support LDAP user authentication.
For an explanation of EAP-TTLS, see this document: EAP-TTLS support for IPsec VPN.
See this article for instructions on how to configure IKEv2 with LDAP using EAP-TTLS: Technical Tip: IKEv2 dial up VPN with LDAP authentication.
To implement EAP-TTLS, there are some requirements.
FortiClient version 7.4.3 and later;
FortiClient EMS v7.4;
IKEv2 tunnel (works with IKEv2 over UDP or TCP).
Using a FortiToken with EAP-TTLS is supported starting in v7.4.4. The free 7.4.3 FortiClient will be unable to connect if tokens are enabled: Technical Tip: Multi-Factor Authentication support for Windows FortiClient with LDAP (EAP-TTLS).
Related documents:
Technical Tip: A guide to Dial-Up IPSec VPN Authentication and Policy Matching
Technical Tip: IKEv2 dialup IPsec tunnel with Radius server authentication and FortiClient
Troubleshooting Tip: for using Ikev2 for dialup Ipsec tunnel with radius server and Local user
Technical Tip: How to enable EAP-TTLS for IPSec IKEv2 tunnels in VPN-only (unlicensed) FortiClient
Technical Tip: IKEv2 tunnel fails when LDAP based usergroup is used for EAP