Psychologically Acceptable Security

Getting user buy-in for security is critical. Using certificate autoenrollment is a way to make it pain-free.

• By Roberta Bragg
• February 01, 2004

Your security policies should be psychologically and socially acceptable. I don’t mean they should have users dancing on their desktops, but they shouldn’t make people afraid, upset or incompetent. If security is to work, it has to be acceptable—you don’t want to provoke people into finding ways around it, force them into other forms of revolt or require enormous effort to obtain acquiesce.

There’s a security principle that expresses this, known as the principal of “psychological acceptability.” It means that you can’t shove security down someone’s throat; users have to understand why they’re doing what you want them to do. It says that the best security is unobtrusive. If I don’t have to do anything, but my data is secure, what could be more acceptable than that? Though we may pay for the product, and as IT pros we may have to struggle a little to implement unobtrusive security, the ordinary user shouldn’t see it as a hassle. Researchers have found, for example, that people don’t like biometrics such as hand geometry (they feel their hand might not be returned if it doesn’t identify them) or retinal scanning (they don’t want to place their eye on something the light might hurt).

Autoenrollment
When you design security for your Windows Server 2003 network, keep psychological acceptability in mind. One way you can increaher se security in your organization is by implementing smart cards and otcertificates. But organizations have found that certificate enrollment, especially smart card enrollment, is hard for people to figure out on their own. Frustrated users can become non-cooperative users. You may be able to get them to comply eventually, but nobody feels good about it. To make it easier—to make it more psychologically acceptable—you can automate most of the process by configuring certificate autoenrollment.

When autoenrollment is used, most certificate enrollment requires no user intervention at all. To complete smart card enrollment, the user must insert the smart card in the reader when prompted and enter a PIN; it’s far less trouble than the non-automated way. When you can reduce the frustration and make security simpler for thousands of users, you rapidly improve the security posture of your entire organization. And that may just be worth checking out even if you feel silly doing so.

To implement smart cards in a Windows network, you must implement a Public Key Infrastructure. While instructions for one part of that, the creation of a Certification Authority, are included here, understand that the first step in any PKI deployment is the development of a policy, proper planning and testing. Understand, too, that the steps below are no substitute, but they can help you understand the technology. When it’s time to implement this solution in production, you should do your own policy, planning and testing.

To see how autoenrollment works, you’ll need at least one Windows Server 2003 Enterprise Edition server and the installation CD-ROM. If you want to test autoenrollment on Windows XP, you’ll need an XP computer to use for the client, a simple hub, and cables to network with the server. Join it to the test domain. You’d never deploy a system exactly like this; the idea here is just to see how it works.

Laying the Foundation
Step 1: Park the server on its own network with no connection to the Internet or your production network.
Install the server, DCPromo, to its own domain—don’t forget DNS—and add IIS. Raise the domain functional level to Windows Server 2003. In the real world, you should install IIS and the enrollment pages on a separate box; in our quick test, we’ll put them all together.

Step 2: Enable Active Server Pages on IIS.
By default it’s disabled, like most everything else. This is a good security model, but it means that we need to know what to do and how to do it for things like installing Web-based applications. The certificate authority Web enrollment pages require ASP. To enable ASP on IIS:

1. Go to Start | Administrative Tools | Internet Information Services Manager console.

2. Select the Web Services Extension folder.

3. Right-click on the ASP pages button and select Enable.

4. ASP extensions should now be labeled “Allowed,” as shown in Figure 1.

Figure 1. You must enable ASP on IIS in order to use the certificate enrollment Web pages. (Click image to view larger version.)

Step 3: Install Certificate Services.
For this simple test, install certificate services using all the defaults. In a production environment you may want to change some settings to meet your requirements and you should back up the CA certificate keys immediately. To install certificate services:

1. Log on as Administrator. (You’ll need to be a member of Enterprise Admins for later exercises, so the default account works well for our test).

2. Open Start | Settings | Control Panel | Add Remove Programs | Add/ Remove Windows Components.

3. Select Windows Certificate Services.

4. At the dialog warning that the computer name cannot be changed, click Yes.

