In the environment, it is one company with many AD domains. There is a business need to make sure that users in one domain cannot access resources in another. The current SSLVPN set up is as follows:
Fortigate has an LDAP server defined for each domain. The Fortigate has a firewall group linked to distinguished name of a group in the AD domain. The group then has a dedicated VPN portal, dedicated IP range, and dedicated policies that define what resources it can access. This is done for each domain.
The customer has added some new requirements:
1. Two Factor Authentication (via Fortitoken)
2. Additional domains (this puts us above the 10 LDAP server limit in Fortigate)
I'm doing a PoC of Fortiauthenticator and Fortitoken and have hit a wall. I've completed the following:
-FAC connects to LDAP server.
-Imported user from LDAP as a remote user.
-Created group and added the remote user. We'll call the group "corp"
-The test user has been assign a Fortitoken.
-Fortigate was configured as a RADIUS client.
On the Fortigate:
-Set up the FAC as a RADIUS server.
-Set up a firewall group called "corp" that uses the FAC as the remote server and specifies the group "group"
-Created a VPN portal and IP range.
-Created a VPN authentication rule mapping the group to the portal.
-Set up policies allowing the IP range and group access to the resources.
When trying to connect:
-I enter user ID & password with domain\user (with domain being a realm on FAC with a matching name)
-I get prompted for the OTP
-Upon entering the OTP from Fortitoken, VPN progresses to 45% then fails with "access denied -455"
The logs on the FAC show the authentication attempt as successful both via LDAP and Fortitoken.
The logs on the Fortigate show the connection attempt as "sslvpn_login_permission_denied"
Thoughts?
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Sounds like you haven't configured the RADIUS Attribute. To send the group attribute to FGT, edit the Group on FAC and add the Fortinet-Group-Name attribute. This is documented on p.18 of the Interop Guide.
Dr. Carl Windsor Field Chief Technology Officer Fortinet
You should try the test diag authserver commands imho
e.g
diag test authserver ldap
if this passes, than you can see what happens on the 2FA
for the fortiToken you can also run diagnostics via the debug command to see what happening ;
diag fortitoken debug enable
Now back to multidomains are these hosted on the same AD server(s)? I think there's a better method for doing what your doing that might be simpler like using a loopback and a portal+ipvv4 address per customer with a simple FortiAuth+token and Group imho
ken
PCNSE
NSE
StrongSwan
I'll check the diag commands on Monday. That being said, logs on the FAC show authentication via LDAP and the Fortitoken as successful. Logs on the Fortigate shows authentication as successful via the FAC. Just that the now successfully authenticated user is not allowed access to the VPN.
I *think* the issue is that I'm not making it to the correct group on the Fortigate. I've defined the group as:
config user group
edit "fac-corp"
set member "fac-radius"
config match
edit 1
set server-name "fac-radius"
set group-name "GROUP" <---- I think somehow this is not matching up with the "GROUP" group on the Fortiauthenticator that contains the LDAP users.
Multiple domains: Domain 1, lives on its own DCs. Domain 2, lives on its own DCs. They don't talk, they don't share resources. They don't even know each other exists. It's like that for all the domains. The only exception is there is a shared resource domain that all domains have a two-way trust with. Domain1 <---> SharedDomain & Domain2 <---> SharedDomain, but the trust is not transitive. Thought of trying to just do it all through SharedService domain with THOSE groups, but FAC would still need to authenticate to the individual domains.
Use the net user /domain <username> from a cmd.exe and see what groups the user account has.
You can also use one of the diag test authserver ldap- options for querying the group(s). This should match the net user /domain output and validate the FGT has the right permission and bindings for LDAP.
The group has to match in order for the user to be accepted and allowed.
PCNSE
NSE
StrongSwan
Sounds like you haven't configured the RADIUS Attribute. To send the group attribute to FGT, edit the Group on FAC and add the Fortinet-Group-Name attribute. This is documented on p.18 of the Interop Guide.
Dr. Carl Windsor Field Chief Technology Officer Fortinet
I tried specifying the Fortinet-Group-Name attribute earlier. With that specified, I don't get prompted for the OTP, it fails with "access denied -455" without even asking for the OTP.
It's a late post and I had same issue and resolved it. -455 on the FAC logs reflect that the token is out-of-sync and I re-synced the token to fix the issue.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1692 | |
1088 | |
752 | |
446 | |
228 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.