Friday 5 July 2013

What's New in BitLocker for Windows 8 and Windows Server 2012

  •        New functionality in Windows 8 and Windows Server 2012:
    • BitLocker provisioning

      BitLocker can be used to deploy drives to an encrypted state during installation prior to calling setup.
    • Used Disk Space Only encryption

      BitLocker now offers two encryption methods, Used Disk Space Only and Full volume encryption. Used Disk Space Only allows for a much quicker encryption experience by only encrypting used blocks on the targeted volume.
    • Standard User PIN and password change

      Allows a standard user to change the BitLocker PIN or password on operating system volumes and the BitLocker password on data volumes, reducing internal help desk call volume.
    • Network Unlock

      Enables a BitLocker system on a wired network to automatically unlock the system volume during boot (on capable Windows Server 2012 networks), reducing internal help desk call volumes for lost PINs.
    • Support for Encrypted Hard Drives for Windows

      BitLocker support for Encrypted Hard Drives provides users a familiar method for managing drive encryption along with the benefit of using hardware-based encryption.
In Windows Vista and Windows 7, BitLocker is provisioned post installation for system and data volumes through either the manage-bde command line interface or the Control Panel user interface. In Windows 8 and Windows 8.1 Preview, BitLocker can also be easily provisioned before the operating system is installed.
With this improvement administrators can enable BitLocker from the Windows Preinstallation Environment (WinPE) prior to operating system deployment. This is done with a randomly generated clear protector applied to the formatted volume and encrypting the volume prior to running the Windows setup process. If the encryption uses the Used Disk Space Only option described in the next section, this step takes only a few seconds and so incorporates well into regular deployment processes.
To check the BitLocker status of a particular volume, administrators can look at the status of the drive in the BitLocker control panel applet or Windows Explorer. When a drive is pre-provisioned for BitLocker, a status of "Waiting For Activation" is displayed with a yellow exclamation icon in the BitLocker Control Panel. This status means that there was only a clear protector used when encrypting the volume. In this case, the volume is not protected and needs to have a secure key added to the volume before the drive is considered fully protected. You can use the control panel, manage-bde tool or WMI APIs to add an appropriate key protector and the volume status will be updated. The following table shows the appropriate key protectors that can be added to drives that have been pre-provisioned with BitLocker protection:

 

Drive Type Key protector
Operating SystemTPM
TPM+PIN
Startup Key (for systems without a TPM)
Password (for systems without a TPM)
Fixed data driveAutomatic unlock
Password
Smart card
Removable data drivePassword
Smart card
In Windows 7, BitLocker requires that all data and free space on the drive are encrypted. The encryption process can take a very long time on larger volumes. In Windows 8 and Windows 8.1 Preview, administrators can choose to encrypt the entire volume or the used space only. When you choose the Used Disk Space Only encryption option, only the portion of the drive that has data will be encrypted. Free disk space will not be encrypted. Used Disk Space Only encryption allows encryption to complete much faster on empty or partly empty drives than previous implementations of BitLocker. When provisioning BitLocker during Windows deployments, Used Disk Space Only encryption allows BitLocker to encrypt a drive in a short amount of time before installing the operating system. Full Encryption encrypts both data and free space on the volume, similar to the way BitLocker works in Windows 7 and Windows Vista.
New Group Policy settings for encryption type
You can use Group Policy settings to enforce that either Used Disk Space Only or Full Encryption is used when BitLocker is enabled on a drive. Group Policy settings for BitLocker Drive Encryption are located under the \Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption path of the Local Group Policy Editor
The following new Group Policies are available:
  • Fixed Data Drives\Enforce drive encryption type on fixed data drives
  • Operating System Drives\Enforce drive encryption type on operating system drives
  • Removable Data Drives\Enforce drive encryption type on removable data drives
For each of these policies, once they are enabled you can then specify which type of encryption is required to be used on which drive type. If the policy is not configured the user will be able to choose the encryption method when they turn on BitLocker.
Administrative privileges are required to configure BitLocker for operating system drives. In an organization where computers are managed by IT professionals and users are not normally granted administrative privileges, deploying the TPM + PIN protection option to large numbers of computers can be challenging. In Windows 8, administrative privileges are still required to configure BitLocker, however standard users are allowed to change the BitLocker PIN or password for the operating system volume or the BitLocker password for fixed data volumes by default. This gives users the ability to choose PINs and passwords that correspond to a personal mnemonic instead of requiring the user remember a randomly generated character set and allows IT professionals to use the same initial PIN or password setting for all computer images. This also presents the opportunity for users to choose passwords and PINs that are more susceptible to password guessing, dictionary attacks, and social engineering attacks and gives users the ability unlock any computer that still uses the original PIN or password assignment. Requiring password complexity and PIN complexity by Group Policy is recommended to help ensure that users take appropriate care when setting passwords and PINs.
Standard users are required to enter the current PIN or password for the drive to change the BitLocker PIN or BitLocker password. If a user enters an incorrect current PIN or password, the default tolerance for retry attempts is set to 5. Once the retry limit is reached, a standard user will not be able to change the BitLocker PIN or BitLocker password. The retry counter is set to zero when the computer is restarted or when an administrator resets the BitLocker PIN or BitLocker password.
You can disable the option to allow standard users to change PINs and passwords using the Group Policy setting Disallow standard users from changing the PIN located in the \Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Operating System Drives section of Local Group Policy Editor.
Windows Server 2012 has added a new BitLocker protector option for Operating System Volumes called Network Unlock. Network Unlock will enable easier management for BitLocker enabled desktops and servers in a domain environment by providing automatic unlock of operating system volumes at system reboot when connected to a trusted wired corporate network. This feature requires the client hardware to have a DHCP driver implemented in its UEFI firmware.
Operating system volumes protected by TPM+PIN protectors require a PIN to be entered when a machine reboots or resumes from hibernation (for example, when configured for Wake on LAN). The requirement to enter a PIN can make it difficult for enterprises to install software patches to unattended desktops and servers. Network Unlock provides a method by which computers that are configured to use a TPM+PIN key protector can start Windows without user intervention. Network Unlock works in a similar fashion to the TPM+StartupKey. Rather than needing to read the StartupKey from USB media, however, the key for Network Unlock is composed from a key stored in the TPM and an encrypted network key that is sent to the server, decrypted and returned to the client in a secure session. The network key is stored on the system drive along with an AES 256 session key, and encrypted with the 2048-bit RSA public key of the unlock server's certificate. The network key is decrypted with the help of a provider on a Windows Server 2012 WDS server and returned encrypted with its corresponding session key. In instances where the Network Unlock provider is unavailable, the standard TPM+PIN unlock screen is presented to unlock the drive. The server side configuration to enable Network Unlock also requires provisioning a 2048 bit RSA public/private key pair in the form of an X.509 certificate, and for the public key certificate to be distributed to the clients. This certificate must be managed and deployed through the Group Policy Management Console directly on Windows Server 2012 Domain Controller. For more information see BitLocker: How to enable network unlock

