Why it's important for remote users to change passwords regularly.
- By Chris Brooke
- March 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!
Dim strUser, strDateBack, dtDateBack, dtExpire, objADSI, lFlag
Username of account to check")
Date of return. Format: mm/dd/yyyy")
& strUser &
If (lFlags AND &H10000)
<> 0 Then WScript.quit
If dtExpire < dtDateBack
WScript.Echo "The password will expire"
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.