THE OFFICIAL BLOG OF THE SBS DIVA

If someone is rattling your doors, you double check the windows too right?

My guess is most SBS admins arent monitoring there DC security logs, so how do you know if someone is jiggling the handles on your network?

And since your users set there own passwords, how do you know they are 'good enough'? If they are long enough passwords, they would be OK no matter what they are, but windows won't let you require a password longer than 14 charecters.

For me, if the doors on my houre are rattling, I'm calling the cops, not rolling over and going back to sleep because my locks are good enough.

Susan wrote today about "the knock on the door" that occurs when attackers bang on accounts on an SBS network. She pointed out that Steve Riley and Dr. Jesper Johansson in their book on Protecting your Windows network say that if you have the proper passwords...[great passwords are akin to great strong locks on your doors].... you can let them bang on those doors all you want because you are snug behind those locks. As an information security professional, I think this is a rather FLAWED view of things. It is the difference between a PAPER TIGER in the field, and those who actually have to live it every day. I mean no disrespect to Steve or Jesper, as they are completely correct on the surface of their writings, but they are ignoring a VERY critical component of our REAL WORLD. The weakest link in security is the human factor. We need to EXPECT that some users will use weak passwords. When not forced to use stronger authentication types such as two factor auth, users will always choose simplicity over security... each and every time. It's human nature. And even though people are starting to realize that writing passwords down isn't as stupid as you would think, the reality is their is a HUGE disconnect between the practical and the theoretical. So what is the right answer? Well that will all depend on your environment, the profile your system has, and the tolerance of risks you are willing to accept. As an SBSer who is an information security professional, let me give you my take on it. Windows Server 2003 (the OS behind SBS 2003) has a bunch of configuration options to mitigate the risks of "door knockers" with account lockout policies. There are three critical settings which you can configure: Account Lockout Duration Account Lockout Threshold Reset account lockout counter after Lets first talk about "Account Lockout Duration". This is a setting that determines the length of time before an account is unlocked and a user can log on again after it has been locked. By default, this is normally not defined. If you set it, it will determine how long (in minutes) it will take before the account is unlocked. Here is an interesting tidbit... setting it to 0 does NOT unlock the account... it forces accounts to REMAIN locked until an admin unlocks them. I recommend you turn this setting ON, and set it to 15 minutes. The second setting is the "Account Lockout Threshold". This settings determines the number of failed attempts that a user can make before the account becomes locked. Now careful consideration needs to be taken when configuring this setting. To little, and you can plague yourself with the possibility of a denial of service attack, or just regular lockout from users who forget their password after a reset. You would be amazed, but it's quite easy to do that, especially after a forced password change. And its why in large networks that a LOT of cost is in password management on Windows networks. If you set it to high, then the setting becomes useless... not being effective at all. The NSA and Microsoft recommend that in high security environments that you set this to 10 invalid login attempts. I think that should be doubled on SBS. That's right, you should ENABLE this setting and set it to 20 invalid login attempts. Why so many? Because in SBS environments, a single login attempt with Exchange may cause for double login attempt failures. In other words, when doing a failed login to things like OWA, depending on your settings you would actually get TWO failed login attempts in the eventlog... both which causes the lockout counter to go up. Finally there is the "Reset account lockout counter after" setting. This setting determines the length of time (in minutes) before the "Account lockout threshold" resets itself to 0, and the account is unlocked. When you define the "Account lockout threshold", then this reset time MUST be less than (or equal) to the value you set for the "Account Lockout Duration". Without this setting configured, administrators would be FORCED to manually unlock all locked accounts. I recommend that you set this to the same timeout as whatever you set in "Account Lockout Duration". In our case, that's 15 minutes. So doing this, what happens? People are welcome to "rattle at the door". If a user fails to log in 10 times (up to a maximum of 20 if double printing isn't occuring) the account will be locked out for 15 minutes. After that 15 minutes, the counters reset, and the user can try again. In this scenario, it's an acceptable timeout that can block out the baddies, but also reset when valid users make one to many mistakes. And its all automated so the SBSer doesn't have to be part of the account management process until its time to do so. And it comes with a side benefit. In your daily SBS report you will be able to audit this by looking at the "Critical Events" section of your report. You can review which accounts seem to be having problems and address it in a more proactive manner by re-educating users if they seem to be constantly causing bad login attempts. Or force them to reset their password. Or watch the account more closely in the future. At this point it's a user management issue... and something you can more address. YMMV. But this strategy has been very successful for me. Of course, I have to be honest here. I use two factor authentication where ever I can now, so I don't get much "door knocking", since users can't SEE anything until they have already authenticated to the network. However, this strategy still works effectively as I watch internal users log into LOB terminal servers. Being able to protect against the internal threat is just as important, and this strategy works well to add another layer of defense of our systems....