Examining BitLocker’s Drive Encryption

BitLocker was first introduced with the release of Windows Vista. Since entering the Windows Server 2008 family of operating systems, Microsoft has continued to improve BitLocker by adding new features, for example: support for data volumes, smart card certificates, data recovery agents, USB flash drives, a new RSAT BitLocker interface, and so on.

Understanding Its Benefits
By using BitLocker in conjunction with Windows Server 2008 R2, an organization can enjoy a number of benefits:

. Prevention of unauthorized access to data at rest, which is located on Windows managed system volumes, data volumes, and USB flash drives.

. Support for integrity checking of early boot components using Trusted Platform Module (TPM) to ensure that a machine has not been tampered with and that encrypted materials are located on the original machine.

. Protection against cold boot attacks by requiring an interactive form of authentication (including a PIN or a USB key) in addition to the presence of the TPM hardware before a machine will boot or resume from hibernation.

. Support for escrow of BitLocker recovery materials in Active Directory.

. A streamlined recovery process, which can be delegated to non-Domain Administrators.

. Windows Server 2008 R2 and Windows 7 automatically creates the necessary BitLocker disk partitions during installation.

. Support for BitLocker protection on USB flash drives. This feature is called BitLocker To Go.

. Lastly, support for Data Recovery Agent (DRA) support so that authorized IT administrators will always have access to BitLocker protected volumes.


Understanding TPM
The term Trusted Platform Module (TPM) is used to refer to both the name of a published specification by the Trusted Computing Group for a secure cryptoprocessor and the implementation
of that specification in the form of a TPM chip. A TPM chip’s main purpose in life is the secure generation of cryptographic keys, the protection of those keys, and the ability to act as a hardware pseudo-random number generator. In addition, a TPM chip can also provide remote attestation and sealed storage. Remote attestation is a feature in which a hash key summary is created based on a machine’s current hardware and software configuration. Typically, remote attestation is used by third-party applications such as BitLocker to ensure a machine’s state has not been tampered with. Sealed storage is used to encrypt data such that it may only be decrypted once the TPM chip releases the appropriate decryption key. This release is only done by TPM chip once the required authenticator for that data has been provided. Lastly, a TPM chip can also be used to authenticate hardware devices.

In BitLocker, a TPM chip is used to protect the encryption keys and provide integrity authentication for a trusted boot pathway (that is, BIOS, boot sector, and so on). This type of TPM-supported protection is only performed when BitLocker is in either Transparent Operation mode or User Authentication mode. When in either of these modes, BitLocker uses the TPM chip to detect if there are unauthorized changes to the preboot environment (trusted boot pathway protection) such as the BIOS and MBR. If unauthorized changes were made, BitLocker will then request that a recovery key be provided before the Volume Master Key can be decrypted and bootup of the machine can continue.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Understanding BitLocker Drive Encryption

Microsoft added Windows BitLocker Drive Encryption to Windows Server 2008 mostly as a result of organizations demanding protection not only for their operating systems in remote locations, but also for the vital data stored on the system volume, data volumes, and USB flash drives that were used in these locations. BitLocker Drive Encryption, commonly referred to as just BitLocker, is a software-based Full Disk Encryption (FDE) dataprotection security feature included in all versions of Windows Server 2008 and Windows Server 2008 R2, as well as in the Ultimate and Enterprise Editions of Windows Vista and Windows 7. It is an optional component that must be installed if you choose to use it.

BitLocker increases data at rest protection for an operating system by merging two concepts together: encrypting a volume and guaranteeing the integrity of the operating system’s boot components. The first component, drive encryption, safeguards data residing on the system volume and configured data volumes by preventing unauthorized users from compromising Windows system files encrypted with BitLocker. The second component provides integrity verifications of the early boot components, which essentially refers to components used during the startup process, by validating that the hard disk has not been tampered with or removed from its original server. Equally important, when you use BitLocker, confidential data on a protected server cannot be viewed even if the hard disks are transferred to another operating system. If these two conditions are met, only then will data on a BitLocker volume be accessible and the system allowed to boot.

If you have worked with previous versions of Windows Server, you will recognize immediately that BitLocker is a great addition to Windows Server 2008 R2 as it protects all of the data residing on a server’s hard disks because everything written to the disk including the operating system is encrypted. In previous versions of Windows Server, encryption based on integration with integrity controls was not supported, which meant personal information could be compromised. In addition, with BitLocker now on the map, branch offices concerned over the physical security and theft of their domain controllers stand to benefit the greatest from leveraging BitLocker because this feature further bolsters security and ensures confidential data is not disclosed without authorization.
Many professionals are posing questions as they wonder about the differences between BitLocker and Encrypting File System (EFS). Both technologies offer tools for encryption; however, BitLocker is intended to protect all personal and system files on a system and after it is enabled, it is transparent as well as automatic. EFS, on the other hand, encrypts individual files based on an administrator’s judgment call.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Limitations Associated with Windows Server 2008 R2 RODCs