5. Click Enterprise Root CA, then click Next.

6. Enter a common name for the certification authority; the name CA2 is used here.

7. Enter the distinguished name suffix. Use the form DC= domain DC= extension, for example, .com, and click Next.

8. Accept the default storage locations and click Next.

9. If prompted, enter or browse to the path for the Windows 2003 installation disk.

10. When installation’s finished, click Finish.

11. Open Start | Administrative Tools | Certification Authority and note that the CA service has started, as evidenced by a green check mark on the CA.

Configure Autoenrollment
Both Windows 2000 and 2003 certificate templates are used by Enterprise Certification authorities to lighten the chores a certificate requestor must perform in order to get a certificate. The information in the template and the Active Directory user’s account provides enough information to issue the certificate. This makes autoenrollment a snap, since the user doesn’t need to enter any information. Win2K computer certificates can even be configured that way.

Windows 2003 v.2 templates have another advantage: They can be customized. One of the available customizations is autoenrollment. When autoenrollment’s configured and a domain member logs on using a domain account from an XP Pro desktop or Windows 2003 server, the computer checks the templates then automatically enrolls those certificates configured for autoenrollment and for which the domain account has the Enroll permission. The process by which a user or computer certificate is issued can be broken down into three steps:

1. Request: A certificate is requested by using the Web enrollment pages or the Certificates snap-in. When autoenrollment is configured, a certificate request may also be automatically issued when a user or computer authenticates to Active Directory.

2. Issue: A certificate request is approved (either automatically or manually) and the certificate is created.

3. Distribution: The certificate is installed in the certificate stores of the computer.

Any of these parts may occur automatically. User intervention may be required for specific steps to occur. When these processes are automatic it’s called autoenrollment. There are three places where this is configured:

On the Policy Module property page of the CA

In the Certificate Template

In Group Policy

To configure enrollment in the CA, first right-click on the CA in the Certification Authority console and select Properties. Select the Policy Module page and click the Properties button. On the Request Handling tab, select “Follow the settings in the Certificate template, if applicable. Otherwise, automatically issue the certificate.” See Figure 2.

Figure 2. The Properties dialog specifies how the CA should handle requests by default.

Autoenrollment Certificate Templates
Several template property pages can have an impact on autoenrollment. To configure templates for autoenrollment, you’ll need to select the settings described in Table 1. Only a Windows 2003 Enterprise Edition CA or a Windows 2003 DataCenter Edition CA can be used to configure the certificate properties. Template properties and Group Policy configuration determine how user requests are treated.

Page Setting Roberta Says Request Handling Enroll Subject Without Requiring Any User Input Users don't have to participate and won't be aware that any changes are occurring. Request Handling Prompt the User During Enrollment The user may need to take an action, like inserting a smart card, during enrollment, and therefore will be prompted. Request Handling Prompt The User During Enrollment and Require User Input When the Private Key is Used. May cause problems if users aren't trained in its use. Request Handling CSP Selection If multiple cryptographic service providers (CSPs) are listed for the template, the user is given a choice. Subject Name Supply In The Request The user must be prompted to enter a subject name autoenrollment isn't available). Subject Name Include the e-mail address of subject name If this is checked, and the e-mail address is missing from the user account, no certificate will be automatically enrolled. Subject Name E-mail address (In the "Include This Information in the alternative subject name.") If checked, and no e-mail address is present, the certificate can't be issued. Issuance Requirements This Number Of Authorized Signatures If more than one signature is required, autoenrollment is disabled. The valid signature certificates required are specified on this page. Issuance Requirements Valid Existing Certificate If configured, the subject may not need to supply a valid signing certificate for certificate renewal of a valid certificate based on this template. General Validity Period and Renewal Periods Autoenrollment can't renew a certificate unless 20 percent of the certificate lifetime has expired. This should prevent autoenrollment based on improper configuration. Security Permissions A user or computer must have the Read, Enroll and Autoenroll permission on the certificate template.

Warning: If you design custom Windows groups and assign them template permissions, make sure the Enterprise CA has Enroll permission on the template. The Enterprise CA usually gets this permission because it’s a member of the Authenticated Users group. If the Authenticated Users group isn’t given Enroll permission for the Authenticated Users group, be sure to add the Enterprise CA and provide the proper permissions if you wish automatic enrollment to occur.

To create certificate templates that can be used in autoenrollment, duplicate the template and then configure it for autoenrollment. To avoid the extra complexity of configuring smart card enrollment, use the User and Computer certificates in your first tests. Here’s the sequence:

1. Open the Certification Authority console, right-click on the Certificate Templates node and select Manage to open the Certificate Templates console.

2. Right-click the User template and select DuplicateTemplate.

3. A new template is created and opened to its properties pages.

4. Click the General Page and enter a name for the template AutoUser (you can use any name you choose).

5. Click the Request Handling Page.

6. Make sure that Enroll Subject Without Requiring Any User Input is selected, as shown in Figure 3.

Figure 3. Setting enrollment preferences is done on the Request Handling page.

7. Select the Subject Name tab, shown in Figure 4, and click to deselect “Include e-mail name in subject name.”

Figure 4. If you don’t deselect e-mail name requirements, the certificate won’t be issued.

8. Click to deselect “E-mail name” in the “Include this information in alternative subject name.”

Note: This extra step isn’t necessary if an e-mail name is listed in the user’s account properties in Active Directory. If you don’t select it here, the certificate won’t be issued. See Knowledge Base 330238, “Users Cannot Enroll for a Certificate When the Include E-mail Name in Subject Name Option Is Selected on the Template.”

9. Select the Security page.

10. Select Authenticated Users and give them the Enroll and Autoenroll permissions. Click OK.

11. Repeat the process to create an AutoComputer custom template. But this time, give the Domain Computers group the Autoenroll permission.

12. Exit the console and return to the Certification Authority Console.

13. Right-click the Certificate Templates node, select New, then Certificate Template to Issue.

14. In the Enable Certificate Templates box, select AutoUser and AutoComputer and click OK. Note that the two certificates are now shown in the details pane of the Certification Authority.

Autoenrollment in Group Policy
The next step is to configure autoenrollment in Group Policy.

1. Open the Group Policy Object for the domain or the OU in which you wish to use Autoenrollment.

2. Browse to Computer Configuration | Windows Settings | Security Settings | Public Key Policy.

3. In the details pane, double-click Autoenrollment Settings and on its properties page, shown in Figure 5, and select “Enroll certificates automatically.”

Figure 5. Group Policy must be set to allow autoenrollment.

4. Select “Renew expired certificates, update pending certificates, and remove revoked certificates.”

5. Select “Update certificates that use certificate templates.”

6. Click OK to close the properties page.

7. Browse to User Configuration | Windows Settings | Security Settings | Public Key Policy.

8. Open the automatic Certificate Request Setting Policy and select the “Enroll certificates automatically” and other settings as before for computers.

9. Click OK to close.

Seeing the Results
When autoenrollment is properly set up, the new certificates will be issued when the user or computer next logs onto the domain. You can also force autoenrollment using the Certificates console. To force enrollment:

1. Open an empty Microsoft Management Console.

2. Select File | Add, Remove Snap-in; click Add.

3. Select Certificates from the list, then click Add.

4. When prompted, click Finish to add the certificates console for the logged-on user.

5. Select Certificates and click Add again.

6. This time, select the computer account, click Next, then Finish. This will add the certificate store for the local computer to the console.

7. Open each node and inspect the Personal, Certificates store to see that the AutoComputer and AutoUser certificates are not present.

8. Right-click on the Certificates– Current user node and select All Tasks, then Automatically Enroll Certificates.

9. Select the Edit menu, then select Refresh.

10. Select the Personal, Certificates node and view the details pane.

11. Double-click the new certificate and examine the Details tab. The Certificate Template Information Field shows that the AutoUser certificate has been issued.

To test autoenrollment during log-on, add users to the domain and use their accounts to log on. Create a Certificates console for them and examine it to find their certificates. If you’ve added an XP computer to the domain, test autoenrollment by rebooting the computer.