Modifying filtered attribute set

The Filtered Attribute Set (FAS) is the set of attributes not replicated to an RODC. The default FAS contains the following:
- ms-PKI-DPAPIMasterKeys
- ms-PKI-AccountCredentials
- ms-PKI-RoamingTimeStamp
- ms-FVE-KeyPackage
- ms-FVE-RecoveryPassword
- ms-TPM-OwnerInformation
Items you place in the FAS aren’t replicated, in case the RODC is placed at a lower security site and then compromised. Therefore, you can add items to the FAS so that they aren’t replicated.

Like confidential attributes, the FAS is modified using the ldifde tool. For example, to mark an attribute as being part of the FAS, first view the attribute in ADSI Edit. Figure 5-4 shows the secretary object found at CN=secretary,CN=Schema,CN=Configuration. Notice that the value for SearchFlags is 0x0, meaning that no flags are set for this attribute.

FIGURE 5-4 Viewing the searchFlags to determine if any are now set for this object.

Open a command prompt as Administrator and run the following command, again using secretary as the example and the adventure-works.com domain:
ldifde -d “CN=secretary,CN=Schema,CN=Configuration,DC=adventure-works,DC=com” -f en_ldif -l searchflags

The ldifde command produces a file in the current directory called en_ldif. The contents of that file look like the following:
dn: CN=secretary,CN=Schema,CN=Configuration,DC=adventure-works,DC=com
changetype: add
searchFlags: 0

Edit the file with a text editor such as Notepad. Set the changetype to modify, add the line replace: searchFlags, change the searchFlags value to 512, and add a - at the end. The final result looks like this:
dn: CN=secretary,CN=Schema,CN=Configuration,DC=adventure-works,DC=com
changetype: modify
replace: searchFlags
searchFlags: 512

Save that file as en-confidential.
Now import the file with the following command:
ldifde -i -f en-confidential

Examine the searchFlag value through ADSI Edit again. Notice in Figure 5-5 that the value is now 0x200 (bitwise representation of 512), reflecting the change that you made.

FIGURE 5-5 The object’s searchFlags is now set to 0x200 = (RODC_FILTERED), which indicates that it’s part of the FAS.

Delegating administration

Administration of an RODC can be delegated at the time of installation through a feature called Administrator Role Separation (ARS). Delegation can be done to a user or group. This user has local administrative rights (not Domain Admin rights) to perform administration tasks on the RODC.
RODC delegation can be configured when the domain controller is being configured. Alternatively, delegating administration after installation is accomplished through Active Directory Users and Computers on the Managed By tab of the RODC’s Properties sheet, as shown in Figure 5-3.

FIGURE 5-3 The Managed By tab is used to delegate administration of an RODC.

Implementing confidential attributes

You can mark certain attributes as confidential within a domain. The typical reason for doing so is to prevent unauthorized individuals from seeing the data marked as confidential. To mark an attribute as confidential, you use ADSI Edit and typically the ldifde tool.

-----------------------
NOTE: CONFIDENTIAL ATTRIBUTES
Confidential attributes apply to all domain controllers, including RODCs.

----------------------

Although you can use ADSI Edit to mark an attribute as confidential, the scenario described here illustrates the use of ldifde, which is typically used for bulk or scripted operations. To mark an attribute as confidential, first view the attribute in ADSI Edit. For example, Figure 5-1 shows the documentLocation object found at CN=documentLocation,CN=Schema,CN=Configuration.
Notice that the value for SearchFlags is 0x0, meaning that no flags are set for this attribute.

FIGURE 5-1 The searchFlags attribute is set to 0x0.

Open a command prompt as Administrator and run the following command, again using documentLocation as the example and the adventure-works.com domain:
ldifde -d “CN=documentLocation,CN=Schema,CN=Configuration,DC=adventure-works,DC=com” -f en_ldif -l searchflags
The ldifde command runs and produces a file in the current directory called en_ldif. The contents of that file look like the following:
dn: CN=documentLocation,CN=Schema,CN=Configuration,DC=adventure-works,DC=com
changetype: add
searchFlags: 0
Edit the file with a text editor such as Notepad. Set the changetype to modify, add the line replace: searchFlags, change the searchFlags value to 128, and add a - at the end. The final result looks like this:
dn: CN=documentLocation,CN=Schema,CN=Configuration,DC=adventure-works,DC=com
changetype: modify
replace: searchFlags
searchFlags: 128
-
Save that file as en-confidential.
Now import the file with the following command:
ldifde -i -f en-confidential
After this command completes, examine the searchFlag value through ADSI Edit again. Notice, as shown in Figure 5-2, that the value is now 0x80 (bitwise representation of 128), reflecting the change that you made.

FIGURE 5-2 Marking documentLocation as Confidential, as seen through ADSI Edit.

Understanding branch office infrastructure design considerations

During the design of a branch office infrastructure, your overall goal is to provide reliability for remote locations, regardless of the connectivity status back at the main data center. At the same time, you need to keep the management overhead of additional infrastructure to a minimum.

RODC, global catalog, and UGMC
RODCs are a primary means with which branch offices can achieve the goals of local service and data availability, without the burden of extra administrative overhead. Objective 5.2, "Design a domain controller strategy," discussed several design considerations for both RODC and the global catalog.
In a multi-domain forest scenario, Universal Group Membership Caching (UGMC) prevents additional traffic from crossing the WAN for initial user logon. UGMC is deployed for branch offices in multi-domain forests that don’t have a local global catalog server at the branch office.
If a global catalog server is to be deployed, UGMC isn’t necessary.

DNS and DHCP
Domain Name System (DNS) servers should be placed with a domain controller, even an RODC. So when you deploy a domain controller for a branch office, you should also deploy the DNS service on that domain controller. The benefit of doing so means that the branch office can continue with DNS lookups, even if the link to the data center is unavailable.

For an RODC deployment, you should use primary read-only zone types. The RODC then copies all the application directory partitions, including the domain partition,ForestDNSZones, and DomainDNSZones. If the domain controller at the branch office isn’t an RODC, you can operate the DNS server in caching mode or as a secondary to the main DNS server, with the latter option being more complicated to initially configure.
You can also operate Dynamic Host Configuration Protocol (DHCP) on the same server with Active Directory, although the decision to do so rests largely with the amount of traffic and resource usage already on that  domain controller, as well as the amount of administrative overhead incurred by implementing an additional server to handle DHCP traffic at a branch office. Three deployment options are available for DHCP at a branch office:
- Deployment with Active Directory and DNS
- Deployment with File and Print services
- Deployment with a networking server, such as Internet Security and Acceleration (ISA)

The decision to deploy a DHCP server rests on the need for availability at that location, along with the reliability and overhead for the WAN link between the branch office and the data center—essentially, the same set of decisions that go into deployment of any services for the branch office.

BranchCache
BranchCache helps reduce network traffic over WAN links by locally caching content accessed from the data center or cloud-based content. BranchCache operates in two modes: distributed cache mode disperses cached content among client computers, and hosted cache mode stores the cached content on a server at the branch office. The choice of cache mode becomes a central decision when designing a deployment with BranchCache.

-------------------

Note: You should be familiar with the difference between hosted and distributed modes for the exam, including when to use each.

-------------------

Hosted cache mode has the benefit of increased cache availability because the content cache doesn’t rely on whether a given client is online. With hosted cache mode, content also can be shared on multi-subnet branch offices, a scenario that isn’t possible with distributed cache mode. However, hosted cache mode requires deployment of a server for hosting the cache and therefore incurs additional administrative overhead.

The BranchCache feature needs to be installed on select web and application servers for content to be cached.
Follow these guidelines for determining which mode is appropriate for BranchCache in a given situation. Use distributed cache mode when

- The branch office has fewer than 100 users and has no other servers deployed in the branch.
- The branch office has multiple subnets, each with fewer than 100 users per subnet.

Use hosted cache mode when
- The branch office has more than 100 users, either in a single subnet or multiple subnets.
- The branch office has other servers deployed on which BranchCache can be installed.

Design and implement branch office infrastructure

Branch offices refer to remote locations or even locations managed distinctly from the organization’s main data center and management operations. Branch offices frequently have specific requirements to help them operate smoothly. Therefore, designing a branch office infrastructure is an important task.

Following are points which will discuss in coming sections.

[pt_view id="d79e8670cb"]

Domain controller cloning

Virtual domain controllers have been an available deployment option for quite some time.Windows Server 2012 makes the process of virtual deployment easier by enabling cloning. Deploying a new virtual domain controller with Windows Server 2012 no longer requires the use of sysprep.

Active Directory relies heavily on clock-based replication using an increasing number known as an Update Sequence Number (USN). Each domain controller within an organization has a unique identity known as an InvocationID. Combining the USN and the InvocationID creates an identifier that must be unique across the entire forest.

A new identifier called a VM-GenerationID, a feature added in Windows Server 2012, adds safeguards for virtually deployed domain controllers. The VM-GenerationID is stored in the msDS-GenerationID attribute in the domain controller’s computer object. If a virtual snapshot is used or rolled back, the VM-GenerationID is compared to the original value in the msDS-GenerationID and, if different, the InvocationID is reset.

Virtualized domain controller cloning is helpful for rapidly deploying test environments or deployment to branch offices. Cloning is also helpful for scaling out when resource capacity of the existing domain controllers are reached.

Partial attribute set

As discussed earlier, the global catalog contains a read-only copy of the objects from other domains in the forest. This partial copy includes only a subset of attributes—those commonly used for search operations as well as other required attributes. When considered as a whole, this copy is known as a partial attribute set (PAS), which can be changed to help customize the attributes available for speeding up search operations. When an attribute isn’t found in the local global catalog, the search might be referred to another domain controller.