Our stalwart columnist tackles your toughest security questions.

Readers Write

Our stalwart columnist tackles your toughest security questions.

• By Roberta Bragg
• November 01, 1999

Plenty of you have been kind enough over the last year to write me when I make a mistake, solve a mystery, hit a funny bone, or unwittingly provide you with help. I’ve tried to answer as many questions as possible via email—sometimes the same question many times. This month, I’m sharing a few reader letters, along with my answers. I hope they’re useful in your security efforts.

Changing Local Admin Passwords

Roberta, I enjoyed your article, “Concealed Weapons,” in the July issue. I’d like to know the best or most efficient way to change the local admin password for each NT 4.0 workstation in the domain. Is there a way this could be done through a script or batch file, or must it be done to each machine?

Take a look at Microsoft KnowledgeBase articles Q137978, “Using NET USERS to Manage Local User Accounts on a Workstation,” which discusses the netusers command on Windows NT Workstation, and Q149427, “How To Change User Password at Command Prompt.” Use NET USER at the command prompt to change a password; yes, you can also use it in a script.

Expiring Passwords

How can I have passwords expire every 30 days? If I do this, my service account passwords will expire and critical systems won’t work.

If you select “Password Never Expires” at each service account properties page in User Manager for Domains (this is what should always be selected for a service account), then it doesn’t matter what you do at the global “Policy” property page. Selections at the user level override global selections. Thus, we can have service accounts whose passwords never change (unless we change them manually), while everyone else is asked to changed his or her password as they log on every “X” days.

Service Pack Reinstalls

In your article, "Inside Service Pack 4,” in the January 1999 issue, you state, “If you change or add new software or hardware components after installing Service Pack 4, you must reinstall the service pack.” I haven’t seen a service pack that works that way. What’s different about SP4 that it must be reinstalled each time new software or hardware is installed? Doesn’t this seem a bit strange? What are the ramifications of not reinstalling it?

Check out the readme files for Service Packs 3 and 4. If you install a “Microsoft” component—for example, you add the DNS service or a new NIC and therefore a new driver—you need to reinstall the service pack. The reason becomes clear when you see the notes. When a service pack is installed, it inspects your current system and replaces some software with new versions of DLLs, drivers, and the like. If you don’t have the DNS service, it won’t load any new versions, new components, or fixes available with the service pack. Therefore, when you load a new Microsoft component, you have to reinstall the service pack to get fixes or new stuff. If you don’t, you won’t benefit from the improvements, bug fixes, or security holes that may be closed. You may also run into operational problems as new and old components attempt to work together.

Security Registry

We’re a small software development company trying to develop a shell control product that protects the desktop from abuse from multiple users. This product is intended for Windows 95, Windows 98, and Windows NT. We’ve been successful in using it with Win95 and Win98. NT, however, has been a bit more difficult. The problem has to do with the security and protection of the Registry, specifically the HKey_Current_User keys.

We wrote a service that executes the reg changes on the NT machine (called from another program). This program runs in the context of the logged-on user (domain user). We have the service running in the context of the Admin. User is a Domain user. Current_User changes occur, but they’re for the Admin, not the logged-on user.

My question: Is there a way to load Current_User hive and modify it via the programmatic means we’re trying? Or is there a better way to make Registry changes programmatically so we can make these modifications to the system?

For an example of how to do this and an explanation try KnowledgeBase article Q168877, “How To Load a User’s Hive Programmatically.”

Where Should Policies Go?

I was reading your article, “Hardening NT,” in the October 1998 issue. Currently, we’re a Novell 4.11 environment, slowly building up with NT. We have 50-plus NT 4.0 servers with many apps. One department uses NT Workstation. We have one person who is insisting that policies should be placed locally on each machine. We have other people (mainly the administrators) who believe the policies should be placed on the server. What do you think?

The only advantage I can think of for putting a policy on a machine is that if the individual doesn’t log on to a domain, policies can still be implemented. However, how does the policy get on that person’s machine and how do you update it? And how do you protect it from others? Sounds like an administrative and security nightmare.

Policies placed on the server are accessed during logon, and so changes can easily be implemented. You’ll need to make sure that the policy is on every logon server (domain controller). You can do this with replication. Thus, whenever a change is made, it can be made from one server and replicated automatically to all. You can protect the policy as it resides on servers (protect the servers, protect the folder). You then avoid the distribution nightmare of having the policy editor on local machines.

Strong Password Policies

I’ve taken all your advice and applied it in our network, with the exception of something I’m having difficulty with. You mentioned putting the string c:\winnt\system32\passfilt.dll in the LSA key. I have been unsuccessful in finding a way to put a string into a key. It seems to require adding a value to the key and then adding the string to the value. Could you please elaborate? I’d really like to apply this to the network.

Sorry for the confusion. Here’s what you need to do:

1. Install Service Pack 3.
2. Check to see that the passfilt.dll is in
3. Start regedt32 and browse:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

4. Double-click the “Notification Packages” key and add the following entry beneath the FPNWCLNT entry:

PASSFILT

or, Double-click the “Notification Packages” key and add the following string:

“C:\

Yes, use quotes.

5. Click OK and close the registry editor.
6. Shut down and restart the computer.

Using the path is more secure, since an individual could place an executable that might compromise your system and name it PASSFILT.

Don’t forget to:

1. Open User Manager for Domains
2. Select all users.
3. Click on the User Menu.
4. Click Properties page.
5. Select “user must change password at next logon.”
6. Click OK.

To test the function, log on from a client and attempt to enter a less strong password.

For more information, see KnowledgeBase articles Q161990, “How To Enable Strong Password Functionality in Windows NT”; Q151082, “How to: Password Change Filtering & Notification in Windows NT”; Q174075, “Strong Passwords with PASSFILT.DLL Are Not Enforced”; and Q174076, “Invalid Password Message When Strong Passwords Are Required.”