Administrator’s Guide to

Windows Server 2003

Security
Best practices for securing Windows
Server 2003
Oct. 20, 2003
By Brien M. Posey, MCSE
I
f you’ve ever deployed Windows NT
Server or Windows 2000 Server, you prob-
ably know that Microsoft designed those
products to be unsecure by default. Although
Microsoft has provided many security mecha-
nisms, it’s been up to you to implement them.
But when Microsoft released Windows 2003
Server, the company switched philosophies.
The new philosophy is that the server should
be secure by default.
This is generally a good idea, but Microsoft
didn’t take it quite far enough. While a default
Windows 2003 installation is certainly more
secure than a default Windows NT or Win-
dows 2000 installation, it is still anything but
totally secure. Let’s discuss some relatively easy
measures that you can take to make Windows
2003 Server even more secure.
Know your role
Understanding the server’s role (i.e., intended
purpose) is absolutely critical to the security
process. There are many roles for which a
Windows Server can be configured. For exam-
ple, a Windows 2003 Server can act as a
domain controller, a member server, an infra-
structure server, a file server, a print server, an
IIS Server, an IAS server, a terminal server,
and the list goes on. A server can even be con-
figured to fill a combination of roles.
The problem with this is that each server
role has its own security needs. For example, if
your server is going to function as an IIS
server, you need to enable the IIS services.
However, if the server is going to function
solely as a file and print server, enabling IIS
would be a huge security risk.
The reason I’m telling you this is to point
out that there is no way that I can just give you
a set of steps to follow and expect those steps
to work in every situation. A server’s security
needs vary tremendously by the server’s role
and by the server’s environment.
Because there are many ways to harden a
server, I’ll discuss the steps necessary for con-
figuring a server to act as a simple, but secure,
file server. I’ll try to point out some things that
you might do differently if the server is filling
an alternate role. Just please understand that
this isn’t intended as a comprehensive guide to
securing every type of server.
Physical security
To achieve true security, your server must be in
a secure location. Normally, this means placing
the server behind a locked door. Physical secu-
rity is extremely important because many
administrative and disaster recovery tools exist
that can double as hacker tools. Anyone with
such tools and a minimal skill level can hack a
server in a matter of minutes once they have
physical access to the machine. Your only hope
against preventing such attacks is to place the
server in a secure area. This is true of any
Windows 2003 Server, regardless of its role.
Creating a baseline
Aside from establishing good physical security,
the best advice that I can give you when
deploying a series of Windows 2003 Servers is
to decide on your security requirements prior
to deployment and to enforce those policies
immediately after deployment.
The best way to do this is to create a secu-
rity baseline. A security baseline is a list of
documented and accepted security settings. In
most cases, your baseline settings will differ
considerably depending on the server’s role. So
the best thing to do is to create several differ-
ent baselines that you can apply to various dif-
ferent types of servers. For example, you
might have one baseline for file servers,
another for domain controllers, and still
another for IAS servers.
Windows 2003 contains a tool called the
Security Configuration And Analysis Tool.
This tool allows you to compare a server’s cur-
rent security policy against a baseline security
policy contained within a template file. You
can either create these templates yourself or
use one of the included template files.
Security 189
Administrator's Guide to Order now and

Windows Server 2003 receive free

shipping!

TechRepublic's Administrator's Guide to Windows Server

2003 gets you up to speed quickly on Microsoft's newest
server operating system. Each chapter is packed with the
clear and concise how-to information you need to opti-
mize,
troubleshoot and secure Windows Server 2003.
Tap field-tested solutions. Minimize your learning curve. Turn
to the Administrator's Guide to Windows Server 2003 book and
accompanying CD to learn how to:
Plan for and deploy Windows Server 2003
Configure VPN connections
Fine-tune servers for optimum performance
Solve Group Policy problems
Troubleshoot Active Directory
Overcome DNS errors
Lock down servers
Secure wireless connections
Recover from disasters
And more
Eliminate guesswork. Leverage the proven expertise in TechRepublic’s
Administrator’s Guide to Windows Server 2003. Designed by IT pros for IT
pros, this unique book and CD set provide you with the tools and information
required to become an effective Windows Server 2003 administrator.

Order now and receive free shipping!

 The security templates are a series of text-
based INF files stored in the %SYSTEM-
ROOT%\SECURITY|TEMPLATES folder.
The easiest way to examine or modify the indi-
vidual templates is through the Microsoft
Management Console (MMC).
To open the console, enter the MMC com-
mand at the Run prompt. When the empty
console loads, select the Add/Remove Snap-in
command from the File menu. This will cause
Windows to display the Add/Remove Snap-in
properties sheet. Click the Add button found
on the properties sheet’s Standalone tab and
you will see a list of all of the available console
snap-ins. Select the Security Templates snap-in
from the list and then click the Add, Close,
and OK buttons.
Once the Security Templates snap-in is
loaded, you can view each of the security tem-
plates. As you navigate through the console
tree, you will see that each template mimics the
group policy structure. The template names
reflect each template’s purpose. For example,
the HISECDC template is a high-security
domain controller template.
If you’re trying to secure a file server, I rec-
ommend starting with the SECUREWS tem-
plate. As you look through all of the template’s
settings, you will find that although the tem-
plate can be used to make the server more
secure than it currently is, it may not meet your
needs. Certain security settings may be too
strict or too relaxed. I would recommend
either modifying the existing settings to meet
your needs or creating a brand new policy. You
can easily create a new template by right-click-
ing on the C:\WINDOWS\Security\Tem-
plates folder within the console and selecting
the New Template command from the result-
ing menu.
Once you have created a security template
that meets your needs, go back to the
Add/Remove Snap-in properties sheet and
add a snap-in called Security Configuration
And Analysis. When the snap-in loads, right-
click on the Security Configuration And Analy-
sis container, then select the Open Database
command from the resulting menu. Since no
database currently exists, make up a name for
the security database. Click Open, and the nec-
192 Administrator’s Guide to Windows Server 2003
essary database will be created using the name
that you provided.
Next, right-click on the Security Configura-
tion And Analysis container and select the
Import Template command from the shortcut
menu. You’ll see a list of all of the available
templates. Select the template that contains
your security policy settings and click Open.
After the template has been imported, right-
click on the Security Configuration And Analy-
sis container once again and select the Analyze
Computer Now command from the shortcut
menu. Windows will prompt you for a location
to write the error log. Enter a file path and
click OK.
At this point, Windows will compare your
server’s existing security settings against those
in the template file. You can see the results of
the comparison by navigating through the
Security Configuration And Analysis console.
Each group policy setting displays both the
current setting and the template setting.
Once you’ve had a chance to look through
the list of discrepancies, it’s time to enforce
the security policy based on the template. To
do so, right-click on the Security Configuration
And Analysis container one last time and select
the Configure Computer Now command from
the shortcut menu. The tool will then modify
your computer’s security policy to match the
template policy.
Group policies are hierarchical in nature. A
group policy may be applied at the local com-
puter level, the site level, the domain level, or
the OU level. When you implement security
based on a template, you’re modifying the
computer-level group policy. Other group poli-
cies aren’t directly affected, although the final
policy may reflect a change due to a setting in
the computer policy being inherited by higher
level policies.
Modifying built-in accounts
For years, Microsoft has been preaching that
you need to rename the Administrator
account and disable the Guest account to
achieve good security. In Windows Server
2003, the Guest account is disabled by default,
but renaming the Administrator account is
still a good idea because it’s common for
attackers to try to compromise the Adminis-
trator account.
There are a number of hacker tools that
reveal the Administrator account’s real name
by examining the account’s SID. Unfortu-
nately, you can’t change this account’s SID
and there is really no way of preventing such
a tool from determining the Administrator
account’s real name. Even so, I encourage
everyone to rename the Administrator
account and to change the account’s descrip-
tion for two reasons.
First, less sophisticated hackers may not
know of the existence of such tools or have
access to them. Second, renaming the Admin-
istrator’s account to a unique name makes it
easy for you to monitor attacks against the
account.
Another tip pertains to member servers.
Member servers have their own built-in local
administrative account that is completely sepa-
rate from the domain Administrator account.
You can configure every member server to use
a different administrator account name and
password. The idea is that if someone were to
figure out the local administrator account
name and password on one member server,
you wouldn’t want them to be able to use those
credentials to hack your other servers too. Of
course, if you have good physical security in
place, no one should be able to gain access to a
server to be able to use a local account.
Service accounts
Windows Server 2003 is designed in a way that
minimizes the need for service accounts. Even
so, some third-party applications absolutely
insist on a traditional service account. If possi-
ble, always use a local account as the service
account instead of using a domain account,
because if someone were to gain physical
access to the server, they could dump the
server’s LSA secrets and compromise the pass-
word. If you use a domain password, the pass-
word can be used from any computer within
the forest to gain access to the domain. If a
local account is used, though, the password is
useless from anywhere other than the compro-
mised machine and doesn’t provide any access
to the domain.
System services
There is a fundamental law of computing that
states that the more code running on a system,
the greater the chance that the code will con-
tain a security vulnerability. One of the pri-
mary security strategies that you should focus
on is to reduce the amount of code running
on your server. Doing so reduces security risks
and will also improve the server’s performance.
In Windows 2000, there were a lot of serv-
ices that were running by default, but were
totally unnecessary in most environments. In
fact, a default installation of Windows 2000
even included a fully operational IIS server. In
Windows Server 2003, Microsoft turned off
most of the services that aren’t absolutely nec-
essary. Even so, there are some services that
are running by default, but are open to debate.
One such service is the Distributed File Sys-
tem (DFS) service. The DFS service was pri-
marily designed to make a user’s life easier.
DFS allows an administrator to create a logical
name space containing resources from multi-
ple servers or partitions. To a user, all of these
distributed resources appear to exist within a
single folder.
I personally like DFS, especially because of
its fault tolerance and scalability features.
However, if you were to not use DFS, you
would force users to know the actual path to a
specific resource instead of being able to
access all resources through a single path. In
some environments, this may translate to bet-
ter security. In my opinion, though, the
rewards of DFS far outweigh the risks.
Another such service is the File Replication
Service (FRS). The FRS is used to replicate
data between servers. This is a mandatory
service on domain controllers because it’s
responsible for keeping the SYSVOL folder
synchronized. For member servers, however,
this service isn’t mandatory unless you are run-
ning DFS.
If you have a file server that isn’t a domain
controller and isn’t using DFS, I recommend
disabling the FRS. Disabling the FRS decreases
an attacker’s ability to replicate a malicious file
across multiple servers. The FRS is enabled by
default.
Security 193
 Another service worth taking a look at is
the Print Spooler service. The Print Spooler
manages all local and network print queues
and controls all of the print jobs within these
queues. The Print Spooler is required for all
printing operations and is enabled by default.
The flip side to this is that not every server
requires printing capabilities. Unless a server is
acting as a print server, you should disable the
print spooler. After all, why should a dedicated
file server run the print spooler? Normally, no
one should be sitting at the server console
working, so there should be no need to print
locally or from across the network.
I realize that often during disaster recovery
operations, it might become necessary to print
Tips to help secure Windows Server 2003
Active Directory
Oct. 27, 2003
By Brien M. Posey, MCSE
I
f I were to tell you that Windows NT
Server 4.0 was a lot more secure than Win-
dows 2000 Server, you would probably
think that I had lost my mind. Sometimes,
though, truth is stranger than fiction. In some
ways, Windows NT Server was more secure
than Windows 2000 Server. However,
Microsoft learned from their mistakes and
implemented a Windows NT-like security
structure into Windows Server 2003’s Active
Directory. Let’s discuss these security issues
and learn some tips you can use to build a
secure Active Directory (AD) environment.
Physical security is job 1
When attempting to secure AD, it’s critical that
you implement physical security first. If any-
one you wouldn’t trust with the Administrative
password has physical access to a domain con-
troller or to your DNS servers, you don’t have
a secure AD. Many administrative and disaster
recovery tools exist that can easily double as
hacker tools.
194 Administrator’s Guide to Windows Server 2003
an error message or an event log. However, I
recommend simply turning on the Print
Spooler Service when it is needed rather than
leaving it on all the time for non-print servers.
Believe it or not, the Print Spooler is one of
the most heavily exploited Windows compo-
nents. There are countless Trojans that work
by replacing the Print Spooler’s executable file.
The reason for such an attack is that the Print
Spooler operates as a system-level service and,
therefore, has a high level of privileges. So any
Trojan posing as the Print Spooler can also
gain these high-level privileges. To protect your
server from such an attack, just prevent the
Print Spooler service from running.
Given physical access to the server, it is eas-
ily possible for someone with minimal com-
puter knowledge to hack the server in a matter
of minutes. So don’t even bother trying to
secure AD until you’ve made sure that all of
your servers are placed in a secure location.
Windows NT vs. Windows 2000
Don’t get me wrong. In many areas, Windows
2000’s security is far superior to that offered by
Windows NT. However, there is a basic law of
computing that states that the more complex a
piece of software is, the greater the chance
that it will contain a security hole or a major
bug that can be exploited. As we all know,
Windows 2000 is a lot more complex than
Windows NT.
Perhaps the best example of simplicity and
security going hand-in-hand involves the
domain model implemented by each server
operating system. In Windows NT, the domain
was pretty much the only organizational struc-
ture that existed. A domain often contained all
of the users, groups, and computers for an
entire organization. If an organization was
really big, they could create multiple domains
and have the domains trust each other; but,
each domain was an independent structure.
When Microsoft created Windows 2000,
they realized that the Windows NT domain
model just didn’t scale well into larger organi-
zations. So, they based the AD on a structure
called a forest. A forest is basically a collection
of domain trees. Within a forest, you can have
many different domains and can even use
parent and child domain trees. Just as was the
case with Windows NT, each domain has its
own Administrator. This is where the similari-
ties end, though.
In Windows 2000, Microsoft decided they
needed to make the domains more manage-
able. They created different levels of domain
administration. For example, a member of the
Domain Admins group could typically admin-
ister the current domain and any child domains
beneath it. A member of the Enterprise
Admins group had the ability to administer
any domain within the entire forest. Herein
lies the problem.
The fatal flaw in the Windows 2000 AD
model is that every domain completely trusts
every other domain within the forest. This
causes a couple of problems. First, if security
has not been applied properly, administrators
can just add their accounts to the Enterprise
Admins group to gain control over the entire
forest. If the domain is a bit more secure,
rogue administrators need only to tamper with
the SID history and launch an elevation of
privileges attack against the forest. By manipu-
lating the SID history, administrators could
give themselves Enterprise Admin status.
There are other inherent weaknesses in the
Windows 2000 AD security model as well. As
you probably know, each domain requires at
least one domain controller. Likewise, each
domain controller contains information relat-
ing not only to the domain but also to the for-
est. Such information includes AD’s schema
and some basic configuration.
Now, imagine you had an administrator
who wasn’t being intentionally malicious but
who installed a malicious application or incor-
rectly modified an AD. If the change that the
administrator made was to a forest-level AD
component, the change would eventually be
propagated to every domain controller in the
entire forest, thus corrupting every single
copy of AD and potentially crashing the
entire network.
Let’s compare this situation to Windows
NT. Even if one domain trusts another
domain, both domains include a copy of the
Security Accounts Manager pertaining to
their own domain only. In this way, rogue
administrators can’t make a change to the
SAM in their domain and then use that
change to corrupt other domains. Likewise,
there is no all-powerful group within Win-
dows NT that a rogue administrator could
use to gain control over every domain in the
entire organization.
Another nice thing about the way that Win-
dows NT’s trust relationships worked was that
trust relationships could either be one-way or
two-way, and they were never transitive in
nature. This meant that if you had a Users
domain and an Admin domain, you could
either allow both domains to trust each other
or you could configure the network so that the
Users domain trusted the Admin domain, but
not vice versa. It also meant that if Domain A
trusted domain B and domain B trusted
domain C, then domain A didn’t trust domain
C unless you told it to.
Windows Server 2003 security
You’re probably wondering what all of this has
to do with Windows Server 2003. I went into
the long comparison between Windows NT
and Windows 2000 because in Windows
Server 2003, Microsoft incorporated the best
of both worlds. And so, to properly secure
your Windows Server 2003 network, you need
to understand the strengths and weaknesses of
both security models.
The biggest AD security weakness in Win-
dows 2000 is that all domains within a forest
are linked together by a common administra-
tive structure, the forest itself. In Windows
Server 2003, the forest structure still exists and
works almost identically to the way it did in
Windows 2000.
Security 195
 What is different about the forest structure
