Active Directory (AD) is a foundational part of the Windows Server system, and any changes to it must address three broad sets of requirements. The first requirement set is for the entire Windows Server ecosystem that depends upon it for authentication and access control. Whether it’s Exchange Server, System Center, Hyper-V, SQL Server, or many other products inside and outside Microsoft, thousands of enterprise software solutions depend on AD.
The second set of requirements is for AD service owners—the systems administrators who actually manage the AD distributed application across its span of domain controllers (DCs). Though AD has made great strides in manageability since its early days, it still remains a complicated beast (perhaps a hydra with its many heads). How can this critical but confusing piece of infrastructure be made easier to work with in an IT environment that’s far more complicated than when the directory service was first designed?
The third, of course, is for the literally millions of users around the world who work with AD directly or indirectly for access control to various resources in their domain. How will the aging users/groups model of access control evolve to meet the complex security and compliance requirements we live with today, and grow for tomorrow’s certainly expanding needs? As Microsoft’s Nathan Muggli said, “Designing changes to Active Directory is like ordering pizza for a million people; everyone wants something different.”
For Windows Server 2012, the AD team didn’t alter the product dramatically. There’s no SQL Server-based directory service database, nor can a DC host more than one domain partition (why would you need to anymore, when you can create another virtual DC?). Instead, the team focused on three major goals that address all of its stakeholders to varying degrees. First, AD needs to have virtualization that just works. Second, AD must be simple to deploy. Finally, AD must also be simple to manage.
AD Virtualization Now Just Works
Ensuring that virtualizing AD just works should be a great relief to many systems administrators, because even though the rules for a safely virtualized AD aren’t that difficult, the responsibility for it is spread across several teams. This means that keeping AD safe in a virtual world isn’t just a technical problem; it’s a people or organizational problem. And the consequences for screwing it up can be severe, as illustrated in the Microsoft article “USN and USN Rollback.”
What causes problems for AD before Windows Server 2012 in a virtualized environment is that the AD distributed application isn’t aware of any virtualization-specific actions taken underneath it at the host level. Specifically, you can confuse AD and potentially induce an unhealthy condition known as USN rollback if you restore a DC VM from a snapshot or image backup. Why? Because a distributed application such as AD has more off-server dependencies than a single-instance application. When a DC has been restored from an image backup, it magically appears as though it’s from an earlier time—but in an incomplete manner because neither its partners nor the restored DC itself recognizes it.
In contrast, Windows Server 2012’s “virtualization safe” AD technology ensures that a virtual domain controller (VDC) is able to detect when snapshots are applied or a VDC has been copied. Detection of these changes is built on what’s known as a VM generation ID (gen ID) to detect changes and protect AD, or take corrective measures. This requires changes to Hyper-V, and Microsoft is working with other virtualization vendors to make sure they include this technology in the latest version of their hypervisors as well. It’s in their interest to do so, because until then Microsoft has a competitive advantage in its own Hyper-V.
AD Domain Controller Cloning
The team’s second goal of making AD simple to deploy was made possible by the gen ID technology. Because of it, it’s easy to safely clone virtual Windows Server 2012 DCs. From the administrator’s viewpoint, the process is pretty simple: You copy/paste/rename the source virtual DC’s .VHD disk file to create a second copy on disk. Relocate it to the destination folder you desire. Use Hyper-V Manager or Virtual Machine Manager to create a new VM, and associate the copied VHD with the new VM. Then, just start it up. There’s more that happens under the covers, of course; I’ll be describing more about this VDC cloning process in a future article.
Domain and Forest Upgrades Made Simple; DCPROMO Improvements
In addition to being able to clone VDCs, the upgrade and promotion process has been completely reworked and made far simpler. In Windows Server 2012 AD, you can upgrade your domains and forest from a previous version to the Windows Server 8 version entirely from Server Manager. Unlike with previous versions, you don’t have to log on to different DCs with different sets of credentials, find the right version of ADPREP, run /FORESTPREP in the forest, run /DOMAINPREP in each domain, and choose when to update SYSVOL—it’s all taken care of for you. (If you do want to run an a la carte upgrade step by step, that’s still available.) The DCPROMO process has also been simplified and includes significant built-in troubleshooting, because this area was one of the highest call generators to Microsoft’s Customer Service and Support (CSS) division.
Active Directory Administrative Center PowerShell History Viewer
The third goal of Windows Server 2012 AD is to make it easier to manage. In keeping with the pervasive PowerShell management theme found throughout the OS, it’s now possible to do pretty much any administrative task in AD with PowerShell. Since PowerShell has increased its coverage of administrative tasks from 200 to more than 2,300 cmdlets, this actually makes your life easier because instead of having to script up a number of PowerShell cmdlets to get something done, you can very probably find a dedicated cmdlet for what you want to do.
Although other AD actions have been PowerShell-ized, interestingly the AD Recycle Bin (a welcome addition to Windows Server 2008 R2 that was PowerShell only) has gained a GUI. Personally, I’m all for a Recycle Bin GUI; when someone has fat-fingered an account or group into oblivion, no one wants to spend time looking for the PowerShell syntax to restore it!
Additionally, the Windows Server 2012 Active Directory Administrative Center (ADAC) has a new pane at the bottom called the PowerShell History Viewer. Although it’s hidden by default, you can expand the History Viewer pane to see what PowerShell commands are executed “under the covers” as a result of the actions you’re taking in ADAC. This way, you can learn the syntax of AD-related PowerShell cmdlets by watching them flow by. You can also easily copy the cmdlets to paste them into a script of your own, or combine cmdlets into tasks with the Tasks feature in the pane. The history is retained between ADAC sessions, so you can go back days to find the syntax of a particular command you ran a while ago. By the way, the venerable Active Directory Users and Computers (ADUC) console isn’t going away any time soon because it has extensibility that ADAC currently lacks, but ADUC isn’t being enhanced. An appropriate maxim might be, “ADUC is dead; long live ADAC!”
AD-Integrated Product Activation
Another feature that falls under the “easy to manage” goal is something that simply makes sense: Product activation now uses AD instead of a separate infrastructure. It uses LDAP for communication with its clients instead of RPC, and no data is written back to the directory. You won’t be getting rid of KMS for a while, though, as it’s still required for down-level (e.g., everything that’s in production today) licensing.
AD FS Takes One More Step Toward Integration
Active Directory Federation Services (AD FS) has become a little more integrated into the mainstream server bits than its previous releases. In Windows Server 2012, AD FS is installed as a role within Server Manager instead of as a downloadable add-on. It hasn’t yet taken the much larger architectural step of becoming an AD component, but it’s a step in the right direction. With the addition of claims into the Kerberos token (see "Exploring Windows Server 2012 Dynamic Access Control"), AD FS will be able to extract and use these claims from the token, and also use static device claims (such as what department a notebook belongs to).
Active Directory and Dynamic Access Control
Finally, Windows Server 2012 AD is an integral component of a huge new feature in the identity and security area for the OS: Dynamic Access Control, a far more powerful, flexible, and natural way of managing access to files on NTFS volumes. You can find more information about this authorization engine in my related article, "Exploring Windows Server 2012 Dynamic Access Control."
Windows Server 2012 Active Directory has made a number of much-appreciated improvements in virtualization, deployment, and management designed to ease the frustration and support headaches of the tens of thousands of IT pros that aren’t dedicated AD specialists. They improvement help to “lower the friction of deployment” of Windows Server (to quote Jeffry Snover). And many smaller changes to AD are underpinnings for a wide variety of new features in the OS. As the product goes into full beta it’ll be interesting to see what tweaks and adjustments are made to one of Microsoft’s most widely deployed enterprise applications.
Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.
