Unfortunately this is not always the case as expanding will usually mean more work for you.

But in case the company you work for opens up another office in a different city, state, or country, in order to keep your network manageable it’s best to put the new office into its own child domain — a.k.a sub domain.

Why Add a Child Domain?

There are several good reasons for splitting the new office into its own child domain, here are 3 of them:

• Less Network Traffic between your main office and the new one – that means your company will spend less money on the direct connection between the two offices and you will never experience a network delay.
• You will be able to delegate control of the new network to another administrator who actually lives in the location of the new office. If your offices are close and you are about 20 minutes away to any one of them, then I guess that’s no big deal. But if your main office is located in New York and the new office is going to be in … oh, let’s say Paris, how the heck are you going to get there in case of an emergency? See my point?
• Having the child domain will allow you to keep track what is going on in a specific office.

These are only the main good reasons for creating a child domain. Once you start working in an environment with sub domains you will realize there are a lot more good reasons for splitting the two locations in your Active Directory.

Before you begin …

1. In order to create a child domain on your network, you will need another server, or rather a Domain Controller.

You can build that DC in your main office and then ship it out to the new office. This DC will also be a Global Catalog as well as DNS Server to assist all the clients in the new office with any DNS requests, etc.

2. You also need to prepare your current network for the new sub domain. So before you begin with the new DC configuration you need to do the following:

• Create a new site in your Active Directory that will represent the physical structure of your network. In my example our main office is in New York and the new one is in Chicago. Based on that info, you would create a new site for the Chicago office.
• In addition to the new site you will also need to create a new subnet for your new location. It will allow you to track all of your machines by location. This new subnet should be assigned to your new location.

Once you prepare your network as mentioned above, we are now ready to create a new Domain Controller.

Creating a New Domain Controller

Once you have prepared your network for you child domain and have created the site and sub domain, it’s time to install the new DC on our new site.

As you can see our main office is in New York and we have 3 DCs already configured in the New York Site (see the screenshot below).

Our new site called Chicago doesn’t have any DCs configured yet –- this is where we are going to configure our new DC.

1. After you have installed Windows Server 2008 on your new machine and completed all the Initial Configuration Tasks, open up Server Manager and click on the Roles section.

2. We will need to install the Active Directory Domain Services (ADDS) Role first. So go ahead and check the box next to it and click Next.

3. In this window you will see some additional information about ADDS. Once ready, click on Next.

4. As always you are being informed that once the installation is completed the server will restart and you will need to use the ADDS Installation Wizard to make the server a fully functional Domain Controller.

Go ahead and click on the Install button.

5. The installation will now run for a few minutes.

6. Now it’s time to click on the link and run dcpromo.exe.

7. Go ahead and click Next on the welcome screen.

8. And Next again (for more detailed information on this step you can check out this post on Installing Active Directory Domain Services on Server 2008).

9. Since this is going to be your child domain, make sure you select the Existing forest option and then select Create a new domain in an existing forest.

When ready, click on the Next button.

10. Type in your domain name with the correct internet suffix. In my example I’m are using our globomantics.com domain.

Since this domain already exists and you are logged in to this machine only as a local administrator you will also need to enter alternate credentials of a domain administrator in order to proceed.

So go ahead and click on the Set button.

11. Enter the domain administrator’s name and password, then hit OK.

12. When ready, click on Next.

13. In this step you will need to enter the Fully Qualified Domain Name (FQDN) of your child domain in two steps.

The first is the FQDN of your parent domain. In our example it is going to be globomantics.com.

Next you need to enter the single-label DNS name of your child domain — that means anything that is before the globomantics.com.

In my example I entered na for na.globomantics.com — as seen on the bottom.

That will be our FQDN for the new child domain. Once ready, click on the Next button.

14. Now it’s time to select a site for this DC.

Now you see why we needed to create the new site before we started this installation. Select the correct site and click Next.

15. As mentioned earlier we are going to make this DC be our DNS server as well as Global catalog for our new site.

Make sure both check-marks are checked and then click on the Next button.

16. I would recommend leaving the default locations for these databases unless you have a really good reason not to. Click Next.

17. In this windows you will need to setup the Directory Services Restore Mode Administrative Password for restore purposes.

Go ahead and type that in and then click on the Next button.

18. On this summary window double check your selections and when ready click Next.

