Mr. Script

Password Currency

Why it's important for remote users to change passwords regularly.

• By Chris Brooke
• 03/01/2004

My home office is a geek’s paradise. I have my dual-processor “monster” machine running almost all the time. My wife and I each have laptops, and the kids have a desktop system upstairs, all connected wirelessly to my gateway/router. (The Monster still connects with a Cat 5 cable.) The gateway router is connected to a high-speed Internet connection. We exist in a state of fast access online nirvana.

Unfortunately, my blissful life comes crashing down the minute I need to access my company network. I have to kick everyone off the home network and plug directly into my high-speed Internet connection. Why? My VPN software doesn’t work over the Network Address Translation that my router uses. Having my notebook tethered to the network again can be a real bummer!

I’m not the only person plagued by VPN woes. Marvin Adeff recently wrote to me about an issue he was having with his remote users: “I’ve been racking my mind trying to come up with a script that remote users can run on their client laptops, which will allow them to change their passwords...”

It seems that Marvin has several remote users who go long periods of time without being directly connected to the office network (sometimes as long as a year). Like any good administrator, Marvin has a mandatory password expiration policy in place on the network. Regrettably, his users log onto their laptops using local, not domain, accounts. They’re authenticated on the domain by connecting to a stand-alone concentrator, which only performs authentication; it doesn’t support changing passwords. Consequently, when his users’ passwords expire, they have no way of changing them.

Marvin wanted a way to help facilitate this via a script. Indeed, you can script password changes via Active Directory Service Interfaces (ADSI), but the user running the script needs the appropriate administrative permissions—not a good idea for a remote user. The “least bad” solution in his case is to have an intranet server running a Web page that allows the users to change their domain passwords. They can access this Web server via the VPN, so there’s a reasonable level of security. Better yet, make those laptops members of the domain. This negates the need for a separate concentrator to authenticate domain credentials. It also provides better security, in general, for the laptops.

Can Open...Worms Everywhere!
Marvin’s question begets a larger one: How can we keep our networks secure with remote users? The answer isn’t a simple one. There are many issues to be concerned with. First and foremost, Windows NT, Windows 2000 and Windows XP clients have their own Security Accounts Manager (SAM) database for storing user account and password hash information. If the computer is a member of a domain and the user logs on with a domain user account, there must be a way to sync this database with the domain when the password is changed. When the computer is connected directly to the network, this happens automatically. If the computer is remote and only connected via a VPN, the results are less predictable and may vary, depending on whether the domain is AD or NT.

No problem. For those few telecommuters who only make it into the office once a year, we’ll manually change their passwords here and share it with them. This makes the previous point a non-issue, correct? Well, yes, it does...sort of. So long as the users’ VPN solution directly integrates with Windows DialUp Networking (DUN), the user can check the little box on the login screen to “Log on using dial-up networking,” and the username and password will be authenticated by the domain controller, not by the local SAM database. But which VPN solutions integrate with DUN? Well, Microsoft’s VPN, to be sure. There are probably others that integrate also, but mine doesn’t and neither does Marvin’s.

So Now What?
Assuming that you most assuredly do not want to allow users to go a full year between password changes, what can we do? The first thing is to remember that not all users are away from the corporate network for a full year—some are only gone weeks or months at a time. Keeping that in mind, there are some steps we can take. And, I’ve got it in a script!

'CheckExpire.vbs

Option Explicit
Dim strUser, strDateBack, dtDateBack, dtExpire, objADSI, lFlag

strUser=InputBox("Enter Username of account to check")
strDateBack=InputBox("Enter Date of return. Format: mm/dd/yyyy")
dtDateBack=CDate(strDateBack)

Set objADSI=GetObject("WinNT://domain/" & strUser & ", user")
lFlag=objADSI.Get("UserFlags")
If (lFlags AND &H10000) <> 0 Then WScript.quit
dtExpire=objADSI.PasswordExpirationDate

If dtExpire < dtDateBack Then
   WScript.Echo "The password will expire"
End If

Of course, you’ll need to plug in the name of your own domain when retrieving the ADSI object.

This script allows you to determine when a particular password is set to expire. Assuming that your long-term telecommuters have some knowledge of their travel schedule, it should be easy enough to schedule this script to run just prior to their departure and determine whether their password will expire while they’re away. If so, they can change it before they leave, thus, resetting the expiration “clock.”

The first thing the script checks for is if the user’s “Password Never Expires” property is set to True. If it is, then there’s no chance of the password expiring before the user returns to the office, so the script terminates. Maybe this is a good time to go ahead and change that. We don’t want our password policy circumvented, now do we?

This script relies on human data entry. It would be better to get the travel dates (and the usernames, for that matter) from a file or database. You should also add in a little error handling.

Balancing Security with Usability
Finally, keep in mind that this is only one possible solution—in one small area—of the complex issue of keeping our networks secure with VPN users. As with almost everything concerning Windows, there’s a tradeoff for convenience. What’s traded is usually security. From the moment you plug a network cable (metaphorically, of course, for you wireless junkies!) into your computer, you give up absolute security. From that point on, you must deal with a series of compromises intended to maintain security that’s “good enough,” while still being able to use your computer.

Next month, I share a gem of a script that will help you locate specific events in logs that may be scattered across multiple servers in your environment. The next time your boss asks you to track down who did what, when and where, you’ll be prepared.