Using the Account Lockout Feature in TMG 2010
Introduction
A much needed feature was added in Service Pack 2 for Forefront TMG 2010. This great new feature gives you the ability to lock accounts on TMG at the local level before accounts are actually locked out in the domain. The account lockout feature, when used properly, will prevent TMG from trying to authenticate a user to a Domain Controller after the defined number of bad passwords has been attempted.
In one of my previous blogs I talked about scenarios where TMG is being used as a reverse proxy and the Account Lockout Threshold has been set in the AD domain. Often times, when companies require their users to change passwords at a given interval, devices will end up with a bad password stored on them. Devices may use the old password for Exchange ActiveSync over and over again until the domain account has been locked out. This can cause a lot of frustration for IT departments that are trying to track down the source of the lockouts and also having to frequently unlock accounts.
To enable this new feature, install SP2 which you can get here. The details for the new lockout feature can be found here.
The new feature, however, is not automatically enabled after installing the Service Pack and cannot be modified using the TMG GUI. The account lockout feature can only be modified through the Forefront TMG Com Object Model. Fortunately for us there are examples available out there on how to do this using PowerShell. One such example has been provided to us by Jan Egil Ring in the Microsoft Script Center and it is located here.
There are a couple of important things to keep in mind when using this feature:
1.) Only Web Listeners configured to use Forms Based Authentication (FBA) can be configured to use the new feature.
2.) The value you choose for the AccountLockoutThreshold variable is set on TMG on a “per server” basis and must be set on each TMG server
individually.
Scenario
Let’s look at a specific example to help you understand how the feature works and the implications of using it. In our example I am the administrator for a domain called Fabrikam.com and I have decided that I want to set the number of bad password attempts allowed in my Fabrikam Domain to 5. I would normally do this by setting the Account Lockout Threshold value in my Default Domain Policy using the Group Policy Editor. I also require that my users change their passwords every 30 days.
Now let’s assume also that I have 3 TMG Servers (TMG 1, TMG2, and TMG3) that sit on the edge of my network. The 3 TMG Servers are load balanced using Microsoft’s built in Network Load Balancing (NLB). These servers are used only for reverse proxy (Outlook Web Access and Exchange ActiveSync) so that my users can retrieve their email while on the road or at home. I have 2 Publishing Rules on TMG, 1 is for OWA and the other is for Exchange ActiveSync. They both share the same Web Listener which uses FBA Authentication.
Everything is going fine until one day we start getting reports that accounts are being locked out. It appears that some of the Executives have devices managed by their administrative assistants. My domain password policy requires users to change their passwords every 30 days. After some initial investigation it is found out that these devices were storing bad passwords and causing the account lockouts.
I have just learned of the new account lockout feature on TMG and I follow the links given earlier and configure it so that the AccountLockoutThreshold value is set to 3 on each one of my TMG Servers. My thinking is that the local value of 3 that I am using on TMG is lower than my Domain value of 5 so I should be okay. If TMG does its job correctly, it will stop trying to authenticate bad password attempts before the devices lock the domain accounts out.
Even after setting the lockout feature on TMG I am still getting reports of accounts being locked out in my domain. What did I do wrong? Keep in mind something that I pointed out earlier which is that this value is “per TMG Server”. In my example I have 3 TMG servers that are being load balanced. Devices, such as phones, that are used for Exchange ActiveSync will sometimes get a different IP address every couple of minutes for their carrier. Because TMG is using NLB, this device may be serviced by any 1 of the 3 TMG Servers (depending on a few factors).
Let’s say that the CIO of Fabrikam, John Smith, has a phone which is carried by his admin assistant and has an IP addresses provisioned to it by the carrier that ends in 10. John recently changed his domain password but it was not changed on the phone that his administrative assistant carries. The phone is now attempting to retrieve his email using the old (incorrect) password on TMG1 since it has been load balanced to it. TMG1 tries to authenticate John Smith to a Domain Controller 3 times using the bad password. On the fourth attempt, TMG1 no longer tries to authenticate to a DC. So far so good right? TMG has done its job and the account is not locked out. Let’s further assume that John Smiths phone hits another cell tower and is now provisioned an IP address that ends in 11. Because of the way NLB works, the phone tries to use TMG2 to retrieve John's email. Again it tries 3 times using the bad password. Since the AccountLockoutThreshold value is “per server”, TMG2 also tries to authenticate the account to a Domain Controller. From the perspective of the Domain Controller, a bad password attempt has been tried 6 times so the account is locked out.
Conclusion
As you can see from the example above you will need to tweak the settings on the TMG server and possibly even on your Domain Password Policy to get the desired results from this new feature. This will all depend on your individual environment and certain factors such as how many TMG servers you are using, how they are load balanced, and what types of devices are potentially trying bad passwords.
Comments
- Anonymous
July 23, 2013
Great, how can I find the locked out accounts and how can I unlocked them? Thank you.