BitLocker provides Full Volume Encryption (FVE) of Windows operating system and data volumes using software-based encryption. In Windows 8 BitLocker also provide support for a new enhanced storage device type, the Encrypted Hard Drive, that is becoming a more common option in new servers and computers. Encrypted Hard Drives offer Full Disk Encryption (FDE), which means encryption occurs on each block of the physical drive. Encryption operations are more efficient on Encrypted Hard Drives because the encryption process is offloaded to the storage controller on the drive (also known as hardware-based encryption).
Windows 8 supports Encrypted Hard Drives natively in the operating system through the following mechanisms:
  • Identification: Windows 8 will be able to identify that the drive is a Encrypted Hard Drive device type
  • Activation: Windows 8 disk management will activate, create and map volumes to ranges/bands as appropriate
  • Configuration: Windows 8 will create and map volumes to ranges/bands as appropriate
  • API: Windows 8 provides API support for applications to manage Encrypted Hard Drives independently of BitLocker Drive Encryption
  • BitLocker: BitLocker Control Panel will enable users to manage Encrypted Hard Drives in the same manner as full volume encrypted drives.

What's New in Active Directory Rights Management Services (AD RMS) in Windows 2012 server

 Active Directory Rights Management Services (AD RMS) in Windows Server® 2012. These changes should enable IT professionals working with AD RMS to meet the needs of their business in a secure, reliable and flexible way.

AD RMS is the server role that provides you with management and development tools that work with industry security technologies—including encryption, certificates, and authentication—to help organizations create reliable information protection solutions. For more information, see Active Directory Rights Management Services Overview.
New AD RMS features covered in this topic include:
  • Changes to AD RMS and Microsoft SQL Server requirements.
  • Changes in deployment of AD RMS when using Server Manager and Windows PowerShell
For Windows Server 2012, requirements for configuring Microsoft SQL Server to support AD RMS have been revised or changed in response to customer feedback.

What value does this change add?
The following changes to AD RMS Setup have been made to enable better support for remote deployment of AD RMS and SQL servers and to address customer feedback that requested more flexible deployment options.

What works differently?
In previous releases, AD RMS setup required that the account used to install AD RMS must have local administrator privilege on any computers hosting a SQL Server installation that was to be used to support the storage of AD RMS-related data. This was because AD RMS Setup required the ability to read SQL database settings from the Windows Registry. Because of customer feedback, this has been changed for this release.
For Windows Server 2012, AD RMS now has the following requirements for access to SQL Server.
  • The AD RMS installer account must have sysadmin permissions in the SQL Server installation.
  • The SQL Server Browser service must be running to locate available SQL instances.
  • Firewall exceptions should be enabled on the SQL server computer for ports that will be used by AD RMS setup. The TCP port for the SQL instance that will host the AD RMS databases should be enabled. The UDP port for the SQL Server Browser service should also be enabled. For example, the default ports are usually TCP port 1433 for the SQL Server instance and UDP port 1434 for the SQL Server Browser service.
In addition to the previous access requirements, for Windows Server 2012 the following versions of Microsoft SQL Server have been tested and are supported for use with AD RMS deployment.
  • SQL Server 2005 Service Pack 3
  • SQL Server 2008 Service Pack 3
  • SQL Server 2008 R2 Service Pack 1
  • SQL Server 2012
For more information on applicable SQL Server requirements for AD RMS, see AD RMS SQL Server Requirements (http://technet.microsoft.com/library/dd772673(WS.10).aspx).
In previous releases, AD RMS Setup supported only deployment at the same server computer where AD RMS was to be installed. Based on customer feedback, this has been changed. For Windows Server 2012, AD RMS now supports remote deployment at targeted server computers.

What value does this change add?
The following changes to AD RMS Setup have been made to enable better integration with the newly revised Server Manager in Windows Server 2012 which better supports secure and flexible remote server deployment for AD RMS and other Active Directory technologies.

What works differently?
As a result of this change, when deploying AD RMS on remote servers to ensure the security of your deployment, you will be prompted for user credentials. Deployment now also requires an additional step that can be completed using either Server Manager or Windows PowerShell.
For Windows Server 2012, Server Manager has been redesigned to provide support for remote deployment of AD RMS as part of a two-step process that can be summarized as follows:
  1. Launch the Add Roles and Features Wizard in Server Manager to add the AD RMS role. This will add and install the files necessary for AD RMS.
  2. After adding the AD RMS role, launch the AD RMS Configuration wizard to select deployment options and configure the AD RMS cluster.
When the AD RMS configuration wizard first launches, if you are installing AD RMS on a remote server you will be prompted for the credentials needed to complete AD RMS configuration.
The requirements for selecting the credentials that you enter here are as follows:
  • The account used to deploy AD RMS must have membership in the local Administrators group on the server computer where you are installing and configuring AD RMS.
  • The account used must also have sysadmin permissions on the server that hosts the configuration database for the AD RMS cluster.

    noteNote
    Prompting for credentials only occurs in Server Manager if you are installing AD RMS to a remote server; however, the credentials requirements are the same for installing locally.
Additionally, if you wish to register the AD RMS service connection point (SCP) with Active Directory during configuration, the account also needs to be a member of the Enterprise Admins group for the forest. Because this requires additional privilege, you might choose to complete this task later after you have completed the basic server configuration. To do so, you must use the AD RMS console. For more information, see Register a Service Connection Point (http://technet.microsoft.com/library/cc725573.aspx).
noteNote
If you are going to be viewing reports related to AD RMS, you must also install the .NET Framework 3.5 using Server Manager (or by typing Install-WindowsFeature NET-Framework-Core at the Windows PowerShell prompt) prior to installing the Microsoft Report Viewer 2008, which is used to generate troubleshooting and system health reports on AD RMS in Windows Server 2012. For more information, see the Test Lab Guide: Deploying an AD RMS Cluster.
For Windows Server 2012, you can now optionally complete the two-part AD RMS deployment process as described in the previous section using Windows PowerShell commands. In Windows Server 2008 R2, the ADRMS module was provided as part of the base operating system but this has changed to enable more flexibility and modularity in installing the product. For this release, you need to use commands provided within the new ServerManager module for Windows PowerShell.
For example, to complete the first part of the deployment process (copy and install all required files for AD RMS) you would use the following Server Manager cmdlet examples at a Windows PowerShell prompt.

 

Example Description
Add-WindowsFeature ADRMS –IncludeAllSubFeature -IncludeManagementToolsAdds all AD RMS role services and tools. This command downloads and makes available all support files needed to work with AD RMS.
Add-WindowsFeature ADRMS-ServerAdds the AD RMS server role only. This command downloads and makes available those files needed to support an AD RMS server installation.
Add-WindowsFeature ADRMS-IdentityAdds identity federation support for AD RMS. This command downloads and makes available files needed to support AD RMS working with AD FS.
You can then install AD RMS by using the Install-ADRMS cmdlet which is provided as part of the AD RMS deployment module for Windows PowerShell. When using this cmdlet, use the new Credentials parameter as shown below. This parameter is required to support remote deployments and is recommended that you include it for all PowerShell-based deployments.
Install-ADRMS –Path adrmsDrive:\ -Credential
By adding the -Credential parameter you will be prompted to enter the required credentials to deploy AD RMS. If the installation is targeted for a remote computer, credentials must be passed through and validated at the remote computer before installation of AD RMS will proceed.
For Windows Server 2012, uninstalling AD RMS can also be accomplished using Windows PowerShell as a two-step process comparable to a reversal of the process described in the previous section for AD RMS deployment. This process can be summarized as follows:
  1. Uninstall the AD RMS role.

    This can be performed separately by using Windows PowerShell and running the Uninstall-ADRMS cmdlet in the ADRMS module.
  2. Remove the AD RMS files and registry settings that were previously added to support AD RMS.

    If you are using Windows PowerShell, use the Remove-WindowsFeature ADRMS cmdlet in the ServerManager module to perform this step as a separate action.
noteNote
If you use the Remove Roles and Features Wizard in Server Manager to remove the AD RMS role it accomplishes as a single action both of the steps summarized above. Also, this same joint action occurs if you run Remove-WindowsFeature ADRMS, which calls the Uninstall-ADRMS cmdlet.
In addition to new changes to Windows PowerShell that affect deployment of the AD RMS role and its services and components, new properties have been added for Windows Server 2012 that can be used when deploying AD RMS installations. The following table provides details and comments on where these new properties can be used to support new changes such as support for strong cryptography.

 

Install Type Container Property Default Value Description
RootClusterCryptoSupportSupportCryptoMode2TrueThis container appears by default and is set to enable support for strong cryptography.
RootClusterSSLCertificateSupportThis container only appears when the ClusterURL property is set to HTTPS.
RootClusterSSLCertificateSupportSSLCertificateOptionChooseLaterThe default for this property enables you to choose a certificate later after deploying AD RMS. Other alternate values include Create (enables creation of a self-signed certificate) or Existing (Enables use of an existing certificate).
RootClusterSSLCertificateSupportThumbprint[not set]This property is used to specify the thumbprint to identify a certificate. It only appears when the SSLCertificateOption property is set to Existing.
LicensingClusterSSLCertificateSupportThis container only appears when the ClusterURL property is set to HTTPS.
LicensingClusterSSLCertificateSupportSSLCertificateOptionChooseLaterThe default for this property enables you to choose a certificate later after deploying AD RMS. Other alternate values include Create (enables creation of a self-signed certificate) or Existing (Enables use of an existing certificate).
LicensingClusterSSLCertificateSupportThumbprint[not set]This property is used to specify the thumbprint to identify a certificate. It only appears when the SSLCertificateOption property is set to Existing.
JoinClusterSSLCertificateSupportThis container appears when the DatabaseName property is set to a cluster database that is using SSL.
JoinClusterSSLCertificateSupportSSLCertificateOptionChooseLaterThe default for this property enables you to choose a certificate later after deploying AD RMS. Other alternate values include Create (enables creation of a self-signed certificate) or Existing (Enables use of an existing certificate).
JoinClusterSSLCertificateSupportThumbprint[not set]This property is used to specify the thumbprint to identify a certificate. It only appears when the SSLCertificateOption property is set to Existing.
JoinClusterADFSSupportThis container exists by default in all AD RMS installations that are running at Windows 2008 R2 or later but only appears in Windows Server 2012 if the ADRMS-Identity role service is installed.
JoinClusterADFSSupportADFSUrl[not set]The value of this property must be a Web address (URL) to a valid AD FS server. For example, "http:// fs.corp.contoso.com"
noteNote
When the SSLCertificateOption property is configured to use a value of Existing and the Thumbprint property is empty or not set, it might appear incorrectly that installation of AD RMS has failed when using the Install-ADRMS cmdlet in a Windows PowerShell session. For example, under these conditions, you see the following error message after a PowerShell-based installation.
    PS rmsdrive:\> install-adrms -path . -force
    Install-ADRMS : Value cannot be null.
    Parameter name: findValue
    At line:1 char:1

If such an error should appear, it indicates only that AD RMS is missing an expected SSL binding. If this happens, you can assume that AD RMS is fully provisioned and operating as expected. To address the issue, you only need to configure SSL certificates on IIS before using the AD RMS server.
In previous releases of AD RMS included with Windows Server® 2008 and Windows Server® 2008 R2 it was not possible to launch more than a single instance of the AD RMS Configuration wizard to install or update multiple AD RMS deployments from the same server computer. Because of design changes to Server Manager for Windows Server 2012, multiple instances of the Add Roles and Features Wizard can now be run simultaneously, making it possible to launch two or more instances of the AD RMS Configuration wizard.

What value does this change add?
The changes to Server Manager in Windows Server 2012 enable server roles and technologies across Windows Server 2012 to be more open, efficient and flexible when you are choosing role deployment options.

What works differently?
As a result of changes to Server Manager to enable multiple instances to be deployed and configured simultaneously in Windows Server 2012 and because this change is at odds with how AD RMS is best designed to be deployed, AD RMS setup is not able to prevent multiple AD RMS configuration wizards from being launched to create new clusters or for joining an existing cluster. Therefore, the AD RMS Configuration wizard applies the following logic and process detection to determine how to manage the occurrence of multiple instances of AD RMS setup occurring at the same time.
  • If multiple instances are launched and are used to join an already existing AD RMS cluster, AD RMS setup should succeed for all active instances.
  • If multiple instances are launched and are being used to try to create the same new AD RMS cluster, AD RMS setup fails for all active instances.
This section describes issues to consider when you deploy AD RMS on virtual machines. In general, AD RMS is well suited to virtualization especially for testing and evaluation purposes. There are, however, a few practices that you should observe when you are working with virtualized AD RMS servers. The following section describes these considerations.

What value does this change add?
Using virtualization platforms, such as Hyper-V to deploy AD RMS for evaluation purposes offers a number of convenience features that can make testing easier. For example, virtualization enables you to easily establish a full private virtual networked configuration separate from your production networked environment in which you can freely test and evaluate AD RMS deployment to your satisfaction before attempting a deployment of it in your production environment.

What works differently?
When working with virtualized AD RMS servers, the following are some deployment practices and features that need to be observed or followed for best results.
  • To ensure consistent performance between virtualized AD RMS servers operating in test conditions to how a comparable physical AD RMS server might perform in a subsequent production deployment of AD RMS, follow the recommended guidance requirements as you create your virtual machines and then use those as well for installing AD RMS on a physical server computer. In particular, select the recommended amount of RAM for virtual AD RMS servers to the higher recommended amount. If you follow recommended hardware guidelines, there should be no perceptible difference in performance between virtualized test server deployments of AD RMS and any comparable physical server installations you might later deploy into production as a result of your virtual lab test results.
  • When you install AD RMS on a virtual server you will not be able to use an internal hardware security module (HSM) for AD RMS key storage. You can, however, use all other forms of key storage: network HSM key storage, AD RMS centrally managed key storage and software CSP key storage.
  • If you have previously installed AD RMS on a virtual hard drive (VHD) and then take that VHD offline to uninstall AD RMS, the AD RMS role will not be completely removed. To ensure full and proper removal of AD RMS, you should remove the AD RMS server role first before shutting down any VHD associated with the original installation of AD RMS on your virtual machine.
For Windows Server 2012, AD RMS now joins the list of server roles such as Active Directory Domain Services (AD DS) and Active Directory Certificate Services (AD CS) that are supported for Server Core deployment. Server Core is an installation option that enables you to perform a minimal installation of the Windows Server operating system which can be useful for reducing total cost of ownership (TCO) in deploying and managing servers.

What value does this change add?
Using Server Core to deploy AD RMS can provide you with simplified management, reduced maintenance, reduced memory and disk requirements and a reduced attack surface. Servers that run under Server Core can be simpler and less costly to manage and more stable and secure in production deployments. For more information, see What is Server Core? and Why is Server Core Useful?

What works differently?
In Windows Server 2012, the Server Core installation option is no longer an irrevocable selection that is made during setup. In Windows Server 2008 R2 and Windows Server 2008, if your requirements changed, there was no way to convert between a full installation and Server Core installation without completely reinstalling the operating system. You can now administratively convert between a full Windows Server installation and running on Server Core as needed. For more information, see Windows Server Installation Options.
On Server Core installations, the optional Identity Federation Support role service for the AD RMS server role is not supported. This is because Identity Federation Support relies on a role service of the AD FS Server role, the Claims-aware Agent, which is disabled on Server Core installations.
If you attempt to add Identity Federation Support for AD RMS, the following error will occur.

The request to add or remove features on the specified server failed.
Installation of one or more roles, role services, or features failed. - The source files could not be downloaded. Use the /source option to specify the location of the files that are required to restore the feature. The file location should either be the root directory of a mounted image or a component store that has the Windows Side-by-Side directory as an immediate subfolder.
The instructions to work around the issue by downloading the source files do not apply for this case. Identity Federation Support cannot be installed because the Claims-aware Agent is disabled on Server Core.

Windows Server 2012 also includes the following feature updates, which have been added recently as updates for the AD RMS role in Windows Server 2008 R2.
  • Simple delegation
  • Strong cryptography
Because these features are still relatively new to most customers, they are discussed more here to help increase awareness for them and provide additional context for those who are unfamiliar with their appearance in the AD RMS feature set.
Simple delegation for AD RMS enables you to have the same access rights to protected content that are assigned to one person delegated to other individuals within their organization.

What value does this change add?
Simple delegation provides the ability to have content rights assigned to executives and managers be easily and effectively delegated to their assistants. This enables the assistants to have the same level of access permission to Information Rights Management (IRM)-protected content as the executive. By extending the Active Directory schema to support two new attributes, delegation of rights can be easily turned on or off as needed to accomplish the appropriate level of privilege or restriction for those who support the leadership and management of your organization.

What works differently?
The requirements for enabling the use of AD RMS simple delegation in Windows Server 2012 are similar to the requirements for using it in Windows Server 2008 R2. Two attributes, msRMSDelegator and msRMSDelegatorBL must be added to the Active Directory schema. This can be done using update files executed using the Ldifde.exe tool. These extension attributes must be applied to all forests where AD RMS licensing occurs. Also, you might also need to set additional permissions for AD RMS to read these attributes and update your SQL installation that supports AD RMS as part of preparing your deployment to support the use of simple delegation as well.
The only other change in requirements for simple delegation in Windows Server 2012 that differs from how it was enabled in Windows Server 2008 R2 is a new AD RMS PowerShell property that can be used to enable and disable it. By default, the feature is disabled, however, to enable simple delegation use the following command line at an elevated Windows PowerShell prompt at an AD RMS provided PowerShell drive:
PS w:\SecurityPolicy\Delegation> Set-ItemProperty -path . –Name IsEnabled –Value $true
For more information, see An update is available to enable simple delegation in AD RMS on Windows Server 2008 R2-based computers.
Strong cryptography for AD RMS enables you to increase the cryptographic strength of your AD RMS deployment by running in an advanced mode known as cryptographic mode 2.
What value does this change add?
Running AD RMS in strong cryptographic provides an updated and enhanced cryptographic implementation to support much stronger encryption as well as stronger cryptographic keys. For example, in mode 2 operation, RSA encryption is enhanced from 1024 bit encryption to 2048 bit encryption. Also, cryptographic keys are also longer (moved from 160 bit keys to using 256 bit keys) and the option to use a SHA-2 hashing algorithm (SHA-2/SHA-256) standards.
The value of strong cryptography in AD RMS is that it can be part of enabling your organization to satisfy regulatory compliance with current security standards that are set by the National Institute of Standards and Technology (NIST). Starting January 1, 2011, NIST issued Special Publication 800-57 which recommends the use of 2048-bit RSA keys. United States Federal agencies are required to comply with NIST recommendations and many private enterprises and other countries may choose to implement this recommendation. To learn more, see NIST Special Publications (http://csrc.nist.gov/publications/PubsSPs.html).
What works differently?
To enable the use of strong cryptography in your AD RMS deployment, all computers that host either AD RMS server or client software must be patched and updated.
To update AD RMS servers to cryptographic mode 2, you can use the AD RMS management console or the AD RMS cmdlets for Windows PowerShell.
Using the AD RMS management console, you can choose to update existing AD RMS servers from cryptographic mode 1 to cryptographic mode 2 by doing the following:
  1. In the navigation pane, select the AD RMS server you want to upgrade.
  2. From the Action menu (or in the Actions pane), select the Update to Cryptographic Mode 2 option.
If you are using Windows PowerShell, you can also choose to update an existing AD RMS server from cryptographic mode 1 to cryptographic mode 2 using the ADRMS module.
To update to Cryptographic Mode 2 using Windows PowerShell, use the following syntax:

Update-ADRMS –UpdateCryptographicModeOnly –ServiceAccount <PSCredential> -force –NewCSPName <”Mode2 Supported CSP”> -Regen
The following items apply to the parameters specified as part of the above syntax:
  • UpdateCryptographicModeOnly is the parameter that indicates that cryptographic mode 2 should be enabled. This is a one-way operation. Once complete, you cannot return the AD RMS server to cryptographic mode 1.
  • The Force parameter is an optional switch that can be used to override prompting for user confirmation.
  • The NewCSPName parameter indicates the cryptographic providers that you want to use for encryption. This is an optional setting depending on your current cryptographic key settings. By default it is the Microsoft Enhanced RSA and AES Cryptographic Service Provider, but could also be another cryptographic mode 2 provider, such as one from a Hardware Security Module (HSM) that supports at least 2048 bit encryption.

    noteNote
    The CSP name cannot be specified for centrally managed keys. If an AD RMS cluster is using a centrally managed key for cryptographic mode 1, it must update to a centrally managed key for cryptographic mode 2. It cannot update to a CSP key.
As an example, if the AD RMS service account is named ADRMSSvc, you would open a Windows PowerShell prompt and run the following command to update the AD RMS server to cryptographic mode 2:

Update-ADRMS –UpdateCryptographicModeOnly –ServiceAccount ADRMSSvc –NewCSPName "Microsoft Enhanced RSA and AES Cryptographi

What's New in Active Directory Domain Services (AD DS) in Windows Server 2012

You can use Active Directory Domain Services (AD DS) in Windows Server 2012 to more rapidly and easily deploy domain controllers (on-premises and in the cloud), increase flexibility when auditing and authorizing access to files, and more easily perform administrative tasks at scale (locally or remotely) through consistent graphical and scripted management experiences. AD DS improvements in Windows Server 2012 include:

  • Virtualization that just works

    Windows Server 2012 provides greater support for the capabilities of public and private clouds through virtualization-safe technologies and the rapid deployment of virtual domain controllers through cloning.
  • Simplified deployment and upgrade preparation

    The upgrade and preparation processes (dcpromo and adprep) have been replaced with a new streamlined domain controller promotion wizard that is integrated with Server Manager and built on Windows PowerShell. It validates prerequisites, automates forest and domain preparation, requires only a single set of logon credentials, and it can remotely install AD DS on a target server.
  • Simplified management

    Examples of simplified management include the integration of claims-based authorization into AD DS and the Windows platform, two critical components of a broader feature known as Dynamic Access Control (DAC). DAC comprises central access policies, directory attributes, the Windows file-classification engine, and compound-identities that combine user and machine identity into one. In addition, the Active Directory Administrative Center (ADAC) now allows you to perform graphical tasks that automatically generate the equivalent Windows PowerShell commands. The commands can be easily copied and pasted into a script simplifying the automation of repetitive administrative actions.
  • AD DS Platform Changes

    The AD DS platform comprises core functionality, including the “under-the-covers” behaviors that govern the components upon which the rest of the directory service is built. Updates to the AD DS platform include improved allocation and scale of RIDs (relative identifiers), deferred index creation, various Kerberos enhancements and support for Kerberos claims (see Dynamic Access Control) in AD FS.
Active Directory and AD DS has been at the center of IT infrastructure for over 10 years, and its features, adoption, and business-value have grown release over release. Today, the majority of that Active Directory infrastructure remains on the premises, but there is an emerging trend toward cloud computing. The adoption of cloud computing, however, will not occur overnight, and migrating suitable on-premises workloads or applications is an incremental and long-term exercise. New hybrid infrastructures will emerge, and it is essential that AD DS support the needs of these new and unique deployment models that include services hosted entirely in the cloud, services that comprise cloud and on-premises components, and services that remain exclusively on the premises. These hybrid models will increase the importance, visibility, and emphasis around security and compliance, and they will compound the already complex and time-consuming exercise of ensuring that access to corporate data and services is appropriately audited and accurately expresses the business intent.
The following sections describe how AD DS in Windows Server 2012 addresses these emerging needs.
For more information about installing AD DS, see Deploy Active Directory Domain Services (AD DS) in Your Enterprise and Upgrade Domain Controllers to Windows Server 2012.
AD DS in Windows Server 2012 allows you to deploy replica virtual domain controllers by “cloning” existing virtual domain controllers. You can promote a single virtual domain controller by using the domain controller promotion interface in Server Manager, and then rapidly deploy additional virtual domain controllers within the same domain, through cloning.
The process of cloning involves creating a copy of an existing virtual domain controller, authorizing the source domain controller to be cloned in AD DS, and running Windows PowerShell cmdlets to create a configuration file that contains detailed promotion instructions (name, IP address, Domain Name System [DNS] servers, and so on). Or you can leave the configuration file empty, which allows the system to automatically fill in the information. Cloning reduces the number of steps and time involved by eliminating repetitive deployment tasks, and it enables you to fully deploy additional domain controllers that are authorized and configured for cloning by the Active Directory domain administrator.
For detailed information about virtualized domain controller cloning, see Active Directory Domain Services (AD DS) Virtualization.
AD DS has been virtualized for several years, but features present in most hypervisors can invalidate strong assumptions made by the Active Directory replication algorithms. Primarily, the logical clocks that are used by domain controllers to determine relative levels of convergence only go forward in time. In Windows Server 2012, a virtual domain controller uses a unique identifier that is exposed by the hypervisor. This is called the virtual machine GenerationID. The virtual machine GenerationID changes whenever the virtual machine experiences an event that affects its position in time. The virtual machine GenerationID is exposed to the virtual machine’s address space within its BIOS, and it is made available to the operating system and applications through a driver in Windows Server 2012.
During boot and before completing any transaction, a virtual domain controller running Windows Server 2012 compares the current value of the virtual machine GenerationID against the value that it stored in the directory. A mismatch is interpreted as a “rollback” event, and the domain controller employs AD DS safeguards that are new in Windows Server 2012. These safeguards allow the virtual domain controller to converge with other domain controllers, and they prevent the virtual domain controller from creating duplicate security principals. For Windows Server 2012 virtual domain controllers to gain this extra level of protection, the virtual domain controller must be hosted on a virtual machine GenerationID–aware hypervisor such as Windows Server 2012 with the Hyper-V role.
For detailed information about the virtualization-safe technology feature, see Active Directory Domain Services (AD DS) Virtualization.
AD DS deployment in Windows Server 2012 integrates all the required steps to deploy new domain controllers into a single graphical interface. It requires only one enterprise-level credential, and it can prepare the forest or domain by remotely targeting the appropriate operations master roles. The new deployment process conducts extensive prerequisite validation tests that minimize the opportunity for errors that might have otherwise blocked or slowed the installation. The AD DS installation process is built on Windows PowerShell, integrated with Server Manager, able to target multiple servers, and remotely deploy domain controllers, which results in a deployment experience that is simpler, more consistent, and less time consuming. The following figure shows the AD DS Configuration Wizard in Windows Server 2012.
Review OptionsFigure 1   AD DS Configuration Wizard

An AD DS installation includes the following features:
  • Adprep.exe integration into the AD DS installation process. Reduces the time required to install AD DS and reduces the chances for errors that might block domain controller promotion.
  • The AD DS server role installation, which is built on Windows PowerShell and can be run remotely on multiple servers. Reduces the likelihood of administrative errors and the overall time that is required for installation, especially when you are deploying multiple domain controllers across global regions and domains.
  • Prerequisite validation in the AD DS Configuration Wizard. Identifies potential errors before the installation begins. You can correct error conditions before they occur without the concerns that result from a partially complete upgrade.
  • Configuration pages grouped in a sequence that mirror the requirements of the most common promotion options, with related options grouped in fewer wizard pages. Provides better context for making installation choices and reduces the number of steps and time that are required to complete the domain controller installation.
  • A wizard that exports a Windows PowerShell script that contains all the options that were specified during the graphical installation. Simplifies the process by automating subsequent AD DS installations through automatically generated Windows PowerShell scripts.
For detailed information about AD DS integration with Server Manager see Deploy Active Directory Domain Services (AD DS) in Your Enterprise.
Numerous areas were addressed with a view towards simplifying AD DS management experience. These areas include:
Today, it is difficult to translate business-intent using the existing authorization model. The existing capabilities of access control entries (ACEs) make it hard or impossible to fully express requirements. In addition, there are no central administration capabilities. Finally, modern-day increases in regulatory and business requirements around compliance further compound the problem.
Windows Server 2012 AD DS addresses these challenges by introducing:
  • A new claims-based authorization platform that enhances, not replaces, the existing model, which includes:

    • User-claims and device-claims
    • User + device claims (also known as compound identity)
  • New central access policies (CAP) model
  • Use of file-classification information in authorization decisions
  • Easier access-denied remediation experience
  • Access policies and audit policies can be defined flexibly and simply:

    • IF resource.Confidentiality = high THEN audit.Success WHEN user.EmployeeType = vendor
Requirements
  • One or more Windows Server 2012 domain controllers
  • Windows Server 2012 file server
  • Enable the claims-policy in the Default Domain Controllers Policy
  • Windows Server 2012 Active Directory Administrative Center
  • For device-claims, compound ID must be switched on at the target service account by using Group Policy or editing the object directly
For more information about Dynamic Access Control see the Dynamic Access Control section of the technical library.
The offline domain-join feature that was added to AD DS in Windows Server 2008 R2 effectively allows client computers to be joined to a domain without requiring network connectivity to a domain controller, but the client computer could not also be preconfigured for DirectAccess as part of the domain join.
Windows Server 2012 AD DS provides the following improvements:
  • Extends offline domain-join by allowing the blob to accommodate DirectAccess prerequisites

    • Certs
    • Group Policies
  • What does this mean?

    • A computer can now be domain-joined over the Internet if the domain is DirectAccess enabled
    • Getting the blob to the non-domain-joined machine is an offline process and the responsibility of the administrator
Requirements
  • Windows Server 2012 domain controllers
For more information, see DirectAccess Offline Domain Join.
AD FS v2.0 shipped out-of-band of the Windows Server release. In Windows Server 2012, AD FS (v2.1) ships in-the-box as a server role. This provides:
  • Simplified trust-setup and automatic trust management
  • SAML-protocol support
  • Extensible attribute store
  • Allows claims to be sourced from anywhere in the enterprise
  • Active Directory Lightweight Directory Service (AD LDS) and SQL attribute-store providers supplied out-of-the-box
Requirements
  • Windows Server 2012
For detailed information about AD FS in Windows Server 2012, see AD FS.
Windows PowerShell is a key technology in creating a consistent experience between the command-line and the graphical user interface. Windows PowerShell increases productivity, but also requires investment in learning how to use it.
To minimize the learning investment, Windows Server 2012 includes the new Windows PowerShell History Viewer. The benefits include:
  • Allow administrators to view the Windows PowerShell commands executed when using the Active Directory Administrative Center. For example:

    • The administrator adds a user to a group
    • The UI displays the equivalent Windows PowerShell for Active Directory command
    • The administrator copies the resulting syntax and integrates it into a script
    • Reduces Windows PowerShell learning-curve
    • Increases confidence in scripting
    • Further enhances Windows PowerShell discoverability
Requirements
  • Windows Server 2012 Active Directory Administrative Center
For more information about the Windows PowerShell History Viewer, see Active Directory Administrative Center Enhancements.
The Active Directory Recycle Bin feature introduced with Windows Server® 2008 R2 provided an architecture permitting complete object recovery. Scenarios that require object recovery by using the Active Directory Recycle Bin are typically high-priority, such as recovery from accidental deletions, for example, resulting in failed logons or work stoppages. But the absence of a rich, graphical user interface complicated its usage and slowed recovery.
To address this challenge, Windows Server 2012 AD DS has a user interface for the Active Directory Recycle Bin that provides the following advantages:
  • Simplifies object recovery through the inclusion of a Deleted Objects node in the Active Directory Administrative Center (ADAC)

    • Deleted objects can now be recovered within the graphical user interface
  • Reduces recovery-time by providing a discoverable, consistent view of deleted object
Requirements
  • Recycle Bin requirements must be met:

    • Windows Server 2008 R2 forest functional level
    • Recycle Bin optional-feature must be enabled
  • Windows Server 2012 Active Directory Administrative Center
  • Objects requiring recovery must have been deleted within Deleted Object Lifetime (DOL)

    • By default, DOL is set to 180 days
For more information about the user interface for AD DS Recycle Bin, see Active Directory Administrative Center Enhancements.
The Fine-Grained Password Policy (FGPP) introduced with Windows Server 2008 provided more precise management of password-policies. In order to leverage the feature, administrators had to manually create password-settings objects (PSOs). It proved difficult to ensure that the manually defined policy-values behaved as desired, which resulted in time-consuming, trial and error administration.
In Windows Server 2012:
  • Creating, editing and assigning PSOs now managed through the Active Directory Administrative Center
  • Greatly simplifies management of password-settings objects
Requirements
  • FGPP requirements must be met:

    • Windows Server® 2008 domain functional level
  • Windows Server 2012 Active Directory Administrative Center
For more information about the user interface for fine-grained password policies, see Active Directory Administrative Center Enhancements.
Administrators require a variety of tools to manage Active Directory’s site topology
  • repadmin
  • ntdsutil
  • Active Directory Sites and Services
The usage of multiple tools results in an inconsistent experience that is difficult to automate.
Using Windows Server 2012 AD DS, administrators can:
  • Manage replication and site-topology with Windows PowerShell

    • Create and manage sites, site-links, site-link bridges, subnets and connections
    • Replicate objects between domain controllers
    • View replication metadata on object attributes
    • View replication failures
  • Take advantage of a consistent and easily scriptable experience
  • Compatible and interoperable with other Windows PowerShell cmdlets
Requirements
  • Active Directory Web Service (also known as Active Directory Management Gateway for Windows Server 2003 or Windows Server 2008)
  • Windows Server 2012 domain controller or Windows Server 2012 with the Role Administration Tools (RSAT) for AD DS and AD LDS installed
For more information about the Windows PowerShell cmdlets to manage Active Directory topology and replication, see Active Directory Replication and Topology Management Using Windows PowerShell.
Today, Volume Licensing for Windows and Office requires Key Management Service (KMS) servers. That solution requires minimal training, and is a turnkey solution that covers about 90% of deployments.
But there is complexity caused by the lack of a graphical administration console. The solution requires RPC traffic on the network, which complicates matters, and it does not support any kind of authentication. The end-user licensing agreement (EULA) prohibits the customer from connecting the KMS server to any external network. For example, connectivity-alone to the service equates to activated.
In Windows Server 2012, the Active Directory-based activation provides the following improvements:
  • Uses your existing Active Directory infrastructure to activate your clients

    • No additional machines required
    • No RPC requirement; uses LDAP exclusively
    • Includes RODCs
  • Beyond installation and service-specific requirements, no data is written back to the directory

    • Activating initial CSVLK (customer-specific volume license key) requires:

      • One-time contact with Microsoft Activation Services over the Internet (identical to retail activation)
      • Key entered using volume activation server role or using command line.
      • Repeat the activation process for additional forests up to 6 times by default
  • Activation-object maintained in configuration partition

    • Represents proof of purchase
    • Computers can be member of any domain in the forest
  • All Windows 8 computers will automatically activate
Requirements
  • Only Windows 8 computers can leverage AD BA
  • KMS and AD BA can coexist

    • You still need KMS if you require down-level volume-licensing
  • Requires Windows Server 2012 Active Directory schema, not Windows Server 2012 domain controllers
For more information about AD BA see the following:
Managed Service Accounts (MSAs) were introduced with Windows Server 2008 R2. Clustered or load-balanced services that needed to share a single security-principal were unsupported. As a result, MSAs were not able to be used in many desirable scenarios.
Windows Server 2012 includes the following changes:
  • Introduces a new security principal type known as a gMSA
  • Services running on multiple hosts can run under the same gMSA account
  • One or more Windows Server 2012 domain controllers required

    • gMSAs can authenticate against any domain controllers that run any version of Windows Server
    • Passwords computed by Group Key Distribution Service (GKDS) running on all Windows Server 2012 domain controllers
  • Windows Server 2012 hosts using gMSAs obtain password and password-updates from GKDS

    • Password retrieval limited to authorized computers
  • Password-change interval defined at gMSA account creation (30 days by default)
  • Like MSAs, gMSAs are supported only by the Windows Service Control Manager (SCM) and IIS application pools
Requirements
  • Windows Server 2012 Active Directory schema updated in forests containing gMSAs
  • One or more Windows Server 2012 domain controllers to provide password computation and retrieval
  • Only services running on Windows Server 2012 can use gMSAs

AD FS v2.0 is able to generate user-claims directly from Windows NT tokens. AD FS v2.0 was also capable of further expanding claims based on attributes in AD DS and other attribute stores.
In Windows Server 2012, Kerberos tickets can be populated with user and device attributes serving as claims. AD FS 2.0 cannot read claims from Kerberos tickets. Therefore, a separate LDAP call to Active Directory must be made to source user-attribute claims, and AD FS 2.0 cannot leverage device-attribute claims at all.
AD FS v2.1 in Windows Server 2012 is able to populate SAML tokens with user- and device-claims taken directly from the Kerberos ticket.
Requirements
  • Dynamic Access Control enabled and configured
  • Compound ID must be switched on for the AD FS service account
  • Windows Server 2012 AD FS v2.1
For detailed information about AD FS in Windows Server 2012, see AD FS.
The following RID improvements in Windows Server 2012 provide greater ability to react to any potential exhaustion of the global RID pool space:
  • Periodic RID consumption warning

    • At 10% of remaining global space, system logs informational event

      • First event at 100,000,000 RIDs used, second event logged at 10% of remainder

        • Remainder = 900,000,000
        • 10% of remainder = 90,000,000
      • Second event logged at 190,000,000

        • Existing RID consumption plus 10% of remainder
    • Events become more frequent as the global space is further depleted
  • RID Manager artificial ceiling protection mechanism

    • A soft ceiling that is 90% of the global RID space and is not configurable
    • The soft ceiling is deemed as ”reached” when a RID pool containing the 90% RID is issued
    • Blocks further allocations of RID pools

      • When the ceiling is reached, system sets msDS-RIDPoolAllocationEnabled attribute of the RID Manager$ object to FALSE. An administrator must set it back to TRUE to override.
    • Log an event indicating that the ceiling is reached

      • An initial warning is logged when the global RID spaces reaches 80%
    • The attribute can only be set to FALSE by the SYSTEM and is mastered by the RID master (for example, write it against the RID master)

      • Domain Admin can set it back to TRUE

        noteNote
        It is set to TRUE by default
  • Increased the global RID space per domain, doubling the number of security principals that can be created throughout the lifetime of a domain from 1 billion to 2 billion.
Requirements
  • Windows Server 2012 RID master
  • Windows Server 2012 Domain Controllers
For more information on RID improvements, see Managing RID Issuance.
In the past, index creation could adversely impact domain controller performance. Windows Server 2012 introduces a new capability that allows forest administrators to defer index creation to a point in time they choose. By default, domain controllers create indices when they receive the appropriate schema change through replication. In Windows Server 2012, a new DSheuristic was introduced to control whether or not domain controllers defer index creation. The details are as follows:
  • Setting the 19th byte to 1 causes any Windows Server 2012 DC (DCs that run earlier operating systems will ignore the setting) to defer building indices until:

    • It receives the UpdateSchemaNow rootDSE mod (triggers rebuild of the schema cache)
    • It is rebooted (which requires that the schema cache be rebuilt and, in turn, the deferred indices)
  • Any attribute that is in a deferred index state will be logged in the Event Log every 24 hours

    • 2944: Index deferred – logged once
    • 2945: Index still pending – logged every 24 hours
    • 1137: Index created – logged once (not a new event)
Requirements
  • Windows Server 2012 domain controllers
Kerberos Constrained Delegation (KCD) was introduced with Windows Server 2003. KCD permits a service’s account (front-end) to act on the behalf of users in multi-tier applications for a limited set of back-end services. For example:
  1. User accesses web site as user1
  2. User requests information from web site (front-end) that requires the web server to query a SQL database (back-end)
  3. Access to this data is authorized according to who accessed the front-end
  4. In this case, the web service must impersonate user1 when making the request to SQL
The front-end needed to be configured with the services (by SPN) to which it can impersonate users. Setup and administration requires Domain Admin credentials. KCD delegation only works for back-end services in the same domain as the front-end service-accounts.
The KCD in Windows Server 2012 moves the authorization decision to the resource-owners, which provides these advantages:
  • Permits back-end to authorize which front-end service-accounts can impersonate users against their resources
  • Supports across-domain, across-forest scenarios
  • No longer requires Domain Admin privileges

    • Requires only administrative permission to the back-end service-account
Requirements
  • Clients run Windows XP or later
  • Client domain’s domain controllers running Windows Server 2003 or later
  • Front-end server running Windows Server 2012
  • One or more domain controllers in front-end domain running Windows Server 2012
  • One or more domain controllers in back-end domain running Windows Server 2012
  • Back-end server account configured with the accounts that are permitted for impersonation

    • Not exposed through Active Directory Administrative Center
    • Configured through Windows PowerShell:

      • New/Set-ADComputer [-name] <string> [-PrincipalsAllowedToDelegateToAccount <ADPrincipal[]>]
      • New/Set-ADServiceAccount [-name] <string> [-PrincipalsAllowedToDelegateToAccount <ADPrincipal[]>]
  • Windows Server 2012 schema update in back-end server’s forest
  • Back-end application server running Windows Server 2003 or later
For more information about Kerberos constrained delegation see the Kerberos section of the technical library.
Today, offline dictionary attack against password-based logons is possible. There is a relatively well-known concern around Kerberos errors being spoofed. Clients may:
  • Fallback to less-secure legacy protocols
  • Weaken their cryptographic key strength and/or ciphers
Kerberos in Windows Server 2012 supports Flexible Authentication Secure Tunneling (FAST)
  • Defined by RFC 6113
  • Sometimes referred to as Kerberos armoring
  • Provides a protected channel between a domain-joined client and DC

    • Protects pre-authentication data for user’s AS_REQs

      • Uses LSK (logon session key) from computer’s TGT as shared secret
      • Note that computer authentication is NOT armored
    • Allows DCs to return authenticated Kerberos errors thereby protecting them from spoofing
  • Once all Kerberos clients and DCs support FAST (the admin’s decision to make)

    • The domain can be configured to either require Kerberos armoring or use it upon request

      • Must first ensure all or enough DCs are running Windows Server 2012
      • Enable the appropriate policy

        • “Support CBAC and Kerberos armoring”
        • “All DCs can support CBAC and Require Kerberos armoring”
Requirements
  • Windows Server 2012 servers
  • Ensure that all domains the client uses including transited referral domains:

    • Enable the “Support CBAC and Kerberos armoring” policy for all Windows Server 2012 DCs
    • Have a sufficient number of Windows Server 2012 DCs to support FAST
  • Enable “Require FAST” policy on supported clients
  • RFC-compliant FAST interoperability requires Windows Server 2012 domain functional level