Mr. Grey said:
Se my responses below...
Wanjos, it is likely that as a security precaution (or even default
configuration) your VPN server or VPN endpoint device that your office
is using for VPN services is configured to disallow split tunneling.
In-short split tunneling causes a big risk to corporate networks
allowing VPN access, it is effectively a backdoor into the corporate
network and would allow the bypassing of perimiter security if your
endpoint (Dell Laptop) were compromised in any way. This is
considered a bad thing to do relative to security standards and
best-practices.
I completely agree with you, and would've written essentially the same
thing, but unless the OP has made a typo in the first line of his second
paragraph, this is occuring when he *cannot* VPN into the office. I then
assumed this was happening when he's had trouble with his VPN connection -
not when the tunnel is up.
So, the best thing that you can do is ask your corporate IT folks if
they allow split tunneling (let's hope that they know what it is and
have not pidgeonholled themselves into knowing only EXCHANGE).
Ahem. That, sir, brings you perilously close to a glove-slap.
If
they do allow split tunneling they can help you get it going. If
not, you will have to disconnect from VPN to print to your local LAN
or be able to access any shares that exist on your local LAN...more
info here:
http://en.wikipedia.org/wiki/Split_tunneling
Now, onto dealing with the response from Lanwench...
Lanwench....the reason for having your Laptop as a member of the
corporate domain is, infact, for management of said laptop and the
software thereon.
Yes. I'm a big fan of domains. However, a computer that will never actually
be in direct contact with a DC gets virtually no benefit of domain
membership (including, generally speaking, remote management) - and I find
plenty of potential detriments.
Furthermore, as a member of the domain it makes
accessing corporate resources simpler because you are authenticated
against the domain (both the computer and user account) and this
information persists as you would say, when the user is connected to
the VPN...
That said, I completely disagree with your assertion above
concerning domain membership and it's function relative to VPN
clients.
Entirely depends on the VPN client, really. If the user is using the native
Windows VPN client and selecting the option to logon to the domain using
dialup, at the login screen, it may be of some use - but I don't use or like
PPTP, and I haven't yet worked with a third party IPSec VPN client that
allows for seamless (or two-way) connectivity to/with the domain.
Why does it matter what VPN client the user is using? We know that
it's not a hardware endpoint...
Eh. We know it isn't a VPN link made between compatible hardware appliances,
yes. We don't know what the endpoint is on his company network.
so it must therefore be VPN software
Yes, I know that bit...
and launched Manually by the user...even then, inconsequential to the
issue.
VPN client software doesn't necessarily need to be launched manually / on
the fly
Are you using a login script, or persistent mapped drives? I would
go with the former (and probably manually run it after enabling the
tunnel to map drives to the remote domain servers). E.g.,
net use x: /del
net use x: \\remoteserver\share /persistent:no
net use y: /del
net use y: \\remoteserver\anothershare /persistent:no
[....and if you don't belong to the domain, you could append this
after the 2nd line:
/user
OMAIN\username
which would prompt you for your domain password once, and the
credentials would persist throughout the session]
Seems to me that a lot of your problems might simply disappear if
you didn't belong to the domain. Surely you can have a local login
and provide domain credentials for the resources you need to access,
once your VPN tunnel is established. I log in remotely via VPN to
several of my clients' networks and my computer doesn't belong to
their domains; it belongs to my own. It just might make things a
lot simpler.
Lanwench, this is absolutely not true...this would cause MORE problems
than it would fix (since it wouldn't fix the problem at hand). I
apologize and I'm not trying to be mean here or flame you
I'm pretty thick-skinned, and have taken no offense, but thank you for
including that. I don't mind an argument as long as it doesn't become a
personal attack, and you do not appear to be a boor.
, but you did
not answer the question in the slightest
I don't agree....again, you may now understand how I interpreted the
question, based on the first line of the OP's second paragraph. If that's
true as written, something else is awry.
and you sent the user on a
wild goose chase, talking about scripts etc etc... when it's a simple
VPN design / policy / configuration issue.
I join all my users' workstations to the domain and lock them down as much
as possible via various means, including group policy - and for laptops &
remote computers, I do the same, if:
* The user is on a laptop and roams around, with at least occasional direct
communication with a DC, or
* The remote office network where this user works, is connected via some
form of site link (leased line or VPN) to the corporate network
(and in that case, it would also be beneficial to have a local DC/DNS/GC
box there if at all possible)
Otherwise, I think it's more of a pain than it's worth The user generally
can't change his/her domain password, group policy can't be updated, I can't
manage the workstation directly from the server(s). [And if any network
member server or workstation has been out of contact with a DC for long
enough, it likely would have authentication problems even if it were to be
subsequently put in contact - I don't have exact details on that, sorry, but
IIRC it's some Kerberos-related mishegoss.]
From a security standpoint, I don't see that there's much benefit to ersatz
domain membership, either. Yeah, you can pass your credentials through - big
deal. Is the main office not requiring regular forced password changes for
some reason? If they are requiring it, can the VPN-client user actually do
it?. The bottom line is, allowing unfiltered VPN traffic from anywhere,
directly into the corporate network, is just plain risky, split tunnel or
no. Ideally, it's IPSec and using hardware endpoint at the other side,
ideally that endpoint is in a perimeter network in the main office, ideally
there's two-factor authentication in place, ideally the workstation is
locked down within an inch of its life such that the user can do nothing the
corporate IT folk don't want it to. But this may not be an investment bank
we're talking about here... frankly, sounds to me like this is the OP's own
computer and he's using it for many purposes on his own network. I'd be very
surprised if he wasn't a local admin on the box.
Regardless, I think persistent / locally controlled network drive mappings
are a bad idea, no matter what - VPN or no. My cheesy little batch files
aren't very sophisticated (and there are nicer ways to deal with this), but
they work.
That said, I applaud you for trying to answer and assist the user.
<curtseys>
Have we scared the user away?
Cheers,
Mr. Grey
It had Blue Eyes...no, no...Green
http://www.redsphereglobal.com
