Security

Previous Topic Next Topic

Client Certificate Mapping

Traditionally, computer systems have used a centralized accounts database to manage users, their privileges, and their access controls. This technique has worked well and is readily understood. However, as systems become more and more distributed—with hundreds of thousands to even millions of users—this form of centralized control becomes unwieldy. The problem ranges from trying to verify an account against a database located on the other side of the Internet to administering a very large list of users.

Certificates can often simplify these problems. They can be widely distributed, issued by numerous parties, and verified by simply examining the certificate, without having to refer to a centralized database. Sometimes a server might need to refer to a central site in order to gather certificate revocation information, but this data is cached.

Existing operating systems and administration tools can only deal with accounts, not certificates. The simple solution—one that maintains the advantages of both certificates and user accounts—is to create an association (or mapping) between a certificate and a user account. This allows the operating system to continue using accounts, while the larger “system” and the user take advantage of certificates. In this model, a user presents a certificate; the system then looks at the mapping in order to determine which user account should be logged on. For more information about public key certificates, see “Public Key Infrastructure” in the Distributed Systems Guide.

Mapping a certificate to a Windows user account can be done in one of two ways:

  1. With Microsoft® Active Directory™ directory service.
  2. With rules defined in IIS 5.0.

Note   Windows Active Directory Mapping and IIS 5.0 Native Mapping are mutually exclusive service-wide. You cannot use rules defined in one form of mapping in the other mapping form.

See the following:


© 1997-1999 Microsoft Corporation. All rights reserved.