VPN domain membership. Perhaps a dumb question.

[wharfish]

Need a workaround.

I have two domains. One is:

myserver.mydomain.com
remoteoffice.mydomain.com

The office are connected via a hard Cisco VPN link. I have a MS VPN server
at myserver.mydomain.com. My remoteoffice users who are traveling want to VPN
into myserver.mydomain.com from the road but their machines are not joined to
the myserver.mydomain.com but to the remoteoffice server.

Any way I can give them access to myserver via VPN without demoting the
remoteofffice PDC and joining them to the myserver domain?

Any help appreciated.

 

[Phillip Windell]

I have two domains. One is:

myserver.mydomain.com
remoteoffice.mydomain.com

The office are connected via a hard Cisco VPN link. I have a MS VPN server
at myserver.mydomain.com. My remoteoffice users who are traveling want to
VPN
into myserver.mydomain.com from the road but their machines are not joined
to
the myserver.mydomain.com but to the remoteoffice server.

Any way I can give them access to myserver via VPN without demoting the
remoteofffice PDC and joining them to the myserver domain?

No, you don't change their domain memberships,...you never do that. You
will cut the user off from their user profiles until the machine can be
brought back and rejoined to the correct domain. Wait to hear the screems
of agony when the user can't get to the things they had on their desktop or
"My Documents". They also don't have a user account on the "other domain"
so what good is it for the machine to be a member of it?

Off the top of my head here are few things that may help. They go from the
simplest to the most extreme. Regaurdless what you do,..the WAN link via
VPN is *always* going to be slower than crap. Internet speeds, no matter
how fast, are still a *lot* slower than normal LAN speeds, and then VPN
itself adds a lot of "overhead" to the communications. So don't expect them
to use a FileServer over the VPN,...every file they "open" has to "download"
over the Internet (VPN) before it will even begin to open.

Each of these is a separate idea:

1. Statically assign the laptop's DNS Config in the TCP Specs. You wil
notice that even when the machine is set to use DHCP (and it needs to be
DHCP for traveling) you can still statically assign the DNS. Since the two
networks are conneced via VPN the laptop can still find its own Domain
Controller and log into its own Domain. Basically is is no different than
if it was in your own physical location but on a different subnet. The
down side of this is that the Laptop will *fail* when hooked up in a hotel
room (or similar situation) where the AD/DNS does it no good and is
unreachable,..in such cases it needs to get a new DNS setting via DHCP. So
you'd have to teach the user how to switch the DNS TCP/IP Specs back and
forth,..which means they have to be local Admins on their Laptop (bad
deal!).

2. Another option is to setup Zones Transfers between the AD/DC/DNS on your
end and the AD/DC/DNS on the other network so that both networks are fully
"aware" of each other's DNS Structure and what machines are the Domain
Controllers for the two Domains. Now the traveling Laptop can just use
normal simple DHCP and use the local AD/DNS of the LAN they are on and that
will tell them how to find its own Domain Controller which it can get to
over the VPN and it should log into its own correct Domain.

3. You can branch off of the #2 idea and go as far to the extreme as setting
up Inter-Forests Trusts or throwing the whole Domain Structure out and
building a Single Forest/Single Domain with Multiple Sites,...or building a
Single Forest with multiple Domains (or Master/Child Domains) with Multiple
Sites. The Multiple Site would be required either way since that is how AD
maintains replication over slow WAN links.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

 

[wharfish]

Phil,

Yeah, I understand the hassle of demoting their PDC and joining them to my
domain which is why I'm looking for a workaround.

Question on the zone transfer solution:

Now the traveling Laptop can just use
normal simple DHCP and use the local AD/DNS of the LAN they are on and that
will tell them how to find its own Domain Controller which it can get to
over the VPN and it should log into its own correct Domain.

Just want clarify the environment. The remote user will be accessing the MS
VPN server on my network to get access to myserver. They have no MS VPN at
the remote office - only the direct hard Cisco link between sites. So it
actually has to log into my domain to get access. Does solution #2 still
apply?

Thanks.

 

[Phillip Windell]

Just want clarify the environment. The remote user will be accessing the
MS
VPN server on my network to get access to myserver.

No, they will not. You said the two Locations were already joined by a
Site-to-Site Link of some kind. The Laptop doesn't do anything other than
connect to local LAN it is at are at.

the remote office - only the direct hard Cisco link between sites.

Well, what exactly is a "hard cisco link"? We have to use correct industry
terminology for what is being discussed or we won't know what we are talking
about.

But anyway,...it really does not matter if it is a Cisco Site-to-Site VPN or
if it is a non-VPN Private Frame Relay between two Cisco routers. It is
still a Private Link between the Sites, that is all that matters,..the line
technology is irrelevant.
It is like a red Chevrolet -vs- a blue Ford,...it doesn't matter, they are
both vehicles driving down the road,...you'll still get where you are going.
The Chevrolet will just do it faster and cheaper than the Ford

