A holistic view of improvements to identity management in the Microsoft network

Technical White Paper

Published: May 2010

Executive Summary

AD DS Infrastructure at Microsoft

Deployment of Windows Server 2008 R2

Benefits

Best Practices

Conclusion

For More Information

Executive Summary

The management of identities is a core IT task. The upgrade of Active Directory® Domain Services (AD DS) to the Windows Server® 2008 R2 operating system enabled Microsoft Information Technology (Microsoft IT) to take advantage of new technologies in the release to enhance and streamline the way it manages identities. These technologies provide opportunities for Microsoft IT to reduce complexity in its current solution, enhance security, and increase business value by lowering operational costs through coding efficiencies and process improvements.

The implementation of the Active Directory Recycle Bin feature makes it possible to recover, in a matter of minutes, unintentionally deleted Active Directory objects and all of their associated attributes. The implementation of Windows PowerShell™ 2.0 scripting results in a four-to-one reduction in lines of code needed to accomplish repeatable, ongoing tasks. The use of the Fine Grained Password Policy (FGPP) feature enables Microsoft IT to apply unique password restrictions to service accounts to enhance security and reduce, by an estimated 83 percent, service downtime from expired passwords.

Microsoft IT deployed Windows Server 2008 R2 in two distinct phases. In the first phase, Microsoft IT deployed pre-release versions of the operating system software. In its role as an early adopter, Microsoft IT worked closely with the Windows product group to vet out software defects and test the strength and vitality of identity management features in a large enterprise environment. In the second phase of the deployment, Microsoft IT deployed the released version of Windows Server 2008 R2 across the entire Microsoft enterprise network. A well-planned and strategic deployment process maintained business continuity throughout the entire deployment process.

This paper shares Microsoft IT's experience of upgrading to Windows Server 2008 R2. It begins by providing an overview of the AD DS infrastructure at Microsoft. Next, it discusses deployment planning, strategy, and execution. It then describes best practices and the benefits derived from the implementation of new features and functionality in Windows Server 2008 R2.

This paper assumes that readers are technical decision makers and are already familiar with Windows Server 2008 and AD DS technologies. An organization can employ many of the principles and techniques described in this paper to upgrade any Windows-based network configuration to Windows Server 2008 R2. However, this paper is based on Microsoft IT's experience and recommendations as an early adopter and is not intended to serve as a procedural guide. Each enterprise environment has unique circumstances; therefore, each organization should adapt the plans and lessons learned described in this paper to meet its specific needs.

AD DS Infrastructure at Microsoft

The Microsoft AD DS infrastructure maintains information in support of approximately 750,000 computer accounts and 180,000 user accounts in more than 500 buildings located in more than 90 countries across the globe. The average database size is 35-40 gigabytes (GB). About 250 sites house more than 260 domain controllers. The majority of the domain controllers are located in three primary data centers and two secondary data centers. Figure 1 provides an illustration of the global reach of Microsoft data centers.

Figure 1. Data-center topology

In addition to the five data-center locations shown in Figure 1, many secondary and tertiary sites house domain controllers. Each domain controller has a remote management board (RMB) for remote server maintenance through a Web interface.

Active Directory Forests and Domains

The AD DS infrastructure at Microsoft supports both the enterprise production environment and development activities for new software products and operating systems. The Microsoft AD DS infrastructure contains several Active Directory forests and domains, including the following:

• Corporate forest. Corporate is the main forest, with nine domains. On average, this forest contains 160 domain controllers. Microsoft IT created this design when migrating from Microsoft® Windows NT® 4.0 to Microsoft Windows 2000 Server. The domain for Microsoft headquarters in Redmond, Washington, is the largest and most utilized. Its database is approximately 30 GB in size. In the design of the Corporate forest, the Corp domain is an empty root domain, which is a standard design recommendation from early 2000. Users and resources are distributed among the other eight child domains, with each representing geographical locations around the world.

• Windows Deployment forest. The Windows Deployment forest serves as a pre-production forest for the testing of beta operating systems before deployment to production domain controllers in the Corporate forest. This environment contains Microsoft Exchange, Microsoft Office Communications Server, and other key applications for compatibility testing with operating system software before deployment to the Corporate forest.

