A/D Domain without network control?

[KarmaPoliceSTL]

All,

I have the following scenario that i want to pull off... but have limited access (nor neccesarily want to seek approval from the masters) to the core network services...

I would like to setup an A/D domain and attach a series of workstations and servers to it in our office (call it dom1)... however i would like the services from dom1 to be accessible to workstations of coworkers who do not work at my office...

they login to their workstations as dom2\user... which is fine, but i would like them to be able to "see" services hosted from my dom1.com servers...

I think all i need for this is the ability to have dom2's DNS services refer any dom1.com requests to my dom1 A/D-DNS server. Is this true, or is there more than just DNS to consider here? (remember, they don't need to login to their workstations as dom1\user, i'm not trying to manage at that level)

I'm just getting my feet wet with creating A/D domains, so am looking for advice/guidance to minimize the impact to the "rest of the company"... but still have their users be able to interact with my little domain in my office...

Hope that wasn't too newb of me

 

[calvinj]

Domain Trusts... Or give them a user on dom1 and have them type in credentials if they need something on your domain

 

[KarmaPoliceSTL]

i know they won't go for a domain trust... i'm ok with them having to type in credentials... but i'm worried they won't be able to see my servers at all...

all my servers exist in the DNS structure for my domain

all my coworkers' workstations have their DNS servers set by corporate DHCP

I don't want to add my servers into corporate DNS directly because then they will get our corporate default domain (dom2) though not really joined to the domain.

 

[Mak]

What is the nature of the services you are trying to provide? It seems like anything going against your IT dept would be against corporate policy anyway.

 

[KarmaPoliceSTL]

i work for a software development arm of a much larger corporation... i'm trying to build a development lab for some of my guys to work in... they key goal for our project right now is integrating our software's login/authentication with A/D user accounts... we have customers that will be coming to "beta test" the functionality and i have developers working in our other offices to develop the functionality...

I need the servers (windows) to be joined to the domain - dom1, i need some clients in my office to be joined to domain dom1... easy enough since i have full access to the servers/workstations i have setup a DNS server, DHCP, and A/D domain that services the workstations and the servers in the office here...

now i'm trying to extend access out to people that are on our broader corporate network... i just need them to be able to hit things like http://server1.dom1.com and or remote desktop into one of the workstations i have here to do "user testing"...

they login to their workstations as our actual company's domain\userid...

I'm a little unclear what i need to ask corp network admins for in order to have their workstations in other offices be able to establish a route to my "network" with as little footprint as possible in the larger corp network...

I think i just need to have them create a DNS referral entry of somekind so that any workstation in our corp network will hit be able to route to my little network...

but i'm unclear if there is more to it than that...

 

[KarmaPoliceSTL]

nothing?

 

[jjeff1]

You're doing 2 different things here.

But before we go into that, let me just warn you about attaching development to your production network. Development is, by it's very nature, prone to faults. You need to be aware that your developers could potentially torpedo your production network. Even if you're only accessing the production domain for user authentication, you can still lock out accounts by accident, or launch an accidental Denial of Service attack on your company. For this reason, development environments are almost always separate from the production network in all but the smallest and simplest of applications.

That being said, first you need a trust between your dev and prod domains. This will allow the production people (assuming they have the right permissions) to authenticate to your application against their domain.

For the DNS, you need the production DNS administrators to add records to your dev machines. They may simply add a secondary zone, with your DC as master, or might just make an A record in their zone. You may need additional DNS to get your dev servers to find the prod DCs for authentication.

 

[Mackintire]

I could be wrong but without domain trusts...they will not see your services via SMB or the normal windows browser service.

If you can have the primary corporate guys add some records into their local DNS to point to your server then those users could try reach your server, but they still won't be able to discover them and see them via windows networking. Your also going to have to add some routing rules on a layer 3 switch to allow data to route to your network, again this is assuming you are going to be inside your own subnet.
The final part of this is offering the users in the corporate network a way to find your resources.