There are situations when RODCs cannot be used. This is the case with bridgehead servers and operations master role holders. For example, a Windows Server 2008 R2 bridgehead server is responsible for managing Active Directory replication from a physical site. Because an RODC can only perform inbound unidirectional replication, it cannot be designated as a bridgehead server because these servers must support both inbound and outbound replication.

An RODC also cannot function as a Flexible Single Master Operations (FSMO) role holder. Each FSMO role needs to write information to an Active Directory domain controller. As an example, consider extending the Active Directory schema for Microsoft Exchange Server 2007. The new schema extensions would be written on a domain controller to support Exchange 2007. The schema extensions would fail on an RODC because the domain controller is not writable, which, of course, explains why an RODC cannot perform the FSMO role.

To add to its limitations, out-of-the-box RODCs cannot authenticate a smart card logon. This is because the Enterprise Read-Only Domain Controller (ERODC) group is not defined in the domain controller certificate template by default. Because the ERODC is not associated with the default group defined in the template, the RODC is not automatically enrolled in the certificate process, which is a requirement for authenticating smart card logons. Unlike the limitations of RODCs stated in the previous two paragraphs, there is a way to work around this particular drawback so an RODC can authenticate a smart card logon. The following changes must be orchestrated in the certificate templates for an RODC to support smart card logons:

. ERODC group permissions for Enroll must be set to Allow on the Domain Controller certificate template.

. ERODC group permissions for Enroll and Autoenroll must be set to Allow on the Domain Controller Authentication and Directory E-Mail Replication certificate template.

. The Authenticated Users group permissions must be set to Allow Read on the Domain Controller Authentication and Directory E-Mail Replication certificate template.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Examining Prerequisite Tasks When Deploying an RODC

The following bullets list the items you should review and complete before installing RODCs:

. Active Directory running on Windows Server 2003 or Windows Server 2008 R2 must already exist in the environment.

. The Active Directory schema must support the Windows Server 2008 R2 server extensions.

. The forest and domain functional level must be running Windows Server 2003 or higher.

. At least one domain controller within the domain must be running Windows Server 2008 R2.

. The PDC Emulator FSMO role must be running Windows Server 2008 R2.

. A regular non-read-only (writable) domain controller must already exist within the Active Directory infrastructure.

. The RODC cannot be the first domain controller within the Active Directory infrastructure.

. If the DNS service will be configured on a Server Core installation, a non-read-only DNS server must be present within the domain.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Understanding When to Leverage RODCs

As you can see, branch offices were faced with numerous challenges. Because of the many features of RODCs, however, branch offices can now have domain controllers on site without compromising security.

The main benefits of running RODC in branch offices are associated with the following:

. Read-only Active Directory Domain Services
. Reduced replication workload over the network
. Credential caching
. Administrator role separation
. Read-Only DNS
. Read-Only SYSVOL

These features of RODCs, which are discussed in detail in the following sections, assist in alleviating concerns and dilemmas for organizations.


Read-Only Active Directory Domain Services
Poor physical security is typically the most common rationale for deploying an RODC at a branch office. A read-only copy of the domain controller provides fast and reliable authentication, while simultaneously protecting against data loss in the event the server is compromised or stolen. Because no changes can originate from an RODC, a malicious hacker or IT support personnel with little knowledge of Active Directory administration cannot make changes at the branch level. On a writable domain controller, not only can changes be made, but these changes would propagate to all other domain controllers, eventually damaging or polluting the Active Directory domain and forest.


Reduced Replication Workload over the Network
As mentioned earlier, RODCs do not participate in Active Directory replication in the same fashion as writable domain controllers. Replication with RODC is one-way, meaning all changes from a writable domain controller are propagated to the RODC. An RODC receives changes, but does not partake in or perform any outbound replication to other domain controllers. This results in the replication workload being minimized over the network because changes do not have to be pulled from an RODC and because Active Directory replication is unidirectional. Also reduced is the amount of time required to monitor replication, which is another plus for having an RODC.


Credential Caching
Credential caching with an RODC provides numerous security enhancements for a domain controller residing at a branch office. Take, for example, a new functionality in RODCs that increases security in the event an RODC is stolen. When replication transpires between a writable domain controller and an RODC, only a user’s account information is replicated—not the user’s password. Equally important, passwords are not stored on an RODC. In the event the RODC is stolen, the only accounts that can be hacked and compromised are the local administrator accounts and the RODC account, which is specific to the RODC server. These accounts are not considered to be highly privileged, nor do they have access authorization on the forest and domain. On the other hand, traditional writable domain controllers store both the user’s account information and password on a domain controller, ultimately leaving users very vulnerable.

