The Story and the Roadmap

When we began writing this book, we had a lot of ways we could have designed our test bed. But in the end, we decided we wanted our test environment to be something that shows up time and time again in the real world.

In many companies, the Windows guys and the Unix/Linux folks never really fraternized. Because these two factions historically never really talked, two whole universes grew up quasiseparately. The Unix/Linux guys did their thing, and the Windows guys did their thing.

Only when Windows Active Directory was born did the two sides really need to sit down and really talk. And why did they need to talk then, when they never needed to talk before? The Domain Name Service, or DNS.

DNS is fundamental to both Linux and Active Directory, whereas Windows NT and earlier didn't depend on DNS.

So the two sides started talking. They had to work together, or they'd blow something up.

In this chapter, which sets the stage for the rest of the book, we wanted to make sure we captured the most common scenario we've seen in medium and larger environments. That is, when it comes to who "owns" the DNS, nine times out of ten, it's the Unix/Linux guys. However, since Active Directory also needs DNS, the Active Directory guys need a way to play too, which (a) doesn't interfere with the Unix/Linux guys' DNS and (b) allows the Windows guys maximum flexibility.

That way is called a delegated subdomain . To explain this without getting knee-deep in DNS theory, this allows the Linux guys to be the king of the castle and own the internal DNS namesay, corp.com . However, it also permits the Active Directory guys to have their own sandbox to build their own Active Directory sandcastles insay, a DNS domain named ad.corp.com .

To squeeze the maximum out of this book, we'll spend a little extra time in this first chapter setting up this common (and not all that complex) scenario. At the end of the chapter, you'll have one Windows 2003 Server running DNS, one Linux server running DNS, one Windows XP client (talking to the Windows server for DNS lookups), and one Linux client (talking to the Linux Server for DNS lookups). This is representative of the usual story we described: two factions that historically didn't talk much.

We'll also have one little bridge between the two DNS domains: the delegated subdomain from corp.com to ad.corp.com .

Figure 1.1 shows what our test network will look like by the end of the chapter.

Figure 1.1: This is what your test network will look like at the end of the chapter.

You'll install Windows in two parts and Linux in two parts . Here's how the rest of the chapter will go:

• You'll install the basic operating systems on your Windows 2003 and Windows XP machines.

• You'll install the basic operating systems on your Linux server and Linux client machines.

• You'll configure your Linux server as the primary master DNS server for corp.com . You'll then enable your Linux Server to delegate authority for a subdomain named ad.corp.com to your Windows DNS server.

• You'll configure Active Directory to reside in the ad.corp.com subdomainjust as many corporations do in the real world.

The Benefits of Subdomain Delegation

A delegated subdomain allows you to retain the benefits of a robust Linux-based DNS server for the corp.com domain, while still allowing the Active Directory server to be authoritative for DNS queries within ad.corp.com . By delegating authority for ad.corp.com to the Active Directory server, the primary DNS server for corp.com enables all machines in the corp.com domain to resolve names in the ad.corp.com subdomain. For example, you can be working on a workstation in the corp.com domain and still resolve hostnames such as xppro1.ad.corp.com .

Here, you see the delegation relationship between the corp.com domain and the ad.corp.com domain.

Don't worry if your real-world Active Directory doesn't live in a delegated subdomain. There's a huge number of Active Directories out there that are completely unrelated to what the Unix/ Linux guys have done. In the following example, an Active Directory resides in a domain that is completely unrelated to the original corp.com . It's called ad.corp.com , but no relationship has ever been established.

There's nothing wrong with that, per se. It just means that you won't be able to look up hostnames within the Active Directory domain from elsewhere in the corp.com domain.

There are alternative ways around this problem if subdomain delegation doesn't work for your needs, and we'll explore them right at the top of Chapter 9, "Windows/Linux Network Interoperability." In that chapter, we'll discuss some alternative designs that we've seen out there, as well as how to tweak your DNS settings to make everyone see everyone else.

 

Again, for the purposes of this book, we suggest that you follow along and create the machines and such exactly as we describe. Okay, these examples might not 100 percent perfectly match your precise environment. However, by first working through the examples with our baseline setup, you'll later be in a much better position to put the skills you learn here into practice into your real world.