Hi,

we have a strange problem when user accounts get locked in AD. The source of lock is shown as UAG server. UAG has 1 https trunk, where OWA, ActiveSync and EWS published. Problem occurs not for all users, but for some particular.

When I check activity on TMG of UAG I can see source IP address field empty, as well as destination port =0.

User have iphone configured to connect to activesync. When phone connects I can see valid IP address of phone.

Here is TMG record for valid phone:

 

Log type: Web Proxy (Reverse) 
Status: 0 The operation completed successfully.  
Source: 94.234.170.63 
Destination: - 
Request:  
Filter information: The user domain\user with source IP address 94.*.*.*was added to session 4F41832F9-FC0B-4CA8-89C2-62A179113DAB on trunk trunk1 (secure=1). 
User: domain\user
 Additional information 
Object source: (No source information is available.)
Cache info: 0x0
Processing time: 0 MIME type: 

Problem record is:

Log type: Web Proxy (Reverse) 
Status: 0 The operation completed successfully.  
Source: - 
Destination: - 
Request:  
Filter information: User domain\user with source IP address failed to log into trunk trunk1 (secure=1) using authentication server tse with session ID B7274A43-C200-41C6-81F8-94DD9E23F31A. Error code is Logon failure: unknown user name or bad password. 
User: domain\user
 Additional information 
Object source: (No source information is available.)
Cache info: 0x0
Processing time: 0 MIME type: 
 

we tried to remove mail from iphone, but that doesn't help. Problem traffic is generated each 5-10 second. After 5 invalid attempts account get locked. Looks like brutforce attack, but we can't even see the source IP address....

P.S. account lockout works only for OWA and not anyhow prevent this traffic.

What to do next?

P.P.S. TMG and UAG are 2010 SP2 with latest updates.

I don't have a direct answer to your question, but the general mentality on password locks has changed over the last couple of years (at least with many of the folks I talk to). Many now consider it a bad practice to have password lockout policies on your externally facing things. As long as you have strong password requirements, a brute force attack isn't going to guess the password so you don't really need to be worried about that. However, by having a password lockout policy in place, you cause problems for the users (as you are seeing, where a bot or attack can lock out accounts and cause that user to lose productivity), and having a password lock policy just clues the attackers into knowing that they have latched onto a real username in your network. With no password lock policy, they are always guessing and never know when they have hit a real one.

You can implement the block feature of UAG within the trunk.  For example, if your AD lockout policy is 10 bad attempts, then you can set the block setting for the UAG trunk to some number lower than that.  After the number of incorrect authentication attempts against the account reaches the block limit, UAG will block access from the account before it reaches the threshold of AD lockout.  The block period is whatever you want to set it to.  However, be aware that within UAG there is no way to clear a "blocked" session (short of rebooting) until the blocked period expires.  This was not the case in IAG and there was a way to allow the helpdesk to "unblock" an account from IAG.  That tool disappeared in UAG (much to our helpdesk dismay).

Hope this helps.