AsyncOS 5.6.0 for Web is now Generally Available

Unanswered Question
Oct 21st, 2008

I am pleased to announce the "GA" release of 5.6.0. Code named "Maui" internally, this release is primarily focused on core proxy functionality. We have had great feedback from our beta testers and early adopters. I encourage customers to give 5.6.0 a try.

A few notes:

We have changed the way policies work and also added a new authentication layer called "identities". After upgrade we strongly recommend customers verify the post upgrade configuration to ensure policies and identities have been migrated appropriately to match your business needs.

If HTTPS was enabled and then is disabled at the time of upgrade, any archived decryption policies will not be maintained during the upgrade.

To enhance the security of the WSA, we explicitly prevent the WSA from proxying requests on the P2 interface. Customers who need this functionality may want to wait for the 5.6.2 release, which will support this configuration.

New Features in 5.6.0

* New Feature: Multi-core scanning (for improved performance)
* New Feature: Time-based policies for URL filtering
* New Feature: Enhanced routing policies (failover, load balancing, and conditional routing to multiple upstream proxies)
* New Feature: User-agent based policies
* New Feature: Policy trace tool
* New Feature: Custom EUN pages
* New Feature: SNMP enhancements (SNMPv1, 2, and 3, with support for traps and community strings)
* New Feature: Transparent bypass list
* New Feature: PAC file hosting
* New Feature: Active mode FTP over HTTP
* New Feature: GUI-based packet capture

Let us know what you think.

Regards,

Chris Haag
Manager, Technical Support

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
jowolfer Wed, 10/22/2008 - 16:37

Thanks for the heads up. The 5.6 release is great! I'm enjoying the new Identity policies.

It does take getting used to, but in the end, you have much better control over authentication.

thomascollins Tue, 11/04/2008 - 21:58

Agreed, 5.6 is excellent.

One comment about identities: Shouldn't the users be listed in the identity, not the Access Policy? For example, all my users come from a domain called CORP.

Then let's say I need an Access Policy that lets CORP\spresley get to financial sites. Then other Access Policy that lets CORP\jsmith get to streaming sites.

I need two identical identity policies that just say the authentication is CORP. Then in the access policies I limit the users. It would seem the user limiting should be done in the Identity Policy.

Looking forward to Continue Pages in 6.0

Doc_ironport Wed, 11/05/2008 - 19:28

I need two identical identity policies that just say the authentication is CORP.  Then in the access policies I limit the users.  It would seem the user limiting should be done in the Identity Policy.


No, you only need one identity! In fact, if you've got 2 identities which are the same then the 2nd one will never actually match.

Identities and Access Policies are both a top-down, first match - with identities done first. So in your case you'd need one identity matching the domain CORP, and then in the access policy you can further limit that since identity based on the username.

Processing-wise it will do a top-down match on the identity to find the first match (your CORP identity) and then do a top-down match in the access policies to find a policy based on the CORP identity which matches the extra criteria you've added (ie, specific users/groups).

You can certainly end up in a situation where you can implement the same rules in a few different ways through a mixture of identities/policies, but at the end of the day it probably doesn't matter how you do it - pick whichever makes most sense for you!
thomascollins Wed, 11/05/2008 - 20:09

No, you only need one identity! In fact, if you've got 2 identities which are the same then the 2nd one will never actually match. 


For some reason my experience doesn't match.

Right now everything is working correctly, using two different identity policies (both using the CORP domain). I just tried changing both access policies to use a single identity, and it no longer matched. Access Policy #1 gets skipped. Only when I changed it back to using two identity policies did it work again.

I've got another support ticket in right now regarding the policy trace not working correctly. Maybe once that is resolved I'll put in a support ticket about this problem.

Actions

This Discussion