Mandatory password expirations should apply to everyone, even the network administrator.
Change in Time
Mandatory password expirations should apply to everyone, even the network administrator.
- By Chris Brooke
- 11/01/2000
My computer just informed me that my password expires
in 14 days. Sheesh! Now I have to come up with another
password. I know I’m the one who implemented that password
policy, but it shouldn’t apply to me, should it?
Oh yes it should!
I’m often surprised by the number of administrators I’ve
encountered in my travels who exclude themselves from
mandatory password expiration. They say they change their
password “all the time” and that it would never reach
the expiration date anyway. So why do they exclude themselves
if they never get the warning in the first place?
As administrators, we’re more susceptible to password
forging. Indeed, if our passwords get compromised, much
more damage could be done than when a regular user with
zero domain rights lets everyone and their dog know his
password.
There are times when security issues require us to force
password changes on everyone in the domain. Maybe someone
quit or was fired. Maybe this someone had big ears and
bigger eyes and always tried to acquire everyone’s password.
For whatever reason, performing a domain-wide password
reset can be really easy or really hard. If you plan to
do it in User Manager, set aside a day (depending on how
many users you have). Since I know you don’t have that
kind of time, let’s go the easy way.
Several months ago, in my column about third-party components,
we wrote a script to execute this task using Software
Artisans SA-Admin. Last month, I assigned you homework
to write a script performing this task using ADSI. Let’s
see how you did.
' ResetPW.vbs
Option Explicit
Dim objContainer, colUsers
Set objContainer= GetObject("WinNT://domain")
ObjContainer.Filter=Array("User")
For Each colUsers in objContainer
colUsers.Put "PasswordExpired",
1
colUsers.SetInfo
Next
Nothing to it, right? Well, there’s one problem with
this script. If you have users with the “Password Never
Expires” flag set, the above script won’t work on their
accounts—not good.
Homework, Part 1
Write a script that will query each user to determine
if their “PasswordNeverExpires” flag is set. If it is,
you must reset it, then force the password change. (Hint:
It’s not where you think it is. Get ready to search MSDN
online!)
Keeping Things Locked Down
Now, as long as we’re dealing with passwords, let’s ensure
that our domain security policy is tight enough. We can
query this information and change it using ADSI. We’ll
configure things a bit on the conservative side:
- Minimum password age—0
- Maximum password age—30 days
- Enforce password history—10 remembered
- Minimum password length—Eight characters
Homework, Part 2
Write a script (or add it to the previous script) to
query and set the appropriate properties to enforce the
policy we’ve just created. (Hint: Less research will be
required on this one.)
Before we wrap this up, let’s look at some of the new
naming conventions I’ve introduced in the last two issues
and explain what they mean. Those of you who have been
paying attention know that I always preface each variable
name with an indication of its type: obj for objects,
str for strings, b for Boolean, int for integers, etc.
Recently, I’ve introduced two new prefixes: col and cls.
In “ResetPW.vbs,” I used the variable prefix col to specify
a collection of users that was being returned by ADSI.
Last month, I used the variable type cls to specify a
class, which is really just another word for an object.
Under normal circumstances, both of these variables would
be of the type obj. (In past issues, we’ve used the obj
prefix when accessing the Wscript.Arguments collection.)
However—and I only seem to do this when using ADSI—I like
to use the obj identifier only with GetObject. It helps
me keep track of the namespaces, containers, and objects
I have bound to thus far. It’s only a personal preference.
Homework, Part 3
No script this time.
We should complete our romp through ADSI in the next
three months. Next is advanced domain administration!
About the Author
Chris Brooke, MCSE, is a contributing editor for Redmond magazine and director of enterprise technology for ComponentSource. He specializes in development, integration services and network/Internet administration. Send questions or your favorite scripts to [email protected].