v

Books

Contents
Chapter 4 Inside Windows Server 2003 Forests and DNS . . . . . . . . . . . . . 63
Securing Forest Trusts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Cross-Forest Trust Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Authentication Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
SID Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Windows 2003 DNS Additions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
DNS Health Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Windows 2003 DNSLINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Conditional Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Setting Up Conditional Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Stub Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Creating Stub Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Conditional Forwarding vs. Stub-Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Next: Windows 2003 Security Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
 63

Chapter 4:

Inside Windows Server 2003

Forests and DNS
In Chapter 3, I discussed the management aspects of Windows Server 2003 (Windows 2003). I
explored new Active Directory Users and Computers console functions, including the drag-and-drop
feature, the multiple-select feature, and the saved-queries feature. I introduced the Group Policy
Management Console (GPMC) and forest trusts, including cross-forest trusts. In this chapter, I
continue to delve into cross-forest trusts, and I introduce new DNS features.

Securing Forest Trusts

In Chapter 3, you saw that a cross-forest trust might be required if you had already upgraded various
Windows NT domains or Windows 2000 domains to Windows 2003 and wanted to join them. In the
example that Figure 4.1 shows (also presented in Chapter 3), you can see that I’m tying together
three separate Windows 2003 forests: the Corp.com forest, the Sales.jeremyco.com forest, and the
Bigu.edu forest.

Figure 4.1
An organization’s cross-forest trusts
Cross Forest Cross Forest
Trust #1 Trust #2

corp.com sales.jeremyco.com bigu.edu

upgraded NT 4.0 domain;
maintains old NetBIOS name
of SALES

Forest Forest sales.

corp.com jeremyco.com

Forest bigu.edu
europe.corp.com
science.bigu.edu registrar.bigu.edu

As I noted in Chapter 3, tying the forests together doesn’t magically join the Microsoft Exchange
2000 Server or Exchange Server 2003 account lists. Rather, the cross-forest trust accomplishes one
thing: It gives forest trust member domains easy access to each other’s domain resources. However,
how secure is a cross-forest trust?

Brought to you by NetIQ and Windows & .NET Magazine eBooks

64 Windows 2003: Active Directory Administration Essentials

Cross-Forest Trust Security

When you create a cross-forest trust, you basically agree to let users in other domains in trusted
forests access your forest’s resources. However, you can probably imagine situations in which you
don’t necessarily trust all the accounts in the other forests equally. Figure 4.1 shows a cross-forest
trust situation in which you might want to restrict access selectively. A university and two corpora-
tions are tied together. Although the cross-forest trust lets any account within any of the trusting
forests attempt to access resources in the other trusted forests, you might want to impose particular
limitations.
For example, let’s assume that you’re the administrator of the Corp.com domain. After the
cross-forest trust has been established, you want to protect your forest from curious students at
Bigu.edu who might want to pry. You’ve properly locked down access to your Corp.com resources,
including file servers, printers, and other entities that leverage your Active Directory (AD) to maintain
user accounts’ rights to various resources. However, unless you’ve spent time analyzing each share
to ensure that it doesn’t have Everyone: Full Control (or even Everyone: Read) access, you might
not be fully protected.
The setup that Figure 4.1 shows lets users in Bigu.edu try to authenticate on your domain
controllers (DCs) and access your resources. What if the results of your efforts to lock down specific
resources haven’t been 100 percent effective? For example, what if another administrator inadvertently
permits the Everyone group access to resources for which access should be restricted? You’d still be
vulnerable to attacks from Bigu.edu.

Authentication Firewall
To protect your resources from attacks that users in other trusted domains might launch, you can
set up selective authentication through what Microsoft calls an authentication firewall. Setting up an
authentication firewall lets you block certain SIDs from authenticating across the cross-forest trust.
The users whose SIDs you block won’t be able to authenticate on your network resources.
In the example in Figure 4.1, you could block all Bigu.edu student SIDs from traversing the
cross-forest trust, but still let the Bigu.edu faculty member SIDs do so. This approach would prevent
students from taking a whack at Corp.com resources, but let the faculty members authenticate to
Corp.com servers and access Corp.com resources.
Selective authentication isn’t turned on by default. That is, if you accept the defaults when you
set up a cross-forest trust, you’ll need to enable selective authentication to establish the authentication
firewall. When you use the New Trust Wizard to create your cross-forest trust, you choose the scope
of authentication through the Outgoing Trust Authentication Level – Local Forest dialog box options,
which Figure 4.2 shows.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 4 Inside Windows Server 2003 Forests and DNS 65

Figure 4.2
Outgoing Trust Authentication Level – Local Forest option

The terminology in the dialog box that Figure 4.2 shows is a bit confusing. The dialog box text
doesn’t state that your choice here indicates whether you’ll be deploying an authentication firewall to
block certain SIDs from other domains from getting inside your forest. If you select Forest-wide
authentication, the default, you let all users in the cross-forest trust traverse all the forests. If you
select Selective authentication, thereby creating an authentication firewall, you can then manually
add access for specific users.
If you accept the default (Forest-wide authentication) when you use the New Trust Wizard,
which Figure 4.2 shows, a user who logs on to a domain in another forest that trusts your forest
through a cross-forest trust can see the resources you have. Figure 4.3 shows that by using the Net
View command, that user can see the shares on a specific machine.
Figure 4.3
The Forest-wide authentication option

Brought to you by NetIQ and Windows & .NET Magazine eBooks

66 Windows 2003: Active Directory Administration Essentials

If, after your forest trust is built, you decide to further lock down resources and enable an
authentication firewall, you must then use Active Directory Domains and Trusts to change the mode.
After you open Active Directory Domains and Trusts, right-click the domain. Select the Trusts
tab, the name of the trust, and Properties. Then click the Authentication tab and select Selective
authentication as Figure 4.4 shows.
Figure 4.4
Choosing Selective authentication through Active Directory Domains and Trusts

As soon as you choose selective authentication, you can see the immediate consequences for
users who try to gain access through the trust, which Figure 4.5 shows. Access is denied.

Figure 4.5
User access after you choose the Selective authentication option

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 4 Inside Windows Server 2003 Forests and DNS 67

After your authentication firewall is in place, no one in domains outside your forest (i.e., in
“foreign” domains and forests) can get access to any resources through the trust. To then “open up”
the authentication firewall, you need to selectively poke holes in its security. That way, you can
dictate precisely who’ll be given access to the resources in your forest.
You set up selective access through the Active Directory Users and Computers console. First,
you must enable Advanced Features, which Figure 4.6 shows.
Figure 4.6
Advanced Features in the Active Directory Users and Computers console

j Tip
Turn on the Advanced Features in Active Directory Users and Computers to manipulate who
can pass through the authentication firewall.

After you enable Advanced Features, you can specify security for specific objects. You’ll set
the filtering directly upon the computer resource to which a foreign user needs access. In Figure 4.7,
you can see that I’ve enabled the Administrator account from a foreign domain – DOMAINC –
to access resources on server VMSERVER2.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

68 Windows 2003: Active Directory Administration Essentials

Figure 4.7
Selecting the cross-forest trust users who can access this server

After you assign the Allowed to Authenticate right to a selected user, that user can see the
resources to which access was denied previously. As Figure 4.8 shows, the user can see resources
across the forest trust.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 4 Inside Windows Server 2003 Forests and DNS 69

Figure 4.8
A server available to specific users through the authentication firewall

SID Filtering
Another technique to prevent ne’er-do-wells from accessing your resources is SID filtering. SID
filtering can help prevent potential attacks. Imagine this scenario: A domain administrator in another
domain that your domain trusts wants to attack you. The attacker might be a domain administrator
within the same forest. Although that possibility sounds frightening and might be unlikely, it’s
theoretically possible.
If you wonder how such an attack might occur, recall that Win2K’s Native Mode domains and
Windows 2003 Functional Level domains support the SID history feature. The idea behind SID history
is that a user account can be populated with more than one SID – the SID of the user account plus
other SIDs. The user account is usually populated with additional SIDs when someone migrates
accounts with the SID history feature turned on. SID history is often useful – for example, when you
migrate user accounts from many domains and consolidate them into a few domains. SID history lets
a user present an alternate set of credentials to gain access to network resources. Users might need to
present their old credentials to access resources (e.g., Exchange or Microsoft SQL Server) in their
former domains.
An unscrupulous domain administrator could take an account in his or her domain and use
the account to attack your domain. The administrator would accomplish the attack by hijacking the
SIDs from the trusting domain (the NT domain) and putting them in the SID history attribute of his
or her user object. The administrator then “becomes” the user with the hijacked SID – thereby
impersonating (i.e., spoofing) a user in your domain. If the administrator spoofs the account of a
domain administrator in your domain, he or she could do a lot of damage.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

70 Windows 2003: Active Directory Administration Essentials

Win2K Service Pack 2 (SP2) introduced SID filtering to protect against this potential attack.
Enabling SID filtering won’t stop an administrator bent on being destructive from trying this attack;
he or she can still hijack the SID. But your domain will ignore any SIDHistory attributes, which
renders such an attack ineffective. Windows 2003 has the same functionality enabled by default.
To disable or re-enable SID filtering in Windows 2003, you use the Netdom command.
For more information, read the Microsoft Knowledge Base article “Forged SID Could Result in
Elevated Privileges in Windows 2000,” available at the following URL:
http://support.microsoft.com/default.aspx?kbid=289243

n Note SID filtering is sometimes complex. To learn more about it, in particular how to use SID
filtering to prevent elevation-of-privilege attacks, go to
http://www.microsoft.com/windows2000/techinfo/administration/security/sidfilter.asp

j Tip
In addition to selective authentication and SID filtering, you can place another level of security
upon a forest trust by using top-level name (TLN) restrictions. Windows 2003 uses domain
name suffix routing to provide name resolution between forests connected by trust
relationships. TLN restrictions let you enable, disable, or exclude suffixes to control cross-forest
routing. For in-depth information about TLN restrictions, read the article “Windows 2003
Forest Trusts” at http://www.winnetmag.com/windowsserver2003/index.cfm?articleid=38436.

Windows 2003 DNS Additions

DNS is essential to the health of Windows networks. What air is to humans, DNS is to Win2K and
Windows 2003. This section isn’t about in-depth DNS troubleshooting, however, but about DNS
features new to Windows 2003. I’ll assume that you’ve already set up your DNS correctly and that
you have a healthy AD that relies on your DNS infrastructure.

DNS Health Checks

You can perform a subzone spot check before you move forward to ensure that under your domain
name, all four automatically generated subzones appear. The four automatically generated subzones
appear preceded by an underscore, as Figure 4.9 shows.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 4 Inside Windows Server 2003 Forests and DNS 71

Figure 4.9
A domain’s four automatically generated subzones

Verifying that all four automatically generated subzones ( _msdcs, _sites, _tcp, and _udp) are
present ensures that your domain has the records necessary to locate DCs, which clients must be
able to do.

Windows 2003 DNSLINT

You can take your Windows 2003 DNS testing one step further by running a new tool that Microsoft
makes available: DNSLint. DNSLint helps you make sure that you’re running a “clean” DNS server.
You can start by downloading DNSLint from http://download.microsoft.com/download/win2000srv
/utility/q321045/nt5xp/en-us/dnslint.exe
After you download DNSLint to a Windows 2003 server, you can run myriad commands. Be
sure to read the documentation file included to understand all your options. However, to help
diagnose common AD-related DNS errors, you’ll find it useful to run the DNSLINT command with
the /ad switch, which Figure 4.10 shows.
Figure 4.10
Run DNSLint from the command line with the /ad switch

Brought to you by NetIQ and Windows & .NET Magazine eBooks

72 Windows 2003: Active Directory Administration Essentials

When you run DNSLint with the /ad switch, you instruct DNSLint to produce an HTML report
about the state of DNS affairs. This file will reveal any trouble spots in your DNS. Figure 4.11 shows a
DNSLint report with a clean bill of health (the report would list any errors that DNSLint found).

Figure 4.11
DNSLint report

Conditional Forwarding
Before I discuss the new Windows 2003 conditional forwarding feature, let me briefly review standard
forwarding. You enable Win2K’s standard forwarding on a server-by-server basis in the DNS applet.
You simply right-click the computer name, select Properties, then select the Forwarders tab, as Figure
4.12 shows.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 4 Inside Windows Server 2003 Forests and DNS 73

Figure 4.12
Win2K’s Forwarders tab

n Note Other non-Microsoft implementations of DNS, such as Internet Software Consortium’s (ISC’s)
BIND 9.0, support conditional forwarding.

The forwarders address lets one DNS server ask other (possibly nonrelated) servers for the
answer to a DNS question. For example, let’s imagine that a client in a domain wants to discover
Microsoft.com’s address to get to its Web servers. A local AD domain (e.g., Corp.com) probably
wouldn’t know the answer. However, by leveraging the power of forwarders, this server can ask
other servers that might know the answer – and retrieve the answer for the client.
The standard forwarding approach works well for a limited set of circumstances. However,
standard forwarding doesn’t address some situations. For example, imagine the company structure
that the diagram in Figure 4.13 represents: two separate domains that have little to do with each
other.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