Because an RODC by default does not store user accounts or passwords locally, branch office users must authenticate against a writable domain controller in a hub site. This is often not practical for branch office users, especially if the WAN link between the sites is slow or unavailable. In this case, it is possible to configure password replication caching for specific branch office users on the branch office RODC. After the credentials are cached on the RODC, the domain controller will service users the next time they try to log on and every other time after that until the credentials change. Typically, a branch office only has a few users, so only a subset of an organization’s users’ accounts are cached on the RODC at the branch office, limiting the exposure of credentials in the event of a system breach.

To provide an additional level of security and at the same time reduce the amount of information exposed in the event an RODC is stolen, a domain administrator can use tools within Active Directory Users and Computers to delete the RODC from the Active Directory domain/forest and reset the passwords for user accounts cached on the RODC.


Administrator Role Separation
Organizations are encouraged to use RODCs when there is a need to satisfy unique administrative requirements and to maintain administrator role separation and isolation. The use of an RODC is especially encouraged if the domain controller situated in a branch office hosts more than one server function or server role, such as a print server, messaging server, file server, and much more. The use of an RODC is also recommended when there are other applications installed on the domain controller. Traditionally, in this situation the administrator of these applications has privileges not only to the applications, but also to the entire Active Directory, which can pose a threat. With RODC, however, you can delegate permissions to local administrators, granting them rights to a particular server, roles, or LOB applications without ever granting them access to Active Directory or
domain resources beyond the scope of the branch. As a result, the local administrator at the branch can perform his or her administrator work activities effectively without compromising the entire Active Directory environment.


Read-Only DNS
When using RODCs, it is possible to add the DNS role/service to the RODC. After the DNS service is added to an RODC, the RODC will replicate Active Directory–integrated DNS information such as DNS-related AD partitions, including both the ForestDNS and DomainDNS zones.

Running DNS on an RODC is very similar to running DNS on a writable domain controller. Users can query the local DNS server residing on the branch office RODC for A records and other DNS-related items such as Internet requests. However, unlike traditional writable domain controllers, DNS on RODC does not support dynamic updates. The DNS zone information is entirely read-only.

If a client wants to update their DNS A or PTR record in the local branch office, the RODC will send a DNS replicate-single-object change request to a writable domain controller running the traditional DNS service. The DNS change for the client will occur on the writable DNS server and, eventually, the change will be propagated back to the RODC via unidirectional Active Directory replication.


Read-Only SYSVOL
In Windows Server 2008, it was still possible for changes to be made to the sysvol folder of an RODC. When changes were made to the contents of the sysvol folder, those changes persisted until being overwritten by the next DFS Replication cycle. In Windows Server 2008 R2, Microsoft made changes to the RODC functionality such that the sysvol folder is now read-only on an RODC.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Organizations’ Branch Office Concerns and Dilemmas

The next section illustrates typical branch office concerns about having domain controllers onsite. This section makes it evident why the RODC is becoming popular if not extremely necessary for branch offices.

Lack of Physical Security at the Branch Office
Typically, branch office locations do not have the facilities to host a data center. For that reason, it is common to find domain controllers hiding in closets, tucked away in the kitchen next to the fridge, or even in a restroom. As such, branch offices lack physical security when it comes to storing domain controllers, which results in these servers being prime targets for thieves.

Domain Controllers Stolen from the Branch Office
With inadequate physical security in the branch offices, it was very common for domain controllers to be stolen. This posed a major security threat to organizations because domain controllers contain a copy of all the user accounts associated with the domain. Confidential items such as highly privileged administrator accounts, DNS records, and the Active Directory schema could fall into the hands of the wrong people in this situation.

Removing Domain Controllers from the Branch Office
Because of a lack of physical security and concerns over domain controller theft, branch offices often had their domain controllers removed from their site. After being removed, users were forced to authenticate over the WAN to a domain controller residing at their corporate headquarters or to the closest hub site. Although this action solved the security issue, it also cultivated a new problem. If the WAN link between the branch office and hub site was unreliable or unavailable, users could not log on to the workstations at the branch office or the amount of time required to log on was greatly increased. This resulted in a loss of productivity for users in the branch office or outages that resulted in downtime if the WAN link was severed. These types of outages commonly lasted for days.

