Microsoft has positioned its most recent server OS, Windows Server 2012, as a fundamental building block for private cloud environments. The new server OS includes numerous changes to the Hyper-V virtual machine manager, including new security features to allow for better and more flexible network isolation between the virtual machines (VMs) of tenants that use the same Hyper-V instance. But Server 2012 also includes important changes to another crucial element of Microsoft-rooted private clouds: Active Directory (AD).
In this article, I focus on some key security changes that Microsoft bundles with Server 2012 AD. There's much to say about Dynamic Access Control, which represents a big shift in the Windows and AD authorization model. In addition, Server 2012 AD includes some smaller but no less important security-related changes.
Dynamic Access Control: All About Claims
Dynamic Access Control is probably the most fundamental security change that Microsoft incorporates in Server 2012. Dynamic Access Control integrates the claims-based access control (CBAC) model with the Windows OS and AD. Claims are statements about users or devices (e.g., "My account name is JanDC," "I am a member of the sales department") and are issued by a trusted authority. Microsoft first introduced CBAC in Active Directory Federation Services version 1 (ADFS v1), which was bundled with Windows Server 2003.
Claims can provide a flexible mechanism for exchanging trustworthy identity attributes between ADFS servers. Organizations can now use claims to protect the file and folder data stored on domain-joined Server 2012 or Windows 8 machines. Server 2012 domain controllers (DCs) can issue claim statements as part of the user and machine authentication process, by embedding the claims in the user's or machine's authentication ticket. (For more information on claims and how Microsoft leverages them, read "A Guide to Claims-based Identity and Access Control.")
Dynamic Access Control is built on several new and enhanced Windows data-authorization features for classifying and labeling data, applying CBAC settings, auditing access to data, and encrypting data. Under the hood, Dynamic Access Control relies on numerous Microsoft engineering changes to key Windows components, services, and protocols. These include AD, Group Policy Objects (GPOs), DNS, Kerberos, the Local Security Authority (LSA), and the Netlogon processes, as well as network protocols such as Server Message Block (SMB), LDAP, and remote procedure call (RPC). Microsoft has made several Dynamic Access Control–driven changes in Server 2012, including the following:
- Extending the DC and Kerberos Key Distribution Center (KDC) logic, to enable the issuing of claims in authentication tokens
- Changing the Kerberos token format, to enable the transportation of claims
- Adding alternate data streams (ADS) in NTFS, to attach custom properties to files and folders
- Enabling the storage of conditional expressions in the ACLs of file and folders, to enable more flexible access control and auditing settings
- Extending the AD schema, to allow centralized storage of Dynamic Access Control properties and policies
Dynamic Access Control can leverage AD to store central access policies (CAPs) and GPOs and to push these policies to domain members. Microsoft also added a Central Policy tab (which Figure 1 shows) in the Advanced Security Settings dialog box for folders.
From this tab, administrators can choose the CAP that they want to assign to a given folder. Thanks to these changes, you can now grant access to files and folders in your domain or forest, based on the values of standard or custom attributes of your AD user and machine objects. For example, you can now refuse a user access to a file server share if the Department attribute of the AD user object doesn't contain the value "Sales" or "Marketing." This new flexible authorization logic is very different from the user- and group-SID–based logic that we've been using for years.
You can define CAPs from the Dynamic Access Control container in the revamped Active Directory Administrative Center (ADAC), which Figure 2 shows, or by using Windows PowerShell cmdlets.
You can call on the same tools to enable claim support for an AD user or machine object attribute and to add values to these attributes. A Server 2012 DC will add claim statements to user and computer authentication tokens only for the user and computer object attributes that actually contain information and that are linked to an enabled claim type. Before your Server 2012 DCs can issue claims, you must explicitly enable them to issue claim statements; indeed, Server 2012 DCs are disabled for CBAC by default. To enable CBAC, use the Domain Controller support for Dynamic Access Control and Kerberos armoring GPO setting in the \Computer Configuration\Policies\Administrative Templates\System\KDC container. To use GPOs to push CAPs to your machines, you can use the new Central Access Policy GPO option in the \Computer Configuration\Policies\Windows Settings\Security Settings\File System container.
Dynamic Access Control brings the flexibility of claims not only to file and folder access control, but also to file and folder access auditing. For example, in Server 2012 you can configure an audit rule to track all users that were allowed or denied access to folders that are marked with the "confidential" property. To centrally define claim-based auditing settings for files and folders, you must call on the GPO Global Object Access Auditing feature that Microsoft introduced in Windows Server 2008 R2 and has now extended with Dynamic Access Control support.
Administrators can also define flexible access control and auditing settings on files and folders, in addition to or independent of the centrally defined CAPs. Microsoft changed the Advanced Security Settings dialog boxes in Windows 8 and Server 2012 to allow you to configure conditional expressions in the authorization and auditing settings of files and folders. Figure 3 shows this new interface, illustrating the definition of a permission that includes a conditional expression on a folder named SharedData.
Besides access control and auditing, Dynamic Access Control also provides new, flexible data-classification mechanisms. A good example is the ability to add custom file and folder properties, called global resource properties, to the access control and auditing setting dialog boxes of files and folders. Again, you can do this by using ADAC or PowerShell cmdlets. To propagate these custom properties to your domain machines, Microsoft equipped Windows 8 and Server 2012 clients with a special extension that uses LDAP to connect to AD and retrieve these properties. This new data classification feature gives you the flexibility to classify data based on your selected attributes and to apply protection accordingly.
You can classify files and folders manually by using the Classification tab in the properties of a file or folder, as Figure 4 shows. The Classification tab appears only on systems that have the Desktop Experience feature installed or that host the File Server Resource Manager role service.
For files, you can also automate the classification process by using the File Classification Infrastructure (FCI) feature. Introduced in Server 2008 R2, the FCI allows administrators to define custom classification labels, set up classification and expiration rules, and report on classifications. Administrators can manage FCI from the File Server Resource Manager (FSRM). FCI can also be used with the RMS Bulk Protection Tool to automatically apply RMS protection to files.
This is a very short introduction to Dynamic Access Control. You can find plenty more information, including how to set up, configure, and troubleshoot Dynamic Access Control, in the Microsoft white paper "Understand and Troubleshoot Dynamic Access Control in Windows Server 8 Beta."
New Security Management Functions in ADAC
In Server 2012, ADAC has become the main AD administration interface. ADAC even outpaces its predecessor -- the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in -- on the level of administrative features. Two new features that many administrators will welcome are ADAC's GUI support for recovering deleted AD objects and for configuring fine-grained password policy (FGPP) settings.
The AD Recycle Bin was introduced in Server 2008 R2, to enable the recovery of deleted AD objects and their attributes. An important shortcoming of the Server 2008 R2 AD Recycle Bin was its lack of a GUI. Administrators were forced to use either ldp.exe or PowerShell cmdlets, two tools that complicate AD object recovery and slow down the recovery process.
As Figure 5 shows, Microsoft has integrated a Deleted Objects container in the Server 2012 ADAC interface.
You can now easily restore a deleted user object by using the Restore or Restore To links in the right pane of ADAC. In Server 2012, the same restrictions apply to the use of AD Recycle Bin:
- It isn't enabled by default (you can enable it from ADAC).
- Your AD forest must be at least at the Server 2008 R2 functional level.
- You can restore deleted objects only within their Deleted Object Lifetime (DOL), which is 180 days by default.
For more information about the AD Recycle Bin, see the "Active Directory Recycle Bin Step-by-Step Guide."
The second useful GUI addition in ADAC relates to FGPP configuration. Microsoft introduced FGPPs in Server 2008 to allow the definition of multiple Windows domain password and account lockout policies that are linked to different AD user or administrator groups. Before that, Windows Server could support only a single domain password policy. To support FGPPs, Microsoft introduced a new AD object type called the Password Settings Object (PSO).
As for the Recycle Bin, Microsoft didn't provide a GUI to configure FGPPs in the Server 2008 release. Administrators needed to call on tools such as PowerShell cmdlets, ADSI Edit, or LDIFDE to define PSOs. In Server 2012, you can use the ADAC GUI to define new FGPPs and PSOs from the new Password Settings Container that's underneath the System container, as Figure 6 shows.
Just as before, your domain must be at least at Server 2008 domain functional level to use FGPPs. For more details, see "AD DS Fine-Grained Password Policy and Account Lockout Step-by-Step Guide."
Group Managed Service Accounts
Managed Service Accounts (MSAs) are a special type of domain account that Microsoft supports in Server 2008 R2 AD and later. MSAs overcome the password-management problems that administrators encounter when they set up a custom domain account for authenticating a service. Administrators prefer to define custom accounts, which allow them to better isolate the privileges of an application than when using a built-in high-privilege local account (i.e., Local System, Local Service, Network Service) as the service account. But unlike these built-in local accounts, custom accounts don't have automatic password management. Therefore, when you use custom service accounts, you need to manually manage their passwords or create a custom management solution.
MSAs resolve this problem by providing automatic password management. They also simplify the setup of Service Principal Names (SPNs) for a service. Unfortunately, the MSAs that are introduced in Server 2008 R2 could not be used by clustered or load-balanced services (e.g., services in a web farm) that want to share one service account and password. In these scenarios, administrators needed to manually synchronize the passwords of the service instances or implement a custom solution for automatic password synchronization.
Server 2012 group MSAs (gMSAs) resolve this problem for load-balanced services in web farms. Unfortunately, at the time of writing, the MSAs don't yet work for services that are part of a failover cluster.
Behind gMSAs, a new service called the Microsoft Key Distribution Service runs on every Server 2012 DC. This service ensures that the password of the single service account that the web farm service instances use is kept in sync between instances. To use gMSAs, your AD schema must be updated to Server 2012, and you need one or more Server 2012 DCs running the Microsoft Key Distribution Service. The service is automatically installed on every DC but defaults to a manual startup. Only services that run on Server 2012 can use gMSAs. You can create and administer gMSAs by using a set of PowerShell cmdlets. For more information on gMSAs, see "Getting Started with Group Managed Service Accounts."
Primary Computers for Folder Redirection and Roaming Profiles
The last new, powerful feature that I want to discuss in this article is the ability to label AD computer objects as the primary computers of certain domain users. You can use this feature to control the computers to which users' roaming profiles are downloaded and on which users receive access to their redirected folders. On computers that haven't been labeled as primary computers, users will have a local profile and won't have access to their redirected folders.
In the age of the consumerization of IT and trends such as Bring Your Own Device (BYOD), this method is a powerful way to associate or dissociate user data and settings with particular computers or devices and to improve corporate data security. Designating primary computers reduces the security and privacy risks of downloading or leaving personal or corporate data on personal or public computers to which the user has logged on.
The Primary Computer feature is based on a set of new GPO settings and an AD schema extension. When a user logs on to a Windows 8 or Server 2012 machine, the logon logic checks the status of the Download roaming profiles on primary computers only and Redirect folders on primary computers only GPO-controlled settings. The status determines whether the msDS-PrimaryComputer attribute, which is linked to the user's AD user account object, should influence the decision to roam the user's profile or to apply Folder Redirection. The new GPO settings are in the \User Configuration\Policies\Administrative Templates\System\Folder Redirection and the \User Configuration\Policies\Administrative Templates\System\User Profiles GPO containers.
You can use the ADAC or PowerShell cmdlets to populate an AD user object's msDS-PrimaryComputer attribute with a list of DistinguishedNames of computer accounts that should be marked as the user's primary computers. Figure 7 shows how you can leverage ADAC and its built-in attribute editor to set the msDS-PrimaryComputer attribute for a user named Jack.
The support for the Primary Computer feature requires that your AD schema be upgraded to Server 2012. The feature can be leveraged only on domain-joined Server 2012 and Windows 8 machines. For more details on how to set up this feature, I advise you to read the Storage Team Blog post "Configuring Primary Computers for Folder Redirection and Roaming Profiles in Windows Server 8 Beta."
A Model Shift
Dynamic Access Control represents the biggest shift in the authorization and auditing model for Windows files and folders since the introduction of AD, and maybe even since the introduction of NTFS. The support for Dynamic Access Control is certainly the biggest security change in Server 2012 and AD, not only for the Microsoft engineers who developed it but also for anyone who decides to use it. If you're a Windows or AD administrator or architect, I advise you to test Dynamic Access Control thoroughly and become familiar with it before you start using it.
ADAC and PowerShell also enter prime time for general and security-related AD management tasks in Server 2012 AD. Like Dynamic Access Control, ADAC and PowerShell are primarily about adding more flexibility and making it easier for the people who administer and configure AD day-in and day-out.
