AsyncOS 5.6.2 has been temporarily removed from our download servers. Support for NTLM Mode authentication was inadvertently removed from this release. Customers who need access to the fixes in 5.6.2 can request provisioning to 5.6.2 by contacting IronPort customer support. There is a work around available for customers who can switch to ADS mode NTLM authentication, documented in Knowledge Base article 1283. We will re-release 5.6.2 before the end of January 2009. The re-release will contain support for Domain mode NTLM authentication and bring in a fix to a vulnerability in the FreeBSD SSL libraries concerning DSA keys.
Customers who have already upgraded to 5.6.2 without issue are unaffected, the problem only affects users of Domain based NTLM authentication; for these customers NTLM authentication fails after upgrade. We have pulled the release to ensure customers who have not yet upgraded do not experience issues.
As always, we welcome your feedback here.
Manager, Product Support
First of all thanks to those people who decided that it's better to remove this buggy release from the upgrade server at this time.
Although the given workaround is pretty easy (I fully agree) it's not acceptable that such a simple bug was not found by IronPort internal QA. This is really a simple thing to test and I guess that many of your customers are still using NTLM for authentication.
How do you wanna bring back trust to customers that have now serious concerns about the quality of IronPort internal QA processes?
BTW: when talking about NTLM authentication. Will that release (5.6.x) be able to work together with Windows Server 2008? I have still not read an official statement from IronPort saying that NTLM Auth is now supported with Windows Server 2008 as well.
Thanks for your answer!
You raise some valid concerns, gsc and I think it is important to address them as directly as I can.
(1) QA not identifying the regression prior to GA
(2) Communication process around the defect
(1) Quality Assurance:
We take a lot of pride in our Quality Assurance (QA) processes and in the quality of the code we release. Issues like this get a lot of visibility and are taken very seriously by the entire organization. With maintenance releases, there is a balance between the need to get fixes delivered quickly and making sure those fixes do not create any issues or regressions. To maximize effectiveness and efficiency, our QA team prepares test plans for "maintenance releases" that focus largely on the features which saw new or modified code. Generally, we have had good success with this approach and feel it provides the right balance between time to release and thoroughness. In this instance there was an unidentified dependency with Domain Mode authentication and one of the fixes. Of course, our QA team is re-examining the methods they use to determine dependencies and will incorporate what they learn into future releases. We invest heavily in QA and continually work to improve the quality of our releases.
We send notifications to our entire customer base when a release is made "Generally Available" (GA). However, in the case of 5.6.2, we had delayed a general announcement pending the outcome of an investigation into the FreeBSD SSL issue mentioned in my original post. We also assumed any customer who used Domain mode authentication and upgraded to 5.6.2 would have been impacted immediately and have already contacted us. The rest of our customer base presumably either had not upgraded or used ADS mode authentication and would not have been able to take action on our notification. Once we de-provisioned 5.6.2 we felt a notification would have had limited value. We strive to limit our technical notifications as much as possible.
We appreciate the feedback. Feel free to contact me if you me directly if you would like to discuss this more directly.
Manager, Product Support
Thanks alot for the detailed explanation of "how QA works" and the way communication is processed. We'll give it a try today with 5.6.2-102 and I will let you know the outcome. Let's hope that future maintenance releases will eliminate such issues; luckily we came across this by using the "buggy release" in a testlab environment first.
Last not least one question about NTLM authentication against Windows Server 2008 in Native mode. The question that I raised is not yet answered nor do the 5.6.2-014 release notes say anything about it (unfortunately the support portal does not yet provide 5.6.2-102 release notes :-( ). I would appreciate to hear/read something about this. That would help us a lot for our internal planning going with Windows Server 2008.
Full Windows 2008 support is coming in the 6.0 release.
5.6.2 does not change how Windows 2008 is supported. In order for Windows 2008 server to be used, the following workaround needs to be in place:
1. It is necessary to have at least one Windows 2003 AD server running in the AD forest, ideally in the same domain where most of the users reside.
2. To authenticate users from other domains, there must be a trust relationship between the domain where the Windows 2003 AD server resides and the other domains.
3. NTLMv2 must be enabled on the Windows 2003 server. The WSA will actually communicate to the Windows 2003 AD server for authentication.
In order for authentication to work, the 2003 server must be running at all times.
NOTE: Since the WSA will actually be communicating to the 2003 server, the settings on the Windows 2008 servers will not affect the WSA.
I can't believe we pushed the old release notes out! Now corrected and thanks for letting us know.
I am still waiting for the official response on AD 2008. I'll go bang a drum on the appropriate floors until I get the answer ;-)
Hi Chris (and Josh),
Thanks a lot for the answer regarding Windows Server 2008 support. This helps a lot for our planning. If 6.0 ("Aurora") release will support Windows Server 2008 this should be ok for our organization as the deployment of Windows Server 2008 based Domain Controllers may take a bit longer that the 6.0 GA ;-)
One more thing regarding the release notes and user manuals in the support portal. I have to apologize to have no good news regarding this. The link that points to 5.6.2 user guide loads the 5.6.0 user guide whereas the link pointing to 5.6.2 release notes brings up the 5.6.2 user guide (dated Dec 22, 2008). Weird, isn't it?
Sorry for being picky, picky ;-)
I'm pretty sure you guys will be able to fix it.
Ok, this is right now. Thanks for the head's up.
We do not generally create new User Guides for Maintenance Releases so it usually works to just rsync over the latest doc (sigh).
Well, thanks for updating. The main reason to have the updated release notes available is that in some business environments you have to proof every single change, even if it's a minor one or related to bug fixing. Therefore we have to insist to have release notes that are matching the release level. For the user guides I am fully with you.
Hope that you understand this.