Skip to main content
Stuart_Kendrick
New Member
March 30, 2020
Solved

no valid user or group candidate found

  • March 30, 2020
  • 1 reply
  • 12278 views

Would anyone have a mental model to offer for what the SSL VPN feature is doing when it is 'checking rules'?  I'm trying to spin up an SSL VPN service, using the heavy FortiClient, the client sees "Permission denied".  The relevant output of "diagnose debug application sslvpn -1" looks as follows:

 

[...]

2020-03-30 09:04:15 [22521:root:2]sslvpn_auth_check_usrgroup:2039 forming user/group list from policy. 2020-03-30 09:04:15 [22521:root:2]sslvpn_auth_check_usrgroup:2145 got user (0) group (1:0). 2020-03-30 09:04:15 [22521:root:2]sslvpn_validate_user_group_list:1642 validating with SSL VPN authentication rules (1), realm (). 2020-03-30 09:04:15 [22521:root:2]sslvpn_validate_user_group_list:1690 checking rule 1 cipher. 2020-03-30 09:04:15 [22521:root:2]sslvpn_validate_user_group_list:1698 checking rule 1 realm. 2020-03-30 09:04:15 [22521:root:2]sslvpn_validate_user_group_list:1709 checking rule 1 source intf. 2020-03-30 09:04:15 [22521:root:2]sslvpn_validate_user_group_list:1730 checking rule 1 source address. 2020-03-30 09:04:15 [22521:root:2]sslvpn_validate_user_group_list:1963 got user (0:0), group (0:0) peer group (0). 2020-03-30 09:04:15 [22521:root:2]no valid user or group candidate found.

 

What is the Firewall doing when it is 'checking rule 1 cipher' ... 'checking rule 1 source address'?

 

 

The larger 'diag debug' output looks as follows:

 

2020-03-30 09:04:15 [22521:root:2]SSL state:SSL negotiation finished successfully (96.93.107.34) 2020-03-30 09:04:15 [22521:root:2]SSL established: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 2020-03-30 09:04:15 [22521:root:2]req: /remote/info 2020-03-30 09:04:15 [22521:root:2]req: /remote/login 2020-03-30 09:04:15 [22521:root:2]rmt_web_auth_info_parser_common:470 no session id in auth info 2020-03-30 09:04:15 [22521:root:2]rmt_web_get_access_cache:804 invalid cache, ret=4103 2020-03-30 09:04:15 [22521:root:2]User Agent: FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}]) 2020-03-30 09:04:15 [22521:root:2]get_cust_page:130 saml_info 0 2020-03-30 09:04:15 [22521:root:2]req: /remote/logincheck 2020-03-30 09:04:15 [22521:root:2]rmt_web_auth_info_parser_common:470 no session id in auth info 2020-03-30 09:04:15 [22521:root:2]rmt_web_access_check:723 access failed, uri=[/remote/logincheck],ret=4103, 2020-03-30 09:04:15 [22521:root:2]User Agent: FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}]) 2020-03-30 09:04:15 [22521:root:2]sslvpn_auth_check_usrgroup:2039 forming user/group list from policy. 2020-03-30 09:04:15 [22521:root:2]sslvpn_auth_check_usrgroup:2145 got user (0) group (1:0). 2020-03-30 09:04:15 [22521:root:2]sslvpn_validate_user_group_list:1642 validating with SSL VPN authentication rules (1), realm (). 2020-03-30 09:04:15 [22521:root:2]sslvpn_validate_user_group_list:1690 checking rule 1 cipher. 2020-03-30 09:04:15 [22521:root:2]sslvpn_validate_user_group_list:1698 checking rule 1 realm. 2020-03-30 09:04:15 [22521:root:2]sslvpn_validate_user_group_list:1709 checking rule 1 source intf. 2020-03-30 09:04:15 [22521:root:2]sslvpn_validate_user_group_list:1730 checking rule 1 source address. 2020-03-30 09:04:15 [22521:root:2]sslvpn_validate_user_group_list:1963 got user (0:0), group (0:0) peer group (0). 2020-03-30 09:04:15 [22521:root:2]no valid user or group candidate found. 2020-03-30 09:04:15 [22521:root:2]req: /FortiClientSslvpnClearCacheUrl/for/Wini 2020-03-30 09:04:15 [22521:root:2]def: (nil) /FortiClientSslvpnClearCacheUrl/for/WininetLibrary/1/2/3/4/5/6/7/8/9/0/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t

 

FortiClient 6.2.6 / FortiOS 6.2.3

 

--sk

    Best answer by Toshi_Esumi

    I don't think any public doc explaining how SSL VPN is built to work in the FGT.

    Then what's in "config user group" and "edit "Telecommuter VPN Users""? Only one LDAP server is in?

    Did you test the LDAP server from the FGT? Is it pingable from the FGT? If it's reachable, you can test with a set of valid <username><password> below:

        diag test authserver ldap "Telecommuter VPN Users" "<username>" "<password>"

    If you want to see how the test exchange is happening, you can do below:

        diag debug reset

        diag debug console timestamp enable

        diag debug application fnbamd -1

        diag debug enable

     

    I'm guessing the problem is reachability though.

    1 reply

    Toshi_Esumi
    SuperUser
    SuperUser
    March 30, 2020

    What's configured under "config vpn ssl settings", especially under "config authentication-rule"? It doesn't seem to be able to find a group or members of the group.

    Stuart_Kendrick
    New Member
    March 30, 2020

    config vpn ssl settings

    [...]

        config authentication-rule         edit 1             set source-interface "wan1"             set source-address "FortiVPN-Interface"             set groups "Telecommuter VPN Users"             set portal "Full-Tunnel Service"             set auth ldap         next     end

     

    I see ... you are suggesting that this section of 'diag debug' walks through a number of lines ... I'm not sure where to look for cipher or realm ... but in my case, they seem to 'pass' these checks

     

    ==> Do know where this work-flow might be documented?  [Or do I need access to source to document that?  :) ]

     

    Then

    checking rule 1 source intf ==== set source-interface 'wan1'

    checking rule 1 source address ==== set source-address "FortiVPN-Interface"

    got user (0:0), group (0:0) peer group (0) ===== set auth ldap

    no valid user or group candidate found.

     

    So ... if I'm following your thinking here ... you are suggesting that 'set auth ldap' doesn't behave the way the Firewall wants

    ==> How might I increase the verbosity of debugging at this point, to dig deeper into what the Fortigate is doing when it logs the 'got user ...' line?

     

    --sk

    Toshi_Esumi
    SuperUser
    SuperUser
    March 30, 2020

    I don't think any public doc explaining how SSL VPN is built to work in the FGT.

    Then what's in "config user group" and "edit "Telecommuter VPN Users""? Only one LDAP server is in?

    Did you test the LDAP server from the FGT? Is it pingable from the FGT? If it's reachable, you can test with a set of valid <username><password> below:

        diag test authserver ldap "Telecommuter VPN Users" "<username>" "<password>"

    If you want to see how the test exchange is happening, you can do below:

        diag debug reset

        diag debug console timestamp enable

        diag debug application fnbamd -1

        diag debug enable

     

    I'm guessing the problem is reachability though.