Wednesday, 18 February 2009

ISA SP1 introduces an issue (at least the way I'm looking at it, it does!)

We were trying to configure ISA to honour the "force password change at next logon" (something it ought to do, and indeed used to do pre-SP1, OOTB). We have spent hours looking at every configuration item.

We have an ISA 2006 (std edition) server, this is publishing a SharePoint based web application that uses AD for authentication/authorisation. We have ISA FBA working against the DMZ AD using LDAPS, users can login and use the app (ISA delegating NTLM) without issue. We come to load some user accounts into AD for UAT, and enable the "change password at next login" flag within AD, only to find this prevents users from authenticating.


Great, we have delivered a super-secure app (as no-one can get to it). Not even me.

The SOLE reason for using ISA in this scenario was to provide the password management functionality, for now all I need it for is to allow users (and force users) to change passwords - else we aren't offering anything over the existing solution that requires non-expiring passwords in AD.

We have now proven that, pre-SP1, with the "password change at logon" flag set you can enter any password you like and will get the password change page, as long as the username is valid you're fine. Pretty shocking really.




Note that if you are using forms-based authentication with LDAP authentication, ISA Server is not able to perform this action and cannot provide automatic redirection to the change password form. This is because the LDAP provider can't validate passwords.

So, the question is then: what does the user account you give the "LDAP Server Set" [bottom of the form, where it states "user credentials used to access AD to verify user account status and change account passwords (optional)"] actually do??

If this isn't to allow status checks on user accounts/passwords then what does it do?? I see security events on the DC for it, so it's doing something (??).

I regularly praise ISA and design it into solutions we do for clients and so am very disappointed with my findings in this case. I also speak at the SharePoint User Group (UK) sessions and did one last year where I extolled the benefits of ISA:


I raised a case through our TAM/PAM and quickly got through to a MSFT Escalation engineer who responded quickly and issued hotfix 959357 (suitably caveated as below).


WARNING: This fix is not publicly available through the Microsoft website as it has not gone through full Microsoft regression testing.  If you would like confirmation that this fix is designed to address your specific problem, or if you would like to confirm whether there are any special compatibility or installation issues associated with this fix, you are encouraged to speak to a Support Professional in Product Support Services.

This installed without issue, after applying the fix (and rebooting) you need to run a script (this was also supplied by MSFT). Some text from the supporting documentation is supplied below:

After you applied Microsoft Internet Security and Acceleration (ISA) Server Service Pack 1 (SP1), you may notice that the "change password" feature does not work as expected.
For example, in Active Directory settings, you enable the "User must change password at next logon" setting for a certain user account. However, when the user tries to log on by using forms-based authentication (FBA) with the "change password" feature enabled in ISA Server, the user is not automatically redirected to the form that is used to change password.
This problem occurs when FBA is used together with Lightweight Directory Access Protocol (LDAP). Starting from ISA Server 2006 SP1, the default behavior was changed when you use FBA together with LDAP. This change was made to help guard against authentication attacks.
For more information, visit the "Changes in Service Pack 1" section of the following Microsoft TechNet Web site:
Configuring and Troubleshooting the Password Change Feature in ISA Server 2006
To resolve this problem, follow these steps:
1.  Install the hotfix package that is described in the following Microsoft Knowledge Base article:
959357 Description of the ISA Server 2006 hotfix package: October 29, 2008
2.  Start Notepad and paste in the supplied VBS, save as EnableHotfix957859.vbs.
3. Run: Cscript EnableHotfix957859.vbs /webListener:ListnerName/Value:true

Interestingly the URL supplied for the hotfix doesn't work, maybe this is indeed intended for public release, but isn't there yet (??).


Either way, I believe this issue is solvable, if it was approached from a custom .Net point of view at least, therefore it must be solvable in ISA. That said, TMG is now at Beta2 so there won't be much PG attention on ISA 2006 anymore.


If you are reading this and aren't happy with reverting ISA 2006 SP1 to the pre-SP1 funtionality (and the vulnerability this introduces), I can offer 2 suggestions:


  1. Join ISA to the domain (this way you don't need LDAPS)
  2. Employ 2 factor authentication (this largely nullifies the vulnerability discussed above)

With regards to 1 above, there has been, and indeed continues to be, much debate about joining ISA to domains. I see validity to both sides of the argument. My $0.02:

It depends on your scenario...

ISA is a firewall appliance. IMO security appliances should not be joined to something they are protecting (and this is one reason we have things like RADIUS and LDAPS) and an air-gap is great.

ISA is a forward proxy, why not join it for ease of management?

ISA publishes applications, some apps need authentication, authentication needs user accounts, accounts need managing, accounts involve people. Password management is a major headache. ISA allows end-users to manage passwords (except in the above scenario). But if you have multiple apps, maybe in multiple domains without bi-directional trusts, which domain do you join ISA to?? You'll end up having LDAPS to one of the domains, so the above issue can occur even with ISA in the domain.


Right, I'm off to download TMG and see if this has the same issue...


[update: the day after I posted this there was a public release of the fix from MSFT:]


  1. I am seeing the same issue in TMG. I assume TMG includes the hotfix in its build but I wonder if the EnableHotfix957859.vbs script is at all applicable to TMG? Any ideas?

  2. We have TMG2010 SP2 installed and we are running into the identical issue. Is there an additional Hot-fix required? Do we need to run the script? Any info on TMG would be appreciated.

  3. I haven't personally seen this issue with TMG, but I'm not surprised people are reporting it...

    Have you logged a case with PSS?


Please feel free to comment on this post, I want to hear your feedback!