19. You can check the box Reboot on completion and let the installation complete.

Congratulations! Your Child Domain has been created!

Related posts:

• Windows Server 2008: Install Active Directory Domain Services
• Server 2008 Active Directory User Groups — the Easy Way!
• Windows Server 2008 Active Directory — Creating Users is Easy!

Active Directory provides the structure to centralize the network and store information about network resources across the entire domain. Active Directory uses Domain Controllers to keep this centralized storage available to network users.

In this scenario we are going to install Active Directory fresh with a brand new Domain Controller after a fresh install of Windows Server 2008.

Requirements for Active Directory Domain Services

Let’s go through some of the requirements for a fresh install of Active Directory Domain Services. Some of these will be required to be done before hand; others as noted can be done during the install:

• Install Windows Server 2008
• Configure TCP/IP and DNS networking configurations
• The disk drives that store SYSVOL must be on a local drive configured NTFS
• Active Directory requires DNS to be installed in the network. If it is not already installed you can specify DNS server to be installed during the Active Directory Domain Services installation.

Once you verify that these requirements have been met we can get started.

Install Active Directory Domain Services via Server Manager

For the first example let’s start by installing Active Directory through Server Manager. This is the most straight forward way, as a wizard will guide you through the steps necessary.

1. Start Server Manager.

2. Select Roles in the left pane, then click on Add Roles in the center console.

3. Depending on whether you checked off to skip the Before You Begin page while installing another service, you will now see warning pages telling you to make sure you have strong security, static IP, and latest patches before adding roles to your server.

If you get this page, then just click Next.

4. In the Select Server Roles window we are going to place a check next to Active Directory Domain Services and click Next.

5. The information page on Active Directory Domain Services will give the following warnings, which after reading, you should click Next:

• Install a minimum of two Domain Controllers to provide redundancy against server outage (which would prevent users from logging in with only one)
• AD DS requires DNS which if not installed you will be prompted for
• After installing AD DS you must run dcpromo.exe to upgrade to a fully functional domain controller
• Installing AD DS will also install DFS Namespaces, DFS Replication, and Filer Replication services which are required by Directory Service

6. The Confirm Installation Selections screen will show you some information messages and warn that the server may need to be restarted after installation.

Review the information and then click Next.

7. The Installation Results screen will hopefully show Installation Succeeded, and an additional warning about running dcpromo.exe (I think they really want us to run dcpromo).

After you review the, click Close.

8. After the Installation Wizard closes you will see that server manager is showing that Active Directory Domain Services is still not running. This is because we have not run dcpromo yet.

9. Click on the Start button, type dcpromo.exe in the search box and either hit Enter or click on the search result.

10. The Active Directory Domain Services Installation Wizard will now start.

There are links to more information if you want to learn a bit more you can follow them or you can go ahead and click Use advanced mode installation and then click Next.

11. The next screen warns about some operating system compatibility with some older clients.

For more information you can view the support documentation from Microsoft and after you have read through it go ahead and click Next.

12. Next is the Choose Deployment Configuration screen and you can choose to add a domain to an existing forest or create a forest from scratch.

Choose Create a new domain in a new forest and click Next.

13. The Name the Forest Root Domain wants you to name the root domain of the forest you are creating.

For the purposes of this test we will create ADExample.com. After typing that go ahead and click Next.

14. The wizard will test to see if that name has been used, after a few seconds you will then be asked for the NetBios name for the domain.

In this case I will leave the default in place of ADEXAMPLE, and then click Next.

15. The next screen is the Set Forest Functional Level that allows you to choose the function level of the forest.

Since this is a fresh install and a new forest with no additional prior version domains to worry about I am going to select Windows Server 2008. If you did have other domain controllers at earlier versions or had a need to have Windows 2000 or 2003 domain controllers (because of Exchange for example), then you should select the appropriate function level.

Select Windows Server 2008 and then click Next.

16. Now we come to the Additional Domain Controller Options where you can select to install a DNS server, which is recommended on the first domain controller.

If this was not the first domain controller you would have the options of installing Global Catalog and/or setting this as a Read-only Domain Controller. Since it is the first domain controller, Global Catalog is mandatory, and a RDOC controller is not an available option.

Let’s install the DNS Server by placing a check next to it and clicking Next.

17. You will get a warning window about delegation for this DNS server cannot be created, but since this is the first DNS server you can just click Yes and ignore this warning.

18. Next you can choose to place the files that are necessary for Active Directory, including the Database, Log Files, and SYSVOL.

It is recommended to place the log files and database on a separate volume for performance and recoverability. You can just leave the defaults though and click Next.

19. Now choose a password for Directory Services Restore Mode that is different than the domain password. Type your password and confirm it before hitting Next.

Note: You should use a STRONG password for this and will be warned if it doesn’t meet criteria.

20. Next you will see a summary of all the options you have went through in the wizard.

If you plan on creating more domain controllers with the same settings hit the Export settings … button to save off a txt copy of the settings to use in an answer file for a scripted install. After exporting and reviewing settings click on Next.

21. Now the installation will start including the DNS server option if selected. You will notice a box to Reboot on completion that you can check to reboot soon as everything is installed (A reboot is required you can do it manually or use this function to do it automatically).

NOTE: This can be from a few minutes to several hours depending on different factors.

Confirming Active Directory Domain Services Install

When you reboot you will be asked to login to the domain, and be able to open Active Directory Users and Computers from the Administrative menu.

When you do you will see the domain ADExample.com and be able to manage the domain.

You have now successfully installed Active Directory Domain Services and the first Domain Controller.

Related posts:

• Server 2008 Active Directory: Adding a Child Domain
• Server 2008: Install Active Directory Certificate Services
• Install Read-Only Domain Controller on Windows Server 2008

In addition, it can provide a way for local administrator privileges to be assigned to a user that you need to be an administrator at the local level, but who you do not want to allow a backstage pass into the domain-wide AD database via replication.

However, because the RODC intentionally limits its participation in the enterprise-wide AD structure, it is wise to limit its use to only those times when the additional level of security is required.

Let’s Get Physical

First thing is first. Microsoft has spent the years since the release of the first Windows NT products building up a full scale security model around the Windows Server products. However, security is a mission that never ends.

The hackers don’t sit around eating cold pizza and wearing their thumbs out on Xbox moaning about how they can’t use the buffer overflow trick to gain access to secure systems anymore.

Instead, they sit around eating cold pizza and wearing their thumbs out on Xbox while wondering what would happen if they could somehow parse a command string with a hex editor when the command is actually expecting ASCII text … Or at least that’s what it looks like on YouTube.

I wouldn’t know because I wear a white hat (but not after Labor Day), I don’t have an Xbox, and I have some sort of genetic defect that prevents me from using both my thumbs and index fingers at the same time. Thus, since the days of Playstation and its accursed F1, F2 buttons, I have been relegated to the last kid picked for dodge ball status of video games.

One of the new frontiers of security concerns is theft of computers with important data. You’ve heard all about the many laptop thefts. The RODC exists so that you won’t start hearing about all of the Domain Controller thefts.

Don’t Break It To Save It

The Active Directory system is setup to be a robust and fully scalable way to implement security throughout your enterprise. Past versions of Windows Server products suffered from various scalability issues.

One of those issues was caused by the original domain model that had only one Primary Domain Controller operating with many Backup Domain Controllers. The problem was that too much activity had to take place on the Primary Domain Controller.

In an enterprise with several hundred or even thousands of Backup Domain Controllers, the Primary Domain Controller spent so much time replicating that it could be overwhelmed and unable to handle other requests flooding in. The solution was to distribute the responsibilities of the Primary Domain Controller to many servers instead of just the one.

So, in a regular AD environment, Domain Controllers replicate with each other, eliminating the bottleneck at the single replication point. The system has been more robust ever since.

The RODC acts in many ways like the old Backup Domain Controller. It only replicates back to a more powerful Domain Controller. RODCs do no replicate amongst themselves. Implementing too many RODCs without enough regular DCs can trigger a similar problem to the old Primary-Backup paradigm because too many RODCs will be overwhelming the too few DCs. So, while your AD might be more secure, it will be less usable.

So, how do we choose between installing a RODC and a DC? First, keep in mind that RODCs do not provide greater protection for network based attacks. A RODC only provides more security should someone gain physical access to the server, usually through theft. For those servers locked into secure racks in the nice, cool, monitored, server room this shouldn’t be an issue.

When servers are installed elsewhere, usually remote sites, then we need to evaluate the situation. Who will be watching and maintaining these servers?