• Extranet forest. The Extranet forest provides customers and partners with access to Microsoft resources and provides Microsoft employees with internet-facing access to commonly used resources. For security, the Extranet forest is part of the Microsoft perimeter network.

• Test Extranet forest. Primarily, the Test Extranet forest is a pre-production environment that developers use to test applications before moving them to the Extranet forest. The Test Extranet forest is also part of the Microsoft perimeter network.

• Corporate Staging forest. The Corporate Staging forest is used for the initial deployment of pre-release versions of operating system builds. The testing of new builds, updating of deployment scripts, and testing of other changes that affect the AD DS service occur in this forest.

• Exchange forest. The Exchange forest is a resource forest that the Microsoft Exchange product group uses for the early-adopter testing of new Exchange software versions. The Exchange forest has approximately 5,000 disabled accounts that the product group uses to tie to Exchange mailboxes.

• Windows Development forest. The Windows Development forest is a test environment that the AD DS product group uses for the initial deployment of daily operating system builds. This forest is a user-only forest that has limited resources.

Figure 2 provides a graphical representation of the forests in the AD DS infrastructure.

Figure 2. AD DS infrastructure at Microsoft

Placement of Domain Controllers

Microsoft IT evaluates the following factors when determining where to place domain controllers:

• Network performance. A key network performance standard that Microsoft IT considers is how long users take to log on at the beginning of their workday. When initial logon performance standards are not met, Microsoft IT conducts further site analysis to determine the root of the problem, adding domain controllers when needed for better performance.

• Network Latency. Microsoft IT evaluates and considers the time it takes for a network packet to travel from source to destination and back again when determining domain controller placement. A domain controller is typically not need if a site has low latency. However, if a site has high latency, Microsoft IT generally installs a domain controller at the site. Microsoft IT has found that WAN connection speed and the amount traffic going across the WAN often have the most impact on latency.

In some instances, Microsoft IT makes exceptions when deciding where to place domain controllers. Exception factors include the type of work performed at a remote site and the security of the location. For example, Microsoft IT will provide a domain controller if the research or projects conducted at a site require authentications in the event of a WAN connection failure.

Since environments are always changing, Microsoft IT maintains a proactive, rather than reactionary approach to managing and monitoring domain controllers. Microsoft IT reviews placement of domain controllers at least twice a year. Table 1 summarizes common network and business criteria that Microsoft IT evaluates when reviewing placement of domain controllers.

Table 1. Evalution Criteria for Domain Controller eview

Considerations for Deploying Domain Controllers

When deploying domain controllers, Microsoft IT made several key considerations to address security risks and maintain business continuity in the event of data loss, hardware failure, or unanticipated events.

Access to Domain Controllers

To help secure access to domain controllers, Microsoft IT uses two-factor authentication for domain controller logons by requiring smart card access for each domain administrator account in the domains that Microsoft IT manages. When resolving domain controller issues, the operations support teams also use smart cards for local administrator access to domain controllers.

Industry Standards

Microsoft IT uses industry-standard best practices such as those from the National Institute of Standards and Technology (NIST), International Organization for Standardization (ISO), and Internet Engineering Task Force (IETF), including Internet Protocol security (IPsec). For example, IPsec is implemented throughout Microsoft to enable security-enhanced access to computers only from authenticated systems on both the corporate and extranet networks. However, Microsoft IT determined that enabling IPsec on domain controllers would contribute an additional CPU load that would ultimately require additional server capacity to process IPsec negotiations between clients and domain controllers. As a result, Microsoft IT does not have IPsec enabled on domain controllers.

Domain Name System

Microsoft IT installs Domain Name System (DNS) on every domain controller. The number and types of zones hosted on each domain controller depend on the domain and role that the domain controller holds. For example, the DNS records for all of the forests are included in the Corp root forest zone. This root forest zone is hosted and replicated to all domain controllers within the Corporate forest. This way, any domain controller, regardless of location, can find the appropriate record.

Data Backups

Microsoft IT backs up all of the domain controllers that it manages on either a daily basis (data-center locations) or weekly basis (regional locations). To perform the backups, Microsoft IT uses a variety of applications, ranging from Backup Exec to Microsoft System Center Data Protection Manager software.

In addition, to help mitigate a potential rapid AD DS data recovery for instances such as authoritative restores, each domain controller, regardless of operating system, performs a daily system state backup that is stored locally on the server.