in Windows Server 2003 than that of Win-
dows 2000 Server is that Windows Server 2003
makes it relatively easy to establish trust rela-
tionships between forests. Inter-forest trusts
were possible in Windows 2000; but, in Win-
dows Server 2003, inter-forest trusts are actu-
ally useful. When a trust relationship exists
between forests, an administrator can grant
access to a resource in a user from a foreign
forest in the same manner that they would if
the user existed within the local forest.
Single forest vs. multiple forests
A single forest environment is ideal for most
small to medium-sized companies. Single for-
est environments are easy to manage. But
larger companies often need each office or
each department to be able to have full admin-
istrative capabilities over its own users and
computers. In such environments, there is
often a high degree of distrust between these
various groups. In a situation like this, inter-
connected forests are ideal because they give
each group total autonomy.
At the same time, even though the adminis-
trative burden is distributed, such a model usu-
ally has a much higher administrative burden
than a single forest environment, which results
in higher administrative costs to the company
as a whole. My point is that, in a Windows
Server 2003 AD environment, there is a trade-
off between cost and security.
Inter-forest trusts
Let’s discuss the specifics behind using multiple
forests as a mechanism for securing your orga-
nization’s AD. First, each forest has its own AD;
there is no common thread of any kind tying
the forests together. So, it’s possible to config-
ure each forest to use a common DNS server.
Assuming that the DNS server and backup
DNS server are managed by someone trustwor-
thy, DNS server consolidation is a great way to
reduce cost and lessen the administrative bur-
den. On the flip side, sharing a common DNS
server can also be a single point of failure for
the network if no backup DNS server is used.
There are some prerequisites you must meet
before you can establish a trust relationship
196 Administrator’s Guide to Windows Server 2003
between forests in Windows Server 2003. Per-
haps the most difficult of these is that any for-
est involved in the trust must be running at
Windows Server 2003 forest functional level.
Windows 2000 allowed you to run AD in
either mixed mode or in native mode. The
functional level in Windows Server 2003 is
very similar to this. Setting a forest to Win-
dows Server 2003 forest functional level
requires every domain controller within the
forest to be running Windows Server 2003.
Also, to create an inter-forest trust, you
must be a member of the Enterprise Admins
group. You must also have your DNS server
configured so that it can resolve the names of
domains and servers within the forest with
which you’re establishing the trust relationship.
Finally, you may recall from Windows 2000,
every forest has a root domain and all other
domains fall beneath the root. Windows Server
2003 can create an inter-forest trust only from
the root domain, because inter-forest trusts are
transitive at the domain level. This means that
if you were to establish a trust between Forest
A and Forest B, then every domain in Forest A
will trust every domain in Forest B, and vice
versa. Forest trusts are not transitive at the for-
est level, though.
For example, if Forest A trusts Forest B and
Forest B trusts Forest C, Forest A will not trust
Forest C unless you tell it to do so. As you can
see, the transitive nature of inter-forest trusts
makes them fairly powerful. If your forest has
multiple domains, you don’t want an adminis-
trator of some lower-level domain creating an
inter-forest trust without your knowledge or
consent. That would cause huge security prob-
lems. This is why you can create an inter-forest
trust only at the forest root level.
Another interesting thing about creating
trusts with Windows Server 2003 is that you
don’t necessarily have to create a full inter-for-
est trust. Suppose your business needs to
establish a trust relationship with a supplier.
You probably need to establish a trust relation-
ship with only one of the supplier’s domains.
You probably aren’t interested in the supplier’s
human resources or marketing domains. In
such a case, you can create what’s called an
external trust.
 An external trust is a trust relationship
between domains, similar to the trust relation-
ships that existed in Windows NT. An external
trust can be established from any domain
within your forest and links to a domain in a
foreign forest. Aside from being able to estab-
lish the external trust at any domain level,
there are other critical differences between an
external trust and an inter-forest trust.
Unlike an inter-forest trust, an external
trust is completely nontransitive, which
means the trust applies only to the domains
that the trust is assigned to. Other domains
within the two forests don’t acknowledge the
trust relationship.
Whether you are forming an Inter-forest
trust or an external trust, you have the option
of creating a two-way trust, a one-way incom-
ing trust, or a one-way outgoing trust. A two-
way trust simply means that both domains
trust each other. A one-way incoming trust
means that users in the current domain or for-
est can be authenticated by the foreign domain
or forest. Likewise, a one-way outgoing trust
means that users in the foreign forest or
domain can be authenticated by the local
domain or forest.
Cross-forest authentication
Windows Server 2003 inter-forest trusts sup-
port cross-forest authentications. Suppose a
user who normally logged in to Forest A made
a business trip to the company hosting Forest
B. With forest authentication, users from For-
est A could log in to Forest B just as though
they were logging in to Forest A.
This might seem strange at first since nei-
ther the domain controllers nor the global cat-
alog in Forest B would have any knowledge of
a user from Forest A. When the user tries to
log in, the computer checks the domain con-
troller and then the global catalog for the user’s
account. Because the account is not found, the
system implements a cross-forest, name-
matching function. This function compares
the user’s credentials with those found within
all recognized namespaces (forests). The com-
parison is made via Kerberos and NTLM, so
the process is secure.
Cross-forest authorization
Another feature that’s great about Windows
Server 2003 is cross-forest authorization. This
allows you to assign permissions to users
within both the local forest and trusted forests
directly through an Access Control List (ACL).
This comes in handy for both granting and
denying permissions.
Suppose you were an administrator for your
company’s research and development depart-
ment and that your job was to keep all of the
files on your server confidential. The forest-
level administrator for your company didn’t
know what he was doing, and he created an
inter-forest trust with a competitor. If you
wanted to keep users at the competitor’s firm
from being able to access your data, you could
give those users an explicit deny at the root
level of each of the servers in your domain.
As nice as this capability sounds, though,
there is a catch. You must completely type in
the names of users or groups from trusted
forests. Enumeration and wild cards aren’t sup-
ported. This means that you can’t just imple-
ment a blanket policy that says don’t let anyone
from that other forest access any of my data.
You could, however, get the names of each of
the domains belonging to the other forest and
deny access to the Everyone group belonging
to each of those domains.
The best of both worlds
Even though Windows 2000 is newer than
Windows NT, some of the improvements
actually decreased security in your organiza-
tion. Windows Server 2003 gives you added
flexibility to restore that security. One way to
achieve effective security within an organiza-
tion is to implement multiple forests and cre-
ate trust relationships between them. However,
this isn’t a process to be taken lightly, because
there are many prerequisites and the process
tends to increase costs and the administrative
burden.
Security 197
Administrator's Guide to Order now and

Windows Server 2003 receive free

shipping!

TechRepublic's Administrator's Guide to Windows Server

2003 gets you up to speed quickly on Microsoft's newest
server operating system. Each chapter is packed with the
clear and concise how-to information you need to opti-
mize,
troubleshoot and secure Windows Server 2003.
Tap field-tested solutions. Minimize your learning curve. Turn
to the Administrator's Guide to Windows Server 2003 book and
accompanying CD to learn how to:
Plan for and deploy Windows Server 2003
Configure VPN connections
Fine-tune servers for optimum performance
Solve Group Policy problems
Troubleshoot Active Directory
Overcome DNS errors
Lock down servers
Secure wireless connections
Recover from disasters
And more
Eliminate guesswork. Leverage the proven expertise in TechRepublic’s
Administrator’s Guide to Windows Server 2003. Designed by IT pros for IT
pros, this unique book and CD set provide you with the tools and information
required to become an effective Windows Server 2003 administrator.

Order now and receive free shipping!

 Securing information with Windows
Rights Management Services
April 22, 2004
By Brien M. Posey, MCSE
M
ost companies go to great lengths to
protect data. All of your efforts to
secure files basically boil down to
how much you trust your employees. You have
always been able to control access to files
through authentication and permissions, but
until now it has been impossible to control what
an authorized individual does with the files once
they gain access. This is where Windows Rights
Management Services (RMS) comes in. RMS
offers persistent security that stays with a file,
no matter where that file may go.
A practical example
For example, suppose that I had some super-
secret Microsoft Word document explaining
how I was going to take over the world. Nor-
mally, I would grant a couple of highly trusted
people access to the document and pray that
they didn’t pass the document on to anyone else.
With Windows Rights Management, in
addition to the normal permissions on the file
server where I keep my secret plans, I could
actually build permissions into the document
saying that only certain people are allowed to
access the document. That way, if one of my
trusted staff members gave a copy of the doc-
ument to someone else, that someone else
would be unable to open the document.
Beyond passwords
As you know, for years now it has been possi-
ble to password protect Microsoft Office doc-
uments. RMS goes way beyond password
protection. After all, it’s way too easy for
someone to pass a document along to some-
one else along with an e-mail message that says
something like: “Here’s the document that I
told you about. The password to open the doc-
ument is Scarab.”
Speaking of e-mail messages, RMS can even
be applied to an e-mail message. For example,
years ago I worked for an insurance company
that was having some financial problems. The
president of the company sent out a confiden-
200 Administrator’s Guide to Windows Server 2003
tial e-mail message to the managers telling
them that 20 percent of the staff was to be
laid off. Although the message was supposed
to be confidential, one of the managers for-
warded the e-mail to her entire staff, who in
turn forwarded the message to a bunch of
other people. By the end of the day, pretty
much everyone in the company had seen the
memo. Sure, the manager who leaked the
memo was promptly fired, but the damage
had already been done.
If this situation were to occur today, the
president could actually integrate WRM into
the e-mail message. This would prevent the
message from being forwarded to anyone
except for those people that he specifically
designated. He could even go so far as to put a
time bomb in the message so that the message
would “self destruct” after a specific length of
time or after being opened.
Implementing Windows Rights
Management Services
Obviously, RMS is a very useful technology,
but you are probably wondering how it works.
There are two primary components to RMS.
First, there’s the RMS Service itself. This is a
server-level component that provides the
authentication services. Second, there is the
client component. Typically, the client compo-
nent is embedded into an RMS-enabled appli-
cation such as Microsoft Office 2003. There is
also a software developer’s kit that developers
can use to build RMS security into custom
applications.
Although the RMS is designed to run on
Windows Server 2003, it does not ship with
Windows Server 2003. Instead, it is a down-
loadable add-on. You can download the RMS
service from Microsoft’s Windows Server 2003
Web site (http://www.microsoft.com/win-
dowsserver2003/technologies/rightsmgmt/
default.mspx). The RMS setup file consists of
a 2.12 MB self-extracting executable file.
 Although the RMS service is a free add-on,
there are some licensing requirements that you
need to be aware of before you install it. As I
explained earlier, RMS rides on top of Win-
dows Server 2003. Therefore, everyone who
uses RMS either to protect data or to access
protected data requires a Windows Server
2003 client access license. Additionally, each
RMS user also requires an RMS Client Access
License (also called a RMS User CAL). This
license costs about $37 per user. As an alterna-
tive, though, you can purchase device-specific
RMS client access licenses instead of user spe-
cific licenses.
The problem with this type of licensing is
that it makes it difficult to allow RMS security
to be used by those outside of your company.
Because of this, Microsoft also offers an RMS
external connector license. The RMS External
Connector license grants unlimited RMS
access to anyone outside of your company.
The price for an RMS External Connector
License is $18,066 per RMS Server.
Although RMS does have some rather strin-
gent license requirements, there is an upside.
Up to two users may access an RMS server
simultaneously (for administrative purposes)
without an RMS client access license.
The prep work
Before you can install RMS, you need to do a
little bit of prep work on your server. RMS is
dependent on IIS, so you must verify that IIS
is installed. Furthermore, IIS must be given a
certificate so that it can provide secure com-
munications.
There really isn’t much documentation
available on RMS. When I began working on
this article, I had no idea that IIS required a
certificate in order for RMS to work (although
looking back it makes sense). You can actually
make it all the way through the installation and
configuration process without IIS having a cer-
tificate. However, when you eventually try to
attach an RMS client to the server, you will get
an error message telling you that Internet
Explorer is set to work offline.
It took me days to figure out the real cause
of the problem. What was happening was that
the RMS client was passing an HTTPS request
to the server. The server didn’t have a certifi-
cate and therefore could not support HTTPS.
Once IIS is installed, you must install the
Message Queuing service on your Windows
2003 Server. To do so, open the server’s Con-
trol Panel and select the Add/Remove Pro-
grams option. When you do, you will see the
Add/Remove Programs dialog box. Click on
the Add/Remove Windows Components but-
ton to display a list of the various Windows
components. Select the Application Server
option and click the Details button. This will
cause Windows to display a list of the various
Application Server Components. Select the
check box next to Message Queuing and click
OK. Click Next and Windows will copy the
necessary files. Click Finish when the file copy
process completes.
One last bit of prep work that you must
perform is to open the Active Directory Users
And Computers console, right-click on each
user’s account, and select the Properties com-
mand from the resulting shortcut menu. This
will reveal the user’s properties sheet. Check
out the General tab and make sure that the
e-mail address is filled in. Even if the user
doesn’t actually have an e-mail address, RMS
absolutely will not work unless this field is
filled in for each user. In my test environment,
after I had deployed RMS, I kept receiving an
error message that said “An Unexpected Error
Has Occurred” every time I would try to con-
nect to the server with an RMS client. It took
me a week to figure out that the problem was
related to the fact that my Administrator
account didn’t have an e-mail address.
Installing RMS
Now that the Message Queuing Service is
installed, it’s time to install RMS. To do so,
copy the RMS Setup file to your Windows
2003 Server and double-click on it. When you
do, Windows will extract the Setup files and
will display the Windows Rights Management
Services Setup Wizard.
Click Next to bypass the Welcome screen,
and you will see the end user license agree-
ment. Accept the license agreement, click
Next, and you will be prompted for the path to
install RMS to. Enter the desired path and click
Security 201
 Next, followed by Install, to begin the installa-
tion process. After the necessary files are
copied, click Close to complete the installation
process.
Provisioning
After you have installed RMS, the next thing
that you have to do is to provision it. The pro-
visioning process creates the root certification
server and configures all of the services and
Figure A
You must use a Web interface to provision RMS.
Figure B
You must supply the name of a database server and the name for an RMS service account.
202 Administrator’s Guide to Windows Server 2003
resources necessary for RMS to support certi-
fication. The provisioning process is done
through IIS. You must select a Web site to act
as the host for the provisioning process. Using
the server’s default Web site is fine because
RMS simply borrows the site. After the provi-
sioning process is complete, RMS no longer
needs IIS.
To begin the provisioning process, click the
Start button and then select the All Programs\
Windows RMS\Windows RMS Administra-
tion command. When you do, you will see a
screen similar to the one shown in Figure A.
Now, click the Provision RMS On This Web
Site link next to the Default Web Site option.
When you do, you will see the screen shown in
Figure B. As you can see in the figure, you are
asked whether you want RMS to use a local
database or a remote database. Just enter the
name of a SQL server in your organization that
can be used to store RMS data.
Next, you will be asked to specify the RMS
service account. The RMS Service account
must be a different account than the one that
was used to install RMS. If RMS will be run-
ning only on a single server, you can use the
local system account. However, the local sys-
tem account has access to practically every-
thing on the server, so there are some serious
security implications to using the local system
account in a production environment.
After entering the service account creden-
tials, scroll down and you will see the fields
shown in Figure C. The first thing that you
must enter on this portion of the screen is
the URL used by the root certification cluster.
By default, http://servername/_WMCS will
be used.
Next, you must enter a password that will
be used to encrypt the RMS private key in the
database. After entering the encryption pass-
word, enter the server licensor certificate
name. By default, this is the same as the server
name. You also have the option of listing an
administrative contact.
If your network uses a proxy server, then you
will have to enter the proxy server’s URL and
the IP address range for the local address table.
The final portion of the provisioning screen
allows you to enter the name of a file that
contains a public key that can be used to sign Figure C
the revocation list. This is useful in disaster
recovery situations. After you finish filling in
all of the various fields, click Submit and then
go get yourself a cold drink because the provi-
sioning process takes a while to complete.
When the provisioning process completes,
you must specify the RMS service connection
point. To do so, go to http://servername/
_wmcs/admin/default.aspx. Now, scroll to
the bottom of the page and click the link that
says RMS Service Connection Point. When
you do, you will see a screen that allows you to
set the RMS connection point by simply click-
ing the Update button.

Installing the client component

Before you will be able to use RMS to restrict
access to anything, including Microsoft Office
You must enter a cluster URL, private key protection enrollment, and some RMS proxy
documents, you must install the client compo- settings.
nent onto your workstations. To do so, you will
need to download the RMS client from Figure D
Microsoft’s Windows Rights Management
Client Web site (http://www.microsoft.com/
downloads/details.aspx?familyid=3115A3
74-116D-4A6F-BEB2-D6EB6FA66EEC&
displaylang=en). The download consists of
a 3.59 MB self-extracting executable file.
Microsoft Office 2003 also contains an option
for downloading the latest RMS automatically
from within Office.
After downloading the RMS client, copy it
to the workstation (or access it through a net-
work drive) and double-click on it. When you
do, Windows will extract the files from the Enter the e-mail addresses of the users who are allowed to read
or make changes to the document.
setup files in the RMS client file and will
launch the Setup wizard. When the Setup wiz-
ard begins, click Next to bypass the welcome Word 2003. Select the Permissions | Restrict
screen. You will then see the Windows Rights Permission As command from Word’s File
Management Client Privacy Statement. This is menu. When you do, Word will take a minute
basically just a statement indicating that the or two to negotiate a connection with your
RMS client does not try to personally identify RMS server. After the negotiation process
you to Microsoft or keep information about completes, you may see a screen asking you if
your system on file for an extended period of you want to create the RMS permissions by
time. Click Next and you will be asked to using a .NET Passport account or a Microsoft
accept the end user license agreement. After Windows account. If you see this screen, it
accepting the license agreement the installer means that RMS didn’t validate the user’s cre-
will copy the necessary files to the workstation. dentials somewhere and you need to go back
Click Close to complete the installation. and figure out what went wrong.
Once you have installed the client compo- What you should see instead is a screen ask-
nent, you can test it by opening Microsoft ing you which user account you want to use in

Security 203
 order to create or open restricted content.
Select your account and click OK. At this
point, you will see the screen shown in Figure D.
This screen allows you to enter the e-mail
addresses of users who are allowed to read or
make changes to the document.
Figure E
The Permission dialog box gives you greater control over a
document’s permissions.
204 Administrator’s Guide to Windows Server 2003
If you would prefer to have some slightly
more advanced configuration options, then
click the More Options button and you will see
the screen shown in Figure E. As you can see in
the figure, this Permission dialog box allows
you to set an expiration date for the document.
After the expiration date, the document “self
destructs.” You can also control whether speci-
fied users are allowed to print or copy the doc-
ument’s content or access it programmatically.
You can even allow users to browse a docu-
ment with previous versions of Office and to
request additional permissions to a document.
Trust, but verify
Although you may go to great lengths to pro-
tect the documents on your network, it’s too
easy for an employee with authorized access to
a document to copy the document and pass it
on to someone outside of the company. RMS
will prevent this type of information disclo-
sure by limiting who can open the document,
even if the file itself leaves your network.
Run Microsoft Baseline Security Analyzer 1.2
from the command line
July 6, 2004
By Scott Lowe ,MCSE
W
ith the release of version 1.2 of the
Microsoft Baseline Security Ana-
lyzer (MBSA 1.2), Microsoft has
vastly improved this already excellent proactive
security tool and turned it into a much more
full-featured utility. The MBSA includes a
powerful graphical user interface that provides
administrators with a way to interactively scan
the local and remote servers and desktop
machines. From the reports generated, admin-
istrators can take appropriate action to address
potential security problems, such as installing
required patches, enabling automatic updates,
or turning on the Windows XP firewall.
Scripted scans
One area that the GUI does not address is the
ability to script a scanning session. Most
administrators work normal business hours,
which are times that heavy scans are usually
avoided because of their potential impact on
the network, servers, and desktop computers.
For this reason, the MBSA includes a com-
mand-line utility that performs the same func-
tions as its GUI counterpart and can be
included in nightly/weekly/monthly routines
to scan for vulnerabilities. From this scan, a
report is generated from which an administra-
tor can take proactive steps to protect the
infrastructure.
The executables
MBSA includes two executables: mbsa.exe and
mbsacli.exe. The mbsa.exe executable powers
the GUI side of the utility, while, as you might
expect, the mbsacli.exe executable is the com-
mand-line side. By default, both of these exe-
cutables are stored in C:\Program Files\
Listing A
Computer Name, IP Address, Assessment,
—————————————————————————————————————————————————————————
WORKGROUP\W2K3, 192.168.1.103, Severe Risk,
Microsoft Baseline Security Analyzer. Please
note that if you have the GUI MBSA utility
open, the command-line version will not run.
By default, the results of a scan are stored in
the C:\Documents and Settings\user name\
SecurityScans folder and have names similar to
“WORKGROUP - W2K3 (5-20-2004 5-35
PM),” where the workgroup/domain is listed
along with the system name and the date and
time of the scan. This is true for both the GUI
and the command line, but you don’t usually
have to know this for the GUI, since the pro-
gram handles the report display.
Using the command line
There are two ways to run the command-line
version of MBSA. The first syntax actually
performs scans, and the second one provides a
listing of results from the most recent scan.
So, it’s a two-pass process.
Running a basic local scan
Mbsacli.exe doesn’t actually require any param-
eters. If you omit them, the local computer is
simply scanned, assuming that you have
administrative rights with the current logon.
The results of a local scan from the command
line should look something like Listing A.
Viewing the results of the basic scan
As with the GUI version, the command-line
version of MBSA produces very detailed results
to help you pinpoint and address potential secu-
rity weaknesses in your network. I like the fact
that it doesn’t just assume you want things
“fixed.” Instead, it provides information so you
can make a decision about what to address or
ignore. To get the results, type the following,
substituting the appropriate report name:
Report Name
WORKGROUP - W2K3 (6-1-2004 6-21 PM)
Security 205
 mbsacli /ld "WORKGROUP - W2K3
(6-1-2004 6-21 PM)"
When reports are generated using a com-
mand-line scan, they can also be viewed with
the GUI at your leisure. Both the GUI and the
command line store their files in the same loca-
tion, so each utility can use the scan results gen-
erated from the other utility. Figure A displays
the local scan showing up as an entry in the
GUI’s Pick A Security Report To View option.
Figure B shows the first page of that scan.
Personally, I like to be able to script this
kind of stuff and view the results with a GUI.
The command-line viewing option works, but
it’s more difficult to interpret.
Full syntax
As I mentioned, there are two syntaxes for
mbsacli.exe, depending on whether you want
Figure A
The recent scan also shows up in the GUI.
Figure B
The is the first page of the scan.
206 Administrator’s Guide to Windows Server 2003
to just run a scan or view the results of a pre-
viously run scan. Here’s the full syntax of the
mbsacli command:
mbsacli [/c|/i|/r|/d domain] [/n
option] [/o file] [/f file] [/qp]
[/qe] [/qr]
Switches you can use include:
X /c domain\computer—Scan the computer
named in domain\computer.
X /i IP_addr—Scan the computer identified
by the IP address provided.
X /r “IP_addr-IP_addr”—Scan the comput-
ers in the range of IP addresses provided.
X /d domain—Scan all computers in the tar-
get domain.
X /n option—By default, MBSA performs all
scans against the targets. Use /n to remove
specific scans. Valid options are OS, SQL,
IIS, Updates, Password. To omit more than
one scan, separate the /n options with a +
(plus sign).
X /o file—Specify the name of the file to
which to write the results. A default name is
presented above with the syntax “%D% -
%C% (%T%)”, where %D% is the domain
or workgroup name, %C% is the name of
the computer, and %T% is the date and
time of the scan.
X /f file—Write console output to the file
specified.
X /qp—Don’t display the progress of the
current scan.
X /qe—Don’t display errors present in the
current scan.
X /qr—Don’t display the list of reports.
X /s 1—Suppress security notes.
X /s 2—Suppress security notes and warnings.
X /nvc—By default, MBSA always checks for
a new version of itself when it runs. Use
/nvc to skip this check.
X /baseline—Check only for baseline secu-
rity updates rather than all updates (default
in GUI).
X /nosum—Do not verify checksums for
security updates. Use only if you need dif-
ferent language versions of patches and
 need to rename them for a language sup-
ported by MBSA (default in GUI).
X /sus [susserver | susfilename]—Get a list
of approved updates from a SUS server.
This option requires the URL of the SUS
server and will look for a file named
approveditems.txt.
X /hf—Run in hfnetchk mode. Use “mbsacli
-hf /?” for details. This mode allows you to
use the extremely granular scanning and
reporting functionality that was present in
the command-line hfnetchk utility. Note
that, unlike straight-up mbsacli, this does
not produce XML output.
The report syntax and switches slightly vary.
The report syntax is:
mbsacli [/e] [/l] [/ls] [/lr file]
[/ld file] [/unicode] [/hf] [/?]
Switches include:
X /e—Show the errors from the most
recently run scan.
X /l—Show a list of all reports that are avail-
able for viewing.
X /ls—List the reports available from the
most recent scan. Remember that a report is
generated for each system in a scan.
X /lr file—Display the overview of the report
named by file.
X /ld file—Display the complete details of
the report named by file.
X /Unicode—Output Unicode only.
X /v—Display the reason codes for security
updates.
X /hf—Run in hfnetchk mode. Use "mbsacli
-hf /?" for details. This mode allows you to
use the extremely granular scanning and
reporting functionality that was present in
the command-line hfnetchk utility. Note
that, unlike straight-up mbsacli, this does
not produce XML output.
More flexibility from the
command line
Note that MBSA can scan up to 10,000
machines simultaneously. If you need to scan
more, you’ll have to perform multiple scans.
Scanning by IP address is limited to 256
machines. If you want to scan off-hours or run
scans regularly and view the results at your
leisure, mbsacli.exe is invaluable and is espe-
cially useful when combined with the reporting
functions of the GUI version of MBSA.
Security 207
Administrator's Guide to Order now and

Windows Server 2003 receive free

shipping!

TechRepublic's Administrator's Guide to Windows Server

2003 gets you up to speed quickly on Microsoft's newest
server operating system. Each chapter is packed with the
clear and concise how-to information you need to opti-
mize,
troubleshoot and secure Windows Server 2003.
Tap field-tested solutions. Minimize your learning curve. Turn
to the Administrator's Guide to Windows Server 2003 book and
accompanying CD to learn how to:
Plan for and deploy Windows Server 2003
Configure VPN connections
Fine-tune servers for optimum performance
Solve Group Policy problems
Troubleshoot Active Directory
Overcome DNS errors
Lock down servers
Secure wireless connections
Recover from disasters
And more
Eliminate guesswork. Leverage the proven expertise in TechRepublic’s
Administrator’s Guide to Windows Server 2003. Designed by IT pros for IT
pros, this unique book and CD set provide you with the tools and information
required to become an effective Windows Server 2003 administrator.

Order now and receive free shipping!

 Check Group Policy assignment with RSoP
March 24, 2004
By Jim Boyce
I
t’s a good bet you’re familiar with group
policy, which enables administrators to
assert change control and set a broad
range of settings for the operating system,
desktop and working environment, network,
and much more for servers and workstations.
You might also know that group policy can be
applied at different levels, which opens the
possibility for a policy at one level to override
the policy set at another level. So, determining
the resultant set of policy (RSoP) can some-
times be difficult. At best, it can be confusing.
To help administrators get a handle on group
policy, Microsoft introduced the Resultant Set
of Policy MMC snap-in. Here’s what the RSoP
snap-in does and how you can use it to get a
handle on your own policies.
How Group Policies are applied
Understanding how RSoP works requires that
you first understand how group policy is
applied and the factors that affect policy appli-
cation. Group policy can be applied at the site,
domain, domain controller, organizational unit
(OU), and local levels. Whether a particular
policy is effective depends on the level at
which it is applied and whether the same pol-
icy is set differently at a level with higher
precedence. Group policy is applied in the fol-
lowing order of precedence:
X OU policy
X Domain controller policy
X Domain policy
X Site policy
X Local policy
In addition, you can set the No Override
attribute for a group policy object (GPO).
When No Override is enabled, other GPOs
that set corresponding policies cannot override
the ones set in the protected GPO. For exam-
ple, assume you set a policy at the OU level,
which gets applied first, and set the policy dif-
ferently in a GPO that is assigned at the
domain level. At this point, the domain policy
will overwrite the OU policy. However, you
210 Administrator’s Guide to Windows Server 2003
enable the No Override attribute for the OU-
based GPO. Now, even though the domain
GPO would be applied after the OU policy
and therefore take precedence, the No Over-
ride attribute on the OU GPO prevents its set-
tings from being overwritten.
One other factor that determines whether
the settings in a given GPO become effective
is the permissions set on the GPO. For exam-
ple, if you remove the Read Or Apply Group
Policy permissions for a given security group,
the GPO’s policies will not be set for users in
that target group.
What’s the RSoP snap-in?
The RSoP snap-in enables you to query cur-
rent or planned policies and view the results of
that query, which is the resultant set of poli-
cies, for a specified target user and computer.
In addition to group policies, RSoP includes
administratively assigned settings including
those from administrative templates, folder
redirection, Internet Explorer maintenance,
security settings, scripts, and software installa-
tion policies. By including these objects, RSoP
provides a complete view of the environment
resulting from all of these settings.
The RSoP snap-in operates in one of two
modes: Logging Mode or Planning Mode. In
Logging Mode, the RSoP snap-in queries poli-
cies and displays the resulting policy set for a
given user and computer. Logging Mode there-
fore enables you to review the policy settings
that are applied for the target user/computer.
Logging Mode can be a valuable and effective
tool for troubleshooting policy application
problems and determining how security
groups affect policy settings.
Planning Mode enables you to explore differ-
ent policy scenarios. In Planning Mode you
specify several items of information about the
desired target including container or user, com-
puter, site, security group membership, and
other factors to determine the resultant set of
policy based on those selections. Planning Mode
offers an excellent means for determining the
results of planned policy deployment and testing Figure A
the deployment before actually rolling it out.
The RSoP snap-in is available with Win-
dows XP as well as Windows Server 2003. You
don’t need to run the snap-in on a domain
controller to gather information about a user
or computer from the Active Directory in
Planning Mode. Instead, you can run it from a The RSoP MMC starts off empty.
Windows XP workstation.
Both RSoP modes are useful in different Figure B
scenarios. I’ll explore both, beginning with
Planning Mode. All examples assume you are
running the RSoP snap-in on Windows Server
2003, but it’s very similar on Windows XP.

