Active Directory Authentication Types

The two types of authentication are Mutual Authentication and NTLM. Mutual Authentication
requires both the server and the client to identify them. NTLM only requires the client to be
validated by the server.

Two types of authentication are Mutual Authentication and NTLM Authentication.

Mutual Authentication
Mutual Authentication is a security feature in which a client process must prove its identity to a
server, and the server must prove its identity to the client, before any application traffic is sent
over the client-to-server connection. Identity can be proved through a trusted third party and use
shared secrets, as in Kerberos v5, or through cryptographic means, as with a public key
infrastructure.

Support for mutual authentication is provided by the security support provider interface (SSPI)
and is exposed directly through the SSPI APIs and services that layer upon SSPI, including RPC
and COM+.

Not all security packages available to SSPI, or all services running Windows 2000 or later,
support mutual authentication. An application must request mutual authentication and a
supporting security package to obtain mutual authentication.

NTLM
NTLM authentication supports three methods of challenge/response authentication:

 LAN Manager (LM)

This is the least secure form of challenge/response authentication. It is available so that
computers running Windows 2000 or later can connect in share level security mode to
file shares on computers running Microsoft Windows for Workgroups, Windows 95, or
Windows 98.
 NTLM version 1
This is more secure than LM challenge/response authentication. It is available so that
clients running Windows 2000 or later can connect to servers in a Windows NT domain
that has at least one domain controller that is running Windows NT 4.0 Service Pack 3 or
earlier.
 NTLM version 2
This is the most secure form of challenge/response authentication. It is used when clients
running Windows 2000 or later connect to servers in a Windows NT domain where all
domain controllers have been upgraded to Windows NT 4.0 Service Pack 4 or later. It is
also used when clients running Windows 2000 or later connect to servers running
Windows NT in a Active Directory domain
The basics of Active Directory

What is Active Directory? Active Directory is Microsoft's trademarked directory service, an

integral part of the Windows architecture. Like other directory services, such as Novell Directory
Services (NDS), Active Directory is a centralized and standardized system that automates
network management of user data, security and distributed resources and enables interoperation
with other directories. Active Directory is designed especially for distributed networking
environments.

Active Directory was new to Windows 2000 Server and further enhanced for Windows Server
2003, making it an even more important part of the operating system. Windows Server 2003
Active Directory provides a single reference, called a directory service, to all the objects in a
network, including users, groups, computers, printers, policies and permissions.

For a user or an administrator, Active Directory provides a single hierarchical view from which
to access and manage all of the network's resources.

Why implement Active Directory?

There are many reasons to implement Active Directory. First and foremost, Microsoft Active
Directory is generally considered to be a significant improvement over Windows NT Server 4.0
domains or even standalone server networks. Active Directory has a centralized administration
mechanism over the entire network. It also provides for redundancy and fault tolerance when two
or more domain controllers are deployed within a domain.

Active Directory automatically manages the communications between domain controllers to

ensure the network remains viable. Users can access all resources on the network for which they
are authorized through a single sign-on. All resources in the network are protected by a robust
security mechanism that verifies the identity of users and the authorizations of resources on each
access.

Even with Active Directory's improved security and control over the network, most of its
features are invisible to end users; therefore, migrating users to an Active Directory network will
require little re-training. Active Directory offers a means of easily promoting and demoting
domain controllers and member servers. Systems can be managed and secured via Group
Policies. It is a flexible hierarchical organizational model that allows for easy management and
detailed specific delegation of administrative responsibilities. Perhaps most importantly,
however, is that Active Directory is capable of managing millions of objects within a single
domain.

Basic divisions of Active Directory

Active Directory networks are organized using four types of divisions or container structures.
These four divisions are forests, domains, organizational units and sites.

 Forests: The collection of every object, its attributes and attribute syntax in the
Active Directory.
  Domain: A collection of computers that share a common set of policies, a name
and a database of their members.
 Organizational units: Containers in which domains can be grouped. They create a
hierarchy for the domain and create the structure of the Active Directory's
company in geographical or organizational terms.
 Sites: Physical groupings independent of the domain and OU structure. Sites
distinguish between locations connected by low- and high-speed connections and
are defined by one or more IP subnets.

Forests are not limited in geography or network topology. A single forest can contain numerous
domains, each sharing a common schema. Domain members of the same forest need not even
have a dedicated LAN or WAN connection between them. A single network can also be the
home of multiple independent forests. In general, a single forest should be used for each
corporate entity. However, additional forests may be desired for testing and research purposes
outside of the production forest.

Domains serve as containers for security policies and administrative assignments. All objects
within a domain are subject to domain-wide Group Policies by default. Likewise, any domain
administrator can manage all objects within a domain. Furthermore, each domain has its own
unique accounts database. Thus, authentication is on a domain basis. Once a user account is
authenticated to a domain, that user account has access to resources within that domain.

Active Directory requires one or more domains in which to operate. As mentioned before, an
Active Directory domain is a collection of computers that share a common set of policies, a
name and a database of their members. A domain must have one or more servers that serve as
domain controllers (DCs) and store the database, maintain the policies and provide the
authentication of domain logons.