74 Windows 2003: Active Directory Administration Essentials

Figure 4.13
An example company’s DNS configuration

Internet

Forward Forward

CORPNS1 RESEARCHDNS1

CORPSQL1 RESEARCHFILE1
corp.com research.internal.com

However, let’s suppose that from time to time, users in the separate domains must share
resources. For example, the users in Corp.com occasionally need to connect to a computer named
Researchfile1.research.internal.com. And the users at Research.internal.com occasionally need to
connect to CorpSQL1.corp.com. The diagram in Figure 4.13 indicates that the DNS servers of
Corp.com and Research.internal.com can’t “know about” each other.
If a client in Corp.com asked about locating the Research.internal.com computer in
Research.internal.com, resolving that name wouldn’t be easy. Figure 4.14 shows what happens
when standard forwarding is set up.

Figure 4.14
DNS communications in the example company

Client says “I need Internet

something over at
reasearch.internal.com” Forward Forward

CORPNS1 RESEARCHDNS1

CORPDNS1
IBM Compatible Server says
“Check over here.”
CORPSQL1 RESEARCHFILE1
corp.com research.internal.com

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 4 Inside Windows Server 2003 Forests and DNS 75

With a standard forwarder, the Corp.com DNS server (CORPDNS1) probably won’t get any
response other than “I can’t find it” from the servers to which it forwards. The reason is that the
servers forward to a common point (the ISP or the Internet). In such a scenario, the two DNS servers
can’t “see” each other.
Under Win2K, you could fix this problem – but in a sloppy way. That is, you could have the
Corp.com DNS server house a secondary-zone copy of Research.internal.com, and the
Research.internal.com DNS server house a secondary-zone copy of Corp.com. However, this solution
is messy because every time a new record is entered into DNS, a copy of that record must be sent
to the other DNS’s secondary-zone copy. Depending on how you have the zones configured, the
updating can take extra administrative effort and more bandwidth.
If you could tell the Corp.com DNS server where to look for Research.internal.com resources,
you could solve this problem. Windows 2003’s conditional forwarding lets you do exactly that, as
Figure 4.15 shows.
Figure 4.15
DNS communications with conditional forwarding

CORPDNS1 Server says

“Check over here.”

Client says “I need

something over at
reasearch.internal.com” Internet

Forward Forward

CORPNS1 RESEARCHDNS1

IBM Compatible
CORPSQL1 RESEARCHFILE1

corp.com research.internal.com

Conditional forwarding eliminates the need to house unnecessary secondary-zone DNS files in
servers that really shouldn’t have them. Conditional forwarders let you keep copies of only the DNS
zone files you want – without any extras.

Setting Up Conditional Forwarding

You need to set up conditional forwarding just as you set up standard forwarding for Win2K – that
is, conditional forwarding is unique to each Windows 2003 DNS server. Right-click the server name,
select Properties, then click the Forwarders tab, as Figure 4.16 shows.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

76 Windows 2003: Active Directory Administration Essentials

Figure 4.16
Windows 2003’s DNS Forwarders tab

To set up conditional forwarding for a DNS domain, select the domain name, click New,
and type the name of the domain and the IP address. Figure 4.16shows that this server will forward
all requests asking about resources in the Research.internal.com domain to 192.168.2.11.

Stub Zones
Stub zones are another feature new to Windows 2003 DNS. Like conditional forwarding, stub zones
solve a problem. (Also like conditional forwarding, stub zones aren’t new to other non-Microsoft
DNS implementations, such as BIND 9.0.) Figure 4.17 presents a DNS configuration that shows the
need for stub zones.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 4 Inside Windows Server 2003 Forests and DNS 77

Figure 4.17
A second example company’s DNS configuration

Internet

rd
wa
For
Forward Forward

CORPNS1 INTERNALROOTDNS RESEARCHDNS1

CORPSQL1 RESEARCHFILE1
corp.com research.internal.com

As Figure 4.17 shows, you have two unrelated domains asking a central Root DNS for
information. Suppose a client request comes in from Corp.com asking about resources in
Research.internal.com. You can read the “conversation” between the client and the DNS servers
in Figure 4.18’s internal captions.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

