hI,
I am running a FortiGate with Fortios 6.4 version. I have the firewall synced with my AD, this is working so I can see username and stats from my AD users in the Fortiview pages.
I want to configure a policy (is for browsing navigation allowed) only for a group of my AD users, but when I try to configure 'Source' in the policy, and select the group in the list, I get this error.
I ge this error: 'One address, address group, external resource or Internet service is required'
As far as I understand, this means I can't create a policy that only is applied to a single group of users? There is no way to for example allow browsing to one group members and to forbide browsing to all other users?
Thanks a lot.
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.
Dear Servei,
yes, for this kind of policy you have to add users AND source adress in the Source field.
Add both and it will work.
Your Welcome
sudo apt-get-rekt
Hi,
if you have a policy like depicted, with both source-IP (IP/Subnet/Range object defined) AND user group. Then BOTH of those "conditions" have to be met.
Obviously alongside of rest of the 5-tuple - so Destination port and network, and Service as well.
However, pay attention to what king of user group is selected!
Because users needs to be somehow authenticated.
Therefore group type is VERY important element here.
User groups based on locally defined users, or LDAP/RADIUS/TACACS based users are not known to FortiGate (FGT hereinafter). And so called "active" authentication is triggered. Think about it as about captive portal (which is another alternative authentication set-able per ingress interface, not by policy matters). And important part is that pure IP-based firewall policies do have preference over identity based with active authentication.
Therefore if there will be pure IP-based firewall policy, similar in source/destination port/network and service setup, but WITHOUT user group.
Then this identity based policy WITH user group will never match (no matter of its position in policy list)!
As user is not know when policy evaluation goes through first stage.
However that is different story for FSSO type of user groups, as those are so called "passive" authentication. And user details are well known to FGT once user authenticates to let's say his Windows Workstation (and details about user are passed through FSSO mechanisms down to FGT). As user details are known, then those can be used in policy evaluation (in contrast to groups based on active authentication), and so that user group and policy will match, and its position against pure IP-based policies WILL MATTER.
Hint: If you do have FSSO and would like to have a fallback for those who are not known through FSSO as authorized users. For example for initial deployment, to let users pass and see which workstations/users are not matching and falls through, to sort those later on. You can use similar firewall policy, bellow all FSSO identity based ones, with built-in special group named "SSO_Guest_Users". As that group matches everyone as if he is known through FSSO. So logging of such policy matches and handling those who fall through that SSO_Guest_Users group is highly recommended.
To build FSSO, I'd suggest to use standalone FSSO Collector Agent + WinSec WMI + Advanced mode on the agent's config. As it's IMHO entry level to FSSO, still very capable and free of charge agent. Should you need more, like building FSSO records based on Syslog messages, or RADIUS Accounting, or scale your FSSO more, then I'd suggest to have a look on FortiAuthenticator. That's paid product, but far more then just FSSO, as it's truly centralized enterprise grade authentication point with much more then FSSO to offer.
More on FSSO on https://docs.fortinet.com
Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff
Dear Servei,
yes, for this kind of policy you have to add users AND source adress in the Source field.
Add both and it will work.
Your Welcome
sudo apt-get-rekt
Thanks @Hosemacht ,
This means that if I add both into Source (as in image) this means that Policy is only allowing the users that accomplish BOTH conditions?
Thanks a lot
Hi,
if you have a policy like depicted, with both source-IP (IP/Subnet/Range object defined) AND user group. Then BOTH of those "conditions" have to be met.
Obviously alongside of rest of the 5-tuple - so Destination port and network, and Service as well.
However, pay attention to what king of user group is selected!
Because users needs to be somehow authenticated.
Therefore group type is VERY important element here.
User groups based on locally defined users, or LDAP/RADIUS/TACACS based users are not known to FortiGate (FGT hereinafter). And so called "active" authentication is triggered. Think about it as about captive portal (which is another alternative authentication set-able per ingress interface, not by policy matters). And important part is that pure IP-based firewall policies do have preference over identity based with active authentication.
Therefore if there will be pure IP-based firewall policy, similar in source/destination port/network and service setup, but WITHOUT user group.
Then this identity based policy WITH user group will never match (no matter of its position in policy list)!
As user is not know when policy evaluation goes through first stage.
However that is different story for FSSO type of user groups, as those are so called "passive" authentication. And user details are well known to FGT once user authenticates to let's say his Windows Workstation (and details about user are passed through FSSO mechanisms down to FGT). As user details are known, then those can be used in policy evaluation (in contrast to groups based on active authentication), and so that user group and policy will match, and its position against pure IP-based policies WILL MATTER.
Hint: If you do have FSSO and would like to have a fallback for those who are not known through FSSO as authorized users. For example for initial deployment, to let users pass and see which workstations/users are not matching and falls through, to sort those later on. You can use similar firewall policy, bellow all FSSO identity based ones, with built-in special group named "SSO_Guest_Users". As that group matches everyone as if he is known through FSSO. So logging of such policy matches and handling those who fall through that SSO_Guest_Users group is highly recommended.
To build FSSO, I'd suggest to use standalone FSSO Collector Agent + WinSec WMI + Advanced mode on the agent's config. As it's IMHO entry level to FSSO, still very capable and free of charge agent. Should you need more, like building FSSO records based on Syslog messages, or RADIUS Accounting, or scale your FSSO more, then I'd suggest to have a look on FortiAuthenticator. That's paid product, but far more then just FSSO, as it's truly centralized enterprise grade authentication point with much more then FSSO to offer.
More on FSSO on https://docs.fortinet.com
Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff
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 |
---|---|
1647 | |
1070 | |
751 | |
443 | |
214 |
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.