Exam Ref 70-414 Implementing an Advanced Server Infrastructure (2014)
Chapter 4. Design and implement identity and access solutions
The previous chapters looked at various aspects of maintaining an advanced server infrastructure for today’s enterprise environment. Chapter 4 addresses enterprise needs related to security certificates, rights management, and other related aspects. Though the objectives are heavily weighted toward certificate infrastructure and Active Directory, you should also be familiar with basic concepts of least privilege and the three basic tenets of security: confidentiality, integrity, and availability.
Objectives in this chapter:
Objective 4.1: Design a Certificate Services infrastructure
Objective 4.2: Implement and manage a Certificate Services infrastructure
Objective 4.3: Implement and manage certificates
Objective 4.4: Design and implement a federated identity solution
Objective 4.5: Design and implement Active Directory Rights Management Services (AD RMS)
Objective 4.1: Design a Certificate Services infrastructure
The first set of objectives looks at design of certificate services. The next section, Objective 4.2, looks at implementation related to the design discussion in this section.
This objective covers how to:
Design a multi-tier certification authority (CA) hierarchy with offline root CA
Plan for multi-forest CA deployment
Plan for Certificate Enrollment Web Services and Certificate Enrollment Policy Web Services
Plan for Network Device Enrollment Services (NDES)
Plan for certificate validation and revocation
Plan for disaster recovery
Plan for trust between organizations, including Certificate Trust Lists (CTL), cross-certifications, and bridge CAs
Designing a multi-tier certification authority hierarchy
The first objective in this chapter examines planning and design issues while the second looks at many of the same topics from a management standpoint. When designing a Certificate Services infrastructure, the first task is to determine the requirements. This includes where the certificates will be used, specifically the CA hierarchy involved in deployment and certificate validation. For example, in a typical web scenario, validation occurs first at the client browser, even though the certificate itself is deployed on the web server and the root CA is on another server as well. Including and planning for failover is also important with Certificate Services, so examining single points of failure in the hierarchy is essential to a design.
At the top of a multi-tier CA hierarchy is the root certification authority. A single root CA can be used, but multiple root CAs might be needed for regulatory or other reasons, such as a need for the root CA to be physically hosted in a certain geographical location. There are three types of root CAs, as described in Table 4-1.
TABLE 4-1 Root CA types
There are two tiers involved in a typical CA hierarchy, the root tier and the issuing tier, as shown in Figure 4-1.
FIGURE 4-1 Multi-tier CA hierarchy
The first or highest tier of the CA hierarchy is the root tier. A standalone root CA can be operated in offline mode and should exist at the top of the hierarchy. With an offline CA, you need to include a subordinate CA that is online. A subordinate CA is any CA that’s not the root CA, which includes CAs that issue certificates or ones that exist to enforce policy.
Note: Standalone Root CA
Standalone root CAs support subordinate CAs that are either enterprise or standalone.
The next tier in a CA hierarchy, called the issuing tier, is where CAs that can issue certificates exist. The issuing CAs handle enrollment, validation, and revocation of certificates. When using a root CA in offline mode, there should be at least two issuing CAs in the intermediate tier. You can add more issuing CAs to the design if necessary to account for remote sites and fault tolerance.
An intermediate tier is sometimes included between the root and issuing tiers for management purposes, but its use is typically not recommended. A scenario where this tier might be used is for legal or political reasons, such as when companies merge. This tier is sometimes known as a policy tier because it’s where those business policies are enforced. While the tier isn’t required for technical reasons, the policy might dictate that such a tier is created. See the More Info link for additional details.
More Info: Certificate Services Design
See the Active Directory Certificate Services guide at http://technet.microsoft.com/en-us/solutionaccelerators/ee395428 for more information on Active Directory Certificate Services design.
Planning for multi-forest CA deployment and trust between organizations
Using a multi-forest CA deployment can reduce management and administration overhead that would otherwise occur if each forest managed its own CA independently. When planning a multi-forest CA deployment, one forest will be the resource forest and other forests will be account forests. The resource forest hosts the enterprise CAs and is used for certificate enrollment for the entire organization. The resource forest becomes the master copy for all certificate-related objects. Account forests include domain members that perform certificate enrollment from the resource forest.
Thinking back to the tiers in Figure 4-1, the root tier exists logically outside of the multi-forest deployment, and the issuing tier logically includes the resource forest, which is then responsible for certificate-related management to other forests through a two-way trust. Another option is to include an enterprise CA in each forest, which requires no forest trust between forests. In this scenario, the enterprise CA in each forest works directly with the root CA. Finally, Certificate Enrollment Web Services can also be used to provide certificates between forests without a trust relationship. The next section includes a discussion of the planning steps around Certificate Enrollment Web Services.
An organization might have one or more self-signed certificates issued by internal CAs. Certificate Trust Lists (CTLs) are lists of certificates for these internal CAs. Using a CTL enables trust to be established, especially in multi-forest scenarios, because the internal CA certificate can be trusted. CTLs can also have different lifetimes than the underlying certificate, thereby enabling you to have greater control over the trust. See http://technet.microsoft.com/en-us/library/dn265983.aspx for more information on trusted root certificates as it relates to CTLs.
Cross-certification and bridge CAs are useful for migration scenarios where you need to establish a new CA, for example on Windows Server 2012, but your existing CA runs Windows Server 2003. In such a case, you can cross-certify the new CA by using a Cross-Certification Authority Certificate.
Planning for Certificate Enrollment Web Services
Certificate Enrollment Web Services enable certificate enrollment between forests and certificate issuance to external entities, such as contractors. Certificate Enrollment Web Services can be used regardless of domain trusts and in scenarios where certificate enrollment is needed by nondomain devices.
The Certificate Enrollment Web Services server needs to be a member of the domain and should be running at least Windows Server 2008 R2, though Windows Server 2012 is required if automatic renewal of certificates will be used across forests or for nondomain members.
Note: Enterprise CA Required
Certificate Enrollment Web Services requires an enterprise CA and cannot be used with a standalone CA.
The section titled “Implement and manage a Certificate Services infrastructure” discusses Certificate Enrollment Web Services in more depth, with a specific focus on configuration and management.
More Info: Certificate Enrollment Web Services
See http://social.technet.microsoft.com/wiki/contents/articles/7734.certificate-enrollment-web-services-in-active-directory-certificate-services.aspx for more information on Certificate Enrollment Web Services.
Planning for Network Device Enrollment Services (NDES)
Network Device Enrollment Services (NDES) provides a means by which network devices such as routers can obtain certificates even if those devices aren’t part of the domain. NDES uses the Simple Certificate Enrollment Protocol (SCEP). NDES acts as an intermediary by sending enrollment requests to the CA and then retrieving the certificate and sending it back to the requesting network device.
NDES is an Internet Server API (ISAPI) extension and therefore requires a server with IIS. The server works with a CA through DCOM, so that communication will need to be allowed through any firewalls that sit between the NDES server and the server hosting the CA.
You can configure NDES with an enterprise or standalone CA. When configured in an enterprise scenario, the permissions and certificate requests are based on certificate templates. NDES can also be used with a standalone CA. When deploying with an enterprise CA, the server hosting NDES and the server hosting the CA should be separate, whereas when using a standalone CA, the NDES should be on the same server.
More Info: NDES
See http://social.technet.microsoft.com/wiki/contents/articles/9063.network-device-enrollment-service-ndes-in-active-directory-certificate-services-ad-cs.aspx for more information about NDES in AD CS.
Planning for certificate validation and revocation
Clients need to validate a certificate both for its expiration and its overall chain of trust. You might need to revoke a certificate for various reasons, including compromise of the chain of trust for certificates or a change that affects the certificate, such as a name change or an organizational change.
Certificate revocation uses Certificate Revocation Lists (CRLs). CRLs contain a list of certificates that are no longer valid, and the CRL can become large. To solve this, you can use a delta CRL that contains changes or new revocations.
Note: Online Responders
Another method for achieving this functionality is with an online responder. Online responders are discussed later in this chapter.
CRLs are sent through CRL distribution points, which are part of a CA role in Windows Server 2012. When designing a CRL distribution point, you can optionally use HTTP, FTP, LDAP, or file-based addresses as URLs. You should take care in doing so, however, because any change in the CRL URL will be seen only by newly issued certificates; old certificates will use the old URL for revocation list operations.
Another planning point is around the validity period and publishing intervals for CRLs. You can configure the interval between publication of a revocation list or delta list as well as the period in which the CRL is valid. As discussed in the next section, the interval and validity periods have implications for disaster recovery.
More Info: CRL
See http://technet.microsoft.com/en-us/library/cc771079.aspx for information on configuring certificate revocation.
Planning for disaster recovery
Planning for disaster recovery of a CA involves many of the same steps and thought processes that go into planning redundancy and fault tolerance in other areas. For example, eliminating single points that cannot be restored is a goal in any disaster recovery scenario, as is mitigating risks of failure as much as feasible.
Mitigating with CAs in mind means installing clustered issuing CAs. Beyond that, the publication interval for the CRL can also be increased, though doing so also increases the time it takes for clients to become aware of a new revocation.
Planning for backups, including backup of the CA database, is important for disaster recovery. System state should be included in a backup for a CA.
More Info: Disaster Recovery
See http://blogs.technet.com/b/askds/archive/2011/04/07/designing-and-implementing-a-pki-part-v-disaster-recovery.aspx for additional information on disaster recovery and a certificate infrastructure.
Thought experiment: Certificate infrastructure design
You need to design a certificate infrastructure that spans three entities within the same organization. There is one major data center and a small infrastructure at each location. The entities would like to manage their own CAs.
Describe the infrastructure considerations that go into this design.
You can find the solution in the “Answers” section at the end of this chapter.
Objective summary
Certificate infrastructure in a multi-tier environment involves a root CA tier along with an issuing tier that contains issuing CAs, and optionally an intermediate tier between the root and issuing tiers.
Multi-forest CA deployment involves establishing a method so that clients in different forests can trust a CA from a different forest.
Certificate Enrollment Web Services provide a means for external multi-forest CA deployment.
Certificate validation and revocation is handled through CRLs.
NDES can be configured with an enterprise or standalone CA.
Disaster recovery of certificate infrastructure involves configuring the validity period, performing backups, and performing many of the other steps that are taken for disaster recovery planning of other services.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. Which type of CA can be operated in offline mode?
A. Enterprise
B. Standalone
C. Offline
D. On/off
2. Which period defines the amount of time that a CRL can be used?
A. Publishing interval
B. Validation
C. Validity
D. Revocation interval
3. When using NDES, which type of CA should be installed on the same server?
A. Standalone
B. Enterprise
C. Multi-forest
D. CA trust
Objective 4.2: Implement and manage a Certificate Services infrastructure
The certificate infrastructure design accomplished in Objective 4.1 will now be implemented through the tasks related to Objective 4.2. This section looks at configuring several of the items previously discussed and a few new areas as well.
This objective covers how to:
Configure and manage offline root CA
Configure and manage Certificate Enrollment Web Services and Certificate Enrollment Policy Web Services
Configure and manage NDES
Configure Online Certificate Status Protocol (OCSP) responders
Migrate CA
Implement administrator role separation
Implement and manage trust between organizations, including CTLs, cross-certifications, and bridge CAs
Monitor CA health
Configuring and managing offline root CA
Active Directory Certificate Services is installed as a role on Windows Server 2012. Within the role are several role services, one of which is a certification authority, as shown in Figure 4-2.
FIGURE 4-2 Installing the Certification Authority role service
Once the CA role has been installed, configuration is required. The configuration steps include specifying the role services, the setup type (standalone or enterprise), the private key, and other details. The Standalone CA option should be chosen for an offline root CA, as shown in Figure 4-3.
FIGURE 4-3 Choosing the Standalone CA option
The CA type is next, within which the Root CA option should be chosen, as shown in Figure 4-4.
FIGURE 4-4 Selecting a Root CA type
The next page enables you to choose whether a new private key should be created or an existing private key should be used, as shown in Figure 4-5.
FIGURE 4-5 Choosing the key type for a CA installation
When creating a new private key, you can choose the cryptography type, the CA name, and the validity period. Once the details of the private key are specified, you next choose the location for the certificate database, as shown in Figure 4-6.
FIGURE 4-6 Choosing a location for the certificate database
More Info: CA Configuration
See http://technet.microsoft.com/en-us/library/cc731183.aspx for more details on CA configuration, including an overview of CA naming.
Once configured, the Certification Authority tool is used to manage a CA. One of the configuration items to verify with a root CA is the policy regarding request handling, to ensure that certificate requests are set to pending by the root CA. This is accomplished on the Policy Module tab of the Properties dialog for the CA. On the Policy Module tab, clicking Edit reveals the properties for Request Handling, as shown in Figure 4-7.
FIGURE 4-7 Ensuring that the request-handling mode is set to pending
The CRL distribution point should be configured for your CA as well. This is accomplished by selecting the CRL Distribution Point (CDP) extension from the Extensions tab, as shown in Figure 4-8. The CDP should be set to a location from which clients can obtain the CRL.
FIGURE 4-8 Configuring the CRL distribution point
From here, another configuration item includes publishing the CRL to the shared URL that you created previously. This can be accomplished by choosing Publish from the Revoked Certificates action items or by using the certutil -CRL command.
Taking the CA offline can be accomplished in one of several ways, including powering down the host, disconnecting the network cable, or simply stopping the CA service.
More Info: Offline Root CA
See http://social.technet.microsoft.com/wiki/contents/articles/2900.offline-root-certification-authority-ca.aspx for additional details on creating an offline CA.
Configuring and managing Certificate Enrollment Web Services and Certificate Enrollment Policy Web Services
Certificate Enrollment Web Services (CES) and Certificate Enrollment Policy Web Services are added as service roles of the Active Directory Certificate Services role in Windows Server 2012 R2. Once installed, configuration steps are required for each role service.
In the case of CES, configuration items include choosing a computer or CA name for the CA, as shown in Figure 4-9. On this same screen, you can also configure Certificate Enrollment Web Services to operate in renewal-only mode.
FIGURE 4-9 Configuring Certificate Enrollment Web Services
The CES authentication type is configured next from among the options:
Windows integration authentication
Client certificate authentication
User name and password
Finally, the service account is configured, as shown in Figure 4-10.
FIGURE 4-10 Specifying a service account
More Info: CES
See http://technet.microsoft.com/en-us/library/hh831822.aspx for additional configuration options and http://social.technet.microsoft.com/wiki/contents/articles/7734.certificate-enrollment-web-services-in-active-directory-certificate-services.aspx for an overview of CES.
Configuration of Certificate Enrollment Policy Web Services (CEP) is accomplished in the same manner as that of CES. When configuring CEP, you first choose the authentication type (Windows Integrated, Client Certificate, or User Name and Password), as shown in Figure 4-11.
FIGURE 4-11 Choosing the CEP authentication type
Next, the certificate to be used for client communication is chosen. If a certificate isn’t available, this choice can be skipped for now and configured later. Figure 4-12 shows this part of the wizard.
FIGURE 4-12 Choosing the certificate for CEP
Group Policy also needs to be configured so that clients use the CEP server. A new Group Policy Object (GPO) needs to be created in the domain to distribute certificates. CEP can distribute both computer and user certificates. Therefore, the location for the new GPO object will depend on whether you want to distribute computer certificates, user certificates, or both. In either case, the Configuration Model setting of the Certificate Services Client - Certificate Enrollment Policy object needs to be enabled and the policy server URI entered. The authentication type should match what was configured for the CEP server.
More Info: CEP
See http://technet.microsoft.com/en-us/library/hh831625.aspx for more details on configuring CEP.
Configuring and managing Network Device Enrollment Services (NDES)
Configuring NDES follows the same overall process as configuring other role services in that it’s installed as a role service, a service account is specified, and then a CA for the service is specified. NDES requires a registration authority (RA), and the information is specified during configuration time, as shown in Figure 4-13.
FIGURE 4-13 Providing RA details for NDES
Cryptographic service providers (CSPs) are specified for NDES, as shown in Figure 4-14.
FIGURE 4-14 Configuring CSPs for NDES
NDES operates using service certificates. The CEP Encryption template provides the base for NDES. Objective 4.3, “Implement and manage certificates,” later in this chapter contains information on creating certificate templates.
More Info: NDES
See http://social.technet.microsoft.com/wiki/contents/articles/9063.network-device-enrollment-service-ndes-in-active-directory-certificate-services-ad-cs.aspx for additional information on NDES.
Configuring Online Certificate Status Protocol (OCSP) responders
Online Certificate Status Protocol (OCSP) is implemented through the Online Responder service in Windows Server 2012. Unlike other role services, OCSP doesn’t require much specific configuration through the Add Role Services Wizard.
The OCSP service requires a template for use with a revocation configuration. Creating the template is accomplished with the following steps:
1. In the Certification Authority tool on the CA, choose Certificate Templates, right-click, and select Manage. Doing so opens the Certificate Templates Console.
2. In the Certificate Templates Console, select OCSP Response Signing, then right-click and select Duplicate Template. Doing so will create a copy of the OCSP template that can be used by the OCSP service.
3. If you’ll use the Auto-Enroll function for the OCSP, then you need to use the Security tab to add the Enroll permission for the computer object on which the OCSP service is running.
4. With the duplicate template created and (optionally) the Enroll permission added, close the Certificate Templates Console.
5. In the Certification Authority tool, right-click Certificate Templates and select Certificate Template To Issue from the New context menu.
6. Select the OCSP template that you created previously. The OCSP template will now be available for use.
The “Managing certificate templates” section of the next objective contains more details on certificate templates.
The Online Responder Manager is used to manage the online responder configuration. Within the manager you can add a revocation configuration. Doing so reveals the Add Revocation Configuration Wizard. Within the Add Revocation Configuration Wizard, you enter a name and then select the location of the CA to associate with the revocation configuration, as shown in Figure 4-15.
FIGURE 4-15 Selecting the certificate for the revocation configuration
Next, choose the CA certificate. You can auto-enroll using the certificate template created earlier, as shown in Figure 4-16.
FIGURE 4-16 Choosing a signing certificate
The Revocation Provider Properties dialog box, shown in Figure 4-17, can be used to change details of the revocation for the configuration.
FIGURE 4-17 Configuring revocation provider details
Note: Configuration Items in the Registry
The online responder has certain configuration items within the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OCSPSvc\Responder.
CAs need to be made aware of the OSCP responder. This is accomplished within the Certification Authority console on each CA (not the server hosting OCSP). Within the Extensions tab of the CA Properties dialog, choosing the Authority Information Access (AIA) extension and then selecting Add enables the OSCP responder URL to be added. The Include In The Online Certificate Status Protocol (OCSP) Extension option should be checked, as shown in Figure 4-18.
FIGURE 4-18 Configuring the OCSP server on a CA
More Info: OCSP
See http://technet.microsoft.com/en-us/library/cc770413 for more information on OCSP.
Migrating the CA
Migrating the CA to a different server can involve various steps, depending on your configuration and migration needs. The basic steps include those described in Table 4-2.
TABLE 4-2 CA migration
More Info: Migrate a CA
See http://technet.microsoft.com/en-us/library/ee126140 for additional details on the steps discussed in Table 4-2.
Implementing administrator role separation
Several roles can be used to administer a certificate infrastructure, as discussed in Table 4-3.
TABLE 4-3 Certificate management roles
By default, the CA roles (CA administrator and Certificate manager) are granted to the local Administrators group as well as Enterprise Admins and Domain Admins as appropriate. However, on a standalone CA, only local Administrators are members of the CA administrators group, unless the standalone CA is joined to a domain, in which case Domain Admins are also CA administrators.
Numerous permissions can be assigned to implement further role separation. These are listed in Table 4-4, along with the specific roles to which they are assigned by default.
TABLE 4-4 Permissions and roles for a CA
Implementing administrator role separation involves assigning these permissions or using available groups to separate the tasks that a given user can perform. This is typically accomplished through the standard Active Directory Users and Computers tool within a domain environment. A best practice surrounding role-based administration for certificate infrastructure is to ensure that accounts are not members of both the local Administrators group and the CA administrator or Certificate manager group.
Implementing and managing trust between organizations
Cross-forest trust for certificates involves creating a trust between the two forests involved. Prior to that, a resource forest needs to be designated, as discussed in the first exam objective in this chapter.
The next step after designating a resource forest is to establish trust between the forests. A trust is created in Active Directory Domains and Trusts by choosing the domain to be trusted and then going into the Properties of the domain to be trusted and selecting New Trust from the Trusts tab. Doing so reveals the New Trust Wizard. In the New Trust Wizard, enter the name of the domain to be trusted, as shown in Figure 4-19.
FIGURE 4-19 Entering the domain to be trusted in the New Trust Wizard
The remaining screens define the type, direction, and sides of the trust. The trust type should be selected as a Forest Trust, the direction should be Two-Way, and the sides should be Both This Domain And The Specified Domain option. You’ll also be prompted for credentials that have administrative privileges in the external domain.
The scope of authentication is chosen next, with forest-wide allowing all authentication and selective authentication meaning that you need to grant access to resources individually. If the Selective Authentication option is chosen, then the Allow authenticate permission needs to be granted to various objects in both forests. Specifically, domain member computers in account forests need to be granted the Allow authenticate permission to enterprise CAs in the resource forest. Enterprise CAs need to be granted the Allow authenticate permission on domain controllers in account forests. Finally, administrators need the Allow authenticate permission to all domain controllers in all forests.
More Info: Two-Way Trusts
See http://technet.microsoft.com/en-us/library/cc778851 for information on creating a two-way trust.
The next several steps to establish CA trust are as follows:
1. Enable LDAP referrals on enterprise CAs with the command:
certutil -setreg Policy\EditFlags +EDIT_ENABLELDAPREFERRALS
2. Add enterprise CA computer accounts to the Cert Publishers group in the account forest.
3. Set the AIA and CRL distribution points within each enterprise CA or certificate template as necessary.
4. Publish the root CA certificate from the resource forest into the account forests using the commands:
certutil -config <Computer Name> | <Root CA Name> -ca.cert <root CA
certificate file>
certutil -dspublish -f <root CA certificate file>
5. Publish enterprise CA certificates into the account forests. Specifically, publish the certificates into the NTAuthCertificates and AIA containers using the commands:
certutil -config <Computer Name> | <Enterprise CA Name> -ca.cert <enterprise
CA certificate file>
certutil -dspublish -f <enterprise CA certificate file> NTAuthCA
certutil -dspublish -f <enterprise CA certificate file> SubCA
More Info: Cross-Forest Certificate Enrollment
See http://technet.microsoft.com/en-us/library/ff955845 for more information on creating certificate enrollment between forests.
CTLs can be created as part of Group Policy. Within the Group Policy Management Editor, selecting Computer Configuration, Policies, Windows Settings, Public Key Policies, and then Enterprise Trust enables a right-click context action to create a new Certificate Trust List. This invokes the Certificate Trust List Wizard, within which you can select parameters for the CTL, such as those shown in Figure 4-20. In Figure 4-20, a one-month duration has been selected, and the certificates found in the CTL will be valid for server authentication.
FIGURE 4-20 Choosing parameters for a CTL
The certificate or certificates to be included in the CTL are chosen next, as shown in Figure 4-21.
FIGURE 4-21 Choosing certificates for a CTL
More Info: Cross-Certification and Bridge CA
See http://technet.microsoft.com/en-us/library/cc759308 for information on cross-certification and bridge CA.
Monitoring CA health
Monitoring CA health can be accomplished with the Active Directory Certificate Services Monitoring Management Pack available for System Center Operations Manager. The management pack can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=34765 and then imported into Operations Manager, as shown in Figure 4-22. Once imported, the management pack provides service monitoring and can also monitor for various events.
FIGURE 4-22 Importing certificate-related management packs into Operations Manager
Another option for monitoring an enterprise certificate infrastructure is pkiview, shown in Figure 4-23. As you can see from Figure 4-23, there’s an issue with the OCSP location. Accessible from the command prompt by typing pkiview, or as an MMC snap-in, pkiview monitors the health of CAs. The hierarchy of the certificate infrastructure is available through pkiview. You can view the health of certificates and various CA-related endpoints, such as CRL distribution points, using pkiview.
FIGURE 4-23 Viewing certificate server status with pkiview
Thought experiment: Configuring a root CA
In this thought experiment, apply what you’ve learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter.
You’re assisting with the implementation of a certificate services infrastructure for a small organization. The design that’s been chosen includes a root CA and a single subordinate enterprise CA. Your task is to install the root CA portion.
Discuss the configuration involved in a root CA.
Objective summary
Offline root CA needs to be created as a standalone-type CA.
Certificate Enrollment Web Services and Network Device Enrollment Services are both configured as role services within a certificate infrastructure.
When migrating a CA, create backups of the database, log, registry, and other CA-related settings.
When creating a trust for certificate infrastructure, a two-way forest trust should be created between the resource and account forest.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. Which permission needs to be granted to various objects when choosing Selective Authentication for a forest trust?
A. Allow Authenticate
B. Allow Enroll
C. Enterprise CA
D. Certification Admin
2. Which role has the Install A CA permission by default?
A. CA administrator
B. Auditor
C. Enterprise PKI
D. Local administrator
3. When configuring an offline root CA, the request policy should be:
A. Accept All
B. Subordinate Enterprise CA
C. Pending
D. Designated
Objective 4.3: Implement and manage certificates
The previous two objectives looked at planning and then building the underlying certificate infrastructure for an enterprise. This objective examines managing the certificates themselves.
This objective covers how to:
Manage certificate templates
Implement and manage certificate deployment, validation, renewal, and revocation
Manage certificate renewal, including Internet-based clients, CAs, and network devices
Configure and manage key archive and recovery
Managing certificate templates
Certificate templates are managed through the the Certificate Templates Consolein Windows Server 2012. Within the Certification Authority tool, selecting Certificate Templates and then selecting Manage reveals the Certificate Templates Console, as shown in Figure 4-24.
FIGURE 4-24 Viewing certificate templates in Windows Server 2012
Selecting any of the templates and then selecting Properties reveals the properties of the template, as shown in Figure 4-25.
FIGURE 4-25 Viewing properties of a certificate template
Table 4-5 discusses the properties found on the tabs of a certificate template’s properties.
TABLE 4-5 Built-in certificate template properties
You can change these properties and others when creating a new template by selecting a template and then choosing Duplicate. When you do so, several tabs become available, as shown in Figure 4-26 and discussed in Table 4-6.
FIGURE 4-26 Configuring a duplicate template
TABLE 4-6 Certificate template settings
Once the settings have been configured for a template, the next step is to add the certificate template to the CA. This is accomplished in the Certification Authority tool by right-clicking Certificate Templates and then selecting New, Certificate Template to Issue. You can then select from among the available templates, as shown in Figure 4-27.
FIGURE 4-27 Choosing a template to add to the CA
More Info: Administering Certificate Templates
See http://technet.microsoft.com/en-us/library/cc725621 for additional details on the options available for a certificate template.
Implementing and managing certificate deployment, validation, renewal, and revocation
Deploying a certificate can be accomplished in several ways, the simplest of which is using the Certificates MMC snap-in to request a new certificate. The Certificate Enrollment Wizard steps through the process of obtaining a certificate within the enterprise. In the Certificate Enrollment Wizard, the policy is selected first, as shown in Figure 4-28.
FIGURE 4-28 Selecting the certificate enrollment policy
The available templates are shown, and the template from which the certificate request should be generated can be selected, as shown in Figure 4-29.
FIGURE 4-29 Choosing the template type for a certificate
Exam Tip
The templates that appear are dependent on the templates being published in Active Directory as well as your permissions to view them. Selecting the Show All Templates check box reveals additional templates.
There are also other methods for deploying certificates, including:
Configuration Manager You can use Microsoft System Center Configuration Manager to deploy certificates. See http://technet.microsoft.com/en-us/library/gg682023.aspx for details.
Group Policy See http://technet.microsoft.com/en-us/library/cc770315(v=ws.10).aspx for details.
Certificates can be validated through the Certificates MMC snap-in by selecting Open from the certificate’s Actions menu. The Certification Path tab shows the status of the certificate, as shown in Figure 4-30.
FIGURE 4-30 Viewing the current status of a certificate
OCSP through an online responder can be used for validation and revocation management. See the previous section for details on implementing OCSP.
Certificate revocation can be accomplished from the CA by selecting the certificate and choosing Revoke Certificate from the All Tasks menu of the certificate. When a certificate is revoked, a reason code can be given along with a date and time of revocation, as shown in Figure 4-31.
FIGURE 4-31 Revoking a certificate
Note: Deploying Certificates
Deploying certificates to clients can be accomplished by using Group Policy or through another push method.
Managing certificate renewal
Basic renewal of certificates takes place in the Certificates MMC snap-in. There are two options for renewing a certificate:
Renew Certificate With New Key
Renew This Certificate With Same Key
The option chosen depends on the needs of the environment. Choosing to renew with a new key can enhance security because you can strengthen the new key. Renewing certificates is a standard operation, and more information can be obtained from http://technet.microsoft.com/en-us/library/cc730605.aspx.
Exam Tip
Key-based renewal can be used as a means to achieve automatic renewal. Windows 8 and Windows Server 2012 are the minimum client requirements to use this feature. See http://social.technet.microsoft.com/wiki/contents/articles/7734.certificate-enrollment-web-services-in-active-directory-certificate-services.aspx for more information.
CES is used to provide certificate enrollment and renewal for clients, regardless of whether the client is part of the domain. CES uses HTTP and SSL (HTTPS) to provide the services. The section “Configuring and managing Certificate Enrollment Web Services and Certificate Enrollment Policy Web Services” earlier in this chapter discusses CES.
Managing certificate deployment and renewal to network devices
NDES can be used to provide certificate deployment and renewal to network devices. The CEP Encryption template is used as the basis for NDES, and you create a duplicate of the CEP Encryption template as you would when working with other templates. The basic process for enrollment is as follows:
1. Generate a key pair with the device. The key pair can be used for signing and signature verification, or decryption and encryption, or both signing/signature verification and decryption/encryption.
2. An administrator obtains a password from NDES.
3. Configure the device to trust the certificate infrastructure.
4. Submit a certificate enrollment request to NDES. The certificate enrollment request contains the password obtained earlier and also the KeyUsage extension, which should be defined as Key Encipherment (0x20), Digital Signature (0x80), or both (0xa0).
5. NDES then takes the enrollment request and submits it to the CA. The CA issues the certificate based on its policy.
Renewal is allowed as long as the device retains the same subject name.
More Info: NDES
See http://social.technet.microsoft.com/wiki/contents/articles/9063.network-device-enrollment-service-ndes-in-active-directory-certificate-services-ad-cs.aspx for more information on NDES.
Configuring and managing key archive and recovery
Key archival can be performed manually or automatically, depending on the configuration. If the certificate template requires key archival, then the process of archiving the key requires no manual intervention. However, key archival can also be performed manually if the private key is exported and then sent to an administrator for import into the CA database.
The Archive subject’s Encryption Private Key setting on the Request Handling tab of a certificate template’s Properties dialog box is where automatic key archival is configured, as shown in Figure 4-32.
FIGURE 4-32 Configuring automatic key archival for a certificate template
There is also a Key Recovery Agent template that exists in the standard templates with Active Directory Certificate Services. The Key Recovery Agent template enables Domain Admins and Enterprise Admins to export private keys. Additionally, you can also add other accounts and groups to have the necessary permissions (Read and Enroll) through the Security tab of the template, shown in Figure 4-33.
FIGURE 4-33 Configuring permissions for the Key Recovery Agent template
The Key Recovery Agent template also needs to be enabled, as with other certificate templates, through the Certification Authority tool by selecting Certificate Template To Issue. See the section titled “Managing certificate templates” earlier in this objective for more details on enabling a certificate template on a CA.
With the Key Recovery Agent template in place, the following process must take place for key archival and recovery:
1. Request a key recovery agent certificate using the Certificates snap-in.
2. Issue the key recovery agent certificate using the Certification Authority tool.
3. Retrieve the enrolled certificate using the Certificates snap-in.
4. Configure the CA for key archival and recovery.
The final step, configuring the CA for key archival and recovery, takes place in the Properties dialog box of each CA that will need to archive and recover keys. Specifically, the Recovery Agents tab shown in Figure 4-34 configures the behavior of the CA when a request includes key archival.
FIGURE 4-34 Configuring key archival settings for a CA
Each Key Recovery Agent certificate should be added using the Add button in the Recovery Agents tab.
Thought experiment: Certificate templates
In this thought experiment, apply what you’ve learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter.
Your certificate infrastructure consists of an offline root CA and two enterprise CAs. You have three websites that need internal SSL certificates. You’ll be implementing certificate templates for SSL websites in your organization.
Describe the process for creating a certificate template and making it available for use.
Objective summary
Certificate templates provide a means by which an organization can control the parameters for certificates.
NDES provides certificate enrollment services for network devices.
CES provides certificate services to Internet-based clients.
Key archival and recovery can be automated through certificate templates or performed manually with key recovery agents.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. On which tab of a certificate template Properties dialog box can the setting be found for automatic key archival?
A. Server
B. Request Handling
C. Security
D. Cryptography
2. To which setting should the KeyUsage parameter be set for an NDES request?
A. Digital Signature (0x80)
B. Key Change (0xF1)
C. Key Archival (0x5150)
D. Encrypt-Change (0x2a)
3. The online responder implements which protocol?
A. Certificate Revocation Protocol
B. Certificate Status Protocol
C. Security Certificate Enrollment Protocol
D. Online Certificate Status Protocol
Objective 4.4: Design and implement a federated identity solution
This section shifts away from certificates and into authentication and authorization, or at least a limited subset of authentication and authorization. This section examines federated identity and the exam objectives around the same.
This objective covers how to:
Plan for and implement claims-based authentication, including planning and implementing relying party trusts
Plan for and configure claims provider and relying party trust claim rules
Plan for and configure attribute stores, including Active Directory Lightweight Directory Services (AD LDS)
Plan for and manage Active Directory Federation Services (AD FS) certificates
Plan for and implement Identity Integration with cloud services
Integrate Web Application Proxy with AD FS
Planning for and implementing claims-based authentication
Claims-based authentication is provided through Active Directory Federation Services (AD FS). AD FS enables authentication and authorization for external resources, such as web-based applications. AD FS uses the concept of claims to provide authentication and authorization, and AD FS provides the means by which claims are exchanged between partners.
For example, when a user attempts to authenticate to a web application, a claim is generated and the organization hosting the web application, known as a relying party, processes the claim. The processing could be as simple as accessing the values in the claims and granting the user access to an application.
Claims-based authentication relies on trust between the organization making the claim and the organization accepting the claim. The organization that contains the user accounts is referred to as an account partner, while the organization that contains the application to be accessed is referred to as a resource partner.
AD FS uses rules to determine how to process claims and an attribute store to determine what values to place in a claim. This exam objective covers both trust rules and attribute stores later.
More Info: AD FS Key Concepts
This section doesn’t provide exhaustive coverage of AD FS and the concepts of claims-based authentication. See http://technet.microsoft.com/en-us/library/ee913566.aspx for more details on the key concepts of AD FS.
The server on which AD FS is installed must be joined to a domain. Several items can be installed as part of an AD FS implementation, including:
Federation Service The main service to provide claims-based authentication.
Web Agents Claims-aware or Windows token-based agents that process claims received from an AD FS 1.1 Federation Service.
Web Application Proxy Gathers credentials from users and forwards them to the Federation Service. The Web Application Proxy cannot be installed on the same server as the Federation Service.
More Info: Application Strategy
The TechNet article “Determine Your Federated Application Strategy in a Resource Partner” contains several questions that can help frame the discussion when considering a federated identity implementation. The article is available at http://technet.microsoft.com/en-us/library/dd807077.aspx.
AD FS is configured through the AD FS Federation Server Configuration Wizard, in which you can create a new Federation Service or add the server to an existing Federation Service. When implementing the Federation Service, you can choose a federation server farm or a standalone federation server. For most enterprise environments, a server farm would be used to ensure fault tolerance.
The connection to AD DS is configured and then the Federation Service names and certificate are configured next in the wizard, shown in Figure 4-35.
FIGURE 4-35 Configuring the service name for AD FS
The Federation Service name is derived from the SSL certificate used for AD FS. The SSL certificate can be based off of a template, and the common name for the certificate should be the name that will be contacted as part of the AD FS implementation. The SSL certificate needs to be enrolled and used by IIS.
Exam Tip
For internal public key infrastructure, the computer on which the certificate will be enrolled should be granted the Enroll permission within the certificate template.
Once AD FS is installed and initial configuration is complete, the next step in setting up AD FS is to configure a relying-party trust. A relying-party trust can be configured using a URL obtained from the relying party. The URL contains federation metadata that can be used for the configuration. Alternatively, the relying party can also export the federation metadata to a file that can subsequently be imported. Finally, you can also configure a relying-party trust manually.
All three relying-party trust configuration options use the Add Relying Party Trust Wizard. Table 4-7 describes the information necessary to manually configure a relying-party trust.
TABLE 4-7 Relying-party trust manual configuration
Other parameters can also be entered, such as a monitoring URL. These details can be added to the relying-party trust through its Properties dialog box, shown in Figure 4-36.
FIGURE 4-36 Properties of a relying-party trust in AD FS
The relying party configures a claims provider trust that contains many of the same details and uses the token signing certificate from the claims provider’s AD FS implementation.
More Info: Claims Provider Trust
See http://technet.microsoft.com/en-us/library/dd807064.aspx for more information on creating a claims provider trust.
Planning for and configuring claims provider and relying-party trust claim rules
Claims provider trust rules are configured within the AD FS management console and are configured on a per-trust basis. Planning claims rules involves determining what claims are needed by the relying party to complete the authentication and authorization process and which users will need access to the relying-party trust. The relying party determines what claims need to be received and trusted from the claims provider.
More Info: Claims Rules
See http://technet.microsoft.com/en-us/library/ee913586.aspx for more detail on the purpose of claims rules in AD FS.
Trust rules use templates as the basis for the rule. There are different types of claims templates depending on the type of rule being used. The claims rule templates for transforms are described in Table 4-8.
TABLE 4-8 Transform claims rule templates
The template is chosen as the first step of the Add Transform Claim Rule Wizard, shown in Figure 4-37.
FIGURE 4-37 Creating a rule based on the Send LDAP Attributes As Claims template
The values and claim type are configured next in the rule. Note that multiple attributes can be sent as part of a single rule for most of the rule templates, as shown in Figure 4-38.
FIGURE 4-38 Configuring attributes to send as part of a claim rule
There are also templates for authorization, as described in Table 4-9.
TABLE 4-9 Authorization rule templates
For example, creating a rule that denies access to Managers based on their group might look like Figure 4-39.
FIGURE 4-39 Creating a deny rule for a claim
More Info: Using Authorization Rules
There’s a specific article with details about when to use an authorization rule. See http://technet.microsoft.com/en-us/library/ee913560.aspx for the article.
Planning for and configuring attribute stores
Attribute stores are the directories from which claim values are obtained. AD FS supports Active Directory, including Active Directory Lightweight Directory Services (AD LDS) as an attribute store. AD FS also supports SQL Server and custom attribute stores.
You can use AD LDS in an environment that could benefit from directory services but doesn’t have or need a domain or domain controllers available. AD LDS can be used as an attribute store in AD FS and is added within the Attribute Stores folder of AD FS Management.
When adding an attribute store, you can add a type of Active Directory, LDAP, or SQL. You also specify a connection string. For AD LDS, LDAP should be chosen as the Attribute Store Type, as shown in Figure 4-40.
FIGURE 4-40 Adding an AD LDS attribute store
The attribute store can then be chosen when specifying claims rules, as shown in Figure 4-41.
FIGURE 4-41 Adding a rule with an attribute from the AD LDS attribute store
Planning for and managing Active Directory Federation Services (AD FS) certificates
There are three types of certificates used by an AD FS implementation:
Service communications
Token decrypting
Token signing
Exam Tip
A single certificate can be used for all of the AD FS services.
The service communications certificate is used for communication with web clients over SSL and with Web Application Proxy services using Windows Communication Foundation (WCF). This certificate is configured in IIS and specified at configuration time for AD FS.
The token decrypting certificate is used to decrypt claims and tokens that are received by the federation service. The public key for the decrypting certificate is typically shared with relying parties and others as appropriate so they can encrypt the claims and tokens using the certificate.
The token signing certificate is used to sign all claims and tokens created by the server.
You can use multiple token encrypting and signing certificates as needed for an implementation, and new ones can be added within the AD FS Management tool, shown in Figure 4-42.
FIGURE 4-42 Certificates for an AD FS implementation
Management task for certificates in AD FS include adding an additional token signing or token encrypting certificate, changing the service communications certificate, or exporting the certificate. All of these tasks can be accomplished from within the AD FS Management tool. To add certificates, the certificates must exist in the certificate store for the AD FS server. However, to add a new token signing or encrypting certificate, automatic certificate rollover needs to be disabled. This is accomplished with the following Windows PowerShell command:
Set-ADFSProperties -AutoCertificateRollver $false
Once that command has been executed, a new certificate can be added.
Planning for and implementing Identity Integration with cloud services
AD FS is an excellent choice for integration with cloud services that can work with claims-based authentication, such as Office 365 and Windows Intune. The exam indicates that you should be aware of planning involved in such integration efforts. Therefore, at a high level you should be able to plan for and implement identity integration needed by a cloud service. This includes:
Directory synchronization Ensuring that changes to the local Active Directory are propagated to the cloud service.
Web Application Proxy Offsite users might have difficulty creating claims if they can’t reach the AD FS federation server. A Web Application Proxy, configured to be able to communicate with the AD FS server, can solve this issue.
The recommended (http://technet.microsoft.com/en-us/library/dn151324.aspx) topology for AD FS cloud implementations includes a federation server farm using the standard Windows Internal Database (WID) and proxies. In this topology you have multiple servers hosting AD FS, with the first server being the primary server and others being secondary servers. Multiple proxies can then be used to relay information from external users to the AD FS servers.
Microsoft also provides planning guidance based on the number of users involved in the AD FS implementation. A Network Load Balancing server can be used to provide proxy services. For 1,000 to 15,000 users, there should be two dedicated AD FS servers and two dedicated proxies. When 15,000 to 60,000 users are involved, there should be between three and five dedicated AD FS servers and at least two dedicated proxies.
Note: Servers
WID supports up to five dedicated servers.
Active Directory can be directly integrated with cloud services like Windows Intune. This is accomplished within Windows Intune through the Users area by activating Active Directory synchronization and then downloading and installing the Directory Synchronization tool (dirsync.exe), which can be downloaded from Windows Intune as well.
Integrating Web Application Proxy with AD FS
A new role service in Windows Server 2012 R2, Web Application Proxy enables a reverse proxy scenario that enables external users to access internal websites. Web Application Proxy can be integrated with AD FS to provide preauthentication for users. The preauthentication scenario then means that Windows Integrated authentication can be used for the internal websites published through the Web Application Proxy service.
Integrating Web Application Proxy means connecting it to the AD FS server. This is accomplished during configuration of the Web Application Proxy service. After it is integrated, you can add preauthentication through the Web Application Proxy console, a step called publishing. Adding a web application invokes the Publish New Application Wizard, in which you choose the preauthentication method, shown in Figure 4-43.
FIGURE 4-43 Adding a new application for Web Application Proxy
When using AD FS preauthentication, you’ll next choose the relying party for the application, shown in Figure 4-44 (where Device Registration Service has been chosen).
FIGURE 4-44 Choosing the AD FS relying party
More Info: AD FS Preauthentication Configuration
See http://technet.microsoft.com/en-us/library/dn383640.aspx for more information on the steps described in this section.
Thought experiment: Claims-based authorization
In this thought experiment, apply what you’ve learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter.
You need to provide a claims-based authorization solution for users in your organization so that they can access a third-party web application without needing to provide credentials. This solution will be used by about 3,000 users, including those within the organization and several that gain access from remote locations.
Describe the infrastructure setup you’ll use for this solution, including whether you’ll be a claims provider or relying party.
Objective summary
Claims-based authentication is implemented through AD FS in Windows Server 2012.
AD FS works on the concept of claims providers and relying parties.
Claims provider trust rules define the values sent within claims and can also transform claims.
Attribute stores are the databases or directories of information used to provide claims values.
AD FS uses several certificates, including a services certificate and signing and encrypting certificates, though the same certificate can be used for all of these use cases.
AD FS can be used for identity integration with cloud services such as Windows Intune and Office 365.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. Which of the following is an available option when configuring an attribute store type?
A. HTTPS
B. SSL
C. WCF
D. LDAP
2. Which of the following is an available template for configuring an authorization rule?
A. Permit All Users
B. Deny Computer
C. Transform User
D. Permit Claims
3. Supporting a Windows Server 2003 AD FS implementation requires which of the following?
A. AD FS 1.0 or 1.1 support
B. AD FS claims provider trust rule
C. AD FS 2003 support
D. AD FS down-level usage support
Objective 4.5: Design and implement Active Directory Rights Management Services (AD RMS)
The final objective in this chapter and for the exam looks at Active Directory Rights Management Services (AD RMS). AD RMS enables organizations to protect information regardless of the location where the information is accessed and whether the information is moved to a new location. AD RMS operates around the concept of usage rights and conditions that specify which trusted entities can access a given piece of information, such as a document. AD RMS also provides encryption of data and information.
This objective covers how to:
Plan for highly available AD RMS deployment
Plan for AD RMS client deployment
Manage trusted user domains
Manage trusted publishing domains
Manage federated identity support
Upgrade or migrate AD RMS
Decommission AD RMS
Planning for highly available AD RMS deployment
Planning for a highly available AD RMS deployment means not only installing AD RMS in a highly available manner, but also ensuring that the AD RMS database is made highly available as well. AD RMS consists of the following:
AD RMS Certification Server Cluster The main servers used for providing AD RMS services.
SQL Servers The data store for AD RMS configuration and rights-management information.
AD RMS Client Software that runs on each client to enable the usage of AD RMS.
AD RMS Licensing-Only Cluster Optional servers that can be used to support external partners or special rights-management scenarios.
AD RMS is integrated with AD DS so that clients can find the AD RMS service. If there are multiple forests involved in an organization, then AD RMS needs to be installed in each forest. There are various means by which users in separate forests can consume protected content across forests, including:
Trusted user domains (TUD) A TUD enables AD RMS to work with rights certificates created by a different AD RMS cluster. TUD requires import of the server licensor certificate from the other AD RMS cluster.
Trusted publishing domains (TPD) A TPD enables AD RMS to issue use licenses using publishing licenses created by a different AD RMS cluster. TPD requires import of both the server licensor certificate and its private key.
AD RMS with AD FS You can create a trust using AD FS. This can be helpful if users from an external forest need to access rights-protected content in the AD RMS forest.
Microsoft account A Microsoft account, formerly known as a Windows Live ID, that’s trusted with the Microsoft online RMS service can be used to access data.
A best practice when designing AD RMS services is to ensure that there’s a DNS name for the cluster rather than addressing individual servers. This helps to alleviate any issues that might arise if one server becomes unavailable. If you’ll be using a CNAME DNS record, then the SQL Server instances need to have a registry key changed in order to use the fully qualified domain name (FQDN). Specifically, the DisableStrictNameChecking setting needs to be changed from 0 to 1. This setting is found at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters.
The following protocols and ports need to be open for communication between AD RMS applications.
TCP/80 and/or TCP/443 Open one or both of these ports for HTTP or HTTPS traffic to the AD RMS server from clients. This exception is created in Windows Firewall when AD RMS is installed.
TCP/445 This port is opened on the SQL server for AD RMS. The port is used for SQL Server Named Pipes to provision the AD RMS server.
TCP/1433 This port is opened on the SQL server for AD RMS for SQL communication.
TCP/3268 This port is opened on the Global Catalog server from the AD RMS server.
There are new security groups created for AD RMS management, including:
AD RMS Enterprise Administrators This role enables AD RMS policy and settings management.
AD RMS Template Administrators This role enables AD RMS template management.
AD RMS Auditors This role enables the reading of logs and reports about the AD RMS cluster.
Note: AD RMS Service Group
There is also a group called AD RMS Service Group that enables members to run AD RMS services. The group isn’t typically used for normal user accounts but rather for service accounts related to AD RMS.
Planning for the availability of SQL Server is an important step in an AD RMS design. Failover clustering and log shipping provide two primary means for ensuring availability of the SQL Server databases involved in delivering AD RMS. See http://technet.microsoft.com/en-us/library/ee221084(v=ws.10).aspx for more information on each of these options and http://technet.microsoft.com/en-us/library/hh831554.aspx for information on changes to AD RMS for Windows Server 2012.
Managing AD RMS Service Connection Point
The Service Connection Point (SCP) is used to store the URL of the AD RMS cluster. The SCP is stored as an object in Active Directory. The SCP can be configured when AD RMS is being installed or later, through the Active Directory Rights Management Services console.
Managing the SCP is accomplished on the SCP tab of the AD RMS cluster’s Properties dialog box, shown in Figure 4-45.
FIGURE 4-45 Setting the SCP in AD RMS
As you can see from Figure 4-45, changing the SCP requires permissions to create and modify objects in AD DS.
Note: SCP
The SCP has not yet been configured in Figure 4-45, but the process is the same regardless.
Once set, you can view the current SCP properties through ADSIEdit on the domain controller, within the Configuration context in CN=Services,CN=RightsManagementServices,CN=SCP.
More Info: Windows PowerShell and AD RMS
See http://technet.microsoft.com/en-us/library/ee221079(v=ws.10).aspx for information on using Windows PowerShell with AD RMS.
Planning for and managing AD RMS client deployment
The AD RMS client is included as an optional download for Windows XP and is supported (and included) on the following operating systems:
Windows Vista SP2
Windows Server 2008 and Windows Server 2008 R2
Windows 7 SP1
Windows Server 2012 and Windows Server 2012 R2
Windows 8 and Windows 8.1
There is a separate installer depending on the client computer architecture (x86 or x64), though the x64 setup program installs both the 32-bit runtime and the 64-bit runtime to maintain compatibility with 32-bit applications. There are two methods for installing the AD RMS client, and both require local Administrator privileges.
Silent mode The /quiet switch to the setup program installs the client in silent mode, which would be useful for a scripted installation.
Interactive mode A graphical installation of the client software.
Management of the AD RMS client can involve where files and licenses are stored. Table 4-10 describes the file and license locations for the AD RMS client.
TABLE 4-10 AD RMS client file and license locations
Note: A Secure Identifier
The <SID> noted in server installation locations is the secure identifier for the account running the AD RMS client.
Several registry keys can be used to modify the behavior of the AD RMS client. Table 4-11 describes the management that can be done with registry settings.
TABLE 4-11 Registry management tasks for AD RMS
One other registry entry worth noting is used if there isn’t an SCP available. You can add a ServiceLocation subkey to HKLM\SOFTWARE\Microsoft\MSIPC and then, within that key, create an EnterpriseCertifications subkey that contains the URL of the AD RMS cluster name in the format https://<AD RMS Cluster>/_wmcs/Certification, as well as another subkey called EnterprisePublishing that contains the URL in the format https://<AD RMS Cluster>/_wmcs/Licensing.
Managing trusted user domains
TUDs enable trust between domains running AD RMS and are often used to connect users between forests. TUD management is accomplished in the AD RMS Management console. TUD information is exported to a .bin file and then subsequently imported using the Import Trusted User Domain dialog box shown in Figure 4-46.
FIGURE 4-46 Importing a TUD in AD RMS
Once imported, you can manage the TUD through its Properties dialog box, in which you can choose whether to enable licensing SIDs and also specify trusted email domains, as shown in Figure 4-47.
FIGURE 4-47 Viewing trusted email domain information for a TUD
While a forest trust isn’t required for a TUD, if a forest trust does exist, then group expansion is also possible. Group expansion makes the process of granting rights easier. However, certain prerequisites need to be met for group expansion to work. First, the forest trust must exist. Next, the Service Account of the AD RMS cluster that trusts the authentication needs to be granted rights on the Group Expansion pages of the AD RMS cluster. Finally, a group contact should be created in the trusting AD RMS forest for each destination group so that the pointer will use the correct location. The email attribute of the group contact and the destination group, as well as the msExchOriginatingForest attribute, all need to be set to the FQDN of the destination forest for the group contact to work correctly.
More Info: TUD
See http://technet.microsoft.com/en-us/library/dd983944(v=ws.10).aspx for more information on TUD, including details on the trust.
Managing trusted publishing domains
Unlike a trusted user domain, a trusted publishing domain (TPD) enables an AD RMS cluster to issue licenses as if it was a different AD RMS cluster. To accomplish this, both the certificate and the private key need to be imported. This is different than a TUD scenario, where only the certificate is imported.
Importing a TPD is accomplished within the AD RMS Management console using the Import Trusted Publishing Domain dialog box, shown in Figure 4-48.
FIGURE 4-48 Importing a TPD
In addition to the import of the domain itself, clients need to be redirected to the trusted AD RMS cluster. This can be accomplished using registry settings or by adding a DNS alias.
More Info: TPD
See http://technet.microsoft.com/en-us/library/dd996639(v=ws.10).aspx for additional details on TPD.
Managing federated identity support
Federated identity support is provided through integration of AD FS and AD RMS when trust exists between organizations using AD FS. For federated identity to work with AD RMS, the AD FS service needs to be installed, the Identity Federation Support role needs to be added, and federated identity support needs to be enabled in AD RMS. This is accomplished by accessing Trust Policies and then the Federated Identity Support section of the AD RMS Management console. Once federated identity support is enabled, you can alter the validity period and URL, as well as whether to allow proxy email addresses, as shown in Figure 4-49.
FIGURE 4-49 Changing federated identity parameters in AD RMS
Managing distributed and archived rights policy templates
Rights policy templates are managed in the AD RMS Management console. This section focuses on management-related tasks for rights policy templates. Planning and overviews of rights policies are available at http://technet.microsoft.com/en-us/library/ee221094 andhttp://technet.microsoft.com/en-us/library/dd996658.
You can specify a location for templates to be stored as well as whether the templates can be exported by using the Properties of the Rights Policy Templates node, shown in Figure 4-50.
FIGURE 4-50 Configuring parameters for all rights policy templates
Rights policy templates have several properties that can be set on a per-template basis, including language support for clients, expiration policy, user rights, extended policy, and revocation policy, each of which has its own tab in a template’s Properties dialog box. Table 4-12 describes the tabs for a rights policy.
TABLE 4-12 Rights policy template settings
Templates can be archived. When a template is archived, it will no longer be available to clients; however, content protected with the template can still be issued licenses. You can view a summary of the user rights granted for a template by selecting the template and then selecting View Rights Summary. When you do so, a dialog box like the one in Figure 4-51 will be shown.
FIGURE 4-51 Viewing the rights summary for a template
More Info: Configuring Rights Policy Templates
See http://technet.microsoft.com/en-us/library/cc731599.aspx for an overview of many of the same steps discussed in this section.
Configuring exclusion policies
Exclusion policies provide a means by which access to certificates and licenses can be prevented. Exclusion policies can be applied to user, application, and lockbox versions. Exclusion policies are enabled through the AD RMS Management console by selecting the appropriate exclusion policy to create. Prior to doing so, the exclusion policy typically needs to be enabled.
User exclusions can be done based on the user name or based on a public key string, which is helpful for users that don’t have an AD DS account. The Exclude User dialog box is shown in Figure 4-52.
FIGURE 4-52 Creating an exclusion policy for a user
Application exclusion policies are configured based on the application name and version numbering, as shown in Figure 4-53.
FIGURE 4-53 Creating an exclusion policy for an application
It’s worth noting that the minimum and maximum versions need to be specified in a four-digit format, such as 5.1.5.0 or 1.2.3.4.
The Lockbox dialog box, shown in Figure 4-54, enables a minimum version of the lockbox that can be used with AD RMS.
FIGURE 4-54 Configuring a lockbox exclusion policy
Upgrading, migrating, and decommissioning AD RMS
The tasks involved in upgrading AD RMS from one version to another vary depending on the version currently running. This section focuses on upgrades and migrations from Windows Rights Management Services (RMS) to AD RMS. The basic migration path from RMS to AD RMS is to join a new AD RMS server to the existing RMS cluster during configuration time by choosing the Join An Existing AD RMS Cluster option.
Upgrading directly from Windows Server 2003 to Windows Server 2012 R2 is supported. However, if the WID is used for the existing RMS installation, then this must first be migrated to SQL Server. See http://social.technet.microsoft.com/wiki/contents/articles/1084.migrating-the-ad-rms-database-from-windows-internal-database-wyukon-to-sql-server-2005-sp2.aspx for details on the WID to SQL Server upgrade for AD RMS.
RMS should be running with Service Pack 2 (SP2) and should be running on the same version across all legacy RMS servers. The RMS cluster should also be enrolled in the Microsoft Enrollment Service. See http://technet.microsoft.com/en-us/library/cc730885 for details on checking enrollment status.
If the existing RMS installation is using CSP protection rather than RMS key protection, then the CSP private key needs to be imported into the new AD RMS server. See http://technet.microsoft.com/en-us/library/cc753807 for details on this issue. Additionally, the server licensor certificate needs to be imported into the new AD RMS server by exporting the trust policies from within the Windows RMS Administration website.
Decommissioning AD RMS should be done in a specific order so that content protected by AD RMS can be unprotected. Additionally, once decommissioned, the server cannot be brought back to its previous state. Therefore, care should be taken before decommissioning AD RMS.
Decommissioning AD RMS means setting a property in AD RMS. Once decommissioned, users should unprotect their content. Only after these steps are complete should the AD RMS role be uninstalled. A special URL, decommission.asmx, is used to fulfill certificate requests while the AD RMS cluster is in decommissioned state. Therefore, permissions on the decommission.asmx file in IIS should be changed so that all users can access the file, and any AD RMS applications should also be reconfigured to send requests to the decommissioning web service URL.
Decommissioning is set in the Security Policies of the AD RMS Management console. Decommissioning itself, or the ability to select Decommission, is disabled by default. Once enabled, the Decommission button becomes available, as shown in Figure 4-55.
FIGURE 4-55 Getting ready to decommission AD RMS
Thought experiment: AD RMS design
In this thought experiment, apply what you’ve learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter.
You’re planning the AD RMS rollout within your organization. The organization consists of a forest with one domain and about 1,500 users. You need to design an AD RMS infrastructure plan for others in IT to use. The plan should include ports and protocols involved, as well as the topology and elements involved.
Describe your AD RMS design.
Objective summary
AD RMS is used to provide rights management for content within an organization.
AD RMS should normally be set up in a fault-tolerant manner and uses SQL Server for its database, which should also be set up in a fault-tolerant manner.
AD RMS uses trusted user domains and trusted publishing domains to enable cross-forest authentication.
AD RMS can use AD FS for federated identity support.
AD RMS uses templates for rights management.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. Which protocol and port are used by AD RMS to contact the global catalog server?
A. TCP/445
B. TCP/1433
C. TCP/22
D. TCP/3268
2. Which of the following is a valid version number when creating an application exclusion policy?
A. 1.0
B. 5.3.7.2
C. 1.4.3
D. 1
3. Which user groups are allowed to make changes to AD RMS templates?
A. Active Directory Rights Management Services Template Administrators
B. Domain Admins
C. Active Directory Rights Management Services Auditors
D. Template Users
Answers
This section contains the solutions to the thought experiments and answers to the lesson review questions in this chapter.
Objective 4.1: Thought experiment
You can use a standard two-tier design with a root CA operated in the main data center and then multiple issuing CAs, one or more for each location. The root CA would likely be standalone, while the issuing CAs would be enterprise in order to take advantage of AD DS integration.
Objective 4.1: Review
1. Correct answer: B
A. Incorrect: Enterprise cannot be operated in offline mode.
B. Correct: Standalone can be operated in offline mode.
C. Incorrect: Offline is not a valid option.
D. Incorrect: On/off is not a valid option.
2. Correct answer: C
A. Incorrect: Publishing interval defines how long between publications.
B. Incorrect: Validation is not a valid option.
C. Correct: Validity defines the amount of time a CRL is valid.
D. Incorrect: Revocation interval is not a valid option.
3. Correct answer: A
A. Correct: Standalone CA and NDES should exist on the same server.
B. Incorrect: Enterprise CA should not exist on the same server.
C. Incorrect: Multiforest is not a valid option.
D. Incorrect: CA trust is not a valid option.
Objective 4.2: Thought experiment
The root CA is installed as a role in Windows Server 2012. Within the role, the CA role service is configured. A standalone CA should be chosen, because that’s the only type that can be offline. A new private key will likely be created unless one already exists within the organization. The request handling should be set (verified) to pending for new requests, the CRL distribution point should be set to a server that will be online, and the server should be taken offline.
Objective 4.2: Review
1. Correct answer: A
A. Correct: Allow Authenticate needs to be granted to Administrators, domain member computers, and enterprise CAs.
B. Incorrect: Allow Enroll is not a valid permission.
C. Incorrect: Enterprise CA is not a valid permission.
D. Incorrect: Certification Admin is not a valid permission.
2. Correct answer: D
A. Incorrect: CA administrator does not have the ability to install a new CA.
B. Incorrect: Auditor does not have the ability to install a new CA.
C. Incorrect: Enterprise PKI is not a real role.
D. Correct: Local administrator has the permission to install a CA by default.
3. Correct answer: C
A. Incorrect: Accept All is not a valid policy.
B. Incorrect: Subordinate Enterprise CA is not a valid policy.
C. Correct: Requests should be set to pending on a root CA.
D. Incorrect: Designated is not a valid policy.
Objective 4.3: Thought experiment
The first task is to duplicate an existing certificate template, such as the Web Server template. With a duplicate template available, any settings specific to the environment can be changed. Once the template has been configured, it needs to be made available on each CA by selecting the Certificate Template to Issue option from the Certificate Templates folder context menu in the Certification Authority tool.
Objective 4.3: Review
1. Correct answer: B
A. Incorrect: The Server tab does not contain this information.
B. Correct: Request Handling contains the archive subject’s encryption private key setting.
C. Incorrect: The Security tab contains permission information for users and groups.
D. Incorrect: The Cryptography tab does not contain this information.
2. Correct answer: A
A. Correct: Digital Signature (0x80) is one of the allowed KeyUsage parameter settings.
B. Incorrect: Key Change (0xF1) is not a valid parameter setting.
C. Incorrect: Key Archival (0x5150) is not a valid parameter setting.
D. Incorrect: Encrypt-Change (0x2a) is not a valid parameter setting.
3. Correct answer: D
A. Incorrect: Certificate Revocation Protocol is not a valid protocol.
B. Incorrect: Certificate Status Protocol is not a valid protocol.
C. Incorrect: Security Certificate Enrollment Protocol is not a valid protocol.
D. Correct: Online Certificate Status Protocol is the protocol implemented by the online responder.
Objective 4.4: Thought experiment
You’ll need to set up at least two AD FS federation servers and at least two AD FS Web Application Proxy servers for this solution to maintain fault tolerance. Your company is the claims provider and will provide claims based on whatever the third-party web application needs for authentication and authorization.
Objective 4.4: Review
1. Correct answer: D
A. Incorrect: HTTPS is not one of the options for an attribute store type.
B. Incorrect: SSL is not one of the options for an attribute store type.
C. Incorrect: WCF is not one of the options for an attribute store type.
D. Correct: LDAP, along with SQL and Active Directory, are the options for an attribute store type.
2. Correct answer: A
A. Correct: Permit All Users is one of the available authorization templates.
B. Incorrect: Deny Computer is not a template.
C. Incorrect: Transform User is not a valid template.
D. Incorrect: Permit Claims is not a valid template.
3. Correct answer: A
A. Correct: AD FS 1.0 or 1.1 support is needed to support Windows Server 2003 AD FS.
B. Incorrect: AD FS claims provider trust rule is not needed to support Windows Server 2003 AD FS.
C. Incorrect: AD FS 2003 support is not a valid option.
D. Incorrect: AD FS down-level usage support is not a valid option.
Objective 4.5: Thought experiment
The AD RMS design includes two AD RMS servers and two SQL servers to provide fault tolerance. The AD RMS elements include those servers along with an AD RMS client on each computer that will need to access the AD RMS–protected content. TCP/445 and TCP/1433 will need to be open between the AD RMS servers and the SQL servers. The AD RMS server should be allowed to communicate on TCP/3268 to the AD DS servers to obtain global catalog information. Finally, TCP/443 should be allowed from clients to the AD RMS servers.
Objective 4.5: Review
1. Correct answer: D
A. Incorrect: TCP/445 is not used for global catalog traffic.
B. Incorrect: TCP/1433 is typically used for SQL Server traffic.
C. Incorrect: TCP/22 is typically used for Secure Shell (SSH) traffic.
D. Correct: TCP/3268 is the protocol and port used for global catalog traffic.
2. Correct answer: B
A. Incorrect: 1.0 is not a valid version-numbering scheme for an application exclusion policy.
B. Correct: Application exclusion policies require four-digit version numbers, so 5.3.7.2 is valid.
C. Incorrect: 1.4.3 is not a valid version-numbering scheme for an application exclusion policy.
D. Incorrect: 1 is not a valid version-numbering scheme for an application exclusion policy.
3. Correct answers: A, B
A. Correct: Active Directory Rights Management Services Template Administrators can make changes to templates in AD RMS.
B. Correct: Domain Admins can make changes to templates.
C. Incorrect: Active Directory Rights Management Services Auditors cannot make changes to templates.
D. Incorrect: Template Users is not a valid group.