Lack of Administration Role Separation at the Branch Office
In small branch offices, it is also very common for multiple server functions to be hosted on a single server to reduce costs. For example, a single server might provide domain controller, file, print, messaging, and other line-of-business (LOB) functionality. In such cases, it is necessary for the administrators of these applications to log on to the system to manage their applications. By granting administrators privileges to the domain controller, these individuals also received full access to the Active Directory domain, which is considered to be a major security risk.

Lack of IT Support Personnel at the Branch Office
It is very common for secretaries, receptionists, or even high-level personnel such as managers and directors without any prior knowledge of IT management or maintenance to manage servers in a branch office. Typically, these individuals get nominated or promoted to a branch office IT support role because a local IT administrator does not exist. Unfortunately, even when conducting basic administration tasks like restarting an unresponsive server, these individuals can inadvertently wreak havoc on the Active Directory domain when granted administrator privileges on a domain controller. In a Windows Server 2003 environment, there was little that could be done about this situation. You just had to be careful about who you promoted to the exclusive club of domain administrators.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Understanding Read-Only Domain Controllers (RODCs)

One of the new features that received close attention in Windows Server 2008 was a new breed of domain controllers referred to as Read-Only Domain Controllers, also known as RODCs. The RODC hosts a copy of the Active Directory (AD) database like any other writable domain controller, but as its name implies, the contents replica of the domain database residing on the domain controller is read-only and write operations are not supported. It is equally important to mention that the RODCs do not participate in Active Directory replication in the same fashion as writable domain controllers. The fundamental difference between RODC replication and the typical multimaster replication model between writable domain controllers is that RODC replication is unidirectional. This means all changes from a writable domain controller are propagated to the RODCs. As a result, the RODC receives changes, but does not partake in or perform outbound replication with other domain controllers. This characteristic of RODCs provides an extra layer of security as any unauthorized data changes, especially changes made with the intent to hurt the organization, will not replicate out to other domain controllers. Unidirectional replication also reduces the workload of bridgehead servers in the hub site and the effort required to monitor replication.

Another new RODC functionality that improves security is commonly witnessed when replication transpires between a writable domain controller and an RODC. Here, user account information is replicated, but account passwords are not replicated. This is a new phenomenon because of the existence of Windows domain controllers. Security is bolstered in this situation as the only password that resides on the RODC is the local administrator’s password and Krbtgt accounts (the account used for Kerberos authentication). In essence, the read-only philosophy of an RODC is similar to the NT 4.0 Backup Domain Controller (BDC); however, with the NT 4.0 BDC, all user information is replicated from the Primary Domain Controller (PDC), including passwords. Although Microsoft fields numerous questions on this new Active Directory technology, the question that is asked the most is where does the RODC fit in? RODCs are most often used to provide Active Directory Domain Services (AD DS) to remote locations and branch offices where heightened security is essential, where Windows Active Directory administrators are lacking, and where the promise of physical security is practically nonexistent. In many cases, RODCs offer a practical headache-free solution for branch office environments that in the past had to endure solutions that always put them in compromising
situations. If needed, it is also possible to configure credential caching of passwords for a specific user account to an RODC. Moreover, by default, security groups with high privileges such as Domain Administrators and Enterprise Administrators are configured to never allow their passwords to replicate to RODCs.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Optimizing Windows Server 2008 R2 for Branch Office Communications

Today’s organizations are likely to consist of many branch offices. On average, a branch office is a small office hosting fewer than 50 employees in a remote location. Typically, a branch office infrastructure is connected to the headquarters site, centralized data center, or hub site by means of a wide area network (WAN) link in a distributed fashion. Due to the high costs associated with purchasing bandwidth, these WAN links are usually slow, unreliable, and inefficient. Finally, most branch offices lack physical security and IT support personnel.
For many organizations, maintaining branch offices generates significant operational costs and administrative challenges. Two scenarios exist when dealing with branch offices because of the high costs of securing high-speed links between the branch office and hub site. Either the organization implements server infrastructure at the branch office or IT services are provided to the branch office from a centralized site such as the company headquarters.

By providing branch offices with their own infrastructure productivity increases; however, operational and management costs typically rise. When providing services to a branch office from a centralized site, its productivity is reduced as all branch office users must obtain services over a slow and unreliable WAN link. In addition, if the WAN link becomes unavailable, productivity at the branch office can come to a halt until the WAN link is repaired. As you can see, each scenario has cost and efficiency trade-offs.

Challenges like the one just described might, however, become a thing of the past for branch offices. Windows Server 2008 R2 provides new technology solutions that allow organizations to integrate branch offices seamlessly into the organization’s infrastructure.

Source of Information : Sams - Windows Server 2008 R2 Unleashed

Cloud storage is for blocks too, not just files

One of the misconceptions about cloud storage is that it is only useful for storing files. This assumption comes from the popularity of file...