Using RSoP in Logging Mode

If you’ll be querying policies from a remote
computer, you must first log on as a member
of the Domain Admins or Enterprise Admins
security groups, or you must have been dele-
gated Generate Resultant Set of Policy (log-
ging) rights. (I cover delegation later in this
article.) For local querying and logging, any
user can run a Logging Mode query on the
local computer.
To begin using RSoP, you need to open the
RSoP snap-in. Choose Start, Run, and enter
MMC. When the MMC opens, choose File,
Add/Remove Snap-In. On the Standalone tab,
Select the computer to examine.
click Add to open the Add Standalone Snap-In
dialog box. Scroll down, choose Resultant Set
Of Policy, click Add, and then click Close. settings from the query. This is handy when
Click OK on the Standalone tab to close it and you want to focus solely on user policies, such
return to the MMC. as when you suspect a user setting is causing
The RSoP snap-in at first doesn’t look like the problem at hand. Using this option
much (Figure A) because you haven’t queried excludes half of the possibilities and simplifies
for any policies yet. To query policy, you need the resulting policy set.
to run the Resultant Set Of Policy Wizard. Next, the wizard prompts you to specify
Right-click the Resultant Set Of Policy branch whether to use the current user (the one under
in the left pane and choose Generate RSoP which you are logged on) or to select a specific
Data to start the wizard. Click Next to get past user (Figure C). What the user list displays in the
the obligatory splash screen and then choose wizard depends on how you are logged on. If
Logging Mode. When you click Next, the wiz- you are logged on with a regular local account,
ard prompts you to select the computer to use you’ll see only that account. If you log on as
as the target (Figure B). You can choose the the local administrator, you’ll see the local
local computer, specify the remote computer administrator account and all other local
name, or click Browse to look for the com- accounts that have been used to log on at least
puter in the Active Directory. once (accounts that have never logged on do
The option at the bottom of the Computer not appear). It’s necessary to log on with a
Selection dialog box lets you exclude computer domain user account prior to running RSoP if

Security 211
 you want to view the policies for that domain
account. Logging on with the domain adminis-
trator account lets you choose that domain
administrator account or any local accounts
that have been used previously to log on.
You can also select an option here to exclude
the user settings and show only the computer
settings. Again, this option is handy when you
want to focus solely on computer settings and
simplify the resulting query. The Summary dia-
log box that appears when you click Next
shows the settings you have selected.
Figure C
Select what user to check policy on.
Figure D
Here’s a completed RSoP MMC.
212 Administrator’s Guide to Windows Server 2003
After the wizard finishes the query, the
RSoP snap-in will probably look a little more
familiar to you (Figure D), particularly if you
have worked with the Group Policy Editor.
The left pane provides a hierarchical tree of
settings. When you click a branch in the left
pane, the policies under that branch appear in
the right pane. The columns in the right pane
are essentially the same as in the Group Policy
Editor, but with the addition of a Source GPO
column that indicates the source for the policy
setting. You can double-click a policy to open a
dialog box that shows more information about
the policy, including its value (Figure E) and
precedence (Figure F).
At this point you can browse through the
policies as needed. If you need to view policies
for a different computer or user, you can either
clear the current query and reissue it, or open
another instance of the snap-in focused on the
desired target. To clear the query and start a
new one, right-click the upper-most branch of
the policy target in the left pane and choose
Change Query to start the Resultant Set Of
Policy Wizard. Follow the steps in the wizard
to specify the information for the new query,
just as you did for the old one.
Opening a new instance of the RSoP snap-
in rather than clearing the existing query is
useful when you need to compare settings
between policy targets. Just add the snap-in as
you did for the first one, then right-click the
new instance in the left pane and choose Gen-
erate RSoP Data.
Using RSoP in Planning Mode
As I mentioned at the beginning of this article,
Planning Mode enables you explore different
policy scenarios. Essentially, Planning Mode
lets you play “What if ?” with policies and can
be extremely useful for the following tasks:
X Simulating the effects of policy changes at
various levels
X Viewing policies of new user accounts in
the Active Directory
X Testing policy precedence when the com-
puter and user are in different security
groups or different OUs
X Determining the effects of moving a com-
puter to a new location
Figure E Figure F

You can view the value of a policy. You can also view the group policy precedence.

X Simulating a slow network connection Figure G

X Simulating a policy loopback scenario
I’ll cover these in a moment. For now, let’s
get into Planning Mode. Start by adding the
RSoP snap-in to an MMC console. After
you’ve added the snap-in, right-click the Resul-
tant Set of Policy branch of the snap-in in the
left pane and choose Generate RSoP Data to
start the Resultant Set Of Policy Wizard. In
the wizard, choose Planning Mode when
prompted to choose the mode and then click
Next. The wizard displays the User And Com-
puter Selection page shown in Figure G. Here
you choose either a user or a container in the
AD. You also specify the container for the
computer or choose a specific computer.
On the Advanced Simulation Options page
(Figure H) you can specify some additional
options to test certain scenarios. For example, Choose the container here.
choose the Slow Network Connection option if
you want to test the effect of a slow network
connection on the application of group policy. The Loopback Processing option lets you
Why do that? A slow network connection can simulate the effect of configuring the User
affect policy application, causing some policies Group Policy Loopback Processing Mode pol-
not to be applied. Choosing the option to simu- icy for a GPO. Loopback provides a mecha-
late a slow network connection causes the RSoP nism by which you can control the way group
console to slow the data transfer, enabling you policies are applied. This policy offers two val-
to see the effects on the resultant set of policies. ues when set to Enabled: Replace or Merge.

Security 213
 When Replace is selected, the group policy
object list for the user is replaced entirely by
the list already obtained for the computer at
startup. When set to Merge, the group policy
list is a concatenation of the computer list
obtained at startup and the user list obtained
after logon. Setting this option in the RSoP
Figure H
You can select additional options for the RSoP console.
Figure I
Choose a site for your test scenario.
214 Administrator’s Guide to Windows Server 2003
snap-in in Planning Mode has the same effect
as setting the User Group Policy Loopback
Processing Mode policy for the target GPO.
The Advanced Simulation Options page also
allows you to choose a site for the scenario. Site
selection here enables you to analyze the effect
of settings based on startup or logon on a sub-
net other than the one from which you are
running the query. In the Alternate Active
Directory Paths page that follows in the wizard
(Figure I), you specify the location in which the
target policy is intended to be applied.
In the next two pages of the wizard you have
the capability to specify the security groups in
which the user and the computer reside. Figure J
shows the User Security Groups page (the
Computer Security Groups page is similar).
You can add and remove groups to simulate the
effect of actually changing group membership
for the target. However, you’re changing only
the simulated group membership, not the actual
group membership. In this way you can test
the effects of membership changes before you
actually make those changes.
The next two pages of the wizard prompt
you to specify how WMI filters for the GPO
are to be handled. WMI filters enable you to
filter the application of group policy based on
criteria such as hardware configuration. With
these two pages you can specify that all WMI
filters be applied or only selected filters be
applied for the user and/or computer. The final
page of the wizard displays a summary of your
selections and allows you to choose the domain
controller on which to process the simulation.
As with Logging Mode, Planning Mode gen-
erates a policy set that you can navigate and
view. Policies that have a setting other than Not
Defined have a red circle and X icon. This helps
you quickly identify policies that have been set.
Viewing error information
Unless you direct it not to do so, the RSoP
snap-in collects extended error information as
it performs the query. You can view this error
information to determine if any problems
occurred during the query. The availability of
these error messages can help you not only
identify problems with the RSoP snap-in but
also identify network or Active Directory
problems that are causing policy application Figure J
problems.
To view the error information, right-click
the Computer Configuration or User Configu-
ration branch after the query is complete and
choose Properties. Click the Error Information
tab, which lists each group policy component
that RSoP used to generate the policy report.
The list indicates the success or failure for each
component. Click on a component to view spe-
cific error information for that component.

Delegating RSoP
As I hinted at earlier in this article, you can dele-
gate permission to generate RSoP queries to
help distribute administrative workload. A user
who has been delegated the necessary permis-
sion can perform queries in either Logging
Mode or Planning Mode (as you designate) with-
out having to log on as or be a member of the You can simulate the effects on different groups.
Domain Admins or Enterprise Admins groups.
To delegate RSoP, open the Active Direc- Figure K
tory Users And Computers console. Right-
click the OU and choose Delegate Control to
start the Delegation Of Control Wizard. Click
Next, add the user or group to which you want
to delegate, and click Next. In the Tasks To
Delegate page (Figure K), place a check beside
Generate Resultant Set of Policy (Logging)
and / or Generate Resultant Set of Policy
(Planning) and then click Next. Click Finish to
apply the delegation.

Using the Delegation Of Control Wizard, you can allow other users to run the
RSoP MMC.

Security 215
 New Windows Server 2003 tool boosts
group-policy control
March 6, 2003
By Brien M. Posey, MCSE
A
nyone who has ever administered
group policies in a Windows 2000
Server environment knows that the
process can be both confusing and frustrating.
Although Microsoft’s hierarchical approach to
group policy implementation makes sense at a
logistical level, the management interface is
lacking, to say the least. Fortunately, this is one
of the major problems that Microsoft has
addressed in Windows Server 2003. When
Microsoft releases Windows Server 2003, it
plans to simultaneously release a brand-new
Group Policy Management console that pro-
vides a single interface for managing group
policies across the entire enterprise.
What is the Group Policy
Management Console?
The Group Policy Management Console is
Microsoft’s all-in-one solution for working
with group policy objects. It consists of a
Microsoft Management Console (MMC) Snap-
In and a set of script interfaces for managing
group policies via script.
To get an idea of why the Group Policy
Management Console will be such a great tool,
consider this: Administrators today use a vari-
ety of different tools to implement group pol-
icy settings. These tools include things such as:
X Active Directory Users and Computers
X Active Directory Sites and Services
X The Resultant Set Of Policy Snap-In
X The Access Control List (ACL) Editor
X The Delegation Wizard
Each of these tools exposes some fragment
of the total group policy functionality. The
Group Policy Management Console combines
all of the group policy functions currently
available through these tools and combines
them into a single interface. The utility also
includes things like backup, restore, copy, and
import functionality.
216 Administrator’s Guide to Windows Server 2003
Just because the Group Policy Management
Console integrates functionality from all of the
different tools that I mentioned earlier, it isn’t
intended as a replacement for these tools.
Remember that group policies are designed to
control security. While security settings are
certainly available through tools like Active
Directory Users And Computers or Active
Directory Sites And Services, those tools’ pri-
mary functions are related to administration,
not security. Therefore, you’ll still use the tools
that I listed in the same manner that you
always have.
In case you’re wondering, the Group Policy
Snap-In was replaced by the Group Policy
Object Editor in Windows Server 2003. How-
ever, the Group Policy Management Console
didn’t overwrite the Group Policy Snap-In. All
of the Group Policy Object Editor’s function-
ality has been rolled into the Group Policy
Management Console, but that doesn’t mean
that you can’t still use the Group Policy Snap-
In if you want. The Group Policy Manage-
ment Console is available for download at
http://www.microsoft.com/downloads/
details.aspx?FamilyId=0A6D4C24-8CBD-
4B35-9272-DD3CBFC81887&display-
lang=en.
System requirements
The Group Policy Management Console’s sys-
tem requirements are a little strange to say the
least. For example, the product supports Win-
dows 2000, but it won’t run on Windows
2000. The new Group Policy Management
Console can be used to manage group policies
in both the Windows 2000 and Windows
Server 2003 version of Active Directory. This
means that you’ll be able to take full advantage
of the tool’s new management capabilities
even if you aren’t planning to upgrade to Win-
dows Server 2003.
The catch is that the utility won’t run on the
Windows 2000 operating system. Instead, you
can run the Group Policy Management Con-
sole only on machines running Windows
Server 2003 or Windows XP. If you’re plan-
ning on running the utility under Windows XP,
there are some additional system requirements
that you need to be aware of.
You’ll be able to run the Group Policy Man-
agement Console under Windows XP only if
you’ve installed Service Pack 1 and the
Microsoft .NET Framework support. There is
also a post-Service Pack 1 hot fix that must be
installed prior to installing the utility. The hot
fix was previously available on the Microsoft
Web site in Knowledgebase article Q326469.
However, Microsoft has temporarily removed
the hot fix. According to the Web site, the nec-
essary hot fix will be included with the Group
Policy Management Console download.
In case you’re wondering, the Group Policy
Management Console will be localized. When
the product is complete, versions will be avail-
able in English, Japanese, French, and Ger-
man. The current beta release is available in
English and Japanese only. Additionally, the
Group Policy Management Console will be
fully supported by Microsoft Primer Support
Service, once released.
Key features and capabilities
The Group Policy Management Console
includes an MMC Snap-In and a set of script-
ing utilities. The main idea behind the MMC
Snap-In is that it exposes group policy settings
in the way that users tend to use them rather
than in the way that the technology is designed.
For example, the group policy settings relating
to users are kept in a different area of the
Active Directory from the group policy settings
related to Sites And Services. Therefore,
Microsoft initially created two different tools
(Active Directory Users And Computers and
Active Directory Sites And Services) to deal
with the two different areas of the Active
Directory. The new Group Policy Management
Console combines the security-related func-
tionality found in both of these and other tools
and rolls it into a single snap-in.
The new utility will also feature backup and
restore capabilities. Previously, if you wanted
to back up and restore group policy settings,
you had to perform an authoritative restore on
the entire Active Directory. This meant that
other things, like user accounts or printer defi-
nitions, were also reverted to the time that the
backup was made. The new utility, however,
allows you to restore only the group policy set-
tings for a domain.
Yet another new feature is the generation of
HTML reports related to group policy settings
and the resultant set of policy data. You can
even save or print these reports.
Finally, import/export, copy/paste, and
scripting features have been included in the
Group Policy Management Console. Although
you can’t script individual group policy values,
the scripting does have a definite purpose.
The import/export, copy/paste, and scripting
functions all work together to allow you to
migrate group policies between domains.
Migrating group policy objects
to another domain
The new Group Policy Management Console
allows you to migrate group policies from one
domain to another. There are lots of situations
where such an operation is desirable. For
example, if you perfected a new policy in a test
domain, it would usually be easier to migrate
the policy than to manually re-create it in the
new location. Another possible situation is if
your company adopted a new set of security
standards, you wouldn’t want to have to manu-
ally implement those standards across every
domain. Instead, it’s now possible to create the
new policy in one domain and roll it out to all
other domains.
There are a couple of reasons why migrat-
ing group policy objects between domains is
such a big deal. The first reason is that a group
policy is a collection of security settings
applied through various mechanisms to vari-
ous objects. Components of a group policy
might exist in the registry, Active Directory,
the file system, or just about anywhere else. It
isn’t like all of a group policy’s components
exist in a single folder that can easily be copied
from machine to machine.
The other issue that makes copying group
policy objects between domains difficult is that
certain group policy settings contain data that
Security 217
 simply doesn’t migrate well. The two main