Are they trained IT administrators who know how important the servers are?

Or are they financial analysts who think all servers look like the WOPR?

In other words, how hard would it be for someone to walk in off the street and trick the employees into access, or how hard would it be to slip in through the back door that is never locked?

We aren’t talking about master cat burglars who defeat laser beam security systems by memorizing the timing of the laser beam sweeps. (By the way, if you are going to go through the trouble of installing a laser beam security system, would it really be all that hard to put in some sort of random number generator so the pattern can’t be memorized? I’m just saying.)

How to decide when we should install a Windows 2008 Server as an RODC? A simple checklist should cover most scenarios:

• If the server is stored in an open or unlocked area — install RODC
• If the server will be installed at a location without trained IT personnel — install RODC
• If the server is stored in a locked area, but personnel other than systems administrators also have access to the area — consider installing RODC
• If the site will have more than two Domain Controllers — then limit installs of RODC
  
  RODC will not replicate with each other, only with Domain Controllers. Each RODC at a remote site is one more server using the WAN link for replication. For one or two servers, this probably won’t have a noticeable impact, but you don’t want twenty RODCs using your WAN link for replication.
• If the server is stored in a secure server room or other area with restricted access — do not install RODC

Pretty easy, right?

Settle Down Mel …

Systems administrators tend to be clever people. When talking to them about physical security and the RODC they start to imagine all the ways someone could possibly come after their servers, and because sys admins also tend to be movie buffs, things start to get a little crazy.

In the movie Conspiracy Theory, Mel Gibson’s character balances a bottle on the doorknob.

That way, if anyone tries to get in, the bottle will fall, and he’ll have time to slip out the escape hatch and burn down his apartment.

If this is starting to sound like a good idea for your server areas, then it is time to take a deep breath and re-center.

Ommmmm. Ok, that’s better.

While the threat of a stolen server is real, it isn’t something that roving gangs of ninjas engage in on a nightly basis.

If someone breaks into your server room through the ventilation system, disables the alarm, repels down ropes, and loads your servers into phony ambulances for transport, there is probably a bigger problem than the security of your AD infrastructure. The FBI, NSA and the rest of the king’s horses and men will probably be helping you put your network security back together again.

If a delivery man with a delusion of grandeur walks off with a Domain Controller after saying "Candy-gram" to the receptionist — that is what the RODC is for.

Remember, just because someone takes your sever doesn’t mean that it sings like a canary. There is still a login screen, encrypted data, file permissions, and a host of other security measures standing in the way of the would-be pirates. The delivery man has several long nights ahead of him and when he finally gets anywhere, your AD database will have updated so many times that what he has on the RODC won’t be worth much.

So, implement good security and use the RODC where it makes sense and you can feel secure that you have done a good job with your infrastructure.

But, on your way home tonight, I’d make an extra U-turn near the freeway to make sure no one is following you before you go home and crank out your secret leaking newsletter. After all, maybe they are after you …

Related posts:

• Don’t Worry He Can’t Write: The Story of the RODC
• How to Setup & Utilize RODC on Server 2008 Server Core
• Lesson 6: Windows Server 2008 RODC – Read Only Domain Controllers

The computer systems for the XYZ Company were managed by professionals whose full-time job was to install, configure, and maintain the systems.

So if Joe in accounting had a problem with his computer he would call you or Ted, or one of the other admins, and you would stop by Joe’s desk on the way back from grabbing a bagel in the company cafeteria.

If the XYZ Company got big enough it would open up another office. Management would decide which employees should be in which location.

Accounting might stay in the original headquarters while you and the marketing group moved to the new location ("So long, Joe.")

Along the way, things changed …

Companies needed not just two or three big offices, but maybe two or three big offices and DOZENS of smaller offices. Some of those offices might have just a handful of employees.

Your average Sys Admin would get pretty bored maintaining just eight computers. The XYZ Company is not interested in paying for a fully qualified systems administrator for a dozen offices if they aren’t going to be fully utilized.

So, IT responsibilities get handled by a technician or in some cases by Rob, the contracts guy.

Now, Rob is a good guy. He makes sure the Nowhereville office’s contract get approved quickly, and he also manages the local softball team.

His wife is the manager at the local grocery store/video store/bowling alley/Post Office.

