5

In a bit of a pinch: a client needs to test an Active Directory enabled CRM system that consists of a SQL 2008 Server and a Windows 2008 Standard Server (the application server). As far as I know, Active Directory is required for end-user authentication and for application-to-SQL authentication.

We need to pull these two servers out of their current domain environment and setup at a testing facility that has Internet connectivity, but is not on the domain (foo.local) or any domain for that matter; they're just a bunch of workstations in a workgroup at the moment.

My initial thought was to setup an IPSec tunnel to the client's location to/from the testing facility, but I'm wondering if the LAN subnet overlap would be a pain (pfSense firewalls here) to manage and/or if changing the IP addresses of the two servers (FOOAPP and FOOSQL) to a different subnet to avoid the overlap would cause some grief in AD land (i.e. the domain controller would not "know" who these servers are).

My other thought was to setup a Read Only Domain Controller and bring it on-site to the testing facility, but from my cursory reading of the technet docs, it sounds like it needs to be able to talk to the client location domain controller(s).

Lastly, I know you can authenticate a workstation off-line with cached credentials: would that work with a member server? I'm assuming not as the SQL authentication that takes place between FOOAPP and FOOSQL probably does not utilize caching at all, but please enlighten me if not.

Any other options?

CLARIFICATION

These servers aren't being used in production right now. While they're joined to the customer's domain, there's no data in it and nobody's using it; they're just idle member servers at the moment. The SQL database will be loaded with test data and then used for training, but we'll be putting them back into the client's location and thus into production after this user acceptance/end-user training period is completed (with the test data removed).

We can't do the testing/training on-site because it would be too disruptive to the client's office and they don't have a large board room to accommodate the testing/training groups.

EDIT

I guess this can all be distilled into two questions:

  1. What happens to a (Read Only | Writable) domain controller when it's isolated from other domain controllers?

  2. Does Active Directory "care" about IP addresses? i.e. perhaps I can put these two servers on a different subnet temporarily and setup an IPSec tunnel so that these servers and workstations at the testing facility can communicate with the domain at the client's office.

Flimzy
  • 2,375
  • 17
  • 26
gravyface
  • 13,947
  • 16
  • 65
  • 100
  • I'm a bit confused about the testing facility - so, you need to pull the live servers out of the production environment and use them in the testing environment. Although, it's not entirely a test environment as it's using the live DB? – George Hewitt Jun 15 '11 at 21:04
  • @George: no live data yet, servers are not in production. The only "production" part is that they've been joined to the production domain at the client's office, and because the CRM software is tightly-hinged to Active Directory, I need some connectivity there to the DC (or bring a DC with us to the testing facility). – gravyface Jun 16 '11 at 00:11

5 Answers5

3

Active Directory functions by default in a multimaster replication mode, where each domain controller is independently authoritative for the domain(s) it manages. Thus, the test DCs will still be able to handle logins and receive updates (password changes and the like) even while disconnected. The two sets of DCs (the live ones and the ones in the test site) will slowly diverge over time, but that's only a problem if you intend to converge them afterwards.

Here is my suggestion for handling this scenario:

  1. Take a full system state backup of each testing domain controller before relocating them.
  2. Relocate the test DCs and get them settled in (join the workstations to the domain, create users, etc.).
  3. Run your tests.
  4. When you're ready to restore the DCs to production service, do a non-authoritative restore of the system state backups you took earlier. This will reset the DCs to their previous system state (of course).
  5. Return the test DCs to their original network and power them back on. They'll recognize that their copies of the Active Directory data are woefully out of date (due to the ancient USNs), and start sending replication requests to the production DCs that have been there the whole time.
Handyman5
  • 5,177
  • 25
  • 30
2

As this is for testing only have you considered running a VM on one of the machines and setting that up as a DC? Something like Virtualbox, despite not being a good choice for production use, would do fine in this case.

John Gardeniers
  • 27,262
  • 12
  • 53
  • 108
  • The box that houses both servers is running ESXi so yes, it's virtualized already and we could light up a DC VM, but I'm just not sure how that DC is going to behave when not on the same network as the other DCs; this is why I was thinking the Read Only DC might be an option. – gravyface Jun 15 '11 at 23:54
  • @gravyface, couldn't you set up the DC as a standalone domain and create just the accounts you need for testing? – John Gardeniers Jun 16 '11 at 01:20
  • No, the servers are ready to go (there's some integration bits they've built that ties into another production application), so taking them off the domain, reinstalling everything, etc. would not be ideal at all. – gravyface Jun 16 '11 at 01:26
1

1) When a standard DC is isolated from other DCs in the domain, it will continue to perform all of its functions, because every AD DC is able to work on its own; you'll only run into problems if you need access to one of the FSMO roles (such as performing a schema extension or running out of RIDs for new users), but this only happens in some very specific situations you're not likely to run into in a test environment. Of course, if you perform any modification to AD on one of the two segments (such as creating a user account or even changing a password), this will not be replicated to the other one... and if you ever plan about reconnecting them, you'll very likely run into replication conflicts.

This doesn't apply to RODCs: if one of them is isolated from the rest of the network and you don't have any writable DC available (even through a WAN link), most AD functions will be unavailable; you will not be able to create/modify anything, and this of course includes joining computers to the domain, managing user accounts ang groups, etc.

2) AD cares about IP addresses for two things: replicating data and locating the "nearest" available domain controller to avoid unnecessary WAN traffic; both functions rely on the definition of sites, subnets and site links. If you want to setup a WAN link to a location with a different IP addressing than your main LAN and put a DC there, you will need to define a site and a subnet in the Active Directory Sites and Services console; this will allow AD to manage replication between the DCs in the main location and the off-site one, and also will tell servers and clients in that location to talk to the local DC.

Massimo
  • 68,714
  • 56
  • 196
  • 319
1

Here's what I would propose:

Set up an isolated network on the current ESXi host. Clone the existing servers needed for the test and bring them up on the isolated network. If need be, you can sieze the FSMO roles on the isolated DC, as it's isolated from the production network this won't have any ramifications for the production network. Join a test client to the isolated domain and perform your testing.

This seems like the easiest solution to me.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
1

One issue you absolutely must consider when moving a DC to offline (as far as the production network is concerned) is that if it is off the production network longer than the tombstone time, it may contain objects that have been removed from the production network (known as lingering objects) and there can be consistency problems when it is reconnected to the production network. I've experienced such problems and it wasn't pretty.

It doesn't have to be problematic if you just take care of a couple issues in the process. If the domain was originally Windows 2000 and upgraded to 2003, the tombstone age is 60 days where if it started out as a Windows 2003 domain, tombstone age is 180 days. You can change the tombstone age, but this requires going in with ADSIedit or other tool to directly modify the Directory Service partition of Active Directory and I don't know if you would be comfortable with that or not. (the path is: CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=yourdomainsuffix) This will make Active Directory take up more space on your DCs since they will hold on to all removed objects longer before actually completely deleting them.

Before disconnecting the off site DC you should be sure to do a time sync to minimize any time drift while it is off site. The important part is when reconnecting, you should first configure strict replication consistency on the production network DCs prior to reintroducing the off site DC (using the Repadm tool with the /regkey switch) and be sure to set the off site DC up for a nonauthoritative restore, also prior to the reconnection, so it will get the new SYSVOL replicated to it as soon as possible.

Michael Ansnes
  • 11
  • 1