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).
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
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
|Figure 1. You must enable ASP on IIS in order
to use the certificate enrollment Web pages. (Click image to view
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
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.
||Enroll Subject Without Requiring Any
||Users don't have to participate and
won't be aware that any changes are occurring.
||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.
||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.
||If multiple cryptographic service
providers (CSPs) are listed for the template, the user is given
||Supply In The Request
||The user must be prompted to enter
a subject name autoenrollment isn't available).
||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.
||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.
||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.
||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.
||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.
||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.