Best practices for remote Windows laptops that are rarely local to a Domain Controller?

[fusconed_]

We have many users that are rarely ever on our internal network and thus always log on with cached credentials and everything associated with not having a DC available. I'm looking for specifics on whether WSAM or Network Connect is a better connectivity choice and why. Also, if anyone has suggestions on things to specifically do or specifically avoid with regard to these users, I would appreciate that too!

Thanks.

[-red-_]

The choice between SAM and NC will vary based on what you're trying to accomplish, and how much administration you're willing to deal with. If your users need access to only a handful of resources on the network, and you can get away with using SAM, then that is your best bet. Just define what resources they have access to, and you're done. The only downsides are having to deal with managing the resources you're allowing via SAM, and the firewall policy you'll have in place.

If you need to provide the remote users with "look and feel" of being on the network: log-in scripts for drive mapping, etc, then you're probably better off with Network Connect. It allows you to define a much broader access, and then control everything via the firewall policy.

The downsides can depend on how you feel about split tunneling. By not allowing it, you will either have to deny users access to the internet, their resources.. etc, or be willing to absorb this traffic and allow it to traverse your network to get to the internet. If you plan on enabling GINA, then you have to take into account remote users who may be using their own workstations (they tend dislike GINA being loaded on their machines.) If you don't user GINA, you may still invoke their login scripts. The only drawback is that depending upon when their credentials expire, unless you are also using AD to authenticate them across the SSL, they will not be prompted to change them.

I can go on, but I think those are the key points to consider when making a decision. Hopefully this helps.

Regards,

[tdempsey_]

Hello,

We check for resources that are part of the domain and those that are not. They each get mapped to a separate role. Currently, the machines we own are set to kick off a logon script when Network Connect is started. We have, however, run into the password expiring issue that you mentioned. When we were testing, we tried GINA, but it proved someone unreliable... especially when using wireless connections (which I expected). You mention this:

"The only drawback is that depending upon when their credentials expire, unless you are also using AD to authenticate them across the SSL, they will not be prompted to change them."

Can you point me to anything that would explain using AD to authenticate across the SSL VPN (I assume the VPN part was suppose to be there). This is a big problem for us.

Thanks

[-red-_]

Instead of GINA, here's what I found works well, and helps accomplish more or less the same goal. We've disabled GINA for couple of our user roles, and had the end users enable the option (within their network connect client->tools->connections options) to log off on connect. If you have a user that needs to get their drive mappings, etc.. This option a allows a user to establish a VPN tunnel by logging in from their browser (or NC client itself.) Once session is established, the user is logged out of the workstation, yet the VPN session remains. User logs back in to the workstation, as well as the domain, and you get more or less the same functionality as you did with GINA. Granted, there's an extra step involved, but if it allows you to get rid of GINA, its well worth it. And since the user is actually logging in to the domain, instead of merely using cached credentials, they will get prompted if their password is set to expire, and will be able to change it.

Regards,

[tdempsey_]

We had looked at the "log off on connect" feature. I don't believe the higher-ups thought that loging in twice was a good option. Also, even if we did that, there would still be the chance that someone would have to login once with cached credentials and then again with "up-to-date" domain credentials, correct?

[-red-_]

Technically no, at least not that I'm aware of. As long as "log off on connect" is enabled, by virtue of logging a user off the workstation, while retaining the VPN tunnel, I believe the supplied credentials, rather than cached ones are used. At least this has been my observation. Someone please chime in if this isn't the case.

As for the argument that this constitues double authentication. To an extent, I would agree. However, if you get to a point where you're considering using GINA, you'd be essentially doing the same thing. To me, this is a worthwhile alternative.

[tdempsey_]

Yes, but if they have changed their password at work, then they go home and use the VPN. Even with "logoff on connect", they will have to login the first time with the old credentials, it will log them out and then they would logon with the new credentials. Correct?

[jeffreyl_]

Correct, you have to logon. The other quirk with it is it must be a cached domain account for it to work. I tried to invoke the feature with a local account and it just puked.

This is a work around solution developed according to JTAC for Vista.

GINA Enabled NC on XP is a good solution, but it is not perfect. I was not able to deploy it at our company becuase for some reason it must be the only "GINA" Chained app on the computer and I ran into conflicts with another application.

I added gpupdate /force to the NC start up script to make sure the GPO's are updated. We also are going to start notifying users via email that their passwords are about to expire so they can manually change them via ctrl-alt-dlt. Hate to put it back on my users, but I have not found a better solution.

Still looking for a good solution that does not feel like a "bandaid" for the same problem you are dealing with.

[dusannovakovic_]

On IVe, enable a script that simply does the command "gpupdate" when a remote windows pc is establishing a nc tunnel.

Working with cached domain credentials works - but only limited. And when domainaccount changes, but the cached credentials are equivalent to the old domain password, user will have problems.

This is solved be running command "gpupdate" after nc tunnel is established.

[tdempsey_]

But, again, the user still has to log in once with the cached credentials. Seems there is no way to get around that. I'll ask my windows guys if they can put the gsupdate /force in the startup script.

Thanks for the info.