Letters to Redmond

Readers Respond January 2005

Readers sound off on password security, remote scripting and bargaining with Microsoft.

• 01/01/2005

1. You don't need to enable the complexity settings GPO setting, it can be disabled. You only need to set a DLL name in the notification packages. I have done this several times where a company doesn't want the default Microsoft filter but wants some sort of filter.

2. You should make note that password filters are not trivial things. Done incorrectly you can seriously impact the security and stability of your domain controllers. Filters run at the highest security context possible on a domain controller and are fully exposed to outside influence. Coding must be extremely well done so as not to open up security holes.

3. Finally, another more user-friendly solution is to disable the ability to natively change passwords and force people through a Web interface that can give feedback on what is wrong with the password someone is trying to set. The native feedback system is poor at best.
—[email protected]

In reference to your first comment: Correct, you can customize your own DLL to create the filter that you want. The Microsoft filter is rather basic, but does a great job of forcing at least three types of characters in every password, as well as a longer password.

As for your second item: An extremely good point! All new filters should be tested in a lab before rolled out into production. You would not want to have to rebuild your domain controllers or restore any part of Active Directory based on a poor coding error. Every iteration of the password that you are implementing should be tested thoroughly, to ensure it meets all security criteria and possible characters that users will use.

As for your final thought: Plenty of third-party tools do a great job of allowing users to change passwords. You make a great point that these tools do a much better job of communicating back to the user where they have failed with the password complexity. The built-in feedback is far from desirable! Thanks for the comments.
—Derek Melber

Pre-SP2 Firewall
I'm not a scripter, but I did essentially the same thing [as in Chris Brooke's Mr. Script column, "Remote Scripting for SP2," December 2004] by configuring the netfw.inf file to open up the appropriate apps and subnets and by creating a simple batch file that renames the original inf (just in case), copies the new inf and runs the netsh firewall reset command.

I don't see how you can use either method to reset the firewall before installing SP2, because those settings don't even exist in the pre-SP2 firewall.

Let me know if I'm incorrect, as this would be extremely helpful, just as Chris said.
—Charlie
Boston, Mass.

Thanks for the excellent question, Charlie. You may well have prevented even more cards and letters!

You can pre-configure the netfw.inf for a "slipstreamed" installation of XP SP2 by modifying the "netfw.in_" file in the i386 directory of the XP installation CD. If you already have XP installed, the following page outlines the steps to pre-configure the netfw.inf file prior to installing SP2: http://windowsecurity.com/articles/Customizing-Windows-Firewall.html.

Please note that this step includes a LOT of extra work (code signing, etc.) Turns out that maybe it's easier to just fix it after the SP2 install, after all.
—Chris Brooke

No Upgrade Stipulation
Good article overall ("7 Steps to a Better Bargain," November 2004) … just a few comments:

• All OEM software is tied to the original system, not just OEM OSes but OEM Office also.
• Customers are eligible for free upgrades that have been released during the SA term. They do not have to install them during the SA term. They can install them whenever they are ready. SA just provides free access; it doesn't stipulate that you have to upgrade.

—Michael