There are ways to do this, but most of them require help from the corporate IT.

One way that does not would be to make a local web page on the corporate domain that has links to those DNS pointers which point to your resources. I would think the easiest way would be to make a page in sharepoint. But it also can be as simple as links send via e-mail that the enduser clicks on and enters their required credentials.

 

[Mak]

Another possible method of doing this would be setting up a completely separate environment. Setup a Remote Desktop Gateway and use that as a means to get "into" the dev environment. It would keep things separate, but it would still allow you to test.

 

[KarmaPoliceSTL]

hmmm, maybe i'm under thinking this, but those all sound like "over-thought" answers to me... I REALLY appreciate the help though, so let me try to clarify further...

Main Corp "Prod" Network
Domain = mycorp.com
network = 192.168.10.0/255.255.255.0
vlan = 123
DHCP Server = 192.168.10.5
A/D & DNS Server = 192.168.10.2

Branch Office "dev" network
domain = mysite.com
network = 192.168.30.0/255.255.255.0
vlan = 157
DHCP Server = 192.168.30.5
A/D & DNS Server = 192.168.30.2


Use Case 1
mysite.com\User1 logs into workstation 192.168.30.7
this authenticates against 192.168.30.2
they are able to access host.mysite.com because it's the same LAN

Use Case 2
mycorp.com\User2 logs into workstation 192.168.10.7
this authenticates against 192.168.10.2
user2 opens Firefox and navigates to http://host.mysite.com or SSHs to host.mysite.com or RDPs to host.mysite.com

- Question one, what do i need in DNS @ 192.168.10.2 so that this user2 request knows to go to 192.168.30.2 to get the corret IP address for host.mysite.com?

- Question two, what do i need to consider when trying to build a "route" from the "Prod" network to the "dev" network (currently i have a cisco catalyst 2821 here in my office linked through a router/modem/etc to our corporate office)... that catalyst provides for most drops in this office to be "Prod", but i have asked them to set up a segment for the "dev" outlets with the above subnet characteristics, but that i need to manage the IP assignment on my DNS/DHCP servers here, because i do not want to register all these "dev" boxes in production DNS and/or in the production domain...

My concern, is that A/D is so intrusive to DNS that if i setup an DC on 192.168.30.2 and thereby register all DNS entries for my devices in the DNS server on that box, no one in corp will be able to see anything i've setup because mycorp.com will know nothing of mysite.com...

 

[KarmaPoliceSTL]

been doing some googling... the closest idea i've come up with is to create a stub-zone in mycorp.com's DNS server for mysite.com... then any requests on the mycorp network for a mysite hostname should be routed to my DC here at mysite...

Is this correct thought process?

 

[x.sci]

You're about right. We've basically got the same thing set up here.

Just delegate mysite.com in corporate dns to your ad and make sure corporate network can access dev net. That's ip connectivity, probably gonna have to push some routes etc. This is something net admins will have to do for you, if it's not done yet.

But if you wanted users to authenticate to dev servers with their corporate accounts, you'd have to set up trusts (you usually want one-way trusts in this case).

 

[ElvisG]

I'm just curious but why can't the corp office just setup a VMware workstation / ESXi box and do a private sandbox with the test software? It just makes sense to go spend $2000 for everything then to have corp office break off in the future and leave you with the mess of cleaning up the AD Schema.

 

[KarmaPoliceSTL]

I'm just curious but why can't the corp office just setup a VMware workstation / ESXi box and do a private sandbox with the test software? It just makes sense to go spend $2000 for everything then to have corp office break off in the future and leave you with the mess of cleaning up the AD Schema.

I wish... they do this for the development arm of the organization... but since i'm in the services arm, and we manage industry specific projects and each project has its own set of "development projects" for customer specific extensions/customizations, we're kind of left to our own devices for that aspect...