types of data that tend to cause problems are
security principles and Universal Naming Con-
ventions (UNCs).
Security principles are often found in the
form of security identifiers (SIDs). SIDs are
unique identification numbers that are applied
to each object. For example, objects such as
users, groups, and computers all have SIDs
associated with them. Because of the unique
nature of SIDs, a SID that’s valid in one
domain wouldn’t necessarily be valid in
another domain.
Just as SIDs can throw a monkey wrench
into the process of migrating a group policy
object, so too can UNCs. A UNC refers to a
path that’s expressed in the \\servername\
sharename format. The problem is that a
server name and share name that are valid in
one domain may not be valid in another
domain.
The Group Policy Management Console
takes a lot of the work out of migrating
group policy objects to a new domain. How-
WATCH OUT FOR THESE ITEMS
The following items contain security princi-
ples and can therefore cause problems
because they may reference SIDs:
XSecurity policy settings found in user
right assignments
XRestricted groups
XServices
XThe file system
XThe registry
XAdvanced folder redirection policies
XThe GPO DACL
XThe DACL applied to software installa-
tion objects
Also, UNC paths, which can lead to prob-
lems with group policy object migrations as
well, can be found in:
XFolder redirection policies
XSoftware installation policies
XLogin scripts
XStartup scripts
218 Administrator’s Guide to Windows Server 2003
ever, doing so may still be a fairly involved
process. The Group Policy Management Con-
sole is capable of performing four functions
that are related to policy archival. These func-
tions are:
X Backup
X Restore
X Copy
X Import
Don’t even try to use the Backup and
Restore operations for migrations. It’s impossi-
ble to restore a policy backup to a different
domain. You can use the Import function with
the Backup function as a technique for updat-
ing a group policy object’s existing settings, but
to do so, a group policy object must already
exist in the destination directory, even if the
existing group policy object is empty. The
Copy function is almost always the tool of
choice for migrations, because the Copy
process doesn’t require you to have a group
policy object that’s already in place in the desti-
nation domain.
As you can see, the two main problems
associated with migrating group policy objects
between domains are the distributed nature of
the policy settings and the fact that SIDs and
UNCs would be mismatched if the policies
were to be copied directly. Fortunately, with a
little work, you can use the Group Policy Man-
agement Console to overcome both of these
problems. Overcoming the problem of distrib-
uted information is easy and automatic. Since
the Group Policy Management Console
already knows where all of the group policy
setting information is stored, you don’t have to
worry about tracking it down.
Overcoming the information mismatch
problem is a little more complicated though.
In order to deal with SID and UNC mis-
matches, you must create a migration table. A
migration table is an XML file that maps an
old value to a new value. I’m not going to get
into the specifics of creating migration tables,
because it would be possible to write an entire
article on this one step of the process. What I
can tell you though is that each entry in a
migration table has three values: an object
type, a source value, and a destination value.
 For example, if a particular group policy
was applied to a global group called Test
Group in a domain called TEST, and you
wanted the policy to apply to the Finance
group in the PRODUCTION domain, then
the object type would be a global group, the
source value would be TEST\TEST GROUP,
and the destination value would be PRODUC-
TION\FINANCE.
After looking at my sample entry in a migra-
tion table, the process of creating migration
tables may not seem that complicated. The
problem is that in the Beta 2 release of the
Group Policy Management Console, there was
no user interface for creating migration tables.
Therefore, if you need a migration table, you
must either write some raw XML code, or you
can use a script to generate the XML code and
then use a text editor to modify the code and
fill in the appropriate values. Either way is
tedious and complicated.
As you can see, the process of migrating
group policy objects from one domain to
another can be a real pain in the neck. Before
you criticize the Group Policy Management
Console too much though, remember that up
until now there was no way of migrating a
group policy object to another domain.
Migrating a group policy object through the
Group Policy Management Console is a crude
process, but this is first-generation software
that’s still in its beta testing phase. I think that
it’s likely for future versions to include a user
interface for creating migration tables.
Good things come to those
who wait
As you can see, the Group Policy Management
Console should make life much easier for
those who manage group policies. Further-
more, this utility could drive down Windows’
total cost of ownership since it will make the
management process much easier and more
efficient.
Security 219
Administrator's Guide to Order now and

Windows Server 2003 receive free

shipping!

TechRepublic's Administrator's Guide to Windows Server

2003 gets you up to speed quickly on Microsoft's newest
server operating system. Each chapter is packed with the
clear and concise how-to information you need to opti-
mize,
troubleshoot and secure Windows Server 2003.
Tap field-tested solutions. Minimize your learning curve. Turn
to the Administrator's Guide to Windows Server 2003 book and
accompanying CD to learn how to:
Plan for and deploy Windows Server 2003
Configure VPN connections
Fine-tune servers for optimum performance
Solve Group Policy problems
Troubleshoot Active Directory
Overcome DNS errors
Lock down servers
Secure wireless connections
Recover from disasters
And more
Eliminate guesswork. Leverage the proven expertise in TechRepublic’s
Administrator’s Guide to Windows Server 2003. Designed by IT pros for IT
pros, this unique book and CD set provide you with the tools and information
required to become an effective Windows Server 2003 administrator.

Order now and receive free shipping!

 Learn how to take advantage of the Group
Policy Management Console
Feb. 18, 2004
By Louis Nel
M
anaging Group Policies in Windows
has typically required a bit of a jug-
gling act, especially in large corpo-
rate environments with a complex Active
Directory (AD) structure. But those days are
gone, thanks to the Group Policy Manage-
ment Console (GPMC), a free tool that
Microsoft has made available for download
at http://www.microsoft.com/windows
server2003/gpmc/default.mspx.
Without GPMC, you have to employ a vari-
ety of different tools—such as Active Direc-
tory Users And Computers, AD Sites And
Services, Access Control List Editor, the
Resultant Set of Policy (RSoP) snap-in, and
Delegation Wizards—to tame the many-
headed beast of Group Policies in Active
Directory. GPMC brings the functionality of
all those tools neatly together into a single,
powerful management console that enables
you to manage multiple domains and forests
with ease, thanks to a unified interface.
What GPMC can do
In addition to the features mentioned above,
GPMC has the ability to back up and restore
Group Policy objects (GPOs); import/export
and copy/paste GPOs and Windows Manage-
ment Instrumentation (WMI) filters; provide
Figure A
222 Administrator’s Guide to Windows Server 2003
HTML reporting of GPO settings and RSoP
data. What’s more, most of these operations
are scriptable. Using these operations, you can
plan, create, test, and migrate Group Policies.
GPMC can be used to manage Windows
Server 2003 and Windows 2000 domains. Of
course, Active Directory must already be
enabled. The GPMC console itself can be
installed on a workstation running Windows
Server 2003, Windows XP Professional with
Service Pack 1 (plus an additional post-SP1 hot
fix that is included with GPMC), and the
Microsoft .NET Framework (http://www.
microsoft.com/downloads/details.aspx?
FamilyID=262d25e3-f589-4842-8157-
034d1e7cf3a3&DisplayLang=en). GPMC
does not, however, run under Windows 2000.
Also, in terms of the license, you must have at
least one copy of Windows 2003 running on
your network (or have one license of Windows
Server 2003 available).
Using GPMC
Let’s take a look at the unified management
console (Figure A) in GPMC, which is the most
important aspect of the tool.
Until now, a GPO’s strength—an orderly,
categorized collection of layer upon layer of
settings—was also its weakness, because there
was no easy way to get a bird’s eye view of the
policy settings. If this was a problem with one
GPO, the problem became compounded by
the number of GPOs you had to manage and
keep track of.
With GPMC, that has changed. For an
overview of a GPO’s settings (called report-
ing), expand Group Policy Objects and select
the GPO (Figure B).
In the right-hand pane, under the Settings
tab, click on Show All at the top right. A sum-
mary of the GPO’s settings will be displayed
as an HTML report. This report can be gen-
erated by any user with read access to the
GPO. Previously, users required read and write
permissions to the GPO to open it. Why the Figure B
change? This makes things easier for certain
categories of users who need to see but not
edit GPO settings, such as helpdesk techni-
cians or administrators troubleshooting a
Group Policy issue.
With GPMC you now also have the ability
to save all the settings in a GPO to a file for
printing or viewing. Just right-click the
desired category or categories that you’ve
opened, and select Print or Save report from
the context menu. Reports can be saved to a
file as either HTML or XML. To view a saved
report directly in a Web browser, you need
Internet Explorer 6 or Netscape 7. You can
also generate similar reports for Group Policy
Modeling and Group Policy Results (more
about these later).
GPMC will provide you with just as simpli-
AUTHOR’S NOTE
fied an overview of the net effect of all your
Where have all the sites gone? The Sites node is initially
GPOs using Group Policy Results, formerly
empty. Right-click on it and select Show Sites for your sites
known as the Resultant Set of Policy tool.
Can’t see the forest through the trees? to appear. The absence of sites is “to speed up console per-
GPMC allows you to list only the forests and formance by not enumerating a potentially large number of
domains you wish to see. Simply right-click the sites in the forest, unless explicitly requested by the user,”
forest or domain node and select Remove. according to Microsoft.
Getting forests back (or adding more) is as
easy as right-clicking Group Policy Manage- to the RSoP. The former is a powerful new fea-
ment and selecting Add Forest. ture enabling you to simulate the effect of pol-
icy settings for planning purposes. You can
AUTHOR’S NOTE simulate the effect of policies for any user and
By default you can add a forest to GPMC computer in a forest. The Group Policy Results
only if there is a two-way trust with the for- node provides you with the actual resultant set
est of the user running GPMC. You can, of policies for users and computers.
however, get GPMC to work with only Group Policy Results is available only for
one-way trust or even no trust, but that is computers running Windows XP or Windows
beyond the scope of this article. Server 2003. But although you cannot obtain
Group Policy Results data for a Windows 2000
As you probably noticed, a forest has four computer, you can simulate the RSoP data
subnodes: Domains, Sites, Group Policy Mod- using Group Policy Modeling.
eling, and Group Policy Results. The Group Although GPMC, by default, uses the same
Policy Modeling node (the new name for the domain controller for all operations in that
Resultant Group Policies in Planning node) will domain, you can choose which domain con-
be visible only in a forest that has the Windows troller to use for each domain, as well for all
Server 2003 schema for Active Directory. You sites in a forest. You have a choice between the
will also need at least one domain controller PDC emulator, any available DC, any available
running Windows Server 2003 if you want to DC running Windows Server 2003 (useful if
perform a Group Policy Modeling analysis. you are restoring a deleted GPO containing
Both the Group Policy Modeling node and Group Policy software installation settings), or
the Group Policy Results node give you access any DC you specify. To choose a DC, right-click

Security 223
 the domain node and select Change Domain
Controller. To choose a DC for operations on
sites, right-click the Sites node and click
Change Domain Controller.
Microsoft warns that it is important to con-
sider the choice of domain controller in order
to avoid replication conflicts. “This is espe-
cially important to consider since GPO data
resides in both Active Directory and on
SYSVOL, and two independent replication
mechanisms must be used to replicate GPO
data to the various domain controllers in the
domain. If two administrators are simultane-
ously editing the same GPO on different
domain controllers, it is possible for the
changes written by one administrator to be
overwritten by another administrator, depend-
ing on replication latency. To avoid this situa-
tion, GPMC uses the PDC emulator in each
domain as the default to help ensure that all
administrators are using the same domain con-
troller. However, it may not always be desirable
to use the PDC. For example, if the adminis-
trator resides in a remote site or if the majority
of the users or computers targeted by the
GPO are in a remote site, then the administra-
tor may want to choose to target a domain
controller at the remote location. It’s impor-
tant to note that if multiple administrators
manage a common GPO, it is recommended
that all administrators use the same domain
controller when editing a particular GPO, to
avoid collisions in File Replication Services
(FRS).” This comes from the Microsoft White
Paper “Administering Group Policy with the
GPMC” (http://www.microsoft.com/win-
dowsserver2003/gpmc/gpmcwp.mspx).
Creating GPOs
There are various ways you can create GPOs
using the GPMC:
X Right-click any domain or Organization
Unit (OU) and choose Create and Link.
You can then simultaneously create a new
GPO and link it to the domain or OU.
X Right-click Group Policy Objects and click
New to create a new unlinked GPO.
X Use a script, like the sample script called
CreateGPO.wsf, included in GPMC.
X Copy the GPOs.
224 Administrator’s Guide to Windows Server 2003
Once you have created the GPOs, you have
to define settings. To do so (as you did up to
now using the Group Policy snap-in, Group
Policy Editor, or GPedit), merely right-click a
GPO and choose Edit.
Applying a GPO (referred to as “scoping
the GPO”) to users and computers by linking it
to a site, domain, or OU is easy using GPMC.
AUTHOR’S NOTE
GPOs can be applied to sites, domains, and
OUs. These GPO targets have often been
referred to as SDOU, but the preferred term
now is Scope of Management, or SOM.
Here are the ways you can link a GPO
to SOMs:
X Right-click a domain or OU node, and
choose Create And Link A GPO Here.
X Right-click a site, domain, or OU node, and
choose Link An Existing GPO Here.
X Drag a GPO from under the Group Policy
objects node to the OU (you can drag-and-
drop only within the same domain).
If you need to specify new locations in which
to place new user accounts, new computer
accounts, or both, Windows Server 2003 has
two new tools for the job. Redirusr.exe (for user
accounts) and Redircomp.exe (for computer
accounts) can be found in the %windir%\
system32 directory of a WS2K3 system.
GPO security filtering
GPMC simplifies security filtering for a GPO.
Security filtering refers to managing permis-
sions on a GPO. You can employ this to fur-
ther help you determine which users and
computers will receive the settings in a GPO.
For a GPO to apply to a user or computer, that
user or computer must have both Read and
Apply Group Policy permissions on the GPO.
Up to now, you had to use the ACL editor
to set the Read And Apply Group Policy per-
missions for users, computers, and groups if
you wanted to change the scope of a GPO.
With GPMC, all you have to do is add or
remove security principals (users, computers,
groups) in the security filtering section under
the Scope tab for the GPO or the GPO link.
The Read And Apply Group Policy permis-
sions for the relevant security principal is then
automatically set or removed.
Group Policy inheritance
You can also use GPMC to see the effect of
Group Policy inheritance. Just select the con-
tainer and choose the Group Policy Inheri-
tance tab in the details pane. All the GPOs for
the selected container will be shown that
would be inherited from parent containers
(except for GPOs linked to sites). Note the
Precedence column. It shows the order of
precedence for all the links that would be
applied to objects in this container.
To block inheritance, right-click on the
GPO link and deselect Enforced. You can also
set a GPO link to Enabled (again, right-click
the link and select Enabled from the drop-
down menu) to allow it to be processed.
WMI Filters
A new feature of Windows Server 2003 and
Windows XP is WMI Filters, which enable you
to dynamically determine the scope of GPOs
based on attributes of the target computer. As
Microsoft says, “This provides the administrator
with the potential to dramatically extend the fil-
tering capabilities for GPOs well beyond the pre-
viously available security filtering mechanism.”
To create WMI Filters, right-click either the
WMI Filters container or the Contents pane
for this node and select New.
There are three ways to link such a filter to
a GPO:
X On the Scope tab of the GPO, use the
WMI Filter drop-down menu to select a
WMI Filter to link to the GPO.
X On the General tab of a WMI Filter, right-
click the GPOs that use this WMI Filter
section and select Add.
X Drag a WMI Filter onto a GPO.
GPO operations
Because there is too much detail about GPO
operations—the ability to backup (export),
restore, import, and copy GPOs—to cover in
this article, I will focus on one aspect here: the
ability for planning, creating, testing, and
migrating group policies.
Using a test environment closely resembling
the AD structure of your production environ-
ment, you can test and validate changes to your
policy deployment. Once you’re happy with
the result, you can import and/or copy the
GPOs to the production environment.
To help you set up a test environment that
closely resembles the production environment,
Microsoft has provided two sample scripts:
X CreateXMLFromEnvironment.wsf – As
Microsoft states: “This script uses the infor-
mation in a live domain to generate an XML
file and a set of GPO backups that repre-
sent the policy information for that domain.
The XML file captures information such as
OU structure, groups and users, GPOs and
the settings contained in them, links to
GPOs, security on GPOs, and WMI filters.
By running this script against a production
domain, you can capture the essential policy
information for that domain for later re-use.”
X CreateEnvironmentFromXML.wsf –
“This script populates a domain with policy
information such as OU structure, groups,
and users, GPOs and the settings contained
in them, links to GPOs, security on GPOs,
and WMI filters using an XML file and a set
of GPO backups referenced in the XML.
The XML file required as the input for this
script can be generated using the previous
script. By using this second script in con-
junction with the XML file previously gen-
erated, you can replicate the contents of
one domain to another.”
For details on using these scripts, see the
chapter “Staging Group Policy Deployments”
in the Windows Server 2003 Deployment Kit
(http://www.microsoft.com/windows
server2003/techinfo/reskit/deploykit.mspx).
Summary
This tutorial has walked you through the details
of using the Group Policy Management Con-
sole (GPMC) to streamline the creation and
deployment of Group Policies. This article has
also explained several caveats that you need to
be aware of when working with the GPMC and
Group Policies. All in all, most administrators
should be happy to have the GPMC to simplify
Group Policy management.
Security 225
 Configuring wireless security in
Windows Server 2003
Feb. 2, 2004
By Brien M. Posey, MCSE
T
raditionally, one of the biggest prob-
lems with wireless network security is
that it must be maintained individu-
ally for every client. New features in Win-
dows Server 2003 allow you to control
wireless security for Windows XP and Win-
dows 2003 clients via group policy. Here’s
how it’s done.
The Wireless Configuration
Service
Windows Server 2003 is designed to interact
with your wireless network. But in order to do
so, it must have a functional Wi-Fi compatible
NIC, and the Wireless Configuration Service
must be started. The Wireless Configuration
Service enables automatic configuration of
Wi-Fi NICs. By default, the Wireless Configu-
ration Service is set to start manually.
To do so, click Start l Administrative Tools|
Services. You’ll then see the Services console
appear. Scroll the right pane and double-click
the Wireless Configuration Service to open the
Figure A
You must start the Wireless Configuration Service.
226 Administrator’s Guide to Windows Server 2003
Wireless Configuration Properties sheet that’s
shown in Figure A.
Set the Startup type to Automatic and click
the Start button to start the service. Click OK
to close the properties sheet.
Wireless security and
group policies
So far, I’ve explained that there is a Wireless
Configuration Service that allows wireless con-
nections to be automatically configured. What
you might not know is that you can actually
design a group policy that dictates wireless
configuration. Aside from easing the adminis-
trative burden, you might want to also look at
automatically configuring wireless connections
for security reasons.
For example, suppose that your Finance
department and your Sales department both had
wireless networks. You would probably want to
prevent anyone from Sales from using the access
point in Finance, and vice versa. This could be
easily implemented through group policies.
Figure B
The New Wireless Network Policy Properties sheet allows
you to configure the wireless networking portion of the
domain level group policy.
 Remember that group policies can be
applied at the local computer, site, domain, and
organizational unit levels. Therefore, one way
of achieving the desired results would be to
create separate domains for Finance and Sales.
You could then modify the Default Domain
Security Policy for each domain to control the
wireless configuration for the domain.
To modify the wireless network policies for
a domain, go to a domain controller for the
domain and select the Domain Security Policy
command from the server’s Administrative
Tools menu. When you do, Windows will open
the Default Domain Security Settings console.
Navigate through the console tree to Security
Settings | Wireless Network (IEEE 802.11)
Policies. When you select this container, the
pane on the right will display a New Wireless
Network Policy. Double-click on this policy to
open the New Wireless Network Policy Prop-
erties sheet, shown in Figure B.
The first thing that I recommend doing is
replacing the name New Wireless Network
Policy with something more meaningful. For
example, I’m creating a wireless network policy
for a domain called test.com. Therefore, I’ll
use the name Wireless Network Policy For
Test.Com. You can then enter a meaningful
description of the policy’s purpose if you want.
The next option on the Properties sheet’s
General tab is an option to check for policy
changes at a predetermined frequency. By
default, Windows checks for policy changes
every three hours. There is really no reason to
change this unless you expect to be making a
lot of changes to the policy.
The appropriate setting for the next option,
Network To Access, really depends on your
environment. The available choices include
Any Available Network (Access Point Pre-
ferred), Access Point (Infrastructure) Net-
works Only, and Computer-To-Computer (Ad
Hoc) Networks Only.
The default setting of Any Available Net-
work will work in just about any situation.
However, if security is what you’re interested
in, keep in mind that if no one in your office
has a legitimate use for ad hoc networks,
there’s no reason to allow ad hoc connections.
In such an environment your network would
be more secure if you were to set the Network
To Access option to Access Point (Infrastruc-
ture) Networks Only.
At the bottom of the General tab there are
two check boxes that deserve some attention.
The first of these check boxes is Use Windows
To Configure Wireless Network Settings For
Clients. This check box is selected by default
and should remain selected unless you have a
compelling reason to perform manual client
configurations. Keep in mind, though, that
only Windows XP and 2003 clients can be
configured by Windows Server 2003.
The other check box is Automatically Con-
nect To Non-preferred Networks. This check
box is not selected by default. I recommend
leaving this check box deselected because this
is a very dangerous option. Normally, you
would have some access points within your
network that you have designated as preferred
networks.
However, if someone installed a rogue
access point on your network or if a neighbor
installed an access point on their network that
was within range of your clients, the network
would be recognized as a non-preferred net-
work. If the Automatically Connect To Non-
preferred Networks check box were selected,
your clients could end up connecting to access
points that don’t even belong to your network.
The other tab on the New Wireless Net-
work Policy Properties sheet is the Preferred
Networks tab. As the name implies, this tab
allows you to designate which access points
represent your preferred networks. These will
receive preferential treatment when clients are
determining which access point to use for
accessing a network.
To designate an access point, click the Add
button and you’ll see the New Preferred Set-
ting Properties sheet. Begin filling in this prop-
erties sheet by entering the network name in
the Network Name (SSID) field on the Net-
work Properties tab. The network name is the
SSID of the access point. Once you have
entered the access point’s SSID, enter a
description in the space provided. You might
describe the physical location of the access
point or note why the access point is being
listed as a preferred network.
Security 227
 The next section of the Network Properties
tab, shown in Figure C, contains three check
boxes used to reflect the access point’s WEP
configuration. By default, the options Data
Encryption (WEP Enabled) and This Key Is
Provided Automatically are selected. Keep in
mind, though, that these are not always the
most appropriate choices. There are still a lot
of wireless networks that use shared keys that
are not automatically provided. In such a case,
you would deselect the Key Is Provided Auto-
matically check box, and select the Network
Authentication (Shared Mode) check box.
The final element of the Network Proper-
ties tab is the This Is A Computer-To-Com-
puter (Ad Hoc) Network check box. Most of
the time you would not select this check box.
You’d use this option only if you were actually
trying to configure an ad hoc network as a pre-
ferred network.
Once you have filled in the Network Prop-
erties tab, you need to fill in the IEEE 802.1X
tab. This tab allows you to specify all of the
parameters that are associated with 802.1X
network access control.
The first element on the IEEE 802.1X tab
is the Enable Network Access Control Using
IEEE 802.1X. This check box is selected by
default, as shown in Figure D. If you deselect
Figure C
The Network Properties tab allows you to designate the SSID
and WEP settings for the preferred access point.
228 Administrator’s Guide to Windows Server 2003
this check box, all other options on the tab are
disabled. Deselecting this check box tells Win-
dows that rather than using 802.1X authentica-
tion, you’ll use some other authentication
method, such as smart cards, certificates, or
passwords.
The next field that you must complete is the
EAPOL-Start message. The options in the
corresponding drop-down list allow you to
control the EAPOL-Start message’s transmis-
sion behavior. Your choices are Transmit, Do
Not Transmit, and Transmit Per 802.1X. The
Transmit option is selected by default.
Next on the IEEE 802.1X tab is the Para-
meters (Seconds) section. This section allows
you to configure the parameters that are used
with the EAPOL start message (assuming that
EAPOL start messages are being transmitted).
The first field in the Parameters section is
the Max Start field. This field allows you to
enter the maximum number of start messages
that will be generated by a client. Normally, a
client will transmit an EAPOL start message
and will wait for a response. If no response is
received, the client will transmit additional
start messages. This parameter defines the
maximum number of start messages that a
client is allowed to transmit when attempting
to connect to the designated network.
Figure D
The IEEE 802.1X tab allows you to configure 802.1X
authentication.
 Next, you must fill in the Start Period,
which is the number of minutes that a client
will wait after transmitting a start message
before transmitting another one. For example,
if the maximum number of start messages is
three and the start period is 60, then a client
would transmit a start message and wait one
minute for a response. If no response is
received within a minute, then the client would
transmit another message and wait another
minute. The cycle would continue until either a
response to the message is received or the
maximum number of start messages has been
used and the start period for the final transmis-
sion has expired.
Another value in the Parameters section is
the Held Period. The Held Period is the
amount of time that a client must wait after it
has received an authentication failure error
message from the authenticator. This prevents
a malfunctioning client from flooding the net-
work with authentication requests.
The final value that must be configured
within the Parameters section is the Authenti-
cation Period. The Authentication Period
works similarly to the Start period in that it
tells the client how long to wait before taking
additional action. The difference is that the
Start period refers to a wait period while the
client is initially trying to establish communica-
tions. The Authentication period is the amount
of time that the client must wait before
retransmitting any non-acknowledged 802.1X
requests after the initial end-to-end authentica-
tion has been established.
The next thing that must be configured on
the 802.1X tab is the EAP Type. The EAP
refers to the Extensible Authentication Proto-
col. Your choices are Smart Card Or Other
Certificate or Protected EAP (PEAP). Once
you have made your selection, you must click
the Settings button to specify the actual EAP
configuration information.
For example, if you were to select Smart
Card Or Other Certificate and click Settings,
you would see the Smart Card Or Other Cer-
tificate Properties sheet, shown in Figure E. As
you can see in the figure, the top portion of
this properties sheet gives you a choice of
using a smart card or using a certificate.
Figure E
You must choose between a smart card and a certificate.
If you’ve chosen to use a certificate, you
must select the Validate Server Certificate
check box. You must then tell Windows which
certificate authority it will use. If your com-
pany doesn’t subscribe to a commercial certifi-
cate authority, then select Enterprise CA. This
allows you to configure one of the servers on
your network to act as a Certificate Authority.
Click OK to return to the IEEE 802.1X tab
of the New Preferred Settings Properties
sheet. You now have just a couple of check
boxes that need to be configured. The first is
the Authenticate As Guest When User Or
Computer Information Is Unavailable. This
option is disabled by default and should
remain disabled. Enabling this check box
would allow unauthenticated computers or
users to access your wireless network.
You also should take a look at the Authenti-
cate As Computer When Computer Informa-
tion Is Available check box. This check box is
selected by default. It allows a computer to
access the wireless network even if the user is
not logged on. Doing so allows the computer
to receive antivirus updates, operating system
patches, and so forth.
The final option on the IEEE 802.1X tab is
the Computer Authentication drop-down list.
Security 229
 This list allows you to control how computer
authentication works with user authentication.
The default option is With User Re-authenti-
cation. This means that any time the user is
not logged on, authentication is performed
using the computer’s credentials. However,
when a user logs on, the user’s credentials are
used for authentication. When the user logs
off, the system goes back to using computer
credentials.
Another option is With User Authentica-
tion. When this option is used, computer cre-
dentials are used until a user logs on. The
computer credentials stay in effect unless the
user moves to a different access point. At that
point the user credentials take over. The only
other option is Computer Only. This option
means that the user’s credentials are never
taken into account and the computer’s creden-
tials are used for authentication.
Figure F
The preferred network is added to the list.
Figure G
The Access Point Information container gives you information about any access points that the server can see.
230 Administrator’s Guide to Windows Server 2003
When you have finally finished filling in the
New Preferred Setting Properties sheet, click
OK. The network is now added to the Pre-
ferred Network tab found on the New Wire-
less Network Policy Properties sheet, as shown
in Figure F. Click OK to create the new wireless
policy.
The Wireless Monitor
Another handy new tool included in Windows
Server 2003 is the Wireless Monitor. The
Wireless Monitor allows you to keep tabs on
all of the wireless network connections avail-
able near your server. In order to use the
Wireless Monitor, your server must have a
functional wireless NIC and also must be run-
ning the Wireless Configuration Service.
To access the Wireless Monitor, enter the
MMC command at the Run prompt. When
you do, Windows will open an empty
Microsoft Management Console. When the
console opens, select the Add/Remove Snap-
in command from the console’s File menu.
When you do, you’ll see the Add/Remove
Snap-in properties sheet appear. Click the Add
button found on the properties sheet’s Stand-
alone tab to see a list of all of the available
snap-ins. Select Wireless Monitor from the list
and click Add, Close, and OK. The Wireless
Monitor is now loaded within the console.
Now that the console is loaded, navigate
through the console tree to Console Root |
Wireless Monitor | Your Server Name. When
you expand the container with the same name
as your server, there will be about a ten-second
delay, and then two additional containers will
appear: Access Point Information and Wireless
Client Information.
If you select the Access Point Information
container, you’ll see information related to any
wireless access points that the server can see.
For example, if you look at Figure G, you can
see that there is one access point in the area,
named Posey.
The console displays information related to
the network type (which should always be
Access Point), the MAC address of the access
point, signal strength, data rate, and GUID. You
can also look at this screen to see if privacy is
enabled. Privacy refers to WEP or WAP encryp-
tion. You might notice that Windows provides a
column for Radio Channel, as well. In the figure,
the channel is blank because my access point is
configured to use channel hopping.
Securing IIS 6.0
Dec. 18, 2003
By Jim Boyce
M
icrosoft made several changes to
Internet Information Services (IIS)
6.0 to improve security, not the least
of which was a complete architectural over-
haul. This change, combined with others in IIS
function and management, make IIS 6.0 a
more secure platform than previous versions.
Many of the methods for securing IIS 6.0 are
the same as in previous versions, but there are
several new methods you can use to secure the
server in general and specific sites in particular.
Here are the most common methods you can
use to secure IIS 6.0.
General server security
There are common threads for securing
servers, regardless of the services they are run-
ning. Physical security, for example, is often
overlooked, particularly by smaller companies.
All of your servers should be in a locked room
with limited access and proper site preparation
for cooling, fire prevention, and power man-
agement. You should never leave a server
logged on and unattended. You should always
log off, but at the very least, press [Ctrl][Alt]
[Del] and lock the server. You should also use
a limited logon account whenever possible and
The Wireless Client Information container
contains information about wireless clients
connected directly to the server through an ad
hoc connection. You can view information
about wireless clients such as the connection
type, connection duration, local MAC address,
remote MAC address, network name, and even
a description of the client.
As you can see, the Wireless Monitor isn’t
really a security tool. However, it is a good
place to get detailed information about all of
the server’s wireless connections.
use the Runas command to start processes in
the administrator context when your limited
account doesn’t provide the necessary privi-
leges for the management task at hand. Also
consider implementing a strong password pol-
icy, especially for groups with administrative
privileges. Deny remote access to the server
unless absolutely necessary.
It’s also imperative that you protect the file
system, and the only way to ensure such pro-
tection is to use NTFS on all partitions on the
server as well as on any partitions hosting
shared volumes that the server accesses across
the network. Take the time to review permis-
sions on all volumes and folders with an eye
out for potential security risks. Also remove
unnecessary shares and hide shares by prefix-
ing the share name with $ whenever possible.
Keeping the server up to date is another
necessity. This means not only installing secu-
rity updates and patches as they come along
but also ensuring that the server includes a
working virus scrubber that you update at least
once a week. A perimeter scrubber that moni-
tors all incoming traffic is a great addition to
your network as the first line of defense
against viruses and worms, although you
Security 231
 should include virus scrubbers on each server
and workstation as well.
Finally, use member or stand-alone servers
whenever possible to host IIS and dependent
services. Keep IIS off of your domain con-
trollers to improve DC performance but, more
important, to ensure that if the server is com-
promised your domain security isn’t also com-
promised.
IIS 6.0 global security
improvements
There are several changes for IIS 6.0 in Win-
dows Server 2003 that improve server and net-
work security. First, when you install Windows
Server 2003, Setup does not install IIS by
default (a significant security improvement for
Windows Server overall). You can also config-
ure group policy to prevent IIS from being
installed. These two changes reduce the chance
that IIS will end up on servers where it should
not be, thereby reducing the network’s expo-
sure to attack.
When you do install IIS on Windows Server
2003, Setup installs the software in a more
secure state than in previous versions. For
example, the server is configured by default to
serve only static pages, with ASP.NET and CGI
disabled. Other services and components are
disabled as well, including server-side includes,
Internet Data Connector, WebDAV, Internet
Printing ISAPI, and Index Server ISAPI. Front-
Page Server Extensions are disabled, as is the
password change interface. The FTP and SMTP
services are also disabled by default.
The architectural changes in IIS 6.0 also
make for a more secure platform. Worker
processes run in user mode and therefore can’t
access privileged items in the kernel. They also
run in the context of the Network Service
account with relatively low privileges. Built-in
ASP functions run in the context of the
IUSR_machine account
Your capability to configure application
pools enables you to limit the kernel request
queue size, limit CPU utilization, and apply
other restrictions to help ensure that an attack,
when it comes, will have its impact minimized
on the server overall. To help combat buffer
overflow attacks, IIS 6.0 monitors incoming
232 Administrator’s Guide to Windows Server 2003
requests to identify unusually large transaction
requests that are indicative of an attack. You
can also configure IIS 6.0 to recycle worker
processes if they consume too much physical
or virtual memory based on limits that you
specify on a per-application-pool basis, reduc-
ing the impact of memory overflow exploits.
Your capability to isolate sites and applications
using multiple application pools and to config-
ure recycling parameters for those pools helps
reduce the effect of denial-of-service attacks.
IIS 6.0 includes other features and changes
to reduce its susceptibility to attacks. For
example, IIS 6.0 serves only those file types
explicitly defined by the administrator. If a
request arrives for an unregistered file type,
IIS 6.0 returns a 404.3 error to the client. The
server also strips out scripts embedded in
incoming requests before processing those
requests. Command-line tools are disabled for
IIS 6.0 by default, and running executable files
is allowed only to members of the Administra-
tors group and to selected built-in accounts,
preventing anonymous users from running
executable files. In addition, anonymous users
are denied write access to Web content by
default. Script source access is protected by a
new permission, which is disabled by default.
All of these features help block or limit the
impact of various types of Web server attacks.
Authentication options for IIS 6.0
You’ll find some changes in IIS 6.0 authentica-
tion options that also improve site and server
security. For example, anonymous authentica-
tion no longer requires the Log On Locally
right. In addition, sub-authentication, which
enables IIS to manage passwords for anony-
mous accounts, is no longer enabled by
default. You can, however, enable it if needed.
UNC pass-through authentication is also
changed in IIS 6.0 from previous versions.
UNC pass-through authentication enables IIS
to access resources stored on other computers
through Universal Naming Convention (UNC)
paths. UNC paths and UNC pass-through
authentication are commonly used to support
virtual directories hosted by other computers.
If you specify a user name and password for a
UNC share, those credentials are used by IIS
6.0 to access the remote resource.
 Specifying an incorrect user name or pass- Figure A
word results in a 500 Internal Server Error to
the client when the client tries to access the
virtual directory. If no credentials are supplied,
IIS 6.0 uses the credentials of the requesting
client to access the resource. If the client is
accessing the site anonymously, the account
assigned for anonymous access (such as
IUSR_machine) is used to authenticate on the
remote server. If the client has specified
account credentials, those credentials are used
to access the remote UNC resource.
Also new in IIS 6.0 is support for Advanced
Digest Authentication. Advanced Digest
Authentication improves security because the
MD5 hash is virtually impossible to decrypt.
You can allow or prohibit services.
Advanced Digest Authentication provides
higher domain security overall, as well, because Figure B
Windows stores user credentials as an MD5
hash in the Active Directory, eliminating the
need to configure the AD to store passwords
with reversible encryption. In order to use
Advanced Digest Authentication, clients must
be running a Web browser that supports
HTTP 1.1, must be in the same domain as the
server or in a trusted domain, and must be in a
domain controller that is running Windows
Server 2003. IIS drops back to Digest Authen-
tication if the domain controller is not running
Windows Server 2003.

Securing your server and sites

Now that you have some background in the
security changes and improvements in IIS 6.0,
you can turn your attention to protecting your
sites and servers. First, let’s look at enabling and
disabling Web service extensions. Open the IIS
Manager console from the Administrative
Tools folder and click the Web Service Exten-
sions branch in the left pane. The IIS Manager
displays the installed and defined extensions in
the right pane, as shown in Figure A.
To enable or disable a particular extension,
select the extension in the list and click Allow
or Prohibit, respectively. If you need to sup-
port ASP, for example, you will need to enable
the Active Server Pages extension. You can
also add new extensions from this branch.
Next, turn your attention to configuring
application pools to help protect your server
Application pools can help protect your server.
against attacks. To configure default applica-
tion pool properties, right-click the Applica-
tion Pools branch in the IIS Manager and
choose Properties. When you do, you’ll see the
screen shown in Figure B.
In the Memory Recycling area, enable the
Maximum Virtual Memory and Maximum
Used Memory options and specify the memory
limits based on the system’s memory configura-
tion and server load. It’s best to start with the
suggested default values and adjust as needed.
Next, click the Health tab and verify that
the Enable Rapid-Fail Protection option is

Security 233
 enabled. Also click the Identity tab and verify
that the default security account is set to Net-
work Service.
Another security-related task you will likely
need to accomplish is to configure the file types
that IIS 6.0 will support. You do so by modify-
ing the MIME type definitions for the server.
You can configure MIME types on a global or
site basis. To configure them at the global level,
open the IIS Manager console, right-click the
server, and choose Properties. On the Internet
Information Services tab, click MIME Types to
Figure C
Configure the file types your server supports.
Figure D
You should set authentication on virtual directories.
234 Administrator’s Guide to Windows Server 2003
open the MIME Types dialog box. You’ll then
see the screen shown in Figure C.
From here you can edit or remove existing
MIME types or create new ones. Bear in mind
that the global MIME types are inherited at the
virtual server and directory levels. Unless you
need to add a type globally, it’s best to add it
only at the level where it is required. To man-
age MIME types for a virtual server, right-click
the Web site and choose Properties. Click the
HTTP Headers tab and click MIME Types to
open the MIME Types dialog box, where you
can accomplish the same types of tasks as at
the server level. To manage MIME types at the
directory level, right-click the physical or vir-
tual directory in the IIS Manager console,
choose Properties, click the HTTP Headers
tab, and click MIME Types.
At this point, consider authentication
requirements for the server and/or sites. To
configure UNC pass-through authentication,
right-click an existing virtual directory that
points to a UNC share and choose Properties.
This will display the screen shown in Figure D.
On the Virtual Directory tab, click Connect
As to open the Network Directory Security
Credentials dialog box. Here you can specify
an explicit set of credentials to be used to
access the remote UNC share’s contents. If
you want IIS to use the user’s own credentials
to authenticate on the remote server, choose
the option Always Use The Authenticated
User’s Credentials When Validating Access To
The Network Directory. Keep in mind that if
you enable this option, anonymous users are
authenticated with the server’s IIS_machine
account. Configure accounts and permissions
as necessary on the server hosting the share.
Craft your authentication scheme to provide
only the bare minimum permissions necessary
for each user to perform his or her specific
tasks in the folder.
Next, look at the authentication require-
ments for the Web sites or specific directories
that use other than anonymous authentication.
Right-click the Web site or directory, choose
Properties, and click the Directory Security
tab. Then click Edit in the Authentication And
Access Control group to open the Authentica-
tion Methods dialog box.
 To prevent anonymous access, deselect the
Enable Anonymous Access option. Select the
other authentication methods you need to sup-
port from the Authenticated Access group. If
you choose Digest Authentication, IIS 6.0 will
attempt to use Advanced Digest Authentica-
tion and, failing that, will fall back to Digest
Authentication. If you choose Digest Authen-
tication or .NET Passport Authentication, you
also need to specify the Realm and Default
Domain, respectively.
While you have the Directory Security tab
open, consider whether you need to impose
connection restrictions on the Web site or
directory. If you have a directory that should
be accessible only by users internal to your
LAN, click Edit in the IP Address and Domain
Name Restrictions group, then add the individ-
ual IP address or subnet ranges of the allowed
clients. You can also specify a domain name,
but using this option requires a reverse DNS
lookup, which imposes server overhead and
requires that the clients have their IP addresses
appropriately registered in DNS.
You should also verify permissions for each
site and virtual directory. Open the site’s or
directory’s properties and click the Home
Directory or Directory tab. This will display
the screen shown in Figure E.
Ensure that you have not enabled Write
permission unless users need to be able to post
to the site. Script Source Access and Directory
Browsing should be disabled unless specifically
needed, and Execute Permissions should be
set to None unless you want to enable scripts
to execute. Finally, it’s a good idea to remove
all of the extra default documents that IIS
adds for a site or directory. Click the Docu-
ments tab and remove all but the specific
default document your site or directory uses.
Securing other functions
When you finish configuring Web site proper-
ties, you’re not finished configuring server
security. Although IIS 6.0 does not by default
enable FTP or SMTP, you should review secu-
rity for these services, as well. In the case of
FTP, I recommend you disable anonymous
access for FTP before ever considering taking
an FTP site live. If you do want to provide
Figure E
Set permissions on the Home Directory.
anonymous access for users, create a virtual
directory named anonymous and configure
that directory’s permissions as needed for
anonymous users.
Under this directory, add the directory
structure you want anonymous users to see.
Disable Write permission in the site’s main
folder, and then only after verifying the under-
lying NTFS permissions of each directory
should you enable anonymous access. By cre-
ating a virtual directory with the alias “anony-
mous,” you force anonymous users into that
virtual directory when they log on. Although
they can CD to the site’s root folder, you have
disabled Write permission, preventing users
from writing to the home directory. Create
other virtual directories for authenticated
access by other users, matching the virtual
directory alias to the user’s name, which will
cause the user to be placed in that directory
when they log on.
For the SMTP service, review the relay set-
tings to ensure that your server will not be
used for unauthorized relay. Open the proper-
ties for the virtual server, click the Access tab,
and click Relay. Choose the option Only The
List Below, then click Add and add the IP
address, subnet, or domain hosts that can relay
Security 235
Administrator's Guide to Order now and

Windows Server 2003 receive free

shipping!

TechRepublic's Administrator's Guide to Windows Server

2003 gets you up to speed quickly on Microsoft's newest
server operating system. Each chapter is packed with the
clear and concise how-to information you need to opti-
mize,
troubleshoot and secure Windows Server 2003.
Tap field-tested solutions. Minimize your learning curve. Turn
to the Administrator's Guide to Windows Server 2003 book and
accompanying CD to learn how to:
Plan for and deploy Windows Server 2003
Configure VPN connections
Fine-tune servers for optimum performance
Solve Group Policy problems
Troubleshoot Active Directory
Overcome DNS errors
Lock down servers
Secure wireless connections
Recover from disasters
And more
Eliminate guesswork. Leverage the proven expertise in TechRepublic’s
Administrator’s Guide to Windows Server 2003. Designed by IT pros for IT
pros, this unique book and CD set provide you with the tools and information
required to become an effective Windows Server 2003 administrator.

Order now and receive free shipping!

 through the server. Keep the list as restricted
as possible.
Don’t stop there!
Securing your IIS 6.0 server certainly isn’t a
one-click operation. When you finish reviewing
all of the security-related properties on the
server, turn your attention outward. Add-on
Working with Windows Server 2003’s
IP Security Monitor
Feb. 16, 2004
By Brien M. Posey, MCSE
W
hen Microsoft originally released
Windows 2000, it included a new
protocol called IPSec. The idea was
that network security could be greatly
increased by encrypting traffic as it flowed
across the wire. Although IPSec was a good
idea, the problem was that far too many
administrators would enable it and never really
do anything to confirm that IPSec was actually
encrypting traffic. This was unfortunate
because Windows 2000 included a utility called
IPSECMON.EXE that made it easy to check if
IPSec was working properly.
Over the years, I’ve grown quite fond of
IPSECMON.EXE. I was really surprised to
see that it didn’t exist in Windows Server 2003.
Although IPSECMON.EXE is gone, Micro-
soft replaced it with a new tool called the IP
Security Monitor Console. In creating this tool,
Microsoft has basically rewritten IPSEC-
MON.EXE to make it work within a console.
It then added support for all of the new IPSec
features that exist in Windows 2003. In this
article, I’ll introduce you to this new tool and
show you how to use it to verify that IPSec is
working as intended.
What’s new
Before you can really appreciate the IP Secu-
rity Monitor Console, you need to see what its
predecessor looked like. Figure A shows the
238 Administrator’s Guide to Windows Server 2003
applications, network and company policies,
firewall configuration, and a host of other non-
IIS issues ultimately affect IIS server security.
Identifying these and reviewing them in light of
overall security can go a long way toward secur-
ing your servers and your network.
IPSECMON.EXE utility that’s included with
Windows 2000 Server. Notice that the utility
contains no menu options and only two but-
tons: Options and Minimize. The only thing
you can do with the Options button is change
the refresh rate. My point is that although
IPSECMON.EXE does a decent job of count-
ing confidential and authenticated bytes, there
really isn’t much more that you can do with it.
Now that you’ve seen what the IPSEC-
MON.EXE utility looks like, let’s take a look at
the IP Security Monitor Console. As you can
see in Figure B, the console looks a lot different
than IPSECMON.EXE, but the differences
aren’t just cosmetic.
Earlier, I mentioned that the IP Security
Monitor Console had been extended to support
all of IPSec’s new features. There are too many
new IPSec features to discuss here, but I wanted
to at least take a moment and talk about some
of the things that the IP Security Monitor Con-
sole does that IPSECMON.EXE didn’t.
As you look at the console, one of the first
things you might notice is that just below the
IP Security Monitor container is a server listed
by name. The reason for this is that the IP
Security Monitor Console can monitor the
IPSec statistics for multiple computers rather
than just for the local computer, as was the
case with IPSECMON.EXE.
 Another nice new addition to the console is Figure A
the ability to view individual IPSec policies.
You can use the console to view things such as
the policy name, description, modification
date, store, path, OU, and even the name of
the group policy that it is being called from.
Yet another new feature is the ability to use
DNS name resolution for filter and security
association output. At first, this might not
seem like a big deal. After all, if you look at
Figure A, you’ll notice that most of the host
names are being resolved already. Therefore,
DNS name resolutions might not even seem
like a new feature. The difference, though, is
that all of the host names you see in Figure A
belong to hosts on my local network. The new
IP Security Monitor Console allows you to
resolve host names from across the Internet. The IPSECMON.EXE tool allowed you to confirm that IPSec was working, but
was crude, to say the least.
This is important because Windows Server
2003 supports using IPSec over a NAT firewall. Figure B
One last new feature that I want to talk
about is the filter search. As you probably
know, IPSec policies are based on filters and
rules. For example, a filter rule might dictate
that traffic flowing from and addressed to a
specific address must be encrypted. Although
filters and rules tend to work well, the very
nature of the Active Directory allows conflicts
to occur. When conflicts occur between filters,
one filter will take priority over another, and
the lower-priority filter will be ignored. This
can cause IPSec to behave unexpectedly.
If you notice IPSec acting strangely, you can
use the new console to search for specific fil-
ters or rules. This allows you to locate the filter
that is causing the unexpected behavior.

Accessing the IP Security The IP Security Monitor Console has been extended to take advantage
Configuration Console of all of the new IPSec features.

Now that I’ve shown you some of the differ-

ences between IPSECMON.EXE and the IP
Security Monitor Console, I want to demon-
strate how you can use the console to help
monitor and enforce IP security within your
own organization.
Begin by entering the MMC command at
the Run prompt. When you do, Windows will
load an empty Microsoft Management Con-
sole. Now, select the Add / Remove Snap In
command from the console’s File menu. This
will cause Windows to display the Add /
Remove Snap-in properties sheet. Click the
Add button found on the properties sheet’s
Standalone tab to reveal a list of the available
snap-ins. Select IP Security Monitor from the
list of available snap-ins and click Add, fol-
lowed by Close and OK. The IP Security Mon-
itor should now appear within the console.

Security 239
 Adding a computer
Since the IP Security Monitor allows you to
monitor multiple computers, the first thing you
need to know how to do is add another com-
puter to the list of systems to be monitored.
To do so, right-click on the IP Security Moni-
tor container and select the Add Computer
command from the resulting shortcut menu.
When you do, you’ll see the Add Computer
dialog box. It’s important to note that the IP
Security Monitor can monitor only computers
running Windows Server 2003.
Monitoring a computer
After you finish adding the computers to be
monitored to the list, it’s time to begin the
actual monitoring process. Expand the com-
puter container and, after a brief delay, you’ll
see three subcontainers:
Figure C
The Active Policy container shows which policy is in effect.
Figure D
The Generic Filter container applies policy number 1 to all traffic coming from my computer.
240 Administrator’s Guide to Windows Server 2003
X Active Policy
X Main Mode
X Quick Mode
Active Policy
As you’re no doubt aware, IPSec policies are
applied as a part of a group policy. Further-
more, group policies are hierarchical in nature.
Group policies can be applied at the local
computer level, the site level, the domain level,
and the Organizational Unit level. This means
that several policies can be applied to a user or
to a computer. As you might expect, it’s possi-
ble for policies to contradict with one another.
When group policies contradict, Windows uses
an algorithm to determine which group policy
is in effect.
What this means is that IPSec policies can
be applied at many different levels as well. If
Figure E

The Specific Filters container shows which filters apply to the machine, but in more detail than the Generic Filters container shows.

you need to know what IPSec policy is cur- Figure F

rently active, you can work through the algo-
rithm and determine the resultant set of policy,
or you can just open the IP Security Monitor
console and look at the Active Policy section.
The Active Policy section, shown in Figure C,
contains all of the pertinent details regarding
the policy that is presently in effect. As you can
see in the figure, the Active Policy container
lists the policy name and provides a descrip-
tion of what the policy is designed to do. You
can also see the date of the most recent modi-
fication to the policy. Although they’re not
applicable to my current configuration, you
can also see in Figure C that when appropriate,
the Active Policy container also displays infor-
mation regarding the policy path, organiza-
tional unit, and Group Policy Object Name.

Main Mode
The next section is the Main Mode container.
The Main Mode container’s job is to display
various Internet Key Exchange (IKE) statis-
tics. The Main Mode container is divided into
five separate subcontainers: Generic Filters,
Specific Filters, IKE Policies, Statistics, and
Security Associations.
The Generic Filters container, shown in
Figure D, contain a generic representation of
the current IKE policy. For example, on my
test machine, the generic filter is configured to
use my computer as the source and any com-
puter as the destination. The authentication
method is Kerberos, and the filter applies to all
connections. The policy that the filter links to
Each IKE policy consists of one or more methods.
is policy number 1, which is the machine’s
default policy.
The next container in the Main Mode area
is the Specific Filters container. This is really
just an expansion of the information found in
the Generic Filters container. As you can see in
Figure E, the specific filters actually list the
machine’s IP address rather than just saying Me
as the source. Furthermore, the Specific Filters
container also shows the direction of the traf-
fic. As you can see in the figure, there are actu-
ally two filters, one to handle inbound traffic
and one to handle outbound traffic.

Security 241
Figure G
The Security Associations container shows which computers are using the IKE policy to secure communications.
Earlier, I mentioned that the generic filter
(as well as the specific filter) was linked to the
default policy, or policy number 1. That policy
is contained within the IKE Policies container.
The default view simply shows the policy’s
number and the fact that it has four security
methods associated with it. However, if you
right-click on the policy and select the Proper-
ties command from the resulting shortcut
menu, you can see exactly what the four meth-
ods consist of, as shown in Figure F.
I want to momentarily skip over the Statistics
container and look at the Security Associations
Figure H
The IP Security Monitor collects a number of IKE statistics.
242 Administrator’s Guide to Windows Server 2003
container. This container, shown in Figure G,
shows the peer machines that the IKE policy is
being used with. Basically, this screen means
that communications between my machine
(147.100.100.99) and the machines Relevant
(147.100.100.58) and Homer (147.100.100.52)
are encrypted by the current IKE policy.
The last Main Mode feature that I want to
talk about is the Statistics container, shown in
Figure H. As you can see, there are quite a few
different statistics. The statistics you’ll find
include:
X Active Acquire: This reflects the number
of queued requests to initiate IKE negotia-
tion in an effort to establish a secure con-
nection. Under heavy loads, it’s normal for
this number to be one higher than the
actual number of queued requests.
X Active Receive: This is the number of IKE
messages that have been received and are
queued for processing.
X Acquire Failures: This reflects the total
number of outbound acquire requests that
have failed since the last time the IPSec
service was started.
X Receive Failures: This is the total number
of errors occurring while receiving IKE
messages since the last time the IPSec serv-
ice was started.
X Send Failures: This is the total number of
errors that have occurred while transmitting
IKE messages since the last time the IPSec
service was started. It is normal for this to
 be a high number if a dial-up connection is
in use.
X Acquire Heap Size: This is the number of
successful acquires.
X Receive Heap Size: This is the number of
currently buffered inbound IKE messages.
X Authentication Failures: These are the
total number of times that authentication has
failed since the IPSec service was last started.
X Negotiation Failures: The total number of
negotiation failures that have occurred since
the IPSec service was last started. This
counter tracks negotiation failures in Main
Mode and in Quick Mode.
X Invalid Cookies Received: This is the
total number of cookies that couldn’t be
matched to a Security Authority since the
IPSec service was last started. In this case,
cookies refer to an identifying value in an
inbound IKE message.
X Total Acquire: This is the total number of
requests issued to IKE since the last time
the IPSec service was started.
X Total Get SPI: This is the total number of
requests for a Security Parameter Index
(SPI) made since the last time the IPSec
Service was started.
X Key Additions: These are the total number
of outbound Quick Mode security authori-
ties that have been added to the IPSec
driver by IKE since the last time the IPSec
Service was started.
X Key Updates: These are the total number
of inbound Quick Mode security authorities
that have been added to the IPSec driver by
IKE since the last time the IPSec Service
was started.
X Get SPI Failures: These are the total num-
ber of failed requests that have been sent to
the IPSec driver by IKE since the last time
the IPSec Service was started.
X Key Addition Failures: These are the total
number of failed outbound Quick Mode
Security Authority addition requests sent to
the IPSec driver by IKE since the last time
the IPSec Service was started.
Figure I
Quick Mode offers some statistics of its own.
X Key Update Failures: These are the total
number of failed inbound Quick Mode
Security Authority addition requests sent to
the IPSec driver by IKE since the last time
the IPSec Service was started.
X ISADB List Size: This displays the total
number of Main Mode negotiations (suc-
cessful or not).
X Connection List Size: This is the current
number of Quick Mode negotiations that
are in progress.
X IKE Main Mode: This shows the total num-
ber of successful SAs that have been nego-
tiated during Main Mode negotiations since
the last time the IPSec Service was started.
X IKE Quick Mode: This is the total number
of successful SAs that have been negotiated
during Quick Mode negotiations since the
last time the IPSec Service was started.
X Soft Associations: These are the total
number of security associations formed
with computers that failed to respond to
Main Mode negotiation attempts.
X Invalid Packets Received: This shows the
total number of invalid or corrupt IKE
messages that have been received since the
last time the IPSec Service was started.
Security 243
 Quick Mode
Quick Mode works just like Main Mode except
that Quick Mode deals with IPSec instead of
IKE. You might have noticed that Main Mode
has a container named IKE Policies, while
Quick Mode has a container named Negotia-
tion Policies. Although the policy types are dif-
ferent, the actual method for viewing the
policies remains the same whether you’re in
Main Mode or in Quick Mode.
The only real difference between Main
Mode and Quick Mode (aside from the obvi-
ous) is the statistics that are displayed. You can
see the Quick Mode statistics in Figure I. The
statistics you’ll find include:
X Active Security Associations: This is the
number of currently active Quick Mode
security associations.
X Offloaded Security Associations: This
shows the current number of Quick Mode
security associations that have been
offloaded to an IPSec-compatible NIC.
X Pending Key Operations: This is the
number of IPSec key exchange operations
that are currently going on but that have not
yet completed.
X Key Additions: These are the total number
of successful key additions for Quick Mode
security association negotiations that have
been successfully added since the computer
was last rebooted.
X Key Deletions: These are the total number
of successful key deletions for Quick Mode
security association negotiations that have
been successfully deleted since the com-
puter was last rebooted.
X Rekeys: These are the number of success-
ful Quick Mode rekey operations since the
last reboot.
X Active Tunnels: This shows the total num-
ber of currently active IPSec tunnels.
X Bad SPI Packets: These are the number of
packets that have had an incorrect SPI since
the last time the computer was rebooted.
X Packets Not Decrypted: This shows the
number of packets that could not be
decrypted since the last reboot.
244 Administrator’s Guide to Windows Server 2003
X Packets Not Authenticated: This is the
total number of packets that have failed
integrity verification since the last reboot.
X Packets With Replay Detection: This is
the total number of packets with invalid
sequence numbers since the computer was
last rebooted. If this number increases
steadily, it could be an indication of an
attempted replay hack.
X Confidential Bytes Sent: This shows the
total number of sent packets encrypted by
ESP since the last reboot.
X Confidential Bytes Received: This is the
total number of received packets encrypted
by ESP since the last reboot.
X Authenticated Bytes Sent: This is the
total number of transmitted bytes
encrypted by the AH or the ESP protocol.
X Authenticated Bytes Received: This is
the total number of received bytes
encrypted by the AH or the ESP protocol.
X Transport Bytes Sent: This shows the
number of bytes sent using IPSec transport
mode since the last reboot.
X Transport Bytes Received: This is the
number of bytes received using IPSec trans-
port mode since the last reboot.
X Bytes Sent in Tunnels: This shows the
number of bytes sent in IPSec tunnels since
the last reboot.
X Bytes Received in Tunnels: This is the
number of bytes received in IPSec tunnels
since the last reboot.
X Offloaded Bytes Sent: This is the total
number of bytes transmitted using IPSec
hardware offloading since the last reboot.
X Offloaded Bytes Received: This is the
total number of bytes received using
IPSec hardware offloading since the last
reboot.
Administrator's Guide to Order now and

Windows Server 2003 receive free

shipping!

TechRepublic's Administrator's Guide to Windows Server

2003 gets you up to speed quickly on Microsoft's newest
server operating system. Each chapter is packed with the
clear and concise how-to information you need to opti-
mize,
troubleshoot and secure Windows Server 2003.
Tap field-tested solutions. Minimize your learning curve. Turn
to the Administrator's Guide to Windows Server 2003 book and
accompanying CD to learn how to:
Plan for and deploy Windows Server 2003
Configure VPN connections
Fine-tune servers for optimum performance
Solve Group Policy problems
Troubleshoot Active Directory
Overcome DNS errors
Lock down servers
Secure wireless connections
Recover from disasters
And more
Eliminate guesswork. Leverage the proven expertise in TechRepublic’s
Administrator’s Guide to Windows Server 2003. Designed by IT pros for IT
pros, this unique book and CD set provide you with the tools and information
required to become an effective Windows Server 2003 administrator.

Order now and receive free shipping!