Mr. Script

Password Currency

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

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!


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

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

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

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.

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

comments powered by Disqus

Reader Comments:

Thu, May 26, 2005 Phage Anonymous

I had to change line "If (lFlags AND &H10000) 0 Then WScript.quit" to "If (lFlag AND &H10000) 0 Then WScript.quit" to get the script to work.

Sun, May 2, 2004 Anonymous Anonymous

Good column. Lots of appropriate info.

Thu, Mar 25, 2004 mec boston

It does work well, but does often enough to try: Change the password from the Outlook client once authenticated to the exchange server. From the bar: Tools, Options,Other,General,Advanced Options,Custom Forms, Password. Of course this does not solve the expiration issue and cannot be used to change the password once expired- in order to change the password the user needs a new pasword, and cannot get a news password because the password is expired.

Wed, Mar 24, 2004 Charlie Boston

I recently came across the problem of a user who's PC is 400 miles from the LAN. We use a non-MS VPN solution so I had him log on with cached credentials that way he always does, but the KeepRasConnections=1 String Value was added to HKLM\Software\Microsoft\WindowsNT \CurrentVersion\Winlogon.
He made the VPN connection, logged off and then when he logged back on he was able to use his new password, since he was not disconnected from the LAN when he logged off and the DC was available to him at logon. In an environment where users are forced to change passwords, this could also be used for changing the password if the user can remember to do it before the current one expires.

Wed, Mar 24, 2004 Anonymous Anonymous

Use Linux iptables NAT - works great
Can even use an old machine. My house is a geeks toy pad too- eveybody connects at the same time, online games, IM , etc- No vpn issues. Wireless too.

Wed, Mar 24, 2004 Yousef boston

From what I've seen, alot of 3rd Party VPN Clients don't tie in to RAS, this is most likely because their authentication requirements are much broader then just a username and password. Alot of the VPN clients use certificates or even "hard tokens" (think SecurID). Newer versions of all the client's I've seen (Cisco, Nortel, and Checkpoint/Safenet as well as derivatives), all include support for NAT Traversal. If their software wont work over NAT, check out the Nexland SOHO devices, past experience has seen them allow VPN access for 1 client even when the VPN software doesnt support NAT. Nexland says this is because of proprietary technology included in their routers.

Finally, the latest version of the Nortel VPN client includes a GINA replacement that allows users to connect to the VPN BEFORE the user logs in. That way the user's PC can be added to the domain and it acts like they're connected in the office. So you can expire the passwords normally and you don't have the "log in cached, initiate VPN, log out, log in to the domain" procedure that so many of use are used to. Hopefully this will also catch on to other VPN clients as this has solves so many of the "always remote" issues I've had to deal with.

Wed, Mar 24, 2004 Josh Illinois

The article mentions a "concentrator." If this is a Cisco VPN Concentrator, you can set it up to allow the user to change their password through the Cisco VPN Client. You must use RADIUS to authenticate the users to Microsoft Internet Authentication Services (IAS.) It works quite nicely. When a user connects to the VPN with an expired password, they are prompted to change it. This resets the password on the Active Directory for them. There are of course minimum software version requirements, but I have done this and it works well. It's also very easy for the users. Most newer VPN concentrators also support the Industry standard NAT-T where IPSec is encapsulated in a UDP packet on port 4500. Some also support other encapsulations such as TCP encapsulation on an arbitrary port.

Sun, Mar 21, 2004 Gill S'Pore

This article looks outdates where technology is concerned.

Mon, Mar 1, 2004 Craig England

At first I thought this article would anser my problem, but reading through I found that it claims Microsoft VPN handles this problem, well NO IT DOESN'T. I shall explain...... I have an external user accessing the network with VPN (comes as standard in XP and make new connection), I have a SBS2003 with the domain and Exchange, everything is fine until the 31 days password expiry comes up, when the user changes their password they can no longer access the system properly and Outlook stops working, now they are having to use OWA as they cannot get the exchange server to respond and even deleting the Outlook setup and trying to reconfigure doesn't work. Now microsoft acknowledge this as an issue, they have a HOTFIX for it, but guess what - it doesn't work, now I have a team of people on the road, with useless laptops and as per usual Microsoft won't do anything about it. Can anyone help please. Regards, Craig.

Fri, Feb 27, 2004 Ernie Oporto NJ

For your router, you should probably look into the latest line of Linksys routers such as the BEFVP41. These newer models properly allow manual key and IKE VPNs through. Also, your admins should check if there are upgrades to your VPN software...the newer versions from various vendors now do NAT translation so that packets are not destroyed on their way out. Netscreen makes a great firewall and uses IRE/SafeNet as their VPN client of choice, constantly providing new features every few months.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.