The thing about Rob is, that although he is a good guy and can change a printer toner in less than eight minutes, he doesn’t really know a lot about servers.

So, when the professional looking gentleman in the uniform that looks kind of like the ones the phone company guys wear shows up to make the network faster by tuning the Domain Controller, well … Rob points him in the direction of the "big computer" and offers him a cup of coffee.

You Ain’t Got a Thing If You Ain’t Got Physical Security

Microsoft has spent millions of dollars and many years working on the security for its Windows Server products. These days, a Microsoft Server is about as secure as any server can be; that is if you are coming at it from over the network.

With the proliferation of remote offices for companies both big and small, there are more and more computers out there. The workstations are secured in their own way, and if one is compromised by theft or a local administrator run amok the damage is limited to whatever was on that system.

There really is no way to leverage a single computer into enterprise access once the system has been removed from access.

But, the Computer Grinch is not so easily defeated, and one day he got an idea, a really fantastically rotten idea. If he got a Domain Controller he could take as much time as he wanted to get inside at the goodies, and when he did, he would have a way into your whole enterprise right in his hairy green hands.

For a smaller organization it might be possible to rebuild the Directory for security purposes, but for a large organization with hundreds or thousands of man-hours in the design, development, and implementation of a complex Active Directory, that isn’t a viable option.

Just hoping that the Computer Grinch doesn’t work something out isn’t very viable either.

Reading, No Writing, Rithmitic

Although this scenario sounds a bit far fetched, computer hackers aren’t just going to go away. And with good full scale attacks becoming harder to implement thanks to the growing use of firewalls, secure server systems, and even savvier users, the idea of walking off with a domain controller starts to look a little bit better.

So Microsoft has developed the Read-Only Domain Controller. The Read-Only Domain Controller (RODC) is pretty much the same thing as a Writable Domain Controller as far as your users and their resources are concerned. Where it is different is in how its AD database is handled.

Here is a quick point of terminology. Microsoft considers a regular "writable" domain controller to be a Domain Controller. A non-writable domain controller is a Read-Only Domain Controller.

So, if you see the phrase "Domain Controller" it means a full writable Domain Controller. Only if you see the words "Read-Only" or the letters RODC should you think "read only."

The RODC allows your enterprise to put a controller in any office regardless of the level of security that office has. If you want to put a RODC underneath the receptionist’s desk or next to the vending machine, that’s fine. (It’s not great, so if you have a better spot then use it.)

A RODC contains, as one might expect, a Read-Only Active Directory Database, but it isn’t as simple as it sounds.

For starters, the database isn’t really read-only in the traditional sense. The data can be, and is, updated. It is just that the updates only come in one direction: FROM the other domain controllers.

So, any changes that might be made by someone using a compromised local administrator password or a disgruntled field technician won’t be replicated back into the Enterprise. The damage is limited to the RODC.

This means that even if a domain controller was stolen there is no need to change your entire Directory because every second the stolen domain controller is off the network, its database gets staler and staler until it is completely worthless even to the most talented of hackers.

This level of security also provides a way around that nasty problem of needing someone to handle something locally on a domain controller that requires an administrator password like installing a driver or replacement hardware.

In Server 2003 giving someone an administrator password on the domain controller means giving the full access to the enterprise’s Active Directory. While Mr. Local is politely saying, "Ok. Yeah. Ok," to your directions over the phone, he could be giving his user account admin rights. Or, if he’s a little smarter making a new hard-to-spot account with admin rights. Neither one is a good thing.

On the other hand, while giving someone a local admin password to a RODC does give them full access to that machine, it stops there. No changes that are made while in the RODC get propagated back to the enterprise, so your guy gets nothing out if it.

Not a Problem

The most common thing I hear when people learn about the Read-Only Domain Controller is that physical security of the Domain Controllers isn’t a very big problem. I always respond with one word, "Yet."

In the end, the RODC solves a fairly uncommon security issue, that of domain controller theft, and a slightly more common security issue of employee tampering.

It’s likely that neither causes your organization much trouble today, and that is a good thing. By implementing the Read-Only Domain Controller now, you can make sure it stays that way.

And, isn’t it nice to be out in front of the danger instead of catching up?

Related posts:

• To RODC or Not To RODC, That Is the Question
• How to Setup & Utilize RODC on Server 2008 Server Core
• Server 2008 Active Directory: Adding a Child Domain