With Windows NT, primary domain controller (PDC) and backup domain controller (BDC) were
roles that could be assigned to a server in a network of computers that used a Windows operating
system. Windows used the idea of a domain to manage access to a set of network resources
(applications, printers and so forth) for a group of users. The user need only to log in to the
domain to gain access to the resources, which may be located on a number of different servers in
the network.

One server, known as the primary domain controller, managed the master user database for the
domain. One or more other servers were designated as backup domain controllers. The primary
domain controller periodically sent copies of the database to the backup domain controllers. A
backup domain controller could step in as primary domain controller if the PDC server failed and
could also help balance the workload if the network was busy enough.

With Windows 2000 Server, while domain controllers were retained, the PDC and BDC server
roles were basically replaced by Active Directory. It is no longer necessary to create separate
domains to divide administrative privileges. Within Active Directory, it is possible to delegate
administrative privileges based on organizational units. Domains are no longer restricted by a
40,000-user limit. Active Directory domains can manage millions of objects. As there are no
longer PDCs and BDCs, Active Directory uses multi-master replication and all domain
controllers are peers.

Organizational units are much more flexible and easier overall to manage than domains. OUs
grant you nearly infinite flexibility as you can move them, delete them and create new OUs as
needed. However, domains are much more rigid in their existence. Domains can be deleted and
new ones created, but this process is more disruptive of an environment than is the case with
OUs and should be avoided whenever possible.

By definition, sites are collections of IP subnets that have fast and reliable communication links
between all hosts. Another way of putting this is a site contains LAN connections, but not WAN
connections, with the general understanding that WAN connections are significantly slower and
less reliable than LAN connections. By using sites, you can control and reduce the amount of
traffic that flows over your slower WAN links. This can result in more efficient traffic flow for
productivity tasks. It can also keep WAN link costs down for pay-by-the-bit services.

The Infrastructure Master and Global Catalog

Among the other key components within Active Directory is the Infrastructure Master. The
Infrastructure Master (IM) is a domain-wide FSMO (Flexible Single Master of Operations) role
responsible for an unattended process that "fixes-up" stale references, known as phantoms,
within the Active Directory database.

Phantoms are created on DCs that require a database cross-reference between an object within
their own database and an object from another domain within the forest. This occurs, for
example, when you add a user from one domain to a group within another domain in the same
forest. Phantoms are deemed stale when they no longer contain up-to-date data, which occurs
because of changes that have been made to the foreign object the phantom represents, e.g., when
the target object is renamed, moved, migrated between domains or deleted. The Infrastructure
Master is exclusively responsible for locating and fixing stale phantoms. Any changes introduced
as a result of the "fix-up" process must then be replicated to all remaining DCs within the
domain.

The Infrastructure Master is sometimes confused with the Global Catalog (GC), which maintains
a partial, read-only copy of every domain in a forest and is used for universal group storage and
logon processing, among other things. Since GCs store a partial copy of all objects within the
forest, they are able to create cross-domain references without the need for phantoms.

Active Directory and LDAP

Microsoft includes LDAP (Lightweight Directory Access Protocol) as part of Active Directory.
LDAP is a software protocol for enabling anyone to locate organizations, individuals and other
resources such as files and devices in a network, whether on the public Internet or on a corporate
intranet.

In a network, a directory tells you where in the network something is located. On TCP/IP
networks (including the Internet), the domain name system (DNS) is the directory system used to
relate the domain name to a specific network address (a unique location on the network).
However, you may not know the domain name. LDAP allows you to search for individuals
without knowing where they're located (although additional information will help with the
search).

An LDAP directory is organized in a simple "tree" hierarchy consisting of the following levels:

 The root directory (the starting place or the source of the tree), which branches
out to
 Countries, each of which branches out to
 Organizations, which branch out to
 Organizational units (divisions, departments and so forth), which branch out to
(include an entry for)
 Individuals (which include people, files and shared resources, such as printers)

An LDAP directory can be distributed among many servers. Each server can have a replicated
version of the total directory that is synchronized periodically.

It is important for every administrator to have an understanding of what LDAP is when searching
for information in Active Directory and to be able to create LDAP queries is especially useful
when looking for information stored in your Active Directory database. For this reason, many
admins go to great lengths to master the LDAP search filter.

Group Policy management and Active Directory

It's difficult to discuss Active Directory without mentioning Group Policy. Admins can use
Group Policies in Microsoft Active Directory to define settings for users and computers
throughout a network. These setting are configured and stored in what are called Group Policy
Objects (GPOs), which are then associated with Active Directory objects, including domains and
sites. It is the primary mechanism for applying changes to computers and users throughout a
Windows environment.

Through Group Policy management, administrators can globally configure desktop settings on
user computers, restrict/allow access to certain files and folders within a network and more.

It is important to understand how GPOs are used and applied. Group Policy Objects are applied
in the following order: Local machine policies are applied first, followed by site policies,
followed by domain policies, followed by policies applied to individual organizational units. A
user or computer object can only belong to a single site and a single domain at any one time, so
they will receive only GPOs that are linked to that site or domain.

GPOs are split into two distinct parts: the Group Policy Template (GPT) and the Group Policy
Container (GPC). The Group Policy Template is responsible for storing the specific settings
created within the GPO and is essential to its success. It stores these settings in a large structure
of folders and files. In order for the settings to apply successfully to all user and computer
objects, the GPT must be replicated to all domain controllers within the domain.
The Group Policy Container is the portion of a GPO stored in Active Directory that resides on
each domain controller in the domain. The GPC is responsible for keeping references to Client
Side Extensions (CSEs), the path to the GPT, paths to software installation packages, and other
referential aspects of the GPO. The GPC does not contain a wealth of information related to its
corresponding GPO, but it is essential to the functionality of Group Policy. When software
installation policies are configured, the GPC helps keep the links associated within the GPO. The
GPC also keeps other relational links and paths stored within the object attributes. Knowing the
structure of the GPC and how to access the hidden information stored in the attributes will pay
off when you need to track down an issue related to Group Policy.

For Windows Server 2003, Microsoft released a Group Policy management solution as a means
of unifying management of Group Policy in the form of a snap-in known as the Group Policy
Management Console (GPMC). The GPMC provides a GPO-focused management interface, thus
making the administration, management and location of GPOs much simpler. Through GPMC
you can create new GPOs, modify and edit GPOs, cut/copy/paste GPOs, back up GPOs and
perform Resultant Set of Policy modeling.

  Active Directory replication

Understanding Active Directory replication

Active Directory replication is key to the health and stability of an Active Directory
environment. Without proper and timely replication, a domain will be unable to function
effectively. Replication is the process of sending update information for data that has changed in
the directory to other domain controllers. It is important to have a firm understanding of
replication and how it takes place, both within the domain and in multiple-site environments.

There are three main elements or components that are replicated between domain controllers: the
domain partition replica, the global catalog and the schema.

The domain partition replica is the Active Directory database of a domain. Each domain
controller maintains a duplicate copy of its local domain partition replica. Domain controllers do
not maintain copies of replicas from other domains. When an administrator makes a change to
the domain, that change is replicated to all domain controllers immediately.

Each forest contains only a single global catalog. By default, the first domain controller installed
into a forest is the global catalog server. The global catalog contains a partial replica of every
object within each domain of the forest. The global catalog serves as a master index for the
forest, which allows for easy and efficient searching for users, computers, resources and other
objects. Any domain controller can be configured to act as a peer global catalog server. You
should have at least two global catalog servers per domain and at least one per site. As changes
are made to objects within the forest, the global catalog is updated. Once the global catalog is
changed on one domain controller, it is replicated to all other domain controllers in the forest.

Every domain controller in a forest has a copy of the schema. Just as with changes to the Active
Directory database (i.e., domain partition replica), any changes to the Active Directory schema
are replicated to all other domain controllers in the forest. Fortunately, the schema is usually
static so there is little replication traffic caused by schema changes.

Multi-master replication

Within Windows-based Active Directory domains, each domain controller is a peer server. Each
domain controller has equal power and responsibility to support and maintain the Active
Directory database. It is this database that is essential to the well-being and existence of the
domain itself. This is such an important task that Microsoft elected to make it possible to deploy
multi-redundant systems to support Active Directory by making each domain controller a peer.

Whenever a change occurs to any object within an Active Directory domain, that change is
replicated automatically to all domain controllers within the domain. This process is called multi-
master replication. Multi-master replication does not happen instantly across all servers
simultaneously. Rather, it is a controlled process where each domain controller peer is updated
and validated in a logically controlled procedure.

As an administrator, you have some control over how multi-master replication occurs. Most of
your control is obtained through the use of sites. A site is a logical designation of domain
controllers in a network that are all located within a defined physical area. In most cases, sites
control traffic over high-expense low-bandwidth WAN links. When a domain exists on two or
more sites, normal Active Directory replication between the domain controllers in different sites
is terminated. Instead, a single server within each site, labeled as a bridgehead server, performs
all replication communications. You can configure this bridgehead server for when replication is
allowed to occur and how much traffic it can generate when performing replication.

You can use sites to control replication even if you do not employ WAN links on your network.
Sites effectively give administrators control over how and when AD multi-master replication
occurs within their network.

Active Directory replication topology design

One of the secrets to an efficient and error-free Active Directory infrastructure is a well-designed
replication topology. While this can be easy to design in a simple network, a large, complex
network presents a challenge. Designing the AD topology efficiently is to construct it so that it
takes advantage of the strengths and minimizes the weaknesses of the network. In a complex
network, you are likely to have a number of different link speeds connecting remote sites.

The best practices for Active Directory replication design include:

1. Design the AD topology to take advantage of the network topology and link
speeds.
 2. Define lower speed links with higher cost site links. The cost of the links reduces
as you get to faster areas in the topology.
3. Avoid "dead spots" -- all sites must connect to each other eventually. I have seen
some topologies that left certain sites isolated because they didn't design the site
links to connect them.
4. Site links should only have two sites per link. The exception to this is the Core
site link which can have more. Defining more than two sites per link can result in
unpredictable results when a DC failure occurs.
5. Diagram the overall flow of replication (like the figures here). You can use
sophisticated features available in tools like HP OpenView (see the example in
Figure 3) or Microsoft MOM, or you can simply draw it in a PowerPoint slide as I
did in Figure 2. You'd be surprised at how many errors you will find by making a
drawing of the topology.
6. Don't define scheduling unless you really have a good reason, and then you
should test it thoroughly. Since you can schedule replication over the site link as
well as the connection object itself, and since the resultant replication schedule is
a merge of the two, you can end up with a schedule that prohibits replication. You
also define replication frequency, which further complicates it. For instance, if
you schedule the site links to replicate Monday through Friday from 8 a.m. to 6
p.m., and then have some connection objects that only replicate Tuesday and
Thursday from 6 p.m. to 10 p.m., those connection objects will never replicate.
Unless you have a very slow or limited network (such as VPN links), you should
avoid this level of manual intervention.
7. Run the AD in Windows 2003 Forest mode. This means all DCs are at Windows
Server 2003, and all domains are running in Windows 2003 mode. This takes
advantage of the new spanning tree and compression algorithms available in
Windows Server 2003, as well as other features that make replication much more
efficient than were available in Windows 2000.
8. Monitor the AD. Once you get it in place, monitor it. One of the easiest ways to
monitor it, outside of using Microsoft or third-party tools, is using the Repadmin
tool and its "Replsum" option: Repadmin /replsum /bydest /bysrc /sort:delta. This
will provide a nice, neat table of all DCs in all domains in the forest, telling you
how long it has been for outbound and inbound replication (i.e. where each DC
appears as a source and destination). Watching this over several days will give
you a chance to find any holes in the topology.

Troubleshooting Active Directory replication

Replication should occur automatically. When it doesn't, the best solution isn't just to force
Active Directory replication, but to check out the topology. If the replication topology has
become unstable or misconfigured, it needs to be corrected before initiating a manual replication
procedure.

The Knowledge Consistency Checker (KCC) creates the replication topology used for intra-site
replication automatically. Rather than creating a full mesh for replication, the KCC designs a
topology where every DC has at least two replication partners and is no more than three hops
away from any other DC. With such a topology, every DC can be fully updated with as little as
three replication cycles.

The REPAdmin tool from the Windows Support Tools and Resource Kit can be used to check
the topology. The command "repadmin /showreps" runs on a domain controller and produces a
list of replication partners as designated by the KCC. To check the topology, verify that every
DC lists at least two replication partners and that all named partners see each other as partners.
For example, if Server A lists Server B and C as partners, then both Server B and C should list
Server A in return as a partner. If you discover a problem or inconsistency in the topology, use
the KCC to regenerate the topology.

Once you are sure the topology is correct, then and only then should you force Active Directory
replication.

Debugging replication errors

The lion's share of Active Directory problems are to some degree caused by replication failures,
and one of the most notorious replication errors is the Event ID 1311.

The first step in resolving this replication error is to determine the scope of the error. The easiest
way to do this is with the Repadmin/Replsum command. This will give you a complete summary
of all the DCs in the forest, including the relevant event ID if it is in an error state. The general
form of the command is this:

Repadmin /Replsum /bysrc /bydest /sort:delta

Here is a sample output of this command. Note that there are four domain controllers failing
replication. While the 1311 may not show up in the output of this command, it is common for it
to be paired up with the 1722 event (which basically means no physical connectivity).
Obviously, if there is no physical connectivity (which would mean there was a network failure),
replication isn't going to happen. The first thing to do is to check the general health of the
domain using the Repadmin /replsum command just described. You can also ping broken DCs by
address and FQDN, and you can run NetDiag and DCDiag commands from the command line
(with the /v switch on each). This will give you more details about the errors and perhaps related
ones.

Note: The network connecting all the sites should be fully routed. Don't create a site link if there
is no underlying network link to get between the sites in the site link.

Logical connectivity is a bit more difficult to diagnose. It means, bottom line, that something in
the AD site topology configuration is wrong, creating a hole in the topology. This could be
solved by one of the following actions: configuring a preferred bridgehead server, making sure
all sites are defined in site links and making sure there is a complete mesh of sites in site links.

DNS also must be taken into account. Since Active Directory replication relies on DNS name
resolution to find DCs to replicate with, if DNS is broken, it could cause the 1311 events to
occur. The helpful thing here is that if DNS is the culprit, the 1311 event will have the phrase
"DNS Lookup Failure" included in the description. If you see this phrase, then you absolutely,
positively have a DNS problem that must be fixed.

When debugging 1311 events, you should get a scope of the entire forest to see which DCs are
not replicating. You can do this easily using the Repadmin /Replsum command. Note that the
loss of physical connectivity, an incomplete AD site topology or DNS failure usually cause these
events, with an outside chance it will be an orphaned object (an object that connot be found in
the directory tree). Usually, other events will accompany them, such as the 1722 (RPC Server
Unavailable), or the event will contain a descriptive statement such as "DNS Lookup Failure."
This is a critical event that must be resolved in order for Active Directory replication to function
properly to all DCs.

  Security and Active Directory

Avoiding Active Directory security breaches

The importance of protecting your Active Directory has already been touched on in reference to
DNS security. However, that is just the tip of the iceberg when it comes to maintaining a secure
environment.

As far as Active Directory security best practices go, layered security is the best method to use
when planning and designing a security solution. Layered security or defense in depth is the
simple concept of placing your valued assets at the center of your environment and building or
deploying multiple concentric circles or rings of protection around those assets. Thus, violations
to confidentiality, integrity, or availability must overcome numerous security restrictions,
precautions, and protections before being able to affect your assets.

While Microsoft has increased the default security within Active Directory (especially if you
have a Windows Server 2003 Active Directory installation), you still need to consider additional
security settings after it is installed.

Securing your domain controllers

One of the first steps you should take involves developing a solid domain controller security
policy. Protecting your domain controllers is at the core of protecting your Active Directory
investment. Without your domain controllers you won't have your Active Directory network
infrastructure. With exposed and unprotected domain controllers you also are at risk for attackers
to enumerate shared folders and usernames, giving up valuable information that can be used to
further attack the network.

Therefore, it is critical that domain controllers are running and protected in order for the Active
Directory environment to remain functioning and stable. To protect domain controllers, you
should consider the following areas of security protection: physical access (keeping DCs in a
secure location that is only accessible by the IT staff) and network access (protecting DCs from
those who might attack your network).

As an administrator, you need to be concerned with making sure internal users have proper
access and that potential intruders are frustrated in their attempts to compromise a DC. One
danger is for a person to be physically in the room and touch a DC even without any rights
granted to them. Thus, if a person has physical access, he or she owns your computer, since
physical access grants them control. Keeping DCs in a secure location is a simple way to ensure
Active Direcotry security, but it is often overlooked.

As far as network access is concerned, it is important not to give domain admin privileges to
someone who isn't skilled enough to handle the job or to someone you're not sure you can trust.
Anyone with the ability to install/modify system files, including services/drivers (such as server
operators, backup operators or print operators) owns your computer. There are many ways for
this to happen. Naturally, a secure account could be compromised, giving the intruder the rights
to do this, but a valid holder of these rights could cause harm unintentionally by installing an
application without testing it first.

How well you handle Microsoft patch emergencies and updates is also key to the security of your
DCs. You should always deploy the same patches on all domain controllers. DCs should be kept
as close to mirror images of each other as possible, at least in terms of the OS configuration. This
will help eliminate incompatibilities, lost or corrupted data and replication errors.

However, it is important not to patch just because Microsoft offers a patch. Every patch needs to
be tested in your environment for relevance and reliability. If you don't need it, don't install it.
Patches can damage your environment if the install fails to perform perfectly. You don't want to
place your DCs at risk if you can avoid it.

Kerberos security with Microsoft

With the inception of Windows 2000, Microsoft adopted Kerberos as an authentication protocol.
Not only was it much more secure and efficient than NTLM (which was used prior), but it also
plays nicely with other operating systems such as Unix.

Before learning how Kerberos works in the world of Windows, it's best to first understand
normal Kerberos authentication and authorization.

Authentication is the process of presenting credentials (username/password) to a service and

having that service validate you. It works like this. When a user enters his or her
username/password in a Kerberos environment, that information is sent to a server running the
Authentication Service. The Authentication Service passes that information to a database called
the Key Distribution Center (KDC). If the username/password checks out, the Authentication
Service sends a Ticket Granting Ticket (TGT) to the client, allowing the client to complete the
logon process. The TGT contains a time stamp, the public key and a certificate.

Authorization is the process of granting access to resources on a server that is in the network.
Continuing from the authentication discussion, once the client gets the TGT, the client can then
request access to resources. The TGT is presented to the Ticket Granting Service and requests a
session ticket to access a resource on, say, Server 1. If Server 1 is in the domain, the Ticket
Granting Service sees that there is a valid TGT, so credentials check out, and a session ticket is
granted for Server 1. The client then presents the session ticket to Server 1 for access to a
resource such as a printer, file share or document. Server 1 will then check access rights on that
resource to see what the user can do (read, write, etc.).

In a Windows domain, all of the Kerberos-related services just described are held by each
domain controller. When a user presents credentials for authentication in a Windows domain, the
same Kerberos authentication process described above is used -- with one exception. In order to
find a domain controller that is also the KDC, a client must use the DC Locator process, which
requires a DNS server to locate an appropriate DC and send that information back to the client.
The client then passes the credentials to the domain controller, which grants the TGT and then a
session ticket if the server to be accessed is in the DC's domain. The access rights are checked by
the server and granted to the client.

Group Policy security settings

One of the most important steps toward Active Directory security involves Group Policy security
settings. With almost 1,800 policy settings in a single Group Policy Object (GPO), it is no
wonder they provide so much power, control, security, and management over an Active
Directory enterprise.

There are two default GPOs in every Active Directory domain. These default GPOs are there for
very distinct reasons and should be investigated to ensure they are configured properly to provide
the best security for your company network. The first default GPO is the Default Domain Policy.
This GPO is responsible for establishing and maintaining the account policies for the domain
user accounts, which are essential for helping secure the domain user account passwords.

The second default GPO is the Default Domain Controller Policy. This GPO is responsible for
establishing the baseline security for all domain controllers in the domain. The primary security
settings that are established in the GPO are the user rights. Common user rights include:

 Allowing a user to logon using the keyboard attached to the computer (locally)
 Changing the system time
 Backing up files and folders
 Accessing the computer and its resources over a network

However, every network running Active Directory should have more than just the default two
GPOs. The reason is that Group Policy provides an automated, centralized method for
configuring and deploying security settings to all computers and users within the domain. Some
common security related settings and areas of configuration include the ability to restrict which
applications can be run on each computer, use IP Security to encrypt data between computers,
restrict anonymous connections to computers and audit policy settings per computer.

Remember that there are several network security attacks that can be easily avoided with Group
Policy, including simple steps for Kerberos configuration, so be sure to take advantage.

 Active Directory planning and design

It's important to know how to design a plan to implement Active Directory. You should always
fully document your intended domains, forests, organizational units, sites, DNS infrastructure
and security strategies. This documentation becomes the plan for your new infrastructure when
you make the migration.

The basics of Active Directory planning

When you are performing an Active Directory migration, you basically have two options:
domain upgrading or domain restructuring. Domain upgrading is little more than upgrading each
existing Windows domain controller to a more current Windows domain controller. The upgrade
process starts by upgrading the PDCs in each domain, followed by the BDCs. Domain
restructuring involves creating an Active Directory network from scratch. In a restructure, you
will move systems and reroute connections to comply with a new infrastructure and layout
design. Often restructuring will result in fewer but larger domains.

So the question becomes, "Should you upgrade or restructure?"

Deciding which path to take, or which process to perform first, all depends on your specific
situation. But there are a few guidelines that can help you make the choice.

First, if your current domain structure is supporting your work tasks and doesn't seem to involve
an inordinate amount of extraneous administration, then upgrading may be preferable. However,
if the current domain structure is not adequate and is the primary motivation for the migration,
restructuring is likely the way to go. Secondly, if you must support the production environment
throughout the migration process, upgrading will retain overall network functionality and
therefore is preferable. But if you can afford to lose productivity during the migration,
restructuring is better. However, restructuring can be performed on a staggered schedule so no
significant loss of productivity is noticed.

Rememeber that while upgrading will cause the least downtime in terms of getting the domain
back into working order, it often is an insufficient migration. Many of the benefits of Windows
2000 and Windows 2003-based Active Directory domains cannot be fully realized without
reconfiguring the design of your network. Restructuring will require significant work to
implement, but it makes reaping the benefits of Active Directory easier to exploit for your
organization.

Developing an Active Directory migration strategy

When taking on an Active Directory migration project, like with all large projects, it's best to
have a strategy in place. It is key to create an Active Directory migration checklist, with steps
such as collecting diagrams and configuration of the current DNS and network structure
(bandwidth, remote locations, stability, etc.), determining the rights, objects and policies that will
need to be migrated, and creating fall back procedures in case of failure.

Another part of developing your migration strategy, is being aware of the key things you should
and should not do when performing an Active Directory migration.

For starters , it's important to make sure that your support staff is brought up to speed before you
begin migrating any production system. Depending on the size and structure of your
organization, you should have a help desk staff taking support calls. For a complex project like
Active Directory, it's a good idea to make a couple of network engineers available as well. Be
sure to train all members of the support staff involved in the process. Otherwise, you'll have IT
staff fielding questions that they don't know how to answer, and frustration will abound on all
sides.

You should also establish a test bed that mimics your production environment as closely as
possible in terms of hardware specifications and network speed. Leave nothing to chance in the
testing phase. Speaking of testing, be sure to test name resolution and replication before
deploying Active Directory in production. Unlike replication under NT4, Active Directory
replication is possibly the single most important item required for AD to function correctly.
Second only to file replication for a solid Active Directory implementation is name resolution.
Whether you are deploying WINS or DNS, ensure that all systems that need to can effectively
talk to one another.

Designing Active Directory simply

Active Directory is very flexible. So flexible that you can design an Active Directory forest that
is complex beyond imagination. Both Windows 2000 Server and Windows Server 2003 support
the Active Directory containers of forest, domain, site, and organizational unit (OU). With the
only real restriction of one forest per namespace, you can deploy as many domains, sites, and
OUs as you deem necessary.
However, don't be so fast to rush off and design an Active Directory network that includes a
domain for every department in your enterprise. The key to Active Directory design is simplicity.
As a general rule, you want to keep the number of domains to a minimum whenever possible. If
you really need department level divisions on your network that reflect the organization of your
business, then use OUs instead. OUs are much more flexible and easier overall to manage than
domains.

If you are migrating from a Windows NT 4.0 network to a Windows 2000 Server or Windows
Server 2003 Active Directory network, compare the number of domains from your existing
legacy system and compare that with the number of domains in your new AD-based design. If
your new Active Directory network has more domains than your legacy network, you may need
to re-think your design. Yes, it is possible to use as many domains as you wish, but you'll likely
regret that decision down the line. If you need lots of groupings and divisions, it is best to rely
upon OUs.

Active Directory domain design

When you are designing your Active Directory network, it is important to use the four divisions
(forests, domains, organizational units, and sites) to their maximum potential. This is especially
true for Active Directory domain design.

Domain divisions are most often used as logical containers. However, Microsoft recommends
that you employ domains also as physical containers. In other words, create domains whose
members are all geographically close rather than distant. This is an important design aspect since
the level of traffic within a domain is considerably higher than that between one domain and
another. In general, a domain with limited physical size is less likely to include expensive WAN
links or pay-per-bit connections. When slow links must be included in a network design, it is
often beneficial to create multiple domains connected by the slower connections.

Remember that it is not necessary to create separate domains to divide administrative privileges.
Within Active Directory, it is possible to delegate administrative privileges based on
organizational units.

Designing groups and organizational units

With the proper preparation and advance knowledge of their use, a functional organizational unit
(OU) and group design can do wonders to simplify your Active Directory environment. It can
also go a long way toward helping you gain control and reduce overhead.

Often, OUs are indiscriminately used without reason, and group structure is ineffectual and
confusing. Without some form of logical organization of users within your network environment,
chaos reigns and administration grinds to a halt. Some best practices when designing OUs
include:

 Keep the OU structure as simple as possible

 Do not nest OUs more than 10 layers deep
 Keep the number of OUs to a minimum
  Apply Group Policy to groups through Group Policy filtering
 Don't utilize local groups for permissions in a domain environment
 Use domain local groups to control access to resources, and use global groups to
organize similar groups of users.

You also have the option of hiding your OUs. The primary purpose of hidden OUs is to prevent
an administrator from one OU from being able to view, access, or alter another OU. Hidden OUs
are often used in environments that offer network application services to internal departments or
external customers. It allows for a solid separation of duties without requiring separate domains
or forests.

Design rules for Active Directory sites

Sites are an extremely useful design element for Active Directory domains. Sites are limited to
any computer object within a forest. Thus, they can cross domains and organizational units
(OUs) with indifference. An object's membership in a domain or OU does not exclude
simultaneous membership in a site. Sites are used to impose physical network divisions for the
purpose of traffic flow.

By using sites, you can control and reduce the amount of traffic that flows over your slower
WAN links. This can result in more efficient traffic flow for productivity tasks. It can also serve
to keep WAN link costs down on the pay-by-the-bit services.

In general, when designing sites, keep the following in mind:

 Sites should generally reflect the physical or geographic topology of the network.
 Each site should contain at least one local DC.
 Sites should not contain slow links of any type.
 Remote-access clients do not need a dedicated site.
 Sites should be used whenever control over replication traffic is needed or
desired.
 Sites can be added, removed, changed, and moved easily without affecting any
other AD container configuration.

 Changes to Active Directory

Microsoft has made many changes and improvements to Active Directory since its first
incarnation for Windows 2000 Server. It is important for IT managers and administrators to
understand the differences in Active Directory in regards to which version of Windows they are
using.

Differences in Active Directory for Windows 2000 and Windows 2003

For the new features and improvements that were built into Windows Server 2003's Active
Directory, Microsoft focused on five areas:

1. Integration and productivity

2. Performance and scalability
3. Administration and configuration management
4. Group Policy
5. Security

Some changes in the areas of integration and productivity include the abilities to edit multiple
Active Directory objects simultaneously, as well as improved interoperability via inetOrgPerson
for Novell and Netscape solutions. Replication monitoring was also improved for Windows
Server 2003. In particular, a replication enhancement called linked-value replication for objects
such as Active Directory group objects was significant, especially for large environments.
Linked-value replication solved problems such as inconsistent replication and delays by
replicating multi-valued attributes separately.

Are you on Twitter?

Follow us @WindowsTT.

As far as performance and scalability goes, Microsoft eliminated the need to contact a global
catalog (GC) server each time a user logs in. For Windows Server 2003, the GC information is
cached at the local domain controller. Other enhancements include support for clustered virtual
servers, DC overload prevention and GC replication tuning controls.

For better configuration management, Microsoft added automated DNS zone creation, improved
inter-site replication and the ability to rename domains. Better migration and command-line tools
were also created for Windows Server 2003 Active Directory. Some of the new command-line
tools include:

 dsadd -- Allows you to create objects from the command line

 dsmove -- Moves an object from one OU or container to another within the same domain
 dsrm -- Will delete an object from Active Directory
 dsquery -- Will return an object or list of objects that matches criteria that you specify
 dsget -- Will return one or more attributes of a particular Active Directory object

As for Group Policy, Windows Server 2003 greatly improved the Group Policy management
interface, which is able to interact with both 2003 and 2000 GPOs. Other improvements included
GPO results reports, over 150 new GPO controls and improved client management features. New
security features included forest trusts, trusted namespaces, cross-forest authentication and
authorization, and a credential manager.

Other changes to Active Directory for Windows Server 2003 include the "Install from Media"
option for promoting new domain controllers into a domain, and the Users and Computers MMC
snap-in which allows admins to move an object from one location in the directory tree to another
more easily.

Active Directory improvements with Windows Server 2003 SP1

Several changes in Windows Server 2003 Service Pack 1 have to do with the way Active
Directory handles "tombstoned" objects. Just like in Windows 2000, when you delete an Active
Directory object, it is not immediately deleted; instead, it's marked as a tombstoned object. This
allows the deletion to be replicated properly to other domain controllers. Once an object has been
in this tombstoned state for a certain amount of time, it is finally deleted outright.

In Windows 2000, the default tombstone lifetime was 60 days. However, in Windows Server
2003, Microsoft changed it to 180 days, effectively tripling the amount of time that a deletion
had to be communicated to all of the domain controllers in an environment. However, if you
have already installed Active Directory using either Windows 2000 or the original Windows
Server 2003 media, the default tombstone lifetime will not automatically change when you
upgrade to Windows Server 2003 SP1. You will only receive the 180-day tombstone lifetime
value automatically by building a pristine 2003 SP1 Active Directory forest.

In addition to modifying the tombstone lifetime for new Active Directory installations, 2003
Service Pack 1 added the SID History attribute to the list of attributes that are retained when an
object is tombstoned. When an Active Directory object is tombstoned, it is stripped of most of its
attributes, so the tombstoned object only takes up a fraction of the size of the original object
within the Active Directory database. Each user, group and computer object within Active
Directory is assigned a numeric security identifier, or SID. SIDs are unique within the domain
and do not change, even if the security principal is renamed or moved to another container within
the same domain.

Prior to Windows Server 2003 SP1, one of the attributes that was stripped when an object was
tombstoned was this SID History attribute, which meant that if you restored an object, any
previous SIDs that were recorded in its SID History were lost. Fortunately, Windows Server
2003 SP1 includes SID History among the attributes retained when an object is deleted.

Service Pack 1 also made changes in the types of Active Directory information that are logged in
the Event Viewer on a domain controller, thus allowing for more proactive monitoring and easier
troubleshooting. One such update is Event ID 2089, which is recorded in the Directory Service
event log if any directory partition has not been backed up for a significant length of time (half of
the tombstone lifetime or more). The event is logged whether the partition is the Schema,
Configuration, or domain partitions -- or any application partitions or ADAM partitions that are
hosted on the DC in question.
Ever since SP1, administrators can also now run domain controllers using virtualization
technology such as Microsoft Virtual Server 2005. That allows you to run multiple domains or
forests on a single machine or to use virtualization to reduce the attack footprint of a physical
server by separating its roles onto multiple virtual machines.

Changes to Active Directory for Windows Server 2008

Once again, many changes to Active Directory were made with Windows Server 2008.
Microsoft has incorporated two very significant features with Windows Server 2008 that will
probably relate to most Active Directory deployments: the read-only domain controller (RODC)
and server roles.

The read-only domain controller is perhaps the marquee feature for Active Directory in
Windows Server 2008. The RODC hosts a read-only copy of the Active Directory database. That
is, you can't make any changes to the Active Directory database from a read-only domain
controller. You can connect to an RODC to read any information you like (with a few
exceptions, which we'll get to in a moment), but you will not be able to perform any write
operations without connecting to or being referred to a writeable domain controller.

Also with RODC, the administrator can determine which accounts will be replicated to the
domain controller, and replication is unidirectional. RODC does not perform any outbound
replication. This is a fundamental change from the typical multi-master replication model that
many have become familiar with in Active Directory. In Windows 2000 Server and Windows
Server 2003, an administrator can connect to any domain controller to make a change, and that
change will be replicated out to the rest of Active Directory via outbound replication from the
DC that the change originated from.

This is not so with the RODC. The read-only domain controller will receive inbound replication
from other writeable Windows Server 2008 DCs, but it will not replicate any information
whatsoever out to other DCs. This solves a lot of security issues at remote sites since it will
minimize accounts exposed at the site (presumably not any admin accounts), and anything
compromised at the site will not make it out of the site. Combined with the new BitLocker
technology, RODC will allow deployment of DCs at smaller sites where it was not feasible
before.

Server Core was also developed for Windows Server 2008 as a response to customer requests to
provide a lean server operating system that would permit specific server functions to run without
all the overhead of the GUI. It has been referred to by Microsoft as a bare bones installation of
Windows Server 2008.

With Server Core, after logon, a user will be presented with a desktop with no start menu,
taskbar or icons, and two command windows. Installation of roles such as Dynamic Host
Configuration Protocol (DHCP), DNS, file services and print server will be done completely
from the command line. However, this environment will still allow users to open applications
such as Event Viewer, notepad and others. In addition to making the server better defined for
administrative purposes and reducing the hardware resources required, Server Core also permits
better security at remote sites, allowing a smaller footprint of exposure.
Other changes include the Restartable Active Directory, which allows AD to be restarted without
rebooting the server. You can accomplish this via the command line and MMC Snap-ins. It is
designed to save admins time on offline operations (like an offline defrag of Active Directory)
without taking the server offline and shutting down other services and applications.

Active Directory in Windows Server 2008 R2

Microsoft built on Windows Server 2008 with the release of R2, which featured two notable
Active Directory changes. First, the company unveiled the new Active Directory Administrative
Center (ADAC) for managing directory service objects, somewhat replacing the usual AD Users
and Computers snap-in from past releases. One caveat of the ADAC is that it can only be used
on machines running Windows Server 2008 R2; all previous versions of Windows still require
AD Users and Computers. It can, however, be used to manage Windows 2003 and 2008
domains. It should also be noted that the old Users and Computers snap-in is still available with
R2, so admins can continue to use it while learning the ins and outs of ADAC.

The second most notable update to Windows Server 2008 R2 Active Directory is the addition of
the AD Recycle Bin. The tool is designed to work similar to the familiar Windows Recycle Bin
to make it easier for admins to recover accidentally deleted objects. Though initially met with
enthusiasm from IT pros, some were initially disappointed with the Active Directory Recycle
Bin, citing that while it was a step in the right direction, the utility still lacked functionality found
in more mature, third-party recovery tools.

Other Active Directory changes with Windows 2008 R2 include a Best Practices Analyzer, a
flurry of new PowerShell cmdlets and added offline domain join functionality. Microsoft also
introduced a new managed service accounts feature designed to improve security for application
management. The company has announced plans to improve the feature with the first service
pack for R2 for app servers and services running in perimeter networks. Windows Server 2008
R2 SP1 will also feature enhancements for domain controller scalability.