I am just beginning to setup our ironports for our organization. I am trying to gather high level understanding of how the ironports interact with our ldap servers.
If I want to setup 1000 different users on an ironport S360 using ldap. I want to setup about 10 - 15 different security profiles with regards to web filtering. I want each manager to be able to choose the correct profile or profiles for each user in his/her department. I want to use basic ldap authentication to identify each user.
I have read most of the docs for AsyncOS 5.6 the Web Security Appliances. However, it is still unclear to me the correlation between Realms, Group Authorization and Access Policies.
How would I go about doing that? I would like to leverage our ldap servers as much as possible since we are already using that for our company.
Also what purpose do the Security Management Appliances server. We currently are not deploying any C-series ironports only S-series.
Your post seems to indicate that you will have alot of rules that need to be created. It's always key to remember that each additional rule will create more overhead for the WSA to process, so writing the rules efficiently (as few as possible) is something to plan ahead for.
You have 10 to 15 managers that have to create policies for their group. There are a couple ways to write your policies.
If there is a static policy that can be used across the board for the majority of your users (default policy), you should use the default policy for the majority of your users and then create exception rules above it.
Exception rule1: User1 is allowed to everything Exception rule2: Group1 is allowed to a few bad sites. Default policy: block bad sites, allow good sites
If each of your managers requires to write very customized polices for their individual users, You'll probably need to write your rules in the following fashion:
Exceptions: Manager1: User (or multiple users), specific block / allow list Manager1: group (or multiple groups), specific block / allow list Standard rules Manager1: All manager1 users: Default rule for Manager 1's group
Exceptions: Manager2: User (or multiple users), specific block / allow list Manager2: group (or multiple groups), specific block / allow list Standard rules Manager2: All manager2 users: Default rule for Manager 2's group
As you can see, the second method will be much more expensive. If there is a way to implement the first method, processing and rule maintenance will be alot easier.
Don't forget that our Sales Engineer team specializes in different deployments and rules creation and will assist you in this process during your initial setup./
======================== SMA ========================
The SMA is used for config management / duplication across multiple WSAs. If you only have a single WSA, the SMA will have no use for you at this time.
In the future, the SMA will also be a centralized reporting server for the WSAs.
Thanks for the reply. That summary was very helpful. However, this means the LDAP is only used for authentication purposes? and nothing else?
The managers really do not have to create policies for each user. I want managers to assign them from a pre-designated list. For example: a. policies: b. very restrictive c. restrictive d. somewhat restrictive e. non-restricted
Then have a manager in sales assign: user1 -> policy a user2 -> policy b user3 -> policy c ....
I am trying to make the user setup as painless as possible since I have lots of users to deal with. I really don't see myself doing data entry for 900+ users.
From the manual page 355 of WSA 6.0.0 manual
Choose whether or not to enable LDAP group authorization. When you enable LDAP group authorization, you can group users by group object or user object.
The way you are trying to setup your policies make sense to me. The only way to avoid adding 900 users (split into the 5 some odd rules or restrictiveness), is to use LDAP groups with the policies.
The effectiveness of this will depend solely on how your LDAP directory has your users divided into logical groups.
For example, in Active Directory all users are by default part of the "Domain Users" group. So you could just assign "Domain Users" to your rule and all 900 users would match that rule. This obviously won't work for what you're trying to do, because you want more granular restrictiveness.
Here is one way to simplify it on the WSA (assuming these groups existed in your LDAP directory).
WSA access policy:
1. very restrictive = ldap group membership "Very Restricted" 2. restrictive = ldap group membership "Restrictive" 3. somewhat restrictive = ldap group membership "Somewhat Restrictive" 4. non-restricted = ldap group membership "Non-restricted"
That's all you'd need to do on the WSA configuration. In your LDAP directory, you'd need all of your uses that you want 'very restricted' to all contain the group membership object for "Very Restricted".
You'd still need to create these groups in your LDAP structure and assign the appropriate users to them, but it'd make the WSA configuration alot easier.
You could even create WSA-specific groups in your LDAP tree, such as "WSA restrictive" or "WSA Non-Restrictive".
I had one further thought and that is that you should know that if one of your users exists in multiple LDAP groups, such as "restricted" and "not restricted", the rule order of your access policies will be the deciding factor.
Each rule in the WSA is evaluated in order. First match wins. For this reason, it's also recommended to have your most common rule first (other then exceptions to this common rule - they need to be above).
Other then that, I don't think you'll run into any surprises.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :