Deploying Public Key Policies

Kerberos authentication is the most commonly used computer to computer authentication mechanism for Windows computers. Kerberos is in fact, the default authentication mechanism in Active Directory domains. In addition to Kerberos authentication, Windows computers can use public key certificates for authentication.

How Public Key Certificates Work

Public key certificates provide a standard way of identifying users and computers securely. A certificate is like a unique signature that can be associated only with a particular identity. Public key certificates have a wide variety of uses for users and computers alike. They can be used for enabling IPSec communications between computers, for signing code to ensure the code comes from a trusted publisher, for encrypting e-mail, and for enabling the Microsoft Encrypting File System (EFS). Public key technologies are sometimes referred to as the public key infrastructure, or PKI.

Public key policy within Group Policy lets you control which certificates your computers and users use and how they are used. Public key policy provides for autoenrollment of certificates that you specify so your computers and users don’t have to manually add certificates to use services such as encrypted e-mail. You can also ensure that your users use certificates only from reputable certificate authorities (CAs). A CA can be a trusted external organization or an internal CA that you create. You establish your own internal CA by installing Microsoft Certificate Services on a Windows Server 2003 computer within your Active Directory forest.

The CA is responsible for creating and distributing public key certificates to users and computers for a variety of purposes. The CA also provides certificate revocation lists (CRLs) that let users and computers know when previously issued certificates are no longer valid, even if they have not expired.

More Info

More Info

A good starter reference about the essentials of establishing and working with a CA is Chapter 8 of the IIS 6.0 Administrator’s Pocket Consultant (Microsoft Press, 2003). It shows how to set up a CA, issue certificates, revoke certificates, and manage Certificate Services in general.

How Public Key Policies Are Used

Public key policies are available as both per-computer and per-user policy within the Group Policy namespace under Windows SettingsSecurity SettingsPublic Key Policies, as shown in Figure 11-14. The per-user Public Key Policies folder, however, includes only a subset of the capabilities found in the per-computer settings. Specifically, you can use per-user settings only to manage enterprise trust lists and autoenrollment settings.

Viewing public key policies in the Group Policy namespace

Figure 11-14. Viewing public key policies in the Group Policy namespace

Public key policies allow for a variety of public key deployment scenarios and enforcement rules. The four general policy areas are:

  • Encrypting File System. Used to establish key recovery agents for data that is encrypted using EFS. EFS policies allow you to unencrypt data encrypted by users who are no longer around or whose user accounts have been removed. By default, within an Active Directory environment the domain Administrator account is automatically made a key recovery agent for all computers in the domain. These policies apply to computers only.

  • Automatic Certificate Request Settings. Used to specify the types of certificates that a computer can request automatically. These policies apply only to certificate usage that is computer specific, and you must have one or more existing certificate templates. These policies apply to computers only.

    Note

    Note

    Each type of template has a specific use—for example, for computers, domain controllers, enrollment agents, or IP security. You can install certificate templates using Certtmpl.msc. When a computer processes the related policy, it autoenrolls with the enterprise CA for that type of certificate.

  • Trusted Root Certification Authorities. Used to configure the types of trusted root CAs allowed. By default, both third-party root CAs and enterprise root CAs are trusted. You can change this configuration and add new trusted root CAs. Keep mind that Active Directory–based CA root certificates are automatically installed on domain-based computers without the use of public key policies. These policies apply to computers only.

  • Enterprise Trust. Used to specify certificate trust lists (the certificates issued by third-party CAs that you trust). Trusted certificates are listed according to the CA that issued them, the effective date, and the intended purpose. These policies apply to both users and computers.

In addition to these four general policy areas, you can configure autoenrollment behavior for computers and users. By default, users and computers are configured to enroll certificates automatically. You can view or change the autoenrollment settings by completing the following steps:

  1. Select the Public Key Policies under Computer ConfigurationWindows SettingsSecurity Settings or User ConfigurationWindows SettingsSecurity Settings as appropriate.

  2. Double-click Autoenrollment Settings in the right pane. This displays the dialog box, shown in Figure 11-15.

    Specifying global autoenrollment options within public key policy

    Figure 11-15. Specifying global autoenrollment options within public key policy

  3. To disable autoenrollment, select Do Not Enroll Certificates Automatically. To allow autoenrollment, select Enroll Certificates Automatically.

    If you choose autoenrollment, two additional options are available:

    • Renew Expired Certificates, Update Pending Certificates, And Remove Revoked Certificates. Choose this option to ensure that, beyond simple autoenrollment, certificates installed to your users and computers are managed if they expire, are pending, or are revoked.

    • Update Certificates That Use Certificate Templates. Choose this option to use certificate templates to control what kinds of certificates are autoen-rolled and to allow certificates to be updated.

  4. Click OK.

Managing Public Key Policy

Public key certificates are most commonly used in certain scenarios. For example, if you have an enterprise CA root installed, you can automatically enroll your user accounts with a certificate for e-mail signing and encryption. This doesn’t require the use of public key policies, however, because autoenrollment is enabled by default within an Active Directory environment with a CA installed.

One area that requires configuration in policy is the implementation of EFS within an Active Directory environment. By default, when a user encrypts a file using EFS, that user and the domain administrator account (if the computer is in an Active Directory) are made the key recovery agents for that file. This means that either the user or the domain administrator can unencrypt that file. However, you might want to create additional key recovery agents to ensure that the right people within your organization can recover encrypted files before you allow your users to use EFS.

To add a new key recovery agent for EFS, complete the following steps:

  1. Select the Public Key Policies under Computer ConfigurationWindows SettingsSecurity Settings.

  2. Right-click Encrypting File System and choose Add Data Recovery Agent. This starts the Add Recovery Agent Wizard. Click Next.

    Note

    Note

    The shortcut menu that appears when you right-click Encrypting File System also has a Create Data Recovery Agent option. If you select this option, the domain administrator account is automatically added to the GPO as the default key recovery agent. This is necessary only if you want to have the domain administrator account included as a key recovery agent for the computers that process that GPO. You can also select All Tasks followed by Delete Policy to remove all recovery agents specified within that GPO so far.

  3. On the Select Recovery Agent page, shown in Figure 11-16, you can choose to browse Active Directory or a file folder to locate the user certificate that will be used to establish the key recovery agent. The user whose certificate you selected is then added to the Recovery Agents list. Repeat this process to designate additional recovery agents.

    Specifying a new EFS key recovery agent

    Figure 11-16. Specifying a new EFS key recovery agent

    Note

    Note

    Certificates can be exported to files and then imported using the Browse Folders option. In this way, you can import the certificate file when the certificate itself is not stored with the user object in Active Directory.

    Tip

    Tip

    You can view the certificates installed for your user account or for a particular computer account by loading the Certificates MMC snap-in from a blank MMC console. The Certificates snap-in provides details about currently enrolled certificates and allows you to manually enroll certificates. It also lists the currently trusted CAs for the user or computer.

  4. Click Next, and then Click Finish. When this GPO is next processed by computer objects, the policy you configured will add the designated user or users as a valid recovery agent to any encrypted files.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset