We've got a few users in a remote office that only access any of the servers through the SonicWALL Global VPN Client. Their machines are members of the Active Directory domain here, so they can access Exchange mail and network shares while the VPN connection is active... works great.

The issue is changing their domain passwords. If I change it for them manually at the server, any authentication session taking place after the change should be fine (accessing shares, logging into email). But what about their local machine logins to the domain? Will they still need to login with their previous cached password on the machine? Since the VPN connection is activated after login (in software), the initial Windows login can never see the server.

Does anyone know what will happen if we go through with this? Does anyone know a workaround besides bringing the machines back on site here?

6 Answers 6



I see from your comments that you aren't doing the "poor man's trust relationship" with local accounts, but rather are pre-caching credentials on the client computers before shipping them off-site.

With that in mind, you still really, really want a site-to-site VPN solution, rather than running VPN clients on each client computer. That will make the question you're asking be a moot point. Your client computers won't "know" that there's a VPN present, and things like domain logons and group policy, as well as password changes will "just work".

My eyes are nearly bleeding even thinking about having to deal with no site-to-site VPN and cached credentials on client computers in such an environment.

  • I guess that's the only real way to work around the problem anyways, site-to-site hardware. I'll deal with this somehow in the meantime until I can make that happen. Thanks!
    – colemanm
    Commented Jul 7, 2009 at 14:02
  • 1
    You will really, really like just having a site-to-site VPN, though. It makes life so much nicer. Commented Jul 7, 2009 at 14:03

My eyes are bleeding because I'm in a very similar situation with users who work from home.

My experience is that you can login to the VPN, then use ctrl-alt-del to change the pw, then you need to IMMEDIATELY lock and unlock the pc, this will update the cached login credentials.

This has worked on the majority of clients I've needed to use it on, however, I've had it not work once. No idea what was different, but take caution. I'd try it on a non critical machine first.

It does sound like in your situation a site to site VPN would prevent much headache.

  • That is the way it works, you log in with cached then log into vpn, then lock your machine while connected to vpn, and unlock with new credentials (which updates the cache). It's even the MS recommended way to do this. We do this with our remote workers all the time.
    – Zypher
    Commented Jul 7, 2009 at 16:03

Maybe I'm missing something, but if they change their password after connecting to the VPN, it should work fine.

EDIT: Ok, how about this for a workaround: The only reason I can think of for having a policy that prevents users from changing their passwords is to ensure that the sysadmins always know all passwords. Leave that policy in place for any local users.

For the remote users, disable that policy, and simply tell them that they shouldn't change their own passwords until you tell them to (and tell them what to change it to). Then when it's time for them to have a new password, you get them to log in, log in to the VPN, and change the password. If you want to be sure they changed it to what you told them to, you can also change it on the server.

If your management really wants to enforce the policy for remote users, turn on enough auditing that you can see if they ever change it on their own.

  • I think he's having the users logon with local accounts on the client computers, and then using the "poor man's trust relationship" to allow them to access domain resources (i.e. an account in the domain that matches the local account's username / password). Commented Jul 7, 2009 at 13:48
  • Not sure that will work, because we have a Group Policy setting preventing users from changing their passwords. It makes a lot of things easier, but it definitely makes some things a huge pain. (Company policy, not my decision)
    – colemanm
    Commented Jul 7, 2009 at 13:51
  • Wow, if that's right, that is ugly. Commented Jul 7, 2009 at 13:52
  • The remote users log in as the domain account on their desktops, not matching local accounts. The machines were pre-built here in the office, so the authentication info is cached on each machine. Not that this solution is all that superior...
    – colemanm
    Commented Jul 7, 2009 at 13:52
  • I was replying to Evan, but that also applies to your policy. Commented Jul 7, 2009 at 13:53

I don't know if this would help, but the Cisco VPN allows for connection before the windows logon. SonicWALL may have the similar option.

On CiscoVPN you get to it through Options, Windows Logon properties, then check the box for Enable start before logon.

Reboot the laptop and you should be prompted by VPN for your network username and password before you logon to windows.

(I realize this is an old post, but it may help present-day Techs)


This is exactly why I prefer a hardware site-to-site VPN solution. I know it doesn't help specifically with your question, but it will help dramatically with the majority of your problems with the software VPN.

It could be as easy as just using a couple Adtran 2050 routers (or even some consumer-grade Linksys routers will work) to build the appropriate tunnels. You're looking at a couple hundred bucks to save hours and hours of time.

  • A site-to-site VPN solution can't be that expensive. Most of the the SonicWall gear supports standards-based IPSEC tunnels, and even a very cheap router, like one of the DrayTek Vigor series, would support terminating a tunnel on the far end. Commented Jul 7, 2009 at 13:53
  • This is true. A site-to-site device would solve our issues at both remote locations we have, but you guys know the deal. Dollars for new hardware = generally non-existent.
    – colemanm
    Commented Jul 7, 2009 at 13:54
  • You've probably already spent more "dollars" on supporting such a configuration with "hacks" versus just getting a low-end router that supports doing an IPSEC tunnel. Commented Jul 7, 2009 at 13:57

The other question here, is what to do for Group Policy forced change? We too had our users change their passwords with the ctrl+alt+del and that let them change their passwords. However, we soon fell under the evil influence of SOX and had to force our remote users to change their passwords every 30 days (Previously they were exempt). At first we had a script ran and emailed the users of their approaching date, and if they didn't change it manually, the script locked their account out at 30+ days. However, that was obviously less than ideal. We used Checkpoint, did some investigation and found they had an option called "Secure Domain Logon". Basically when you first logged into your workstation, before anything else happened (directly after entering your username/password) your VPN client came up. You logged into the VPN, and then your machine downloaded all of its appropriate Group Policies... one of which, was forced password change every 30 days. The user changed their password and were good to go.

The only possibly issue was if they were using cached domain accounts... they had to lock their machine up to cache the credentials.

So tying this all up... perhaps look to see if Sonic has an option to allow your users to get their GPs before the machine logs in. Otherwise, Site VPN does all that for you as well.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .