I'm not sure what you were told, but the users being member of a group, and that group being referenced in SSLVPN policies, should be sufficient to allow a user to authenticate. There was a bug in some early 6.4 versions where SSLVPN users would sometimes only match into one group even though they were member of several. The authentication/portal mapping is only important to determine what portal a user matches into; they do not impact if a user is allowed to authenticate in the first place or not.
If you are not on the newest 6.4 version, perhaps an upgrade would help.
How SSLVPN authentication works in general: https://community.fortinet.com/t5/FortiGate/Technical-Tip-A-quick-guide-to-FortiGate-SSL-VPN-authent...
If you still have the issue post-upgrade, I would suggest gathering this debug in CLI:
#dia de reset
#dia de app sslvpn -1
#dia de app fnbamd -1
#dia de en
Then try to log in, wait 30s, end debug:
#dia de dis
#dia de reset
That debug should show:
- the SSLVPN connection attempt
- authentication against remote authentication servers (if there are any)
- observed group memberships
- successful authentication via specific group and portal
That should give you some idea if the issue is with group memberships not being observed properly, an unintended portal is being matched, or what might be going on.
+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++