Ongoing Release Maintenance

Microsoft IT deploys monthly released security updates and other similar updates to domain controllers by using Microsoft System Center Configuration Manager. Microsoft IT uses a schedule for restarting servers based on maintenance windows that vary in day and time throughout the week. The schedule allows for a systematic restarting of servers.

Connection of Sites

Microsoft IT does not use the Active Directory database as an authoritative database for the consumption of network sites and subnet data. Instead, the Active Directory database is used as a data store for synchronizing data from other authoritative databases. Microsoft IT uses an external database, referred to as Network DB, for storing network subnets and building associations assigned to regional sites. A daily synchronization of data in the Network DB with data in the Active Directory database occurs using the Identity Lifecycle Management (ILM) synchronization engine. This technique helps Microsoft IT efficiently managing the subnets assigned to various buildings around the world.

The Network DB contains network infrastructure information such as subnets (virtual local area networks, or VLANs), locations, and buildings assigned to VLANs. The basic process for adding a new site to the Active Directory site topology is as follows:

1. The VLAN receives a descriptor that identifies its global location.

2. The VLAN to a building (typically a new Microsoft building) and adds the building information to the descriptor.

3. A Microsoft IT internal custom-built tool connected to Network DB assigns the building or location to an Active Directory site. If the building is located in a city for which an Active Directory site has not been created, the IT administrator can use the custom tool to create a new site by using the following naming convention:

   <Geographic domain location>-<State or Country>-<City or Region>.

   At this time, the custom tool also assigns the upstream hub site and the cost and replication frequency.

4. A daily synchronization of site and subnet data occurs between Network DB and the Active Directory database.

Occasionally, Microsoft IT manually adds subnets by using Active Directory Sites and Services for specific production needs.

Deployment of Domain Name System

When deciding on the best method for deploying DNS, Microsoft IT developed a solution that met the business needs and security requirements of the Microsoft enterprise environment.

Microsoft IT's solution may be different from how other organizations typically deploy DNS within their network environments. Microsoft IT hosts its own root zone ("." zone) for managing the internal namespace needed to test and/or evaluate customer environments. This approach enabled Microsoft IT to delegate child domain zones to various services and teams within Microsoft without affecting anything on the internet. This root zone is hosted on the Corporate forest root domain controllers, with secondary zones hosted on stand-alone DNS caching servers. All internal workstations and servers within Microsoft use the caching servers for their DNS name resolution. Proxy servers perform any external Internet resolution.

Implementation of Disaster Recovery

At Microsoft, as is the case with other organizations, disaster recovery involves a series of actions taken to maintain business continuity and minimize the adverse effects of a significant and unplanned network outage or the loss of data. Disasters can result from uncontrollable events such as hacker attacks, computer viruses, electric power failures, mistakes in system administration, and natural disasters.

Microsoft IT's approach to disaster recovery encompasses prevention and recovery planning. To mitigate potential problems occurring from data loss, Microsoft IT uses a methodically designed system of geographically redundant domain controller locations to support the recovery of services, forests, and data.

Service Recovery

The objective of service recovery is to minimize any local service impact due to server failure. To facilitate service recovery, Microsoft IT maintains an accurate Active Directory site topology and sets DNS records for hub-and-spoke sites by using the DNSAvoidRegistryRecords setting. Guidelines for using this setting are outlined in the Microsoft support document "How to Optimize the Location of a Domain Controller or Global Catalog that Resides Outside of a Client's Site" at http://support.microsoft.com/kb/306602. Although written for Windows 2000 Server and Windows Server 2003, this article also applies to Windows Server 2008 and 2008 R2.

This configuration instructs tail-site domain controllers to register the DNS SRV records for only the site in which the domain controller resides. This allows hub domain controllers to register their DNS records in all other empty sites with a domain controller. Service recovery is achieved when a client attempts to contact the local domain controller that is down, and then searches adjacent sites for a domain controller and finds the hub domain controller DNS SRV records for the hub domain controller.

Forest Recovery

The objective of forest recovery is to minimize the time that it takes to complete a forest rollback in the event of a catastrophic failure. Because of the extent of the forest recovery scenario, Microsoft IT documents and practices forest recovery procedures on an annual basis, maintains at least one non-global catalog domain controller for each domain restoration, and ensures that key application owners understand and test forest recovery.

