Work Domain Network vs Home Workgroup Problem


W

wanjos

I work from home using a DELL D800 Latitude laptop with XP
Professional. I log on to my work domain using cached authentication
and VPN into the office over ADSL to access work resources. I also
have a home network (workgroup, not domain) of a few machines. One in
particular I use as a Print server and backup machine.

The problems is that when I cannot vpn into the office, I cannot
connect to my local machine - I lose access to the printer and
drives. Accessing the drive gives the following message: 'M:\ is not
accessible. The system detected a possible attempt to compromise
security. Please ensure that you can contact the server that
authenticated you.' So the system wants me to check with my work
server to get permission to acces my home machine.

I have created a user on my home PC that has the same name and
password as my work PC and I have tried turning simple file sharing on
and off.

Does anybody know how I can get my work PC to be able to access my
home network without domain authorisation or having to log in locally?
 
Ad

Advertisements

L

Lanwench [MVP - Exchange]

I work from home using a DELL D800 Latitude laptop with XP
Professional. I log on to my work domain using cached authentication
and VPN into the office over ADSL to access work resources. I also
have a home network (workgroup, not domain) of a few machines. One in
particular I use as a Print server and backup machine.

The problems is that when I cannot vpn into the office, I cannot
connect to my local machine - I lose access to the printer and
drives. Accessing the drive gives the following message: 'M:\ is not
accessible. The system detected a possible attempt to compromise
security. Please ensure that you can contact the server that
authenticated you.' So the system wants me to check with my work
server to get permission to acces my home machine.

I have created a user on my home PC that has the same name and
password as my work PC and I have tried turning simple file sharing on
and off.

Does anybody know how I can get my work PC to be able to access my
home network without domain authorisation or having to log in locally?

My first question is, do you always work from home? If you access the
corporate domain only via VPN, does it really make sense for your computer
to belong to the domain at all? If your machine will never actually be on
the same network as a DC (and a VPN client doesn't generally count as such)
I don't really see why it should; you don't get the benefits/group
policy/password change ability/etc for the most part, and the corporate IT
folk can't centrally manage your computer ...what's the point?

Anyway - what VPN client are you using? I'm presuming from your post that
you manually enable the VPN connection & use it on demand. When you 'can't
connect' via VPN, can you even ping the other (local) machine? Do you have
an IP address from the remote server (ipconfig /all) at the time? What if
you log out / back in? If you're simply booting up and logging in with
cached credentials, and can connect to your home network initially - but
then your manually-initiated VPN connection fails - I can't see how it would
then remove your ability to access any local resources.

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:DOMAIN\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.

HTH.
 
M

Mr. Grey

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.

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). 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...
My first question is, do you always work from home? If you access the
corporate domain only via VPN, does it really make sense for your computer
to belong to the domain at all? If your machine will never actually be on
the same network as a DC (and a VPN client doesn't generally count as such)
I don't really see why it should; you don't get the benefits/group
policy/password change ability/etc for the most part, and the corporate IT
folk can't centrally manage your computer ...what's the point?

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. 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.
Anyway - what VPN client are you using? I'm presuming from your post that
you manually enable the VPN connection & use it on demand. When you 'can't
connect' via VPN, can you even ping the other (local) machine? Do you have
an IP address from the remote server (ipconfig /all) at the time? What if
you log out / back in? If you're simply booting up and logging in with
cached credentials, and can connect to your home network initially - but
then your manually-initiated VPN connection fails - I can't see how it would
then remove your ability to access any local resources.

Why does it matter what VPN client the user is using? We know that it's
not a hardware endpoint...so it must therefore be VPN software and
launched Manually by the user...even then, inconsequential to the issue.
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:DOMAIN\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, but you did
not answer the question in the slightest 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.

That said, I applaud you for trying to answer and assist the user.

Cheers,
Mr. Grey
It had Blue Eyes...no, no...Green
http://www.redsphereglobal.com
 
L

Lanwench [MVP - Exchange]

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:DOMAIN\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?
 
Ad

Advertisements

M

Mr. Grey

lol, indeed it is all in the interpretation...I assumed, based on the
context that it was a typo...that said...get your hands on some other
VPN software/solutions (not that Microsoft's are not the BEST)
but..well, I'll leave that one alone heh.

Most of them should allow you to talk directly to the DC (depending on
where the device sits in your routed and security infrastructure).
Different requirements, as always, call for different security
models...though best practices should still be followed...

All of that huffing and puffing out of the way....Wanjos, can you
clarify if you are able to or not connect to the VPN and access your
corporate resources...or are you not able to connect to anything from
home, including VPN?

Cheers,
Mr. Grey
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:DOMAIN\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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top