Skip to main content
kenm30018
kenm30018
New Member
July 28, 2020
Question

SSLVPN User not able to authenticate

  • July 28, 2020
  • 1 reply
  • 8355 views

I'm trying to set up a user to be able to login to an SSLVPN portal with the FortiAuthenticator, and I believe I've got things set up correctly, but the Authenticator logs show:

 

Remote LDAP user authentication with email token failed: user not filtered by groups

And I'm not sure if that means on the FortiAuthenticator or on the FortiGate unit. The user is a remote user and is in a group on the FortiAuthenticator. I also have a group on the FortiGate, so I'm not sure where I'm going wrong.

 

Thanks,

Kenn

    1 reply

    xsilver_FTNT
    Staff
    xsilver_FTNT
    Staff
    September 21, 2020

    If log message is from FortiAuthenticator (FAC) as it seems to me, then it speaks about FAC. If you do have users from LDAP, then how you gave them to FortiGate (FGT)? Via RADIUS ?

    If RADIUS is between FGT and FAC (usual setup), then FAC has LDAP as backend.

    And if LDAP is backend then how it's connected to RADIUS Clients setup on FAC ?

     

    If it's pure 'realm' used in FAC > Authentication > RADIUS Service > and clients config , simply pointing to LDAP, then how you have tokens bonded ? As you spoke about tokens then I guess you synced/imported users from LDAP to FAC, equipped them with tokens, or set to use email token. So you should have those users grouped on FAC user group. Then RADIUS Client with LDAP realm have to have the group filter enabled and this group used.

    This way will FAC read data about synced users from FAC, based on group membership and state of user on FAC (and users are usually synced via Remote User Sync Rules as Remote Users). This way will FAC check known users, and not just proxy auth requests from RADIUS to LDAP. More details on where, in which phase auth fail would make a situation a bit more clear.

    kenm30018
    kenm30018Author
    New Member
    November 10, 2020

    Thank you for the help. As it turned out, I had the same RADIUS client (FortiGate firewall) in two different policies in the FAC. And since the policy the users were trying to connect from was lower than the other, it didn't work. Once I moved the policy for the users above the other, they were able to connect. Of course, there's now the issue of the lower policy still not working.

     

    I was going to try using group name filters, but I'm not sure how to get it to work. I'm trying to use the same RADIUS Service Policy to allow FortiGate administrators to log in to manage the firewall as well as to allow employees to connect to the SSL-VPN on the same firewall without giving them administrator access. I think I'm going about it the wrong way. I'm gonna just try to do some reading in the Cookbooks, but in the meantime if there's something glaringly wrong, here's the setup I currently have:

     

    [ul]
  • There are remote users in FAC that are pulled from Windows AD.
  • The FortiToken is set at the remote user's account in FAC.
  • I have local FAC groups that I put the remote users in.
  • In the RADIUS service policy, I have the realm set to the Windows AD.
  • In the Groups filter in the RADIUS policy, I have set the FAC groups that I want to filter by.
  • In the firewall group, I set the Remote Authentication Server to the FAC and set the Group Name to one of the groups in the FAC RADIUS policy.[/ul]

     

    Not sure where I'm going wrong. I'm going to look at the documentation a bit more to see if I can figure it out. Also, the FortiGates are on 5.6.13.

     

     

     

     

    • xsilver_FTNT
    Staff
    xsilver_FTNT
    Staff
    November 11, 2020

    Little hint here:

    - capture RADIUS traffic for auth

    - pay attention to Connection-Info I think is the right AVP

    - you should note that admins and ssl-vpn users do have slight difference

    - now that can be used in RADIUS Service Policy (in older FAC it was Profiles) to be applied on specific requests based on received AVPs and values in those

     

    I guess it might solve your need to have more than one type of users and distinguish between policies from a single source (FGT).  

    Terms & ConditionsAccessibility statement