Hello Erik, Thanks for your feedback. I will open a WSA support case as you suggested. Regards ... View more

Hi Jennie, Thanks a lot for this feedback. Can you provide a more precise answer than "before too long" ? Can I expect the GA to be delivered before the end of July ? end of August ? This 7.5 release is in FCS since the 6th of March, so since more than 3 months now. Usually, your FCS releases never last more than one month, what is causing such delays here ? Are you facing some troubles with it ? Regards ... View more

Hello Stephan, What is the last status regarding asyncos 7.5 release ? Is it still in FCS or is it finally in General Availability. I see that the release note has changed since 18th June, the tag FCS has disappeared but I still do not see it in GA and I did not receive any notification regarding this. Cisco IronPort AsyncOS 7.5 for Web Security Appliance Cisco IronPort AsyncOS 7.5.0 Release Notes for Web Security Appliances (PDF - 410 KB) New! 18/Jun/2012 Regards ... View more

Hello Ken, Satish Great news so if it is in the roadmap. Thanks a lot for your feedback Regards ... View more

Hello Ken and thanks for your last feedback. I'm aware of this AD Agent but I think it still does not match my requirements. Tell me if I'm wrong, this is what is new with the AD Agent : - you can identify users by an authenticated user name transparently when using Active Directory with an NTLM authentication realm. - previously (pre 7.5), you could only identify users by their source IP address (IP Address Surrogate) when using AD with an NTLM authentication realm. Surrogate by persistent or session cookies may also be an option too but with limitations for HTTPS / FTP and other applications like messengers, updaters, ... As you said, the current version of the AD Agent still requires a trust relationship between all of the domains touched. Now let's take the following example : - customer A is authenticating its users through an AD (realm A) using NTLM authentication with Single Sign On. - recently customer A acquired a new branch office (customer B) using its own AD (realm B) and also using NTLM SSO - both AD do not have any relationship at all between them but the customer still wants to authenticate ALL the users from realms A & B through the same WSA using NTLM SSO. Please note that this example is something that can be seen quite often. I can list at least 4-5 customers who required me such configuration in the past year. -> If I understand well, this configuration is not possible with a Cisco WSA. As you said, at the root, this is a Windows limitation on client side, preventing a Windows box to authenticate against more than one domain. But this limitation is ONLY on the client side. Some others products (Bluecoat proxy through BCAAA agent : no limitation at all, McAfee Web Gateway : limited to 10 realms) are able to answer these requirements but I guess this is because they developped this feature internally on their proxy appliances. Is there a chance to see this feature also on Cisco WSA in the future ? ... View more

Well... there is something I don't understand here. Is there really a Microsoft limitation on this point ? I mean, with Bluecoat proxies for example, you can interact with as many domains as you want through their BCAAA agent. Same thing with McAfee Web Gateway, there is no limitation at all. What is exactly so different with wsa ? ... View more

Why can't I join my wsa with more than one domain, this is exactly what I'm trying to understand. Is there a good reason for such limitation ? ... View more