User Autoenrollment
Win2K supports autoenrollment and renewal for machine certificates. Win2K IP Security (IPSec) tunnel endpoints and domain controllers (DCs) can use this feature to automatically get and renew certificates. .NET Server extends the autoenrollment feature to users, greatly enhancing the PKI's ease of use. This feature requires extra client-side code; that code is currently bundled only with XP clients.
To set up user autoenrollment, you must make configuration changes in both the MMC Certificate Templates and MMC Group Policy snap-ins. To enable autoenrollment at the template level, open the Certificate Templates snap-in, open the template, go to the Security tab, and set the appropriate ACL settings to give users or groups the Autoenroll permission. To enable autoenrollment at the GPO level, open the Group Policy snap-in, drill down to Computer Configuration\Windows Settings\Security Settings\Public Key Policies, then open the Autoenrollment Settings Properties dialog box, which Figure 2, page 53, shows. (As in Win2K, you enable machine autoenrollment from the GPO Public Key Policies' Automatic Certificate Request Settings container.)
User autoenrollment occurs by default when the user logs on to the domain. A user can also force immediate enrollment. To do so, the user opens the MMC Certificates snap-in, opens his or her personal certificates container (i.e., the Current User or My User Account container), selects Actions, All Tasks, Automatically Enroll Certificates from the menu bar. Each time user autoenrollment occurs, a warning balloon appears in the user's system tray. When the user clicks this balloon, a dialog box appears and prompts the user to choose whether to start the autoenrollment process.
Delta CRLs
Win2K PKI's method of supporting CRLs has several disadvantages. The CRLs tend to be huge because revocation information accumulates in each CRL. Win2K CRLs support versioning, but a new version automatically inherits all revocation information from the preceding version, so a CRL becomes no smaller until a certificate expires. Also, each new CRL version causes the client to download the complete CRL, which isn't an efficient use of network bandwidth. As a result, many administrators configure longer CRL lifetimes (CRLs are cached on the client side for their entire lifetimes). But long CRL lifetimes reduce the revocation information's timeliness because new revocation information isn't immediately available.
To resolve these problems, the .NET Server PKI embeds support for delta CRLs. As Figure 3 illustrates, delta CRLs are relatively small CRLs that contain only the revocation changes that have occurred since the most recent base CRL. Because delta CRLs are small, PKI clients can download them regularly, and the CA can provide more accurate revocation information to its clients. You configure delta CRL settings in the CA's Revoked Certificates container's Properties dialog box, which you can access from the Certification Authority snap-in.
PKI for the Masses
I've described some of the most important new .NET Server PKI features, but more exist. For example, this PKI also provides enhanced role separation and administration delegation, compliant with US Common Criteria IT security standards. The .NET Server CA offers enhanced auditing options. And the PKI includes CAPICOM, a COM object that developers can use to easily provide cryptographic functions (e.g., signing, certificate store manipulation) to PKI-enabled applications.
One thing that hasn't changed (and a competitive ace that Microsoft will continue to play) is the low cost of the Windows PKI products. However, Microsoft's CA software is included only with Windows .NET Enterprise Server (formerly Windows 2000 Advanced Server) and Windows .NET Datacenter Server.
Although the .NET Server PKI might not offer all the capabilities of more advanced products, its affordability might make it attractive to a lot of smaller companies. Given the .NET Server PKI's low cost and enhanced features, it might well be the product that brings PKI to the masses. Although Windows PKI isn't proven technology—an important requirement for success in enterprises with high-end security requirements—the software will probably prove itself as it matures over the years and as more organizations adopt it. In the meantime, this upgrade to the Windows PKI is worthy of serious consideration.
Register
