Two AD domains on same subnet - yes or no? 1

[substitute]

Sorry for a long question. I hope it is interesting enough to merit reading!

Thanks to a takeover of our business and integration of IT systems we now have two AD domains on the same subnet. The old domain ("olddomain") had two servers, both domain controllers (primary and backup) and 45 workstations. One of the servers is a production database server so had to be retained. It is not the primary DC so that was retained. The servers have addresses 10.10.174.1 and 3 on the network.

The new domain ("newdomain") is huge and spans several subnets. All the workstations were joined to the new domain but retained their 10.10.174.x IP address range. The new domain controller is 10.11.2.13.

Users log in to their workstations using new "newdomain" credentials but access the database server using their "olddomain" login credentials. We get these in to the system by opening a shared drive on the old server and entering credentials as olddomain\olduser. These get stored so the user can access just about anything without entering new credentials.

Now for the problem.

Every now and again, in some cases several times a day, in others once a week, the user gets locked out of the database server. It might appear unreachable, or it might claim "you can't access the same resource using different credentials". To get back in the user has to disconnect any mapped drives, maybe delete stored passwords in "user accounts" and log out/back in. Usually they get access without re-entering "olddomain" credentials.

I think "two AD domains on one subnet" is the cause - the system is confused as to where to find the login server for the old domain. Once in a while logins fail on the new domain as well, with the same delete/logout/login resolution.

What does everyone think? I could move the database server to a different subnet, but the new parent company won't let me because they don't know what else might go wrong.

Thanks in advance

 

[TechyMcSe2k]

The two domains should be seperated by physical network devices. Then create a forest two way trust between the two domains. Set up DNS on both sides to forward DNS requests. example: from newdomain to olddomain to resolve the IP of the olddomain dns and vice versa


_______________________________________
I hope any help I give leads to great successes.
MCSE, MCSA, MCTS, CCA, VCP, CCNA

 

[Torturednacho]

wouldnt it be easier just to create a child domain from 1?

 

[substitute]

The message seems to be that there could be problems with the current setup.

I don't know about this stuff, I've only ever worked with a single domain system. However, if I point the right people in the right direction I'm sure they can solve it.

The reason the server was left on its old domain was that it's a legacy system with little or no tech support, but I know a lot of processes run under credentials from the old domain. We thought it would be easier not to touch it - until this problem emerged.

When TechMeSe2k says physical separation I assume he means a router or two? so the domains access each other through a gateway device?

TorturedNacho, the pearent company use several subdomains, "newdomain" is "newdomain.parent.com" and other offices are "otherdomain.parent.com" etc. Can we easily turn "olddomain" (actually "olddomain.local") into "olddomain.parent.com"?

Sorry this is all cryptic, the actual names have to be changes to protect the guilty!

Thanks everyone

Ian

 

[TechyMcSe2k]

If he can add that old database machine to a child domain...then surely he would be able to move the DB machine into the primary domain where it is needed.

Are you just unsure of functionality of the production database server if you change its domain and possibly IP? on the old domain, does it still have it AD structure and 45 workstations; if so, are there plans to migrate those users into the primary companies network/AD? If not, I'll stand behind keeping its domain seperate due to the same network/subnet configurations.

Then there are permissions issues I am sure on the DB machine that they are a little sensative about changing properly to prevent downtime.

Torturednacho:
It seems that they may be weary in changing the servers domain affiliation (which adding to child domain would do). Keeping the networks seperate, but adding a trust so that current users in their main domain can easily access resources in the old domain will make life simpler. Plus, if they ever decide to migrate those users and applications to their primary domain; it will be a cleaner scenario than just throwing inherited junk into their clean production. I would recommend a child domain only if they migrate from old domain to a clean child domain. Migrate users with SID history will help in retaining access to resources from the old domain when and if the DB server is migrated to production.

Creating a Forest Trust:

http://technet.microsoft.com/en-us/library/cc780479.aspx

_______________________________________
I hope any help I give leads to great successes.
MCSE, MCSA, MCTS, CCA, VCP, CCNA

 

[substitute]

Thanks Techy, I'm getting the general idea and hopefully the new parent's IT guys can do what is required. The original "two domains on same network" strategy was tried because had it worked there would have been no disruption, and it almost does work, except for the random authentication failures. If we split the networks we should have the same result, without the failures.

In a few months the old system will be redundant due to adoption of a completely new system company wide. Until then (and like most IT projects "then" has already moved back 8 months months) I have to keep it going as best I can with no budget!

Thanks again