Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
serveiwebs
New Contributor II

To apply a policy for a user group obtained from AD integration

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'

USERGROUPS.png

 

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.

2 Solutions
Hosemacht
Contributor II

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

View solution in original post

sudo apt-get-rekt
xsilver_FTNT

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 stuff - TAC Staff Engineer

View solution in original post

3 REPLIES 3
Hosemacht
Contributor II

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

sudo apt-get-rekt
serveiwebs
New Contributor II

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?

USERGROUPS.png

Thanks a lot

xsilver_FTNT

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 stuff - TAC Staff Engineer

Labels
Top Kudoed Authors