Data Recovery

The objective of data recovery is to have a comprehensive solution in place for recovering critical business data such as users and groups, site topology information, and distribution lists. Microsoft IT keeps a master of critical data outside AD DS in the ILM database for performing the following functions:

• Provide an authoritative list of users and groups to allow Microsoft IT to republish all current data in the event of a forest recovery.

• Ensure that the restored data is consistent across the multi-forest environment that Microsoft IT uses.

• Synchronize data with other tools and applications used within the identity ecosystem.

Security Enhancement and Compliance

A critical aspect of Microsoft IT's overall identity management solution was the establishment and ongoing evaluation of policies and procedures for helping to ensure the security, privacy, and confidentiality of identity information. These policies and procedures provide safeguards to potential system risks and vulnerabilities and address regulatory requirements from legislation such as Sarbanes-Oxley (SOX) and Health Insurance Portability and Accountability Act (HIPAA).

Microsoft IT created two distinct teams for managing the AD DS infrastructure and data. The first team is responsible for the physical implementation and maintenance of AD DS. The second team is responsible for maintaining identity data within Active Directory databases. This separation of responsibilities ensures that no one person has complete access or control over identity data.

Deployment of Windows Server 2008 R2

When Microsoft IT deploys an upgrade of the Windows operating system to its AD DS network (as with Windows Server 20 2008 R2), it starts by installing a series of pre-beta and beta releases in the Microsoft production environment. This practice, referred to as "dogfooding," provides several advantages for Microsoft customers.

First, Microsoft IT works closely with the Windows product group to vet out software bugs before releasing the software to manufacturing for general availability. Because Microsoft is such a large organization, the practice of deploying pre-release builds helps to flush out bugs during the development process. Additionally, Microsoft IT can implement new features and functionality, which provides an opportunity to learn, early on, exactly how a new product works. This knowledge can be invaluable to customers by providing hands-on experience in the production environment experience.

The following sections describe Microsoft IT's experience deploying Windows Server 2008 R2.

Approach and Strategy

As with any major deployment, the key to success lies in careful planning. To accommodate the Microsoft approach of deploying pre-release versions of new operating system software, the deployment of Windows Server R2 occurred in two distinct phases:

• In the first phase, Microsoft IT deployed four instances (each approximately three months long) of pre-release versions of the operating system software on a subset of the Microsoft network.

• In the second phase, Microsoft IT deployed post-release software—that is, the version of the operating system that had been released to manufacturing for general availability. Microsoft IT deployed the post-release software across the entire Microsoft network of domain controllers. This phase took approximately nine months to complete.

Deploying Pre-Release Operating System Software

Development of Windows Server 2008 R2 included numerous builds of the operating system software. Because deploying each build would have required an extensive amount of time and work, Microsoft IT installed four milestone releases during the first phase. These releases included M3, Beta, Release Candidate (RC), and Release to Manufacturing (RTM).

Microsoft IT used a staged approach for rolling out milestone pre-release versions of the operating system software to a representative selection of servers. The basic process was to deploy the operating system build to only a few servers in the pre-production forest. After a few days, if no major defects appeared, Microsoft IT deployed the operating system software on the next group of servers in both pre-production and production domains. If Microsoft IT identified no defects at this level, it deployed the operating system software on even more servers. Microsoft IT modified the deployment timing as needed to accommodate software fixes.

Table 2 provides a summary of the upgrade strategy that Microsoft IT used for installing pre-release versions of the operating system software.

Table 2. Upgrade Strategy

Deploying Post-Release Operating System Software

For the deployment of post-release software, Microsoft IT significantly expanded its schedule and strategy, with this phase occurring over approximately nine months. The Microsoft IT team met once a week to review the plan and update the schedule, modifying them to accommodate unanticipated events. At this point, the overall approach to planning was both a methodical and an organic process. The team based weekly schedules on sites, the need to move Dynamic Host Configuration Protocol (DHCP) scope from one server to another, and coordination with site managers for taking servers offline. In some instances, the deployment included upgrading or replacing outdated hardware.

Using an incremental approach, the initial focus was on expanding the deployment of upgrade software from the main data center to the outlying data centers. After the team updated the data center servers, the tail sites became the focus of the deployment. This technique provided business continuity and minimized any impact to production. Figure 3 provides an illustration of Microsoft IT's global approach for deploying operating system upgrades.

Figure 3. Global approach to operating system upgrades

The process for upgrading a server to Windows Server 2008 R2 included:

1. Moving DHCP scope from one server to another.

2. Demoting domain controllers.

3. Rebuilding the server via the RMB.

4. Running configuration scripts on the server.

5. Copying the Active Directory database to the rebuilt server. To enable a rapid promotion of servers, Microsoft IT used Install From Media (IFM) copies of Active Directory databases to seed promotion of new domain controllers.

6. Promoting domain controllers.

7. Moving back DHCP scope.

Management of Large Changes at Microsoft

Over the years, Microsoft IT has learned that communication is a critical component for managing large changes. At Microsoft, as with most other organizations, the operating system upgrade to Windows Server 2008 R2 was a large change. Prior to the upgrade, Microsoft IT made sure to communicate its deployment plans to IT personnel and business owners who might be affected by the change. In addition, Microsoft IT used the standard Microsoft process for managing changes, as follows:

1. Microsoft IT filed a change request before beginning each major milestone upgrade, including the released version of the operating system software.

2. The Microsoft IT Change Advisory Board (CAB) reviewed each change request for organizational impact.

3. Upon approval of a change request, the CAB sent a global communication to groups affected by the change.

4. Microsoft IT tested each new release in a lab environment.

5. Microsoft IT installed each new release as described earlier in this paper.

Schema Changes

To accommodate new features in the Windows Server 2008 R2 release, changes to the Active Directory database schema were required before the deployment of the operating system software. Because schema changes can affect other groups, Microsoft IT used a process similar to the one described in the previous section to distribute the schema changes throughout Microsoft.

Changes to Domain and Forest Functional Levels

To utilize the benefits of new features in Windows Server 2008 R2, Microsoft IT raised the Active Directory domain and forest functional levels. To accomplish this task, Microsoft IT used the following guidelines:

• Before implementing the changes to domain and forest functional levels, Microsoft IT followed the standard Microsoft process for managing large changes, as described earlier in this paper.

• Before changing the domain functional level, Microsoft IT always took one domain controller offline in case something went wrong. Microsoft IT could then use the offline domain controller to restore other domain controllers to the previous functional level if a rollback was needed.

• Before changing the forest functional level, Microsoft IT took at least one domain controller offline in each domain in the forest. Microsoft IT could then use The offline domain controllers could be used as the source for rebuilding servers in the event a rollback to a previous functional level was needed.

• After a period of 48-72 hours, if no issues are found Microsoft IT returns the offline domain controllers to service.

For detailed information on changes to domain and forest functional levels, see the technical reference "What Are Active Directory Functional Levels?" at http://technet.microsoft.com/en-us/library/cc787290(WS.10).aspx.

Benefits

The Microsoft IT deployment of Windows Server 2008 R2 across the Microsoft network provided two key benefits. First, because the deployment process included pre-release versions of the operating system software, Microsoft IT was able play an important role in the development process by helping the Windows product group vet out major defects.

Second, Microsoft IT was able to use new features in the operating system to streamline the way it manages identities. These features allowed Microsoft IT to reduce complexity in its current solution, increase business value by lowering operational costs through coding efficiencies and process improvements, and enhance the security of service accounts. The most significant feature enhancements included:

• Implementation of the Active Directory Recycle Bin feature made it possible to recover, in a matter of minutes, unintentionally deleted Active Directory objects and all of their associated attributes.

• The use of Windows PowerShell 2.0 scripting resulted in a four4 -to-one reduction in lines of code needed to accomplish repeatable, ongoing tasks.

• The use of the Fine Grained Password Policy feature enabled Microsoft IT to enhance overall security by applying unique password restrictions to service accounts. When fully implemented, this feature will reduce service downtime from expired passwords by an estimated 83 percent.

The following sections describe the implementation and use of these features.

Active Directory Recycle Bin

During normal day-to-day operations within Microsoft, there are times where Active Directory objects, such as user, group, or computer accounts, are deleted accidentally. When this happens, Microsoft IT is responsible for restoring the deleted Active Directory objects.

Before Windows Server 2008 R2, two options existed for restoring Active Directory objects. For servers running Windows Server 2008, deleted objects could be restored from backups. This solution, however, was time-consuming. It required Microsoft IT to take a domain controller offline during the restoration, resulting in server downtime.

The other option, available on servers running Windows Server 2003 or Windows Server 2008, was to recover deleted Active Directory objects through a process called tombstone reanimation. This process was possible because deleted objects, though not visible, were physically available and could be recovered for a period of 180 days after deletion. Unfortunately, this option also had drawbacks in that attributes linked to an object were not recovered. For example, group memberships have attributes of user objects. With tombstone reanimation of a group object, Microsoft IT had to re-create the user attributes associated with the group object. This was a time-consuming and often incomplete process.

With Windows Server 2008 R2, Microsoft IT greatly improved its scenario for restoring Active Directory objects by enabling the Active Directory Recycle Bin feature. Instead of restoring from backup, restarting domain controllers, or using tombstone reanimation, Microsoft IT could now use a simple Windows PowerShell command to restore deleted Active Directory objects and all of their attributes. Not only did the Active Directory Recycle Bin feature streamline the process for restoring deleted objects, it provided peace of mind because Microsoft IT could restore an Active Directory object within minutes, without causing server downtime. Figure 4 illustrates the new Active Directory Recycle Bin process.

Figure 4. Restoration of Active Directory objects

For information about Active Directory Recycle Bin installation, refer to "Active Directory Recycle Bin Step-by-Step Guide" at http://technet.microsoft.com/en-us/library/dd392261(WS.10).aspx.

Windows PowerShell 2.0 Scripting

One of the greatest challenges that organizations face with the implementation and maintenance of identity management solutions is the complexity involved with promoting the security of identity data. The ongoing maintenance can be time-consuming and expensive for IT departments in both large and small organizations. The addition of Windows PowerShell 2.0 AD DS cmdlets enabled Microsoft IT to focus on streamlining identity management activities and processes.

The first step in the implementation of new Windows PowerShell scripting was to identify the most problematic processes that were also the best candidates for conversion to Windows PowerShell scripting. Initially, Microsoft IT identified the following three older processes for conversion to Windows PowerShell scripting:

• Life cycle management of computer objects. Removing stale Active Directory objects is an important part of server maintenance because it frees disk space and reduces uncontrolled growth of data. For example, computer objects are added when a user joins computer to a domain. However, when a user rebuilds a computer but uses a different name for it, the object for the old computer remains. In a large organization such as Microsoft, unused objects can accumulate quickly and consume valuable disk space.

• High-security elevated access renewal notification. Individuals who have high-security elevated access must renew their request every six months. To manage renewals, Microsoft IT used a variety of processes to send reminder e-mail messages as well as removal notifications for the deletion of elevated access accounts that were not renewed.

• Gathering of AD DS data for reporting purposes. By using a multitude of customized scripts, Microsoft IT creates reports of Active Directory objects such as users, groups, and organizational units on a regular basis.

The conversion of these older processes to Windows PowerShell scripting resulted in a four-to-one reduction in lines of code. Microsoft IT consolidated processes that required multiple procedures written in a variety of coding methods—such as Structured Query Language (SQL) scripts, custom-coded batch jobs, and Microsoft Visual Basic® scripts—lointo single Windows PowerShell scripts. Through consolidation of code, Microsoft IT is beginning to streamline ongoing maintenance tasks and reduce complexity in the overall identity management solution. Microsoft IT can easily and quickly transition processes from one developer to another. A single scripting language that is easy to understand replaces multiple complex coding languages.

Fine Grained Password Policy

Microsoft currently has three basic types of Active Directory domain accounts: user, service, and elevated access. Before the use of FGPP, these accounts all followed a single password policy. This posed operational limitations and sometimes resulted in costly downtime as Web sites remained offline during the resetting of expired passwords.

To address this outage problem, Microsoft IT created an FGPP policy for service accounts that extended the expiry period from the standard 70 days to 380 days by applying a more stringent password policy. This change enabled Microsoft IT to tighten its security for service accounts and lengthen the span of time between password renewals.

In short, the new FGPP policy provided a significant operational benefit without compromising security. The new password policy will result in an estimated 83 percent reduction in service downtime due to failure to reset a password before expiry, the incorrect resetting of a password, or simply the time required for resetting services. The more-stringent password requirements that the FGPP policy enforces also provides greater security. By increasing the requirements for password bit strength, Microsoft IT exponentially increased the level of security that the password provides. A distributed computing effort known as RC5-72 determined that cracking one of the new service account passwords as implemented through the new FGPP policy would take approximately 1,000 years.

The implementation of the new password policy began as a collaborative effort between Microsoft IT and Information Security groups within Microsoft. This collaboration was necessary to ensure that the new policy met requirements for enterprise security and corporate compliance with regulatory requirements. To ensure due diligence, Microsoft IT developed a proof of concept of the new policy. The proof of concept included the following activities:

• Creating a security group

• Placing the accounts in the security group

• Applying FGPP to the group that requires the new password

• Changing the passwords on the test accounts

• Validating by allowing the passwords to expire and then be reset

After satisfactory completion of the proof of concept, Microsoft IT moved to a pilot program and began plans for enterprise-wide rollout of the new policy. For detailed information about the FGPP feature, refer to "AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide" at http://technet.microsoft.com/en-us/library/cc770842(WS.10).aspx.

Best Practices

Throughout the course of day-to-day operations, the deployment of Windows Server 2008 R2, and the implementation of key identity management features, Microsoft IT learned several valuable lessons that can be passed on to other organizations as best practices.

Day-to-Day Operations

As part of day-to-day operations, Microsoft IT monitors the overall performance of its domain controllers. This monitoring also plays an important role during deployments of operating systems as a means of making sure that the current capacity can handle operating system changes. If the current capacity is not adequate, Microsoft makes plans to improve capacity for handling the extra load.

Microsoft IT best practices for monitoring performance include:

• Monitor CPU% on domain controllers to view the overall average loading. The goal is to maintain a 40 percent average per site. If the domain controllers exceed this percentage, additional capacity is needed to accommodate the ongoing necessity of taking servers offline for maintenance or upgrades.

• Set the NTDS diagnostics registry key called 15 Field Engineering to 5 to monitor for inefficient queries against the domain controllers that might cause temporary high spikes in CPU and/or sustained high spikes. For more information refer to "How to configure Active Directory diagnostic event logging in Windows Server 2003 and in Windows 2000 Server" at http://support.microsoft.com/kb/314980.

• Build domain controllers for agility with handling queries by putting the Active Directory database on an array that has multiple hard drive spindles (where a spindle is equivalent to one hard drive).

Deployment

Microsoft IT derived the following best practices from its experience in deploying Windows Server 2008 R2:

• Test configuration scripts properly on test computers before deploying to production.

• Before beginning a software upgrade, notify IT personnel, including tail-site IT managers, so they are aware of impending upgrades.

• Use performance monitoring of typical daily usage to plan for any extra capacity that will be needed because of the upgrade to the operating system software.

Implementation of New Features

As Microsoft IT implemented new features available through the upgrade to the AD DS role, adhering to the following best practices ultimately saved time:

• Be sure to test any line-of-business applications that use AD DS data before activating the Active Directory Recycle Bin feature in a production environment.

• Always test any changes to processes in a test environment before moving them into a production system. By doing this, the impact of any bugs and/or process changes will be contained to a testing environment without adverse impact to operations or the production system.

• When making code changes or implementing new code such as Windows PowerShell scripting, implement commenting standards to assist in ongoing maintenance. Guidelines include:

  • Spend the time to comment clearly, so that future readers can understand quickly.

  • Focus on the why rather than the what. For example, the code will show that the author is updating a variable; the comment can explain why.

Conclusion

By deploying Windows Server 2008 R2 throughout its production environment, Microsoft IT was able to take advantage of the identity management improvements in the new operating system. Sharing Microsoft IT's deployment provides customers with a baseline and point of reference for their own organizations.

In addition to the implementation of new features, the deployment process provided Microsoft with a real production environment as a testing ground for Windows Server 2008 R2 throughout a large enterprise system. The relationship between Microsoft IT and the Windows product group helped vet out major software defects before release of the operating system to customers. With the deployment of Windows Server 2008 R2 complete, Microsoft IT will begin to focus on the next release of the Windows operating system.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

© 2010 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Internet Explorer, Visual Basic, Windows, Windows NT, Windows PowerShell, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.