Change Active Directory password over VPN

Question

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?

Solution 1

Edit:

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.

Solution 2

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.

Solution 3

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.

Solution 4

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)

View more solutions

Comments

[Spence]

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).

[colemanm]

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)

[Ward - Reinstate Monica]

Wow, if that's right, that is ugly.

[colemanm]

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...

[Ward - Reinstate Monica]

I was replying to Evan, but that also applies to your policy.

[Spence]

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.

[colemanm]

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]

I know, you're right :)

[Spence]

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.

[colemanm]

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!

[Spence]

You will really, really like just having a site-to-site VPN, though. It makes life so much nicer.

[Zypher]

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.