08活动目录的新特性（1）

这事technet的一篇介绍windows2008新特性的文章，全英的，呵呵

其实我觉得08活动目的新特性里面最好的功能就是1server core模式下的操作，2只读dc（read only），这个功能在多站点，多额外域部署的时候，作用比较大，提供了更好的安全性

With Windows 2000, Microsoft introduced the world to Active Directory. The next major release, Windows Server 2003, brought significant improvements to Active Directory, but no

earth-shattering changes. Today, Active Directory ® is a very mature, robust directory service. Even so, the Active Directory team has provided several substantial advancements in the latest version to improve the security and manageability of this core network service.

Back around the turn of the century, Active Directory was the thing that authenticated a user when he logged in, applied group policies to the user and his computer, and helped him find the printer he was looking for. Just a few years later, Microsoft released a standalone variant called Active Directory Application Mode (ADAM).

By 2006, this had all changed. Active Directory was no longer a specific technology. It's now a brand name that identifies a collection of in-the-box Windows ® identity and access control services. Figure 1 provides a quick rundown of what makes up the Active Directory brand.

Figure 1 Active Directory components

Current Active Directory Technology	Previously Called	Description
Active Directory Domain Services (ADDS)	Active Directory	What we used to call Active Directory. It provides Kerberos and NTLM-based authentication for domain users and computers, and manages OUs, users, groups, group policies, and much more.
Active Directory Lightweight Directory Services (ADLDS)	Active Directory Application Mode (ADAM)	A high-performance LDAP server based on the same source code used by ADDS.
Active Directory Certificate Services (ADCS)	Certificate Service	Provides strong authentication using X.509 certificates.
Active Directory Rights Management Services (ADRMS)	Rights Management Server	Protects digital assets, such as documents and e-mail, from unauthorized use by creating rights-protected files and containers.
Active Directory Federation Services (ADFS)	Active Directory Federation Services	Provides Web single-sign-on and identity federation for WS-* compliant Web services.

So, to use the proper terminology, this article is about Domain Services. But to be clear, this is still the same Active Directory you've grown to love since 2000.

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, BitLocker TM drive encryption, and Windows PowerShell TM). 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 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 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 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 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.