78 Windows 2003: Active Directory Administration Essentials

Figure 4.18
A successful lookup with manual delegations

Internet
INTERNALROOTDNS
Server says
“I know where
research.internal.com
is – let me point

rd
you toward a

wa
research.interal.com

For
server that knows
Client says “I need the answer and is
something over at authoritative for the
reasearch.internal.com” zone.”
Forward Forward

INTERNALROOTDNS
CORPNS1 RESEARCHDNS1
CORPDNS1 Server
says “Follow the
forward.”

Client A
CORPSQL1 RESEARCHFILE1

corp.com research.internal.com

In this scenario, ClientA asks CorpDNS1.corp.com for the answer, which forwards to the
InternalrootDNS server. The InternalrootDNS server then looks up in its table the list of servers
that are authoritative for the Research.internal.com domain (i.e., servers that respond to Start of
Authority – SOA – requests). However, what happens if Research.internal.com gets three more
DNS servers – each capable of responding to the SOA request? Such a scenario could evolve if
Research.internal.com introduced three more DCs that run DNS in AD integrated mode.
At this point, the InternalrootDNS server would know about the original ResearchDNS1 server
only – and not about the three newly introduced DNS servers. For the InternalrootDNS server to
know about the new DNS servers in Research.internal.com, someone would have to manually update
the InternalrootDNS server. That design isn’t as responsive to change as you might need it to be.
Stub zones introduce a new technique to help address this situation. Stub zones “learn” about
new DNS servers introduced into other domains. Figure 4.19 shows the different communication that
occurs if you use stub zones after the new DNS servers are introduced in Research.internal.com.

Brought to you by NetIQ and Windows & .NET Magazine eBooks

 Chapter 4 Inside Windows Server 2003 Forests and DNS 79

Figure 4.19
Stub zones and DNS changes

Internet
CORPDNS1 Server says
“Let me check my stub-zone for
research.internal.com – a definitive
list of research.internal.com servers
which are SOA for the zone.”

rd
wa
For
Client says “I need
something over at
reasearch.internal.com”
Forward
Forward

INTERNALROOTDNS Forward your RESEARCHDNS1

CORPNS1 request to a RESEARCHDNS2
DNS server
that is SOA
for the zone.

Client A
CORPSQL1 RESEARCHDNS3 RESEARCHFILE1

corp.com research.internal.com

Creating Stub Zones

You create a stub zone as you would create any DNS zone. That is, you right-click the server and
create a new zone. Then, you select the zone type, as Figure 4.20 shows.
Figure 4.20
Creating new stub zones

Brought to you by NetIQ and Windows & .NET Magazine eBooks

80 Windows 2003: Active Directory Administration Essentials

At this point, you can choose how widely you want to replicate the stub-zone information.
You specify the zone for which you want to create a stub zone. You should then have a functioning
stub zone.

j Tip
If your stub zone doesn’t activate right away, right-click Reload from Master to jump-start the
stub zone.

Conditional Forwarding vs. Stub-Zones

Conditional forwarding and stub zones accomplish similar results. When should you choose one
over the other? Conditional forwarding gets the job done. But if the servers you list in the Forwarders
tab go down and new ones go up, you must manually update the list. Also, conditional forwarding
must be configured individually on each DNS server you set up. One misconfiguration could cause
problems for a while.
In contrast, if you create a stub zone in the source domain for the target domain, DNS servers
can go up and down at will in the target domain – and the source domain is always updated.
Additionally, you can make a stub zone AD-integrated. That means if you create the stub zone in
the source domain once – all AD integrated DNS servers will be aware that you want to use stub
zones for certain target domains. You perform a one-time configuration – and you’re done.

Next: Windows 2003 Security Enhancements

In this chapter, I examined the security ramifications of cross-forest trusts and how to address
some potential vulnerabilities, including by using selective authentication. I review how you set up
an authentication firewall. After the authentication firewall is in place, you must do some manual
labor to open each specific gate to let users in other forests gain access through cross-forest trusts.
I also discussed some Win 2K DNS limitations and how Windows 2003 works around them with
conditional forwarding and stub zones.
In Chapter 5, I’ll present Windows 2003 security enhancements. If you have older clients that
you can’t get rid of, Chapter 5 will be especially relevant to you. If you have all newer clients, you’ll
learn what makes those clients more secure than ever.

Brought to you by NetIQ and Windows & .NET Magazine eBooks