Our stalwart columnist tackles your toughest security questions.
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.
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.
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
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:
- Install Service Pack 3.
- Check to see that the passfilt.dll is in
- Start regedt32 and browse:
- Double-click the “Notification Packages”
key and add the following entry beneath the FPNWCLNT
or, Double-click the “Notification Packages” key and
add the following string:
Yes, use quotes.
- Click OK and close the registry editor.
- 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:
- Open User Manager for Domains
- Select all users.
- Click on the User Menu.
- Click Properties page.
- Select “user must change password at next logon.”
- 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.”
Roberta Bragg, MCSE: Security, CISSP, Security+, and Microsoft MVP is a Redmond contributing editor and the owner of Have Computer Will Travel Inc., an independent firm specializing in information security and operating systems. She's series editor for Osborne/McGraw-Hill's Hardening series, books that instruct you on how to secure your networks before you are hacked, and author of the first book in the series, Hardening Windows Systems.