s360 and ldap

itjack_ironport · ‎08-18-2009

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.

Thanks in advance

-itjack

jowolfer · ‎08-19-2009

IT Jack,

Your setup will look something like this:

------------------------------------------
LDAP Authentication Realm
------------------------------------------

This will identify the appropriate settings to authenticate against your LDAP server. You will configure the appropriate schema attributes for your users and groups.

Creating the auth realm only identifies that authentication may be done using LDAP with the configured settings, it does not enable authentication for your users.

------------------------------------------
Identity Policy
------------------------------------------

In order to use authentication, you'll need to create an Identity Policy. The Identity policy will specify to authenticate using the LDAP realm you previously created.

Typically, all of your clients should hit a single Identity that references your LDAP realm. All other Identities will be exceptions, such as "do not authenticate for subnet X" identity policies.

The Identity policy only specifies that users are going to need to authenticate.

------------------------------------------
Access Policy
------------------------------------------

In order to create differing rules based upon user and group membership, you'll need to create Access policies.

The Access policy will be linked to your Identity policy that uses the LDAP realm.

In each Access policy you can reference any number of users or groups that will apply to the Access policy.

------------------------------------------
Ideal rules setup
------------------------------------------

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.

Example:

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.

itjack_ironport · ‎08-19-2009

Josh,

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.

Could I leverage the group object somehow?

Thanks in advance

itjack

jowolfer · ‎08-20-2009

IT Jack,

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".

itjack_ironport · ‎08-20-2009

Josh,

Thanks. That is exactly what I wanted to hear.

That will make configuration a lot easier.

Now I just have to implement it, but I wanted a high level understanding of what I needed to do.

Regards,

ITjack

jowolfer · ‎08-21-2009

Great! Glad to help.

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.