So it actually has to log into my domain to get access. Does solution #2
still
apply?

Yes.

-----------------------If you use Option #1-----------------

1. After a long plane ride, the Laptop powers up on the remote office LAN
and gets an IP Config but retains the static DNS entries from the "Home"
LAN. The private Site-to-Site link (however it happened) between the sites
provides a path to the "target" DNS/Domain Controller over the Private
Site-to-Site Link

2. User hits Ctrl-Alt-Del to login and provides credentials

3. Laptop queries the DNS which is also the Domain Controller that it
normally uses anyway. It discovers that this is also the same machine that
is the correct Domain Controller. The laptop sends the login attempt over
the slow WAN link to the correct Domain Controller.

4. After a slightly longer than normal wait,...the Laptop is authenticated
with the Domain it is a Member of.

5. A blue Ford was found abandoned on the side of the road in the middle of
nowhere.

-----------------------If you use Option #2--------------------

1. After a long plane ride, the Laptop powers up on the remote office LAN
and gets an IP Config that includes the DNS of that particular LAN

2. User hits Ctrl-Alt-Del to login and provides credentials

3. Laptop queries the DNS of that LAN for the identity of the Domain
Controller for the Domain the Laptop is a Member of.

4. Good news. Because of the Zone Transfers done earlier this DNS *knows*
the identity of the correct Domain Controller and provides that information
to the Laptop. More good news,..the private Site-to-Site link (however it
happened) between the sites provides a path to the "target" Domain
Controller over the Link

5. The laptop sends its login attempt over the slow WAN link to the correct
Domain Controller.

6. After a slightly longer than normal wait,...the Laptop is authenticated
with the Domain it is a Member of.

7. A Ford saleman resigned and got a new job at a Chevrolet dealership


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

 

[wharfish]

Phil,

Thanks for the clarification. Sorry I wasn't more specific on the remote
office "hard-link". I'm adding new information here that would have been
relevant to the initial request. We're running Cisco PIX site-to-site VPN
between both offices on a TW business-class cable connection. The VPN server
sits outside the PIX firewall since the PIX eats up any outside VPN
connections from within the network.

To be clearer our traveler is in some strange city connecting to the VPN
server for myserver domain. Thus, my remote user can't authenticate to my VPN
server because it doesn't have a path to the traveler's remote office domain
to authenticate. So it seems to me a zone transfer wouldn't work here.

That should make it more interesting or more frustrating.

Thanks.

 

[Phillip Windell]

Thanks for the clarification. Sorry I wasn't more specific on the remote
office "hard-link". I'm adding new information here that would have been
relevant to the initial request. We're running Cisco PIX site-to-site VPN
between both offices on a TW business-class cable connection. The VPN
server

Ok, well the bottom line here:
If there is an Open Site-to-Site private link between the offices,..then,...
there is an Open Site-to-Site private link between the offices. Plain and
simple,..it doesn't matter how it got there or what equipment you use.

To be clearer our traveler is in some strange city connecting to the VPN
server for myserver domain. Thus, my remote user can't authenticate to my
VPN
server because it doesn't have a path to the traveler's remote office
domain
to authenticate. So it seems to me a zone transfer wouldn't work here.

Well, if the travler's laptop is a member of your Main Office
Domain,..then,...it is a member of the Main Office Domain. Again, plain and
simple, how he normal connnects and makes use of that is irrelevant. The
machine is a member of the Main Office Domain, that is all that
matters,..nothing else matters.

When he travels to the Remote Office (which I am forced to assume is not
where he is normally at),...he just plugs the laptop into their LAN,...turns
it on,..hits Ctrl-Alt-Del and logs in. The Options #1 or #2 will work just
like I said. However he did things back at whatever town he came from is
totally irrelevant,...he is not going to use whatever method that was while
he is at the Remote Office.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

 

[Phillip Windell]

VPN must be running. I tried to ping it and resolved an IP address of
172.16.x.x but no reply. After determining that the VPN was not connected
(using other means) I wondered how in the world I got name resolution
since I knew I hadn't contacted a DNS server across the VPN. But sure
enough, when I tried to lookup the name (an fqdn) using a known public DNS
server it resolved to that 172.16 address! Then I thought, "Why not make a
public record for your private IP addresses"? Nobody can route to them
anyway and It solves any issues with remote clients and DNS - any public
server will resolve the name.

Yes, I see how that would work. I'm not sure I would want to do it, but I
see how it works.

Glad to know other people pay attention to my post besides the one I write
to. That tensds to be why I sometimes write such long detailed
ones,...assuming that they might help someone down the line unrelated tot he
current conversation.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------