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
• November 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!