I just returned from Microsoft’s annual Most Valuable Professional (MVP) Summit, where recipients of Microsoft's award for technical expertise and community service in various disciplines get together with Microsoft product groups, various speakers, and one aother for a week of tech talk and futures. In the Directory Services breakout—my category—I never really expect to learn anything radical from year to year. The excitement of the topic usually depends on whether a new OS is being released and how big that release is. But this year, I put check marks in both the "new release" and "big release" columns, so there was some serious learning to be done. In this month's column, I'm going to review the major identity and security changes that Microsoft has incorporated into Windows Server 2012.
Mind you, these changes qualify as evolutionary rather than revolutionary; they build on and extend the solid Active Directory (AD) foundation that we already have. Microsoft Program Manager Nathan Muggli once said, "Designing changes to Active Directory is like ordering pizza for a million people; everyone wants something different.” You don't want to rock the boat that holds 75 percent of every midsized and enterprise business in the world. But evolutionary steps are important, too, and they can indicate a product's future direction. In
Before I dig any deeper into Server 2012's (formerly known as Windows Server 8) identity changes, I need to point out a change that Microsoft made in Windows Server 2008 R2: File Classification Infrastructure (FCI). This new capability slipped beneath my radar, and perhaps yours, because it's a file system feature rather than an identity feature. You'll see how FCI gets involved with identity shortly, but first let me explain what FCI is.
FCI provides the ability to define file-classification properties for your file servers, to automatically classify files according to the folder in which the file is located or according to the content of that file, to apply file-management tasks such as file expiration and custom commands based on a file's classification, and to produce reports that show the distribution of a classification property on the file server. With FCI, an end user (such as the content owner) can manually classify a file, or line-of-business (LOB) applications can programmatically set classification properties to files. You can even use FCI to search file content for sensitive words or patterns such as Social Security numbers, and automatically classify the file as sensitive or containing personally identifiable information (PII).
What's so useful about this? With FCI, administrators can—for example—automatically move data from expensive online storage to less expensive, slower storage based on a file's classification and on policies you define. Or you can set files to expire after a certain amount of time. You can play with FCI through the File Server Resource Manager (FSRM) utility by installing this file server role feature, then launching it from Administrative Tools. This is the same utility that lets you control quota, screening, and storage reports. What's relevant to this discussion, though, is that FCI provides one of the building blocks for a really big Server 8 identity and security feature: Dynamic Access Control (DAC).
DAC is one of the many powerful new features of Server 8, and I've written about it in “Exploring Windows Server 8: Dynamic Access Control” (InstantDoc ID 140572). At its highest level, it's about information governance: classifying what data is on your file servers, being able to exert a high degree of control over that data, and being able to demonstrate (e.g., audit) that you have that control. This is a critical need in the IT infrastructure now, driven by the combination of explosive data growth, the increase in external threats, and the cost of a security breach. FCI is a building block for DAC because FCI provides the file classification and tagging engine that DAC depends on to apply its policies.
Another beneficiary of the DAC project is AD. Tagging and classifying file server data is all well and good, but its usefulness is limited if you can't control access to this data based on the new, finer level of detail you have. To control access at this level, you must make significant changes to the Local Security Authority (LSA) on the file server and in AD. I'll leave the file server changes for another time, but the changes in AD are fundamentally important, and they point the way toward AD's future.
To support this greater degree of access control on file servers—and on all resources that support access control lists (ACLs) in future OS releases—AD must support claims. If you aren't familiar with claims, they're simply another facet of asserting identity; a claim is information (e.g., email address) that a trusted source (e.g., your local certificate authority—CA) makes about an entity (e.g., your user account). Claims are already the lingua franca of cloud identity, and they’re a basic component of federation technology that allows us to securely extend local identity to cloud services. But until Server 8, AD had no knowledge of claims; we had to rely solely on Active Directory Federation Services (AD FS) to transform AD attributes to claims. These claims were consumed mostly by external services because traditional enterprise applications didn't understand them. That’s changing, and AD is changing to accommodate them. This change to AD is very important, and every AD administrator needs to start wrapping his or her head around claims-based identity because it's going to be a part of the future.
For Server 8 improvements that focus strictly on AD, the biggest investment the AD team made was to spend a lot of time and effort on making AD easier to deploy. Anyone who has spent any time on AD-related forums knows that deployment questions about Adprep, Dcpromo, duplicating and virtualizing DCs, and DNS-related deployment decisions are the most common. These changes definitely fall into the "evolutionary" category, as they're refinements of existing AD functions.
The upgrade and promotion of DCs has been dramatically simplified. The AD team was happy to tell the assembled MVPs in the Red West campus auditorium that "Adprep and Dcpromo are dead!" Dcpromo is now the Active Directory Domain Services Configuration Wizard, which is fully integrated with Server Manager. (See my article "Upgrading Active Directory to Windows Server 8," InstantDoc ID 141178, for a screenshot gallery of the promotion process.) It's very easy to use, but more important, the configuration wizard does a ton of work under the covers to make promotion as painless as possible.
The first thing it does is take care of the Adprep /forestprep and /domainprep process automatically (although you can trigger it manually if you want to). Dean Wells, a former top AD consultant who is now on the Microsoft AD team, flatly stated that it was a mistake to expose the Adprep process to administrators; the amount of fear and support calls it generated far outweighed the actual problems caused by the process. The promotion process also performs a thorough validation of environment-wide prerequisites before it begins the deployment, so if you have major problems in your AD environment, the promotion won't even continue. It's also become much more tolerant of transient network failures, has some enhanced IFM options, and is also now fully remoteable.
Another aspect of simplifying AD deployment is making virtual domain controllers (DCs) a bulletproof option, and when that happens, DC cloning becomes safe, too. Restoring a virtual DC from an image backup or an earlier snapshot risked causing damage (USN rollback) to the referential integrity of the entire distributed AD database in a domain or forest because, unlike a standard restore process, the restored DC had no idea it had been restored. Server 8 Active Directory Domain Services (AD DS) introduces the VM-Gen ID, a unique 64-bit identifier (much like a GUID) associated with the hypervisor. The purpose of the VM-Gen ID is to detect VM snapshot instances and pass them to the virtual machine (VM). With this notification, the DC will deploy safeguards (such as discarding the record identifier—RID—pool and resetting the invocation ID) to prevent USN rollback from occurring.
DC cloning, which these "virtualization-safe" improvements have made a safe and supported option, really has a lot of potential. It can make the actual promotion process a rare occurrence, because why go to the trouble of running a new promotion when you can simply clone a new DC from an existing one? And it's very fast.
DC cloning also has an enormous benefit in an area that's not yet appreciated: forest recovery in the event of a disaster. In today's supported configuration, to recover a forest you restore a seed forest of DCs (one per domain), then run Dcpromo on other DCs until you have enough DCs in the environment to support your users. The problem is that Dcpromo is time-consuming, even if you install from media (IFM) instead or doing a network promotion. A "forest down" situation is an administrator's nightmare (if not a resume generating event!), and every second you spend in the recovery means thousands or even millions of dollars. DC cloning will enable you to simply make clones of the seed forest DCs—a much faster operation than IFM or network promotion. You might be able to justify a Server 8 AD upgrade on these potential cost savings alone.
The Directory Services team has posted a good entry (blogs.technet.com/b/askds) that lists new Understand and Troubleshoot guides and test lab guides for various Server 8 AD technologies. These updates mean that not only will expanding that AD environment be easier for cloud data centers; it will also be easier for small-to-midsized businesses (SMBs) that don't have an AD specialist. As I mentioned, these changes to AD in Server 8 might not be revolutionary, but that's OK. We don't need revolutionary changes in this area anymore. What we need are substantial improvements, and the AD team has delivered them.