More from the mailbag – user name lockouts


Dan asked (a long time ago, sorry Dan) that he was getting notifications of accounts being locked out due to invalid password attempts. Dan’s assuming this is because someone is trying to hack into an account and wanted to know how to stop SBS usernames from being “broadcast”.

Unfortunately, the question makes a fundamental assumption, that SBS somehow is broadcasting usernames. This is not the case, but it probably doesn’t take someone long to figure out a username for your users.

For example, if your user’s e-mail addresses and logon names are identical, then once they get an e-mail address for a user they can simply use that as their username for their attempt and start a dictionary attack.

How does one get a valid e-mail address? Simple: start at a@foo.com, end at zzzzzzzz@foo.com, and try every combination in between. Run a script to send to your SBS server a piece of spam that will just get deleted by your ordinary user. Wait for NDRs to return for the non-valid addresses, subtract the rest, and you have a user list.

2 ways to obscure this information:

  1. Make your user’s logon name and e-mail address different (can be done in the Add User Wizard at user creation time or afterwards by modifying the e-mail address or logon name in the user properties)
  2. Disable external deliveries of NDRs (840158 You cannot restrict certain automatic responses to the Internet based on http://support.microsoft.com/?id=840158) Note that I don’t typically recommend this as it is technically a violation of the SMTP RFC and won’t help your customers who accidentally mis-type an e-mail address and wonder why they never got a response

Your most effective way of making sure that no one cracks your accounts is to enforce strong password policy. In Dan’s case, though, it doesn’t help his users who are getting locked out of their account legitamately. In that case, your best effort is to take some time and try to determine the IP address of the offending attempts and then block these at your router or higher up.

 

Comments (2)

  1. Alex Lee says:

    There’s also the case of viruses that can enumerate valid domain accounts (such as Randex, Gaobot variants). These simply ask & receive user names. Then they try a laundry list of passwords. Results in lockouts.

    I don’t know if there’s a good method to restrict anonymous access to this type of information. Or if it matters, since a valid computer/user could become infected & then not request anonymously.

    Suggestions…

    – Increase the lockout threshold. This mitigates against the DOS condition when a user is locked out. I know that much of the literature about passwords suggests 3 invalid attempts. I think you’ll find that newer literature suggests thresholds as high as 50 invalid attempts (such as the MS Threats & Countermeasures Guide).

    – Require complex and long passphrases. Change them more frequently. This mitigates against the increased lockout threshold.

    – Use strong passphrases on the Administrator account. These viruses can also propagate by connecting to the hidden $ shares. They will often use the local admin account.

    – Rename the local admin account. Disable it. Create a new, unique to your network or computer local admin account. Obfuscation, I know, but it does add a layer that a virus writer may not think to code for.

    – Audit the security event log for lockout events (or failed logon events). Each event includes the username locked out and the computer the attempt came from. When a virus is causing the lockouts, it is obvious in the logs. One source computer will be the cause of numerous user account lockouts. You are also likely to have an exponential increase in the number of failed logons or account lockouts. Refine the scope of this auditing by pointing EventCombMT at your PDC. That’ll catch most of this type of activity. There are also some automated means such as MS MOM, or eventing (I think it’s eventing), or MS LogParser.