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

Rule for FSSO into AD must have object ANY as well as the AD Group (See Screenshot)

I will try to make this brief. We have FSSO working against our Active Directory in order to pull groups that we use to establish the level of web filtering for a particular group. An example would be where the network and firewall teams can reach site: "almost whatever we want" whereas the Warehouse and Marketing personnel can only reach sites related to their specific job function. This works great for us since the HD is responsible for the group memberships so we change nothing during the on-boarding process. The thing is tho every year the Auditors that come in here ding us because the rule has the word "ALL" in there as the source address and we have to convince them that it's not really "ALL", it's only members of that AD group (fsso.profile.branch in the example below) that will match on that policy and be granted that level of access and not ALL devices in our company.. If it were ALL then no rules below this would be processed for 80 and 443 traffic so they should know better.....

 

So, we recently upgraded to 7 code, and after yet another audit of explaining why the rule says ALL, I went into the policy today and tried to remove ALL and it of course produced an error... I then changed it to a group we have called: "All User VLANs" and hit OK (fully expecting it to fail with the error: "Address ALL is Required") but this time it accepted it?!?!?!

 

Anyone have any idea when that may have changed? And, by changing it to the object group housing all the user VLAN's will it will work as expected? I believe so since my rule has received hits since I changed it and the Helpdesk isn't screaming at me so its maybe okay. I welcome any and all input on this one because I've been saying for years now that this is a requirement (and even had a conversation with support about it while working another issue) and the even worse news is that Ive looked back several rev's Release Notes and am seeing nothing about it so am almost in need of a xanax to calm the nerves over it a little tbh...

rule.ad.group.png

 

1 Solution
Debbie_FTNT
Staff
Staff

Hey fcb,

I think there's a slight misunderstanding going on with the 'source' options.

You have two separate objects in there - an address ("ALL", meaning all IPs, or "all user vlans", I assume a group of all user subnets), and a group

-> there is a logical AND between those, meaning anyone trying to match the policy has to match the address condition (ALL, or whatever address object you have set) AND the group condition (belong to at least one of the group(s) referenced in the policy).

 

This means:

- you cannot remove the 'ALL' address object, only replace it with a different address object

-> at least one address object is required!

- this behavior has not changed in any way in any recent firmware versions. I assume you removed the 'ALL' address object and tried to save, and this failed? and later removed the 'ALL' object, and added a different address object instead (all user vlans) and then saved successfully?

 

In case of the 'ALL' address object, and the group object, this means the user might have any IP address (as all IP addresses are allowed), but still is required to be a member of the group as well.

I hope that clarifies this a bit!

+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++

View solution in original post

3 REPLIES 3
Anthony_E
Community Manager
Community Manager

Hello fcb,


Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.


Thanks,

Anthony-Fortinet Community Team.
Debbie_FTNT
Staff
Staff

Hey fcb,

I think there's a slight misunderstanding going on with the 'source' options.

You have two separate objects in there - an address ("ALL", meaning all IPs, or "all user vlans", I assume a group of all user subnets), and a group

-> there is a logical AND between those, meaning anyone trying to match the policy has to match the address condition (ALL, or whatever address object you have set) AND the group condition (belong to at least one of the group(s) referenced in the policy).

 

This means:

- you cannot remove the 'ALL' address object, only replace it with a different address object

-> at least one address object is required!

- this behavior has not changed in any way in any recent firmware versions. I assume you removed the 'ALL' address object and tried to save, and this failed? and later removed the 'ALL' object, and added a different address object instead (all user vlans) and then saved successfully?

 

In case of the 'ALL' address object, and the group object, this means the user might have any IP address (as all IP addresses are allowed), but still is required to be a member of the group as well.

I hope that clarifies this a bit!

+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++
fcb

Debbie_FTNT,

 

Thank you very much for yet another great and very informative reply that could not be more spot on in this situation. With that said, I am certain that at one point the rule with the AD groups as I've outlined required ALL specifically, but this could have been literally FortiOS from years ago dating back possibly to when this feature was first released, or maybe I done exactly as you outlined... Regardless of that, the main point that I am trying to drive home here is the fact that no matter what address object is in there (ALL or a single IP) the user connecting MUST be on an endpoint falling within that address range, AND must also be a member of the Active Directory group to which the rule is also pointing as you clearly explain with your post:

 

In case of the 'ALL' address object, and the group object, this means the user might have any IP address (as all IP addresses are allowed), but still is required to be a member of the group as well.

 

 

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors