Carbon Factors manufactures emission detectors and employs a job-order costing system. During June, the company’s transactions and accounts included the following Raw materials purchased $265,000 Direct materials used in production 262,000 Raw materials inventory, beginning 4,200 Corporate administrative costs 21,400 Selling expenses 18,500 Sales 334,000 Total manufacturing overhead applied 39,200 Total manufacturing overhead incurred 38,100 Finished goods, beginning 17,200 Work in process inventory, beginning 13,700 Work in process inventory, ending 15,600 Direct labor cost incurred 48,000 Finished goods, ending 16,300 How much is cost of goods manufactured for June? Show all your computations. Solution Direct materials used in production $ 262,000 Direct labor cost incurred $ 48,000 Total manufacturing overhead incurred $ 38,100 Add: Work in process inventory, beginning $ 13,700 Less: Work in process inventory, ending $ 15,600 Cost ofgoods manufactured $ 346,200.

1. Case Project 12-2: Devising an AD DS Design with RODC, AD RMS, and AD LDS This project
can be done in groups. Designs should be presented, with discussion of imple- mentation details.
Create a fictitious multilocation company using Windows Server 2008 Active Directory as its
primary directory service. Describe the company’s line of business and explain why it will
benefit from using the following role services and how they will be used: • AD DS • AD LDS •
AD RMS • RODC • DNS Keep in mind that the main goal of this project is to create a company
in which these role services should be used. Create a diagram showing where servers will be
located and which roles will be installed on the servers, and include information about sites.
Write doc- umentation explaining why each role service is needed, and include information such
as which servers will be global catalog servers and which servers will perform FSMO roles.
Present your project to the class, along with a detailed diagram showing sites, servers, role
services, and so forth.
Solution
Server Manager in Windows Server 2008
The first two improvements for Active Directory I am going to discuss really aren't changes in
Active Directory Domain Services (ADDS); rather, they are changes in Windows that will
change the way you manage Active Directory. The first, the new Server Manager, shows up as
soon as you boot your Windows Server® 2008 server for the first time. (The second is the Server
Core installation, which I'll get to in a moment.)
Server Manager will probably look familiar to you from the Configure Your Server Wizard in
Windows Server 2003, which comes up by default after you install Windows Server 2003. That
version, however, isn't very useful for day-to-day administration, and everyone I know checks
the "Don't display this page at logon" box.
Server Manager in Windows Server 2008, on the other hand, is quite useful (see the article by
Byron Hynes in this issue of TechNet Magazine for an overview of Server Manager). First, as
you can see in Figure 2, Server Manager is now a Microsoft® Management Console (MMC)
snap-in rather than a Microsoft HTML Application (HTA). This means it has a full-featured user
interface that is familiar and easy to customize. Out of the box, Server Manager lets you manage
the installation of server roles (major services such as DNS, ADDS, and IIS) and features
(software components, such as the Microsoft .NET Framework, BitLockerTM drive encryption,
and Windows PowerShellTM). Beyond the ability to add and remove software, Server Manager
also provides a single point of contact for running diagnostic tools (such as the Event Viewer and
PerfMon) and system configuration utilities (such as Device Manager and the Windows Firewall

2. snap-in). If you add in the MMC snap-ins for Active Directory—for instance, Users and
Computers, Domains and Trusts, and Sites and Services—you'll have a pretty nice interface to
perform day-to-day management of your Windows Server 2008 domain controller (DC).
Figure 2 Server Manager in Windows Server 2008 (Click the image for a larger view)
Windows Server 2008 Server Core
Windows Server Core is a new Windows installation option that provides a trimmed-down
version of Windows containing only the components necessary to run certain key server roles,
including Active Directory Domain Services. (Figure 3 lists the roles supported by Server Core.)
Although a Server Core installation has a graphical UI, it doesn't run the Windows desktop shell
and almost all of the graphical tools for managing and configuring Windows are absent (see
Figure 4). In their place, you get a command window and a terrible feeling in the pit of your
stomach that you don't know what to do next. How do I change the computer name? How can I
configure a static IP address?
Figure 4 There's not much to see in the Server Core UI (Click the image for a larger view)
The first few minutes in front of a Server Core installation can be unsettling. But after a little
time re-familiarizing yourself with WMIC, NETSH, and NETDOM, you'll be able to do all the
usual setup and configuration tasks with no difficulty. And you still get Regedit and Notepad to
satisfy your graphical tool needs.
The main advantage to Server Core is that much of the code you get with a typical Windows
installation, which you may not need for these core server roles, is removed. This reduces the
potential attack surface for malware (a good thing) and reduces the amount of patching and
rebooting you'll have to perform on your DCs (an even better thing). And you get a much
smaller disk footprint and reduced hardrive requirements—these aren't usually a big deal, but it
can be a help in virtualized server environments.
Will the lack of graphical utilities make managing ADDS difficult? Not at all. You can perform
almost all of your management tasks remotely by running the utilities on your workstation and
connecting to the domain controller over the network. I expect that the vast majority of DCs will
eventually be running on Server Core installations.
DCPROMO Changes
The first change you'll notice in ADDS itself is the new DCPROMO. It works the same as
DCPROMO in Windows Server 2003, but it's been completely rewritten to make it easier to use.
For instance, you don't have to enter your domain administrator credentials—DCPROMO can
use the credentials of your current login to promote the server. Nor do you have to type
DCPROMO /ADV to get the Advanced Mode DCPROMO options—now there's a checkbox on
the first DCPROMO dialog to enable these options. Advanced mode also lets you select the
existing domain controller to replicate from. This means you can keep the replication load of

3. DCPROMO off of your production DCs.
When you promote a DC into a new domain or forest, DCPROMO gives you the option to set
the forest and domain functional level, rather than having you do this later. You can also specify
the Active Directory site you want to place the DC in during the promotion process, which is
very useful in the unattended DCPROMO scenario. DCPROMO will even suggest the best site
for the DC based on the DC's IP address.
The new DCPROMO also collects all of the configuration options onto a single page, providing
one place where you choose whether the new DC will be a global catalog (GC), a DNS server, or
a read-only DC. You don't have to go to an obscure location in the Active Directory Sites and
Services snap-in to mark the DC as a GC.
But perhaps the nicest feature in the new DCPROMO is the ability to save all the DCPROMO
settings in a response file just before the promotion process starts. This is much simpler—and
less error-prone—than cobbling up the response file by hand. You can then use the response file
to perform unattended DCPROMOs on other servers. And for you script fanatics, all of
DCPROMOs options are now accessible from the command line.
Read-Only Domain Controllers
In the early days of Active Directory, enterprises often deployed domain controllers at every site
at which users might log in. This was common in banks, for instance, placing a DC in every
branch office. The logic was that users at the branch office would be able to log in and access
local network resources even if the WAN failed.
At the time, the need for physical security of DCs wasn't well understood. I saw domain
controllers tucked beneath desks where they could easily be accessed by people walking by. It
wasn't until a few years later that Active Directory architects fully comprehended the security
risk that an unsecured DC creates, and IT organizations started consolidating their DCs back into
more centralized datacenters. Branch office users then had to authenticate over the WAN, but it
was a worthwhile trade-off for the added security.
Active Directory in Windows Server 2008 changes the equation with respect to branch office
deployments by introducing read-only domain controllers, or RODCs. These represent the
biggest change in Windows Server 2008 Domain Services.
The Active Directory team focused on the requirements of the branch office scenario when they
designed the RODC and they adopted the goal of "What happens in the branch office, stays in
the branch office." The point is that if you deploy a DC in a physically insecure branch office,
there's ultimately nothing you can do to prevent the DC (and the machines that trust that DC)
from being compromised, but you can prevent that compromise from spreading from the branch
office out to the rest of the domain.
Note that even though they constitute a huge change to the ADDS infrastructure, RODCs are

4. quite straightforward to implement. Your domain must be at Windows Server 2003 forest
functional level, and there must be at least one Windows Server 2008 DC in the domain. And
beyond simply being a branch-office solution, RODCs make sense in Internet-facing
environments and in situations where the DC is placed in the network perimeter.
DC Gone AWOL
There are several classes of threats to consider in a branch office. The first is the "stolen DC"
scenario, where someone walks off with the DC or the disk of the DC. Beyond the local service
disruption, the risk is that the attacker ultimately gains access to all of the user names and
passwords in the domain and from there elevates his privileges to gain access to protected
resources or cause a denial of service. To address this threat, RODCs, by default, don't store the
password hashes in the Directory Information Tree (DIT) of the RODC. So to authenticate a user
to the domain, when a user first authenticates to a particular RODC, the RODC passes the
request to a full domain controller (FDC) in the domain. The FDC processes the request and, if
successful, the RODC issues a replication request for the password hash.
A compromised RODC could potentially request password hashes for sensitive accounts. To
prevent this, the domain administrator can configure a password replication policy for each
RODC. The password replication policy is made up of two attributes on the RODC's computer
object. The msDS-RevealOnDemandGroup attribute contains the distinguished names of groups,
users, or computer accounts whose passwords may be cached on the RODC (these are typically
the users and computers in the same site as the RODC). The msDS-NeverRevealGroup contains
the distinguished names of groups, users, or computer accounts whose passwords may not be
cached on the RODC (for instance, the domain administrator account should never have its
password hashes cached on an RODC). When the RODC requests the password hash for a
particular account, the FDC evaluates the request against the password replication policy to
determine whether the password hash should be replicated to the RODC. When a DC is stolen,
this limits the vulnerability to those passwords that happen to have been cached on the stolen
RODC at the time it was removed from the network, and it eliminates the possibility of a critical
password being compromised.
The RODC computer object contains two other attributes to help you determine exactly which
accounts should have their passwords cached. The msDS-AuthenticatedAtDC attribute lists the
accounts that have been authenticated to the RODC, and the msDS-RevealedList attribute names
the accounts whose passwords are currently stored by the RODC.
User and computer password hashes are not the only secrets stored on a DC. The KrbTGT
account contains the keys for the Kerberos Key Distribution Center (KDC) service running on
each domain controller. In a typical scenario, each KDC in the domain shares the same KrbTGT
account, and it is possible that an attacker could retrieve these keys from a stolen DC and use

5. them to attack the rest of the domain. However, each RODC has its own KrbTGT account and
keys, eliminating that possibility.
It is also not unusual for applications to store passwords or other secrets in the DIT. If an attacker
were to steal a DC, she could possibly steal these application passwords and use them to gain
access to the applications. To mitigate this risk, Windows Server 2008 Domain Services allows
administrators to define the Read-Only DC Filtered Attribute Set (RO-FAS). Attributes that are
part of the RO-FAS are never replicated to RODCs, and thus they can't be retrieved from a
compromised DC. You assign attributes to the RO-FAS by setting bit 9 (0x0200) of the
searchFlags attribute of the corresponding attributeSchema object in the schema.
Barbarians inside the Gate
Another class of threat for branch office domain controllers is the case of a local server
administrator elevating his privilege by leveraging the DC's privileges to gain access to other
domain resources or to engineer a denial of service attack. Again, if the local administrator has
physical access to the domain controller, there's little that can be done to prevent compromise.
But it is possible to prevent the attacker from using the branch office domain controller to
compromise other DCs in the domain.
RODCs are not trusted as domain controllers by the full DCs in the domain. From a trust
standpoint, FDCs treat RODCs as member servers in the domain. An RODC is not a member of
the Enterprise Domain Controllers or Domain Controllers groups. The RODC account has very
limited ability to update anything in the directory, and therefore even if an attacker does
compromise the RODC account, she'll gain almost no useful privileges.
RODCs don't even show in the normal DS replication topology. Because RODCs look like
normal member servers rather than domain controllers, the Knowledge Consistency Checker (the
KCC, which is the process on each DC responsible for calculating the DS replication topology)
won't build connection objects from RODCs. No full DC or RODC will try to replicate from an
RODC. On the other hand, the RODC will create a connection object representing an inbound
replication agreement from a full DC, but this connection object only exists in the RODC's
replica; no other DC has a copy of that connection object. From a replication standpoint, RODCs
are like Roach Motels for directory objects. Objects replicate in, but they don't replicate out.
Administrative Role Separation on RODCs
It's very common for a branch office DC to be managed by a local server administrator who
does everything from running backups on the domain controller to cleaning keyboards. But it is a
security risk to grant a remote site administrator the rights necessary to do general maintenance
on a domain controller, and the site admin can potentially elevate her privileges in the domain.
RODCs provide two kinds of administrative role separation to mitigate this threat.
With the first form of role separation, the domain administrator can promote the RODC in the

6. normal way using DCPROMO, or she can use a two-step process where the actual promotion
process is securely delegated to the branch site administrator, without granting any domain
administration rights. The domain administrator pre-creates the RODC computer account in the
domain using the Active Directory Users and Computers MMC snap-in, as shown in Figure 5.
Figure 5 Pre-creating the RODC computer account (Click the image for a larger view)
Selecting "Pre-create Read-only Domain Controller account" runs an abbreviated version of
DCPROMO that performs all the tasks that require administrative access to the domain,
including creating the computer account, assigning the RODC to a site, specifying the DC's
roles, specifying the password replication policy, and defining the user or group that will need
the rights to complete the DCPROMO operation on the RODC. The delegated administrator or
group is stored in the managedBy attribute of the RODC computer object.
The delegated administrator can then run DCPROMO on the server itself. DCPROMO will
detect the pre-created account and turn the server into an RODC. Running DCPROMO in this
way does not require domain administrator credentials.
The second way RODCs provide administrative role separation is by creating local
administrative roles on the RODC itself. These roles look like machine local groups—they are
stored in the registry of the RODC, and they can only be evaluated on the RODC. But instead of
using the Computer Management MMC snap-in to manage them, the administrator manages
local RODC roles using NTDSUTIL. Figure 6 lists the local administrative roles on an RODC.
These roles correspond one-for-one with the built-in groups in Windows.
Figure 6 Local RODC administrative roles
RODC Oddities
Because RODCs are read-only and no other domain controller will replicate from them, RODCs
exhibit some unexpected behaviors. For instance, lingering objects—meaning objects that have
been deleted everywhere else but on a particular DC because the DC was unable to replicate for
longer than the tombstone lifetime of the forest—are normally detected by the outbound
replication partners of the DC. But since RODCs have no inbound replication partners, there is
no lingering object detection for them.
RODCs will not service LDAP update (add, modify, delete, rename, or move) operations.
Instead, RODCs return an error with an LDAP referral to a writable DC that can service the
operation. If the application that issued the LDAP update doesn't properly handle the referral
operation, the application could fail.
Finally, if a user from another domain in the forest attempts to authenticate to an RODC, the
RODC must be able to access a full DC in its own domain in order to obtain the trust password
to properly pass the authentication request to the DC in the user's domain. If the network
connection between the RODC and the full DC in its domain is unavailable, the authentication

7. will fail.
Fine-Grained Password Policies
The ability to define more than one password policy in the domain was probably the most-
requested feature for Windows Server 2008 ADDS. As you probably know, in Windows 2000
and Windows Server 2003 Active Directory, each domain supports only a single password policy
that is applied to all security principals in the domain. If you need a separate password policy for
a specific group of users, you have to create a separate domain. But now a new feature in
Windows Server 2008 ADDS, called Fine-grained Password Policies, lets you define multiple
password policies in a domain.
The new strategy uses groups to apply fine-grained password policies to users. You first define
the fine-grained password policy by creating a new msDS-PasswordSettings object in the
CN=Password Settings Container, CN=System, DC= container. The msDS-PasswordSettings
object (PSO for short) contains attributes that parallel the password policy setting in Group
Policy (see Figure 7).
Figure 7 Attributes in the mSDS-PasswordSettings object
You then assign the password policy to users or groups by adding the user or group names to the
multi-valued mDS-PSOAppliesTo attribute of the PSO. Once you accept the idea that you don't
apply password policies to OUs, it's pretty straightforward. But there is some additional
complexity.
Users are usually members of many groups. So what happens if there are multiple conflicting
password policies associated with a user because of these group memberships? In this case,
ADDS uses a precedence evaluation to determine which password policy should be applied. It
works like this:
User objects have a new attribute called msDS-ResultantPSO to help sort out exactly which PSO
applies to a user. This attribute contains the distinguished name of the PSO that governs the
password of that user.
Fine-grained password policies give you more flexibility than you could ever need, but you must
manage these policies carefully and keep them simple. There is no in-the-box utility for defining
fine-grained password policies; you will either need to use ADSIEdit or find a third-party utility.
Restartable Active Directory Service
Every time you take a domain controller down for DIT maintenance you cause some disruption
in your network service levels. Windows Server 2008 DCs have a new feature that lets you stop
the directory service without completely shutting down the DC.
The NET STOP NTDS command stops ADDS on a Windows Server 2008 DC. When you do
this, the Local Security Authority (LSASS) process on the DC continues to run, but it unloads all
the ADDS-related DLLs and the directory service becomes unavailable. LSASS then behaves

8. essentially as it would on a member server by forwarding domain authentication requests to a
DC. Because the DLLs that handle ADDS are unloaded, you can apply ADDS-related patches or
perform an offline defrag of the DIT. Starting ADDS is as simple as NET START NTDS.
Restoring the DIT from a system state backup still requires you to boot into directory service
repair mode, however.
It's important that you understand that the directory service is not a real Windows service. It is
still an integral component of LSASS and you can't stop LSASS without shutting down the
machine. But the ability to start and stop the directory service in Windows Server 2008 is a
convenient option.
Backup and Recovery
The entire backup and restore mechanism has been revamped in Windows Server 2008. I won't
go into all the details here, but the new Windows Server Backup has some changes that affect
ADDS.
Windows Server Backup is a volume-based backup solution, meaning it backs up entire disk
volumes at a time. It also only backs up to disk (or disk-like) devices—there is no tape support.
There is a system state backup option for the WBADMIN command line backup utility. Using
the WBADMIN START SYSTEMSTATEBACKUP command, you can now create a backup
image that contains all the critical system files necessary to restore Active Directory on a domain
controller. There is, however, a potential for as many as five volumes in the backup set, but the
volumes in the backup set will contain only the files needed for a system state restore. Even more
annoying is that, as of the RC0 build of Windows Server 2008, you cannot perform a system
state backup to a network share. You must have a local disk volume available to store system
state backup images, and that volume must not be part of the system state backup volume set.
You may have to add a new disk volume to every domain controller on which you perform
system state backups.
Performing a system state restore is simple. Just boot the DC into Directory Services Restore
Mode and run the WBADMIN START SYSTEMSTATERECOVERY command. The result is a
non-authoritatively restored DIT, on which you can authoritatively restore specific objects using
NTDSUTIL, just as you did in Windows Server 2003.
One aspect of Windows Server Backup deserves special mention: it stores backup images in
Virtual Hard Disk (VHD) format. This is the same format that Microsoft Virtual Server 2005
uses to store its virtual disk images. This means you can take a backup image created with
Windows Server Backup and mount it as a disk drive in a virtual machine running under
Microsoft Virtual Server. You can then browse the backup contents as if it were a normal disk
drive!
Another change regarding ADDS backup is the ability to use the Volume Shadow Copy Service

9. to create point-in-time snapshots of Active Directory. When you create a snapshot using
NTDSUTIL, the Volume Shadow Copy Service saves the before-image of each disk block of the
DIT before it is overwritten by an update operation. By combining the saved before-images with
the current version of the DIT, the Volume Shadow Copy Service can construct a complete
snapshot of the DIT with very little overhead. A typical snapshot takes only a few seconds to
create, regardless of the size of the DIT.
By itself, this is an interesting capability, but not all that useful. However, in Windows Server
2008, ADDS includes a command-line utility called DSAMAIN that mounts the snapshot image
in read-only mode. This provides a standalone LDAP server, much like an ADLDS instance that
contains the contents of your directory at the time of the snapshot. You can browse the directory
using the LDP utility or other LDAP tools and retrieve versions of directory objects from an
earlier point in time.
SYSVOL Replication with DFS-R
Windows Server 2003 R2 featured a revamped Distributed File Service (DFS) that incorporated
a brand-new file replication mechanism called DFS-R. It uses remote differential compression,
which substantially reduces file replication traffic by determining which blocks of a target file
need to be replicated to bring it into sync with the source file. However, Windows Server 2003
R2 still uses File Replication Service (not DFS-R) to replicate SYSVOL between domain
controllers. Because of this, SYSVOL replication continued to be a source of problems for
Active Directory administrators.
When running at the Windows Server 2008 domain functional level, Windows Server 2008 can
replicate SYSVOL using DFS-R, improving the speed and robustness of SYSVOL replication.
And this makes it reasonable to place large files in SYSVOL to make them available on all DCs.
To use DFS-R for SYSVOL, you must first migrate the old SYSVOL data to DFS-R using the
DFSRMIG utility. This process has four steps:
Depending on the size of your SYSVOL and the number of domain controllers you have, this
process may take a while, but the improved performance and reliability make the effort well
worth your while.
Auditing Improvements
The auditing system in Active Directory for Windows Server 2003 is both a blessing and a curse.
On the one hand, it provides a pretty comprehensive, flexible, and secure solution for tracking
changes in the directory. But some may argue that it suffers from several significant usability
problems.
Enabling auditing of directory changes on a Windows Server 2003 domain controller is pretty
much an all-or-nothing affair—it's either on or it's off. And the volume of audit traffic on a
busy enterprise DC can render auditing impractical. Configuring the auditing system to produce

10. the messages that you really need by fiddling with individual security descriptors is tedious and
prone to error. The audit messages themselves are often cryptic, and in many cases don't contain
the information you need, such as the before and after values of changed attributes. And
collecting, correlating, and archiving the messages from multiple domain controllers is not really
feasible using the native Windows tools.
The directory services auditing system in Windows Server 2008 addresses some of these
problems. First, there are four new audit subcategories for directory service auditing: DS Access,
DS Changes, DS Replication, and Detailed DS Replication. So if you want to just audit directory
changes, you don't have to wade through all of the read and replication events. But, if you want
to include object deletions in your audit log, you must enable DS Access. This generates
messages for all DS object accesses, essentially putting you back to generating too many
messages. And it is still up to you to configure the security descriptors to generate the audit
messages that you want for the objects you care about.
The audit messages have been substantially cleaned up so that they are both readable and contain
the data you need. In particular, directory changes generate audit log entries that contain the old
and new values of changed attributes. This is a huge improvement. The only downside here is
that the old and new values appear in separate audit log entries, so you have to correlate them to
really understand the change that was made. Many add-on audit-log collection products,
including the Microsoft Audit Collection Services, support this kind of correlation.
UI Improvements
The Active Directory Users and Computers, Sites and Services, and Domains and Trusts MMC
snap-ins have always been adequate for managing Active Directory. In Windows Server 2008,
the basic admin tools have been cleaned up and introduce a couple of nice new features. If you
enable Advanced Features, the Properties dialog for each object displays an additional tab titled
Attribute Editor. This is the same attribute editor tab used by ADSIEdit, which lets you inspect
and edit all of the attributes of the object. The tab itself now offers better decoding of encoded
attributes, such as the userAccountControl attribute. Figure 8 shows how seamlessly the attribute
editor is integrated.
Figure 8 Attribute Editor in Active Directory Users and Computers (Click the image for a larger
view)
Wrapping Up
Aside from the key points I've discussed in this article, there are many other improvements
you'll find in ADDS in Windows Server 2008. For instance, the KDC uses the 256-bit Advanced
Encryption Standard (AES-256) if the domain is in Windows Server 2008 domain functional
level. You can enable Accidental Deletion Prevention of objects by checking the appropriate box
on the Object tab for any DS object. The Extensible Storage Engine that provides the data

11. management service has been enhanced to use single-bit error correction, reducing the likelihood
of a hardware or software error in the disk subsystem from corrupting the DIT. The DNS service
starts processing requests before it has completely loaded the DNS database. The DC Locator
module has been enhanced so that if it fails to find a DC in the desired site, it will try to locate a
DC in the next nearest site instead of simply using any DC it can find in the domain. And
NTDSUTIL now supports RODCs and Volume Shadow Copy Service snapshots.
Clearly, Windows Server 2008 provides a substantial number of improvements in Active
Directory Domain Services. Taken together, these changes will significantly improve the
security and manageability of ADDS. The best thing, however, is that integrating Windows
Server 2008 into your Active Directory environment doesn't involve a massive migration—it's
an easy and incremental process.