SA4500 Best Practice

[ghuber_]

Hello All,

I recently took over the support of a couple SA4500s. After looking over the current configuration, I found the previous administrator created a lot of different user realms. Truthfully, I'm not sure of the reason... sign-in policies and pre-auth checks are the same on all realms.

Anyway, I was thinking of consolidating all different user realms into one in order to simplify administration. Then, instead of configuring a new sign-in policy, user realm and role each time someone I need to configure a new portal page, I can just configure a new user role and assign it to the consolidated user realm.

From your experience, is this the way to go? Or should I just leave it alone?

Also, is there are really a difference between pre-auth host checks on the user realm and post-auth host checks on the role?

Finally, does anyone know of a best practices guide?

[zanyterp_]

No, there is no best practices guide; you can ask 10 admins and receive 20-30+ answers. :/

As far as the initial question, there is no "right or wrong" way to do it. If you would feel more comfortable with a more consolidated config, go for it; if you want to work on doing that over time, that works too.

I don't know what your user base is, but this _may_ change the user interaction and that is something to keep in mind with making this type of change (or roll it out slowly....)

From the perspective of Host Checker, there is no difference; just user experience. When you have pre-auth checks (require & enforce on the realm) users must pass the checks prior to seeing the login page (no pass, no login attempt for that realm). When you have post-auth, evaluate on the realm and require on the role, users have the option to provide credentials at all time and once they have said they have persmission to login, the endpoint compliance is verified for access you grant them.

Does that help?

[ghuber_]

Yes, that helps, thanks.

Another question -- The previous admin made separate realms for Windows and Mac users. I assume this is because he was applying host checker policies at the realm level and did not want the Mac users to be checked. If I consolidate all my user realms into one and control the enforcement of the host checker policies at the user role level, the evaluation occurs at post-auth, as does the enforcement. If I did not want any evaluation to occur for Mac clients, this would be a problem, because there is not way to disable evaluation (as it occurs before the application of the user role), right?

Also, how does the host checker treat Mac clients since they do not use anti-virus? The current anti-virus rule for Mac in our Junipers appears to just check to see if the Safari web browser process is running. I don't see much value in that.

[srigelsford_]

Hi,

I would only use extra realms for:

- using a different auth server

- Using different Host Checker Policies

- Using different role mapping

Otherwise they can be condensed. You can of course run one hostcheker policy to check different things on Macs vs Windows, just use the tabs in the hostchecker policy. HC is clever enough to only apply mac rules to a mac etc.

Yes Macs can (and should) run antivirus, they currently have security by obscurity and that is changing as they grow in popularity. Granted it is more secure than windows it is far from perfect. Take a look at the below.

http://www.theregister.co.uk/2008/12/02/apple_mac_av_advice/_

Hostchecker is far more basic for Mac and Linux, and can only check the existance (or non existance) of a file, a running process, or an open port. So it can only check for AV if you configure it manually. To check for AV I would point the Host Checker at the signatures file, and select the option 'file must have changed no more than x days' to check that the signatures are up to date.

You're right, checking Safari is runing seems like a complete waste of time to me... It sounds as though the last admin was looking for a way to run hostchecker that would always pass - (s)he could have just disabled hostcheker for that realm.

Cheers,
Sam.

JNCIS-FWV JNCIS-SSL JNCIS-ER JNCIS-SEC