Windows 2000 Certificate Services
Microsoft® Windows® 2000 Certificate Services offers customers an integrated public key infrastructure (PKI) that enables the secure exchange of information across the Internet, extranets, and intranets. Certificate Services verifies and authenticates the validity of each party involved in an electronic transaction and lets domain users log on to a domain using the additional security provided by smart cards. This paper introduces Windows 2000 Certificate Services and describes PKI deployment in a Windows 2000 network.
On This Page
PKI Design and Deployment in Windows 2000
Appendix A. Windows 2000 Certificate Chaining
Appendix B. Interoperability and Standards
Protecting internal communications is an important requirement of the modern enterprise. Information communicated externally is often even more sensitive and must be commensurately safeguarded.
Better communication among employees, vendors, and customers enables organizations to cut costs, bring products to market faster, and build stronger and better customer relationships. These new opportunities must be kept secure, particularly in the potentially hostile environment of the Internet, where third parties could attempt to eavesdrop on information traveling over the Internet, to masquerade as others, or to interrupt the ability to do business. Countering these potential threats requires three types of security services:
Non-repudiation. A service (proof of origin) that allows the recipient of a message to verify the originator of the message.
Confidentiality. A service that creates confidence that a message can be read only by those for whom it is intended.
Integrity. A service that allows the recipient to verify that the message has not been altered since it left the originator.
Microsoft® Windows® 2000 Certificate Services lets you create a certification authority (CA) for managing the Windows 2000 public key infrastructure (PKI). A certification authority (CA) issues certificates that affirm the identity and other attributes of the certificate subject to other entities. PKI refers to a system of digital certificates (also called public key certificates) and CAs that verify and authenticate the validity of each party involved in an electronic transaction, allowing the secure exchange of information on open networks, such as the Internet, extranets, and intranets.
The first half of this document introduces Windows 2000 Certificate Services. The second half describes designing the CA hierarchy and deploying Certificate Services in a Windows 2000 network. The intended audience is system architects who plan to implement Certificate Services.
Appendix A offers additional background information about Windows 2000 Certificate Services certificate chaining. Appendix B describes Windows 2000 Certificate Services interoperability and standards.
For an introduction to cryptography and PKI concepts for readers who are not yet fully conversant with those topics, see the white paper "Cryptography and PKI Basics." For advanced information about diagnosing and troubleshooting Windows 2000 Certificate Services, including optimizing PKI deployment, see the white paper "Troubleshooting Windows 2000 PKI Deployment and Smart Card Logon."
Windows 2000 Certificate Services provides customizable services for managing certificates. You can use Windows 2000 Certificate Services to create a CA that receives certificate requests, verifies both the information in the request and the identity of the requester, issues and revokes certificates, and publishes a Certificate Revocation List (CRL). When using Windows 2000 Certificate Services, you manage certificates using the Certificates snap-in.
Windows 2000 Certificate Services Overview
Windows 2000 Certificate Services lets you do the following:
Use snap-ins. Enroll users for certificates from the CA using either the Web or the Certificates snap-in, depending on the policy used by the CA.
Use templates. Use certificate templates to help simplify the choices a certificate requester has to make when requesting a certificate, depending on the policy used by the CA.
Publish in Active Directory. Take advantage of Microsoft Active Directory™ (the Windows 2000 directory service) for publishing trusted root certificates, issued certificates, and CRLs. (In a Windows 2000 forest, publishing is the act of creating objects in the directory that either directly contain the information you want to make available or provide a reference to it.)
Use smart cards. Implement the ability to log on to a Windows-based domain using a smart card.
The following subsections introduce you to Windows 2000 Certificate Services:
Windows 2000 CA policies
Certificate revocation lists
Where CA information is published in Active Directory
CA certificate distribution
Windows 2000 CA Policies
When you install Windows 2000 Certificate Services, you have the choice of using one of two different CA policies, each having different characteristics when processing certificate requests, issuing certificates, revoking certificates, and publishing CRLs. (CA policies are unrelated to Windows 2000 group policy. However, group policy does play a role in the Windows 2000 PKI—see the section "CA Certificate Distribution.")
The two Certificate Services CA policies included with Windows 2000 are enterprise policy and stand-alone policy. You select the policy a CA uses when you install Certificate Services. Alternatively, you can set up a stand-alone CA and then replace the stand-alone policy with your own custom policy module.
The enterprise and stand-alone policies differ in how they handle interaction with Active Directory, how they handle authentication, and whether they use certificate templates:
Enterprise policy. A CA using the enterprise policy is referred to as an enterprise CA:
Active Directory. Enterprise CAs are integrated with Active Directory and are dependent on the presence of Active Directory.
Authentication. Enterprise CAs use impersonation for authenticating a certificate requestor and compare the client token against a discretionary access control list (DACL)1 set on the certificate template and on the service.
Certificate Templates. Enterprise CAs use certificate templates to craft certificates fitting a particular purpose and as a means of defining enrollment policy for the forest.
Stand-alone policy. A CA using the stand-alone policy is called a stand-alone CA:
Active Directory. Stand-alone CAs are typically not integrated with Active Directory; however, they can (optionally) take advantage of Active Directory's presence. Often, a stand-alone CA is operated offline to provide high security. (The alternative case, integration with Active Directory, occurs when a stand-alone CA is installed by a domain administrator of the root domain or by an enterprise administrator.)
Authentication. Stand-alone CAs rely on administrative action to verify the requestor's identity and to issue the requested certificate.
Certificate Templates. Stand-alone CAs do not use certificate templates.
In a Windows 2000 network, installation of either an enterprise or a stand-alone CA by a root domain administrator or enterprise administrator creates CA and CRL objects in Active Directory. Consequently, in both cases, much of the certificate chain building process and certificate revocation checking takes place using LDAP2 queries to Active Directory.
In addition, installation of root CAs (either stand-alone or enterprise) by a root domain administrator or enterprise administrator automatically places the root certificate into Active Directory, and all Windows 2000 clients on the enterprise network automatically receive copies of that CA's certificate.
Both enterprise and stand-alone CAs can issue certificates for purposes such as digital signatures, secure e-mail using S/MIME3 and authentication to a secure Web server using Secure Sockets Layer (SSL)4 or Transport Layer Security (TLS)5. In addition, enterprise CAs can issue certificates for logging on to a Windows 2000 domain using a smart card. An enterprise CA can also issue certificates that can be used to authenticate the user from a Microsoft Internet Information Services (IIS) server in the forest.
Note: Because of the added security that enterprise CAs provide when authenticating certificate requestors, all Smart Card Logon certificates and Enrollment Agent certificates must be issued by enterprise CAs. If you want this functionality in your enterprise, you must install an enterprise CA in your PKI CA hierarchy.
Enterprise CAs and stand-alone CAs are each described in greater detail in the next two subsections.
To install an enterprise CA, you choose the enterprise CA policy during installation of Windows 2000 Certificate Services. A Windows 2000 enterprise CA has the simplest administration model with the lowest overhead per certificate. It works with the following two Windows 2000 services to minimize the administrative burden of issuing certificates while providing an integrated single point of management:
Active Directory. An enterprise CA uses Active Directory as a registration database. Creating a user on a Windows 2000 domain automatically registers the user to all enterprise CAs in the forest. This lets users who have appropriate permissions request a certificate from any enterprise CA. Enterprise CAs use the information published in Active Directory for the subject contents in the certificate.
Windows 2000 security model. An enterprise CA uses the Windows 2000 security services to identify the user requesting a certificate and verifies the user's eligibility based on the user's Windows 2000 group membership.
The next three subsections describe these features of enterprise CAs:
Enterprise CA certificate templates
Enterprise CA enrollment
Enterprise CA security model
EnterpriseCA Certificate Templates
A Windows 2000 enterprise CA uses certificate templates to control the contents of the certificates that it issues. These templates define the information that goes into a certificate, the certificate extensions, and the origin of the information. They also simplify the use and management of the CA by concealing technical details of certificate contents. Windows 2000 comes with a broad set of templates, which are published in Active Directory and are global across a Windows 2000 forest.
Two types of template exist:
Single-purpose templates generate certificates that can be used only for a single application. For example, the Smart Card Logon Certificate Template is designed to be used for smart card logon. Other examples include templates for Encrypting File System (EFS)6 or S/MIME.
Multi-purpose templates generate certificates that can be used for a number of applications, such as SSL, S/MIME, and EFS. Templates exist for both computers and users for use by SSL servers or Key Distribution Centers (KDCs)7.
Here is how an enterprise CA lets users and computers request certificates:
User domain authentication. An enterprise CA uses domain authentication to identify the user; that is, it uses a person's Windows 2000 user access token as proof of identity. This means that if a user is logged on to a Windows 2000-based domain and requests a certificate from an enterprise CA, Active Directory identifies the user to the enterprise CA. All requests for certificates are processed by the CA impersonating the user to obtain the correct security context8. This enables the policy module (CA policy) to establish the rights of the user to the template and the CA. The policy module can also find the user in Active Directory.
Computer auto-enrollment. An enterprise CA uses domain authentication to identify the computer; that is, it uses the system's Windows 2000 computer access token as proof of identity. Computer auto-enrollment, activated using the Windows 2000 group policy service, is the mechanism by which computers automatically receive certificates. You use group policy to define the number of templates that can be applied to the computer. On startup, the list of certificates (located in the local machine "my certificate store") available to the computer is compared to the templates applied by group policy. If the computer does not have a certificate for each corresponding template, then the computer will enroll to an enterprise CA in the forest for a certificate for that template.
EnterpriseCA Security Model
The enterprise CA security model, designed to be global across the forest, is controlled by DACLs on Active Directory objects. DACLs control the following:
Who in the enterprise can enroll for a certificate
For what types of certificates they can enroll
From which enterprise CAs they can request a certificate
Enterprise CAs have a DACL that defines which users may make enrollment requests to them. Certificate templates in Active Directory have a DACL that defines which users can request a certificate using the template. Enterprise CAs also have a list of templates that they may use to process requests.
For a user to successfully request a certificate from an enterprise CA, three criteria must be met:
The user's group membership gives the user rights to use a template published in Active Directory.
The user's group membership gives the user rights to use an enterprise CA.
The enterprise CA has been configured to issue the template the user is requesting.
Enterprise CAs also have a DACL that governs administration of the CA. The administrative tasks performed on a CA include the following:
Changing the default CRL publishing period
Changing the list of CRL distribution points (CDPs) published in certificates by the enterprise CA. A CDP is a directory entry or other distribution source for CRLs.
Changing the list of Authority Information Access (AIA) locations published in certificates by the enterprise CA. AIA addresses are the uniform resource locators (URLs)—addresses that uniquely identify each location on the Internet—in the certificates that a CA issues that tell the verifier of a certificate where to retrieve the CA's certificate. AIA access URLs can be HTTP, FTP, LDAP, or FILE addresses.
Turning on or off publication of certificates to Active Directory
Renewing the CA
Changing the DACLs on the enterprise CA
Changing the list of certificate templates used by the enterprise CA
To install a stand-alone CA, you choose the stand-alone CA policy during installation of Windows 2000 Certificate Services. A Windows 2000 stand-alone CA, as the name implies, can function independently of Active Directory and other components in the Windows 2000 forest. You can install a stand-alone CA on a Windows 2000 server in a Windows NT® 4.0 domain as well as in a Windows 2000 forest.
When submitting a certificate request to a stand-alone CA, certificate requestors must explicitly supply all identifying information about themselves and the type of certificate desired (unlike a request to an enterprise CA, in which case the user's information is already in Active Directory and the certificate type is described by a certificate template). By default, all requests sent to stand-alone CAs are set to pending until the administrator of the stand-alone CA (using the CA snap-in) verifies the identity of the requestor and allows the request. In addition, the administrator (or the user) has to explicitly distribute the stand-alone CA's certificate to the domain user's local trust root store.
A stand-alone CA cannot issue certificates for logging on to a Windows 2000 domain using smart cards; however, other types of certificates can be issued and stored on a smart card.
Note: A stand-alone CA is not always unintegrated with Active Directory. If a domain administrator of the root domain installs a stand-alone CA in a Windows 2000 forest, then the stand-alone CA will take advantage of Active Directory and publish CA and CRL objects.
Certificate Revocation Lists
A Certificate Revocation List (CRL) is a list maintained by a CA that records serial numbers of certificates that have been revoked. Windows 2000 enterprise CAs publish CRLs in Active Directory. A stand-alone CA will publish CRLs to Active Directory if installed by an enterprise administrator. You can configure the frequency of this CRL publication schedule; the minimum period is one hour.
Because Active Directory replication9 takes time, the CRL is valid for longer than the publication scheduleby default, the CRL lifetime is 10 percent longer than the publication schedule, up to a maximum of 12 hours. If the default allowance for directory replication is insufficient, you can also configure, through the registry, the amount of time by which CRL lifetime is extended. The enterprise CA puts a uniform resource identifier (URI)10 in an extension in the certificate known as the CRL distribution point (CDP) extension. It is also possible to publish CRLs to other locations using other forms of transport, such as HTTP, FTP, and FILE URIs.
After Active Directory is updated when a CRL is re-published, the change is replicated to all domain controllers in the forest. The length of time that the replication takes depends on the bandwidth available and the replication schedule:
Intra-site replication. Within a single Windows 2000 site, LAN-speed connections between all domain controllers enable intra-site replication to complete in a matter of minutes.
Inter-site replication. Between two or more Windows 2000 sites, WAN-speed connections cause replication to take considerably more time than replication within a single site. The replication topology may require that an update cross more than one site, introducing additional delays. To allow for these delays, the lifetime of the CRL is extended. As stated above, by default the amount added to the lifetime of the CRL to allow for replication is 10 percent of the publication period (up to a maximum of 12 hours). For example, a CA configured with a publication period of 24 hours will publish a new CRL every 24 hours that is valid for approximately 26.4 hours (some minor adjustments are also made for clock synchronization, which makes the actual times slightly different).
Where CA Information Is Published in Active Directory
Many types of PKI information must be widely published. In Windows 2000, this information is published in Active Directory. Published information includes the following:
User certificates for asynchronous data exchange applications, such as S/MIME and EFS.
CA certificates for building certificate chains to trusted root authorities.
CRLs to enable checking of status (see also preceding subsection).
An enterprise CA can publish its own user certificates, CA certificates, and CRLs in Active Directory.
Active Directory includes three directory partitions for specific types of data: The domain data directory partition contains all of the objects in the directory for this domain. Domain data in each domain is replicated to every domain controller in that domain, but not beyond its domain. The configuration data directory partition contains replication topology and related metadata. Active Directory-aware applications store information in the configuration data directory partition. This data is common to all domains in the domain tree or forest. Configuration data is replicated to all domain controllers in the forest. The schema data directory partition contains all object types (and their attributes) that can be created in Active Directory. This data is common to all domains in the domain tree or forest. Schema data is replicated to all domain controllers in the forest.
The Windows 2000 operating system's global catalog, which plays major roles in logging on users (in a native-mode domain only) and in querying, is a database kept on one or more domain controllers. If a domain controller is also a global catalog, in addition to the domain data, configuration data, and schema data directory partitions, it also stores and replicates a fourth category of information: a partial replica of the domain data directory partition for all domains. This partial replica contains a subset of the properties for all objects of all domains in the forest, which is replicated to all domain controllers in the forest.
User certificates are published in the User object in the domain data directory partition. User certificates are also replicated to the Windows 2000 global catalog to provide access to the certificate across the forest.
CA certificates are published on a CertificationAuthority object and CRLs are published on a CRLDistributionPoint object in Active Directory. To ensure CA chain building and the availability of revocation status information regardless of domain structure, these objects are published in the configuration data directory partition, the contents of which are replicated throughout the forest. The CDP and AIA pointers in the certificates are constructed in such a way that they work regardless of the domain to which the domain controller belongs in the forest.
The Windows 2000 CAs have a separate optional component known as the Web client. By default, the Web client component is installed on every CA. You can also install it on any separate Windows 2000 server in the forest that is running IIS.
Each type of Windows 2000 CA has a separate Web client. The Web client lets Windows 2000 CAs support end users who are using a wide variety of browsers running on different operating systems, letting these users enroll with a Windows 2000 CA. This means that you can deploy Web-based enrollment services to support non-Windows 2000 systems separately from the CA. A CA can have any number of Web clients, so you can, for example, use a single CA to support multiple languages—you can install a French and a Chinese Web client and use the same certificate service for both.
CA Certificate Distribution
In a Windows 2000 network, three mechanisms exist by which CA certificates are distributed to Windows 2000 computers:
Enterprise root certificate store. The enterprise root certificate store is located in Active Directory. When a domain administrator installs a Windows 2000 root CA (whether enterprise or stand-alone) in the forest, the installation process also updates the enterprise root certificate store with the new certificate. In addition, administrators can use the DSStore tool in the Windows 2000 Resource Kit to add offline stand-alone CA certificates to the store. When a computer in the enterprise boots up, the contents of the enterprise root certificate store are downloaded and subsequently refreshed every eight hours. This simple mechanism distributes root certificates to all computers in the forest.
Windows 2000 Group Policy. You can also use the Windows 2000 group policy feature to distribute any CA certificate to groups of computers within the forest. If an external CA does not need to be trusted by the entire enterprise but by only a set of users or computers in a forest (such as may occur in e-commerce applications), then you can use group policy to apply the desired settings to all the computers involved.
Down-level client certificate distribution. When down-level clients enroll with a Windows 2000 CA using the Web client, the complete chain of certificates (including the root certificate) is downloaded to the client in the response from the CA to the certificate request.
All certificates have a finite lifetime. End entities (users) can simply request another certificate. However, for CAs the problem is more complex because other parties rely on the certificate; that is, CAs form part of a chain of certificates. In addition, it is highly likely that the lifetime of the CA is longer than the lifetime of the CA's certificate. Therefore, it is important that the CA be able to renew its certificate in order for it to continue to be operational. The next three subsections describe factors you need to consider in relation to CA renewal:
Time nesting on issuance
Root CA certificates
CAs that issue end-entity certificates
Time Nesting on Issuance
Windows 2000 CAs follow a policy of time nesting on issuance. What this means is that when the CA issues a certificate, it ensures that the validity period of the new certificate falls within the validity period of the CA's own certificate. If a CA's certificate is valid for only an additional six months, the longest validity period the CA will issue for a new certificate is six months. This ensures that, when a CA's certificate reaches the end of its lifetime, all certificates it has issued will also have expired. If a CA is required to issue certificates valid for one year, and its own certificate is valid only for an additional year or less, then the CA must be renewed each time it has to issue a new one-year certificate.
A root CA (which is probably an offline CA) must have a secure certificate. Because of the high cost of distribution, the temptation is simply to create a very large key and make the certificate valid for a long period. The weakness in this approach is that the longer the certificate is valid, the greater the uncertainty posed by future developments in technology, especially in cryptographic analysis.
As an alternative to creating a very large key and certifying that key for a long time, if a root CA has two certificates with the same subject name and key but different validity dates, most applications can use either certificate to validate the certificates issued by the CA. This simplifies the certificate distribution requirements. If a CA renews with the same key, it is not necessary that all relying parties have the new certificate before they can verify certificates signed by the new certificate. Distribution of the new root certificate can take place at any time after the certificate has been created and especially after the new root certificate has been used to issue new certificates.
The recommended strategy is to reduce the guesswork required by the administrator. Do this by creating a large key that, therefore, has a long lifetime, and then create certificates containing the key that have a shorter validity period than the key. For example, create a 4096-bit RSA key (which probably has a lifetime of approximately 20 years), and use it to create a certificate whose key is valid for five years. The certificate can be renewed with the same key every four years, each time with a certificate validity of five years. The key may be in use for 20 years, but each time the certificate is renewed the administrator must assess whether the key is useable for the next five years.
CAs That Issue End-Entity Certificates
CAs that issue end-entity certificates face different problems than those just described for CAs issuing root CA certificates. Considerations for renewal are also different. These online CAs process certificate requests from users and publish certificate revocation status. Revocation of an end-entity certificate occurs far more frequently than revocation of a CA's certificate. This means that the lifetimes of the keys are much shorter, and the number of certificates being managed is much larger. A CA that issues end-entity certificates has a far larger number of revoked certificates than a CA that issues only CA certificates.
The recommended strategy is to frequently renew the CA's certificate with a new key. This makes an attack on any one key less valuable to the attacker and less damaging to the victim. When a new key is created, a new CDP is also created. This ensures that the key used to sign the certificate also matches the key used to sign the CRL. Creating additional CDPs means that a number of smaller CRLs are created, rather than one large CRL, resulting in a reduction of the download time of individual CRLs. (This process of creating a number of smaller CRLS instead of one large one is known as partitioning the CRL.) Clients—either client machines or users—can tell whether they have the correct CRL by performing a signature check on the CRL; this check provides the greatest reliability when operating with other clients.
This section describes how the following topics relate to Windows 2000 Certificate Services:
Server Gated Cryptography (SGC) certificates
Third-party cryptographic service provider (CSP) support
It is a common misconception that all cryptography is export controlled. In fact, only the components that involve encryption are subject to export restrictions. These export-controlled components are the symmetric encryption algorithms and the public key technologies that deal with key exchange of symmetric cryptography session keys.
Digital signature public key technology is not export controlled, because the signed data is not encrypted. All Microsoft products can generate the same strength of signing public keys. However, export and export-controlled versions of Microsoft products differ in the strength of key exchange public keys that they can generate. Recent new export regulations mean the difference between the versions is now much smaller than before.
Windows 2000 Certificate Services perform only signing operations and use, therefore, only signing public-key pairs. The strength of the public keys that can be used to sign certificates is the same for both North American and export versions of Windows 2000. Subject key generation occurs on the client, not on the CA, and a Windows 2000 CA can therefore support both export-controlled and exportable products as clients.
Server Gated Cryptography (SGC) Certificates
Server Gated Cryptography (SGC) is part of the Windows 2000 operating system (SGC is also included with Windows 95, Windows 98, and Windows NT). Windows SGC provides strong 128-bit cryptography for online banking and other approved uses, and it interoperates with all leading vendors' implementations of SGC. SGC ensures that information exchanged between two parties can be read only by them, and that this information cannot be changed without their knowledge.
SGC is an extension of the Secure Sockets Layer (SSL) protocol. SSL is a widely used way to establish secure communications with a Web site. For example, Microsoft IIS offers the SSL protocol, which provides data encryption, server authentication, and message integrity for a TCP/IP connection.
SSL's security "handshake" initiates the TCP/IP connection. This handshake results in the client and server agreeing on the level of security they will use and fulfills any authentication requirements for the connection. Thereafter, SSL's only role is to encrypt and decrypt the byte stream of the application protocol being used (for example, HTTP). This means that all the information in both the HTTP request and the HTTP response are fully encrypted, including the URL the client is requesting, any submitted form contents (such as credit card numbers), any HTTP access authorization information (usernames and passwords), and all the data returned from the server to the client.
The difference between SSL and SGC is that SGC is used only for certain restricted purposes—primarily for protecting banking information. As a result, U.S. export law, which otherwise prohibits the export of strong cryptographic products, allows SGC to use strong cryptography throughout a great part of the world11. Because SSL, on the other hand, can be used for any purpose, U.S. export law requires that there be two versions of the product, a North American version that uses 128-bit cryptographic keys, and an international version that uses 40-bit cryptographic keys.
You can use both SGC and SSL on the same computer. The digital certificates for SSL and SGC are not interchangeable. An SGC certificate can function as an SSL certificate, but an SSL certificate cannot function as an SGC certificate. This means that both the customer and the bank must have SGC installed to use strong cryptography. If either of them does not, the session steps down to a normal SSL session.
When setting up an Internet server belonging to a qualified foreign bank, a special SGC certificate is installed in place of the usual server certificate. The server-side schannel12 sees that this is an SGC certificate and turns on 128-bit SSL. When this certificate is transmitted to the client (as part of the SSL handshake) the client-side schannel also sees that this is an SGC certificate and enables 128-bit SSL for this connection. (Neither the server nor the client is required to have a domestic version of schannel in order for this to work.)
An SGC certificate has two characteristics:
The SGC certificate has a special extended key usage (EKU) field.
The SGC certificate is issued by one of the CAs authorized to issue SGC certificates.
If an SGC certificate required only the special EKU field in a certificate to be valid, then any CA could issue an SGC certificate. Although any CA, including Windows 2000 Certificate Services, can create a certificate with the special EKU field, only certificates issued by the authorized CAs actually work.
Third-Party Cryptographic Service Provider (CSP) Support
Windows 2000 and Windows 2000 Certificate Services support third-party cryptographic service providers (CSPs). A CSP is a program installed on your computer (or on a device accessible to your computer) that performs cryptography operations such as secret key exchange, digital signing of data, and public key authentication. For both an enterprise root CA and a stand-alone root CA, the default CSP is the Microsoft Base Cryptographic Provider.
The types of algorithm that a CSP implements are not restricted by U.S. export regulations. In addition, no requirement prescribes that all CSPs must behave identically. Some CSPs are designed with end users in mind (as with smart card CSPs), and others are designed for server operation (such as PCI and SCSI cryptographic accelerator products).
PKI Design and Deployment in Windows 2000
This section describes design and deployment issues for Windows 2000 Certificate Services. It is divided into the following topics:
Designing the CA hierarchy
Certificate Services Deployment
See also the section "Optimizing PKI Deployment" in the white paper, "Troubleshooting Windows 2000 PKI Deployment and Smart Card Logon" (link in "For More Information"), which goes into detail about how to troubleshoot potential deployment problems.
Designing the CA Hierarchy
When designing the CA hierarchy, you must first decide how many CAs you need and where to locate them. This section provides guidelines for the design of your organization's CA hierarchy, organized into the following topics:
CA database capacity
Facilitating enterprise reorganization
CA Database Capacity
Microsoft has tested individual servers running Windows 2000 Certificate Services with databases having more than one million certificates. Over time, a typical user is issued several certificates depending on the applications used, the lifetime of the certificates, and so on.
As a rule of thumb, a single Windows 2000 CA is designed to support up to 250,000 users. No practical limit restricts how many Certificate Services servers a Windows 2000 forest can support. Therefore, Windows 2000 Certificate Services can support any practical user population for a Windows 2000 forest.
Even at this capacity, the database repository used by Certificate Services is operating at a fraction of its known storage capacity, and the number of certificates supported per CA will be increased significantly in future releases of the Windows 2000 Server operating system.
DCOM connectivity is required for users to enroll for a certificate from a Windows 2000 client or Web client to a Windows 2000 CA. (DCOM is a message-passing facility that allows a distributed application to call services that are available on various computers in a network.) For users to enroll for a certificate using the Web client, Web connectivity between the users and the IIS server, and DCOM connectivity between the IIS server and the CA, are required.
If the administration model of your organization is highly decentralized, you can, if appropriate, reflect this decentralization in the CA hierarchy. In addition, CA hierarchies can span multiple Windows 2000 forests: A subordinate CA can be in the same domain as the parent, in a child domain to the parent, or in a domain in a separate forest. After you create a subordinate CA, you can delegate all operations for that CA to a group of administrators assigned responsibility for that CA by group policy. In this case, the only recourse of the superior CA is that it can revoke the certificate of the subordinate CA.
Facilitating Enterprise Reorganization
Having a number of CAs rather than just one CA per organization makes administration easier because you can "move the CA." In today's world, many enterprises are in a state of flux. Corporate acquisitions and disposals require that IT infrastructure be reorganized to reflect these changes. With Windows 2000 Certificate Services, the task of reorganizing PKIs is simplified when all of the users belonging to a single CA are affected, because adding or removing a CA with its associated users to or from a hierarchy is relatively easy. However, it is impossible to move a subset of users on a single CA to a new CA without forcing them to re-enroll with the new CA. This latter case results in a significant increase in the cost and inconvenience of the change. You should consider these factors when planning your CA structure.
Windows 2000 CAs (as is also the case for domain controllers) are provided high availability by the use of multiple systems. Making multiple CAs available for enrollment in the forest ensures that at least one CA is always available to process requests.
With Windows 2000 Certificate Services, user certificates are published on the user object in the domain to which the user belongs. This requires that the CA be able to reach a domain controller in the user's domain in order to publish the user certificate to the user object in Active Directory. Therefore, not only must a user have network connectivity to the CA to make the request, the CA must also have network connectivity to a domain controller in the user's domain.
Certificate Services Deployment
The following topics for deploying Windows 2000 Certificate Services are covered in this section:
Building a CA hierarchy
Using a stand-alone CA for your offline root CA
Hardware cryptographic service providers
CRL publication period
Hardware configuration guidelines
Building a CA Hierarchy
Because you are creating a hierarchy, you must start at the top and work down—so deploy the root CA first. If the root CA is outsourced to a commercial CA, then that organization's root CA already exists. It is also their responsibility to maintain the security of the root CA.
If you choose to deploy your own root CA, then the primary requirement is that it be secure. How secure it needs to be depends on what is at stake and what is the scale of threat of attack.
The most frequently used approach is to keep the root CA offline, put it in a vault or other secure location, and use it to sign only a small number of certificates (the secured root CA is used only to sign subordinate CA certificates). This machine should not be made a member of any domain and should, in fact, not have a network card. This physical security provides the assurance that the root CA cannot easily be compromised and that any subordinate CAs on the network can be safely revoked should they become compromised.
Physical security can be enhanced by a high degree of procedural security, such as requiring multiple simultaneous operators to mutually confirm actions.
Using a Stand-Alone CA for Your Offline Root CA
In a Windows 2000 network, stand-alone CAs are designed so that they can be operated offline. The role of an offline CA is to process certificate requests from subordinate CAs. This configuration, although more secure, does add administrative overhead. During installation of a subordinate CA, a signed Public Key Cryptography Standards (PKCS) #10 certificate request is created, and this certificate request must be delivered to the offline CA by hand, using removable media. When the offline CA receives the request, it creates a PKCS #7 message containing the CA certificate from the PKCS #10 request. The PKCS #7 containing the CA certificate must then be physically carried back to the subordinate CA, and only then is the installation of the subordinate CA complete. (For more about PKCS, a family of standards for public key cryptography, see "Public Key Cryptography Standards" in Appendix B.)
In addition, administrators must manually publish certificates and CRLs to Active Directory, and they must manually update CRLs on a regular basis (determined by CRL lifetime). For information about how to accomplish this, see the section "DSStore—New Tool for Windows 2000 PKI" in the white paper "Troubleshooting Windows 2000 PKI Deployment and Smart Card Logon" (link in "For More Information"), as well as the section on offline roots in Windows 2000 Help.
Important: Be sure to change the AIA extensions and CDP locations (to the values displayed by DSStore) in the CA snap-in before issuing subordinate CA certificates from your offline root CA. (See "Appendix A. Windows 2000 Certificate Chaining" for information on the importance of these certificate extensions.)
Hardware Cryptographic Service Providers
Organizations have traditionally used hardware cryptographic service providers (CSPs) to provide enhanced performance by offloading cryptographic operation to specialized hardware. For Certificate Services, the primary goal is to safeguard the private cryptographic key material. Protecting the key material in specialized tamper-resistant hardware increases its security as well as the security of the CA and the certificates it signs. For important CAs, such as offline CAs or high-assurance online CAs, it is advisable to use a hardware CSP.
CRL Publication Period
Your organization must establish a balance between the need to publish CRL information as frequently as possible and the impact that publication has on network and server load.
Frequent CRL publication increases server load. This increase is caused by the fact that clients have to download the CRL each time it expires and is republished.
The more frequently a CA publishes a CRL in Active Directory, the faster the change in status of the certificate becomes known. However, whenever a CRL expires and is republished, the entire list of revoked certificates is republished, even if nothing has changed. Frequent CRL publication increases the amount of network traffic because Active Directory data is replicated to all domain controllers in the forest. (See the earlier section "Certificate Revocation Lists" for a description of how replication affects CRL publication; for more about troubleshooting the impact of replication on the Windows 2000 PKI environment, see the section "Latency Caused by Active Directory Replication" in the white paper "Troubleshooting Windows 2000 PKI Deployment and Smart Card Logon".)
The balance between the need for frequent publication and minimizing infrastructure impact must be reflected in the design and operation of the CA hierarchy. Many certificates do not require that revocation status be published frequently, because the certificates pose little threat. These certificates can be issued from CAs that have a long CRL publication period (such as one week). High-value certificates can be issued from other CAs that have a frequent CRL publication period (one day). Typically, an organization has few high-value certificates, so the CRL is small. Balancing publication frequency with network and server load can also be helped by issuing high-value certificates with a short validity period (three to six months) as expired certificates are removed from CRLs.
Hardware Configuration Guidelines
Certificates and certificate publication involve many variables, so hardware configuration guidelines must be general. Table 1 provides a basic guide to sizing Certificate Services.
Table 1 General hardware configuration guidelines for Certificate Services
Minimum Physical Memory
Recommended Physical Memory
Expected Database Size
Up to 10 KB certificates
Up to 200 KB
10 KB–100 KB certificates
200 KB–2 GB
100 KB–1 MB certificates
2 GB–20 GB
Database size is 1 KB–20 KB (kilobyte) per request.
Keeping both internal and external communications secure, especially information traveling across the Internet, is a critical component of modern networking systems. The Windows 2000 PKI system, Certificate Services, offers the required security services, including proof of origin, confidentiality, and data integrity.
Windows 2000 Certificate Services use CAs and the digital certificates they provide to verify and authenticate the validity of each party involved in an electronic transaction. This paper explains how the Windows 2000 Certificate Services implementation of cryptographic and PKI technologies enables the secure exchange of information across the Internet, extranets, and intranets.
Appendix A. Windows 2000 Certificate Chaining
This appendix describes certificate chaining in a Windows 2000 Certificate Services environment. These topics are discussed in the following subsections:
Trusted root certificates
Active Directory-based enterprise root certificate store
Verifying intermediate certificates
Smart cart logon certificate chain requirements
For additional information about certificate chains and their application in public key trust networks, see the PKI-related white papers and the reference to Applied Cryptography: Protocols, Algorithms, and Source Code in C in "For More Information."
Trusted Root Certificates
To be considered valid, all certificate chains must validate to a trusted root certificate. When you install a CA, these root certificates are distributed in one of three ways:
Added by a machine administrator using the Certificate Import wizard of the Certificates snap-in
Added by a domain administrator using public key group policy (Search for "public key policies" in Windows 2000 online Help for more information about this, including how to do it.)
Added from Active Directory as a result of a domain administrator installing a CA, or added by using the Windows 2000 Resource Kit DSStore tool. You use DSStore to install the root certificate into Active Directory, so that then clients can pull certificates from Active Directory when they process auto-enrollment events. (See the white paper "Troubleshooting Windows 2000 PKI Deployment and Smart Card Logon" for more about DSStore.)
Active Directory-Based Enterprise Root Certificate Store
The Active Directory-based enterprise root certificate store contains trusted root certificates. As its name implies, this store is in Active Directory; there is also a local enterprise root certificate store on individual machines. When a domain administrator installs a CA, a container—the enterprise root certificate store—is created in Active Directory under the following distinguished name13:
CN=<CA NAME>,CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=<root domain in enterprise>,DC=com
Each object in the CA's enterprise root certificate store container has a cACertificate attribute. One or more certificates in each CA container are stored under this attribute. When an auto-enrollment event is pulsed (which happens every eight hours, after a reboot, during group policy updates, or when manually pulsed using the DSStore utility), the root certificates from these containers are downloaded to member servers. This is the preferred trust propagation mechanism when using Microsoft enterprise CAs.
See the white paper "Troubleshooting Windows 2000 PKI Deployment and Smart Card Logon" for additional information about using DSStore to manage these Active Directory-based root certificates.
Verifying Intermediate Certificates
Most CA hierarchies involve several layers of CAs. Using a multi-layer hierarchy simplifies administration and lets you use a high-security configuration where root CAs are locked away in a vault and are used only for signing (or revoking) subordinate CAs.Part of the chain validation process involves retrieving and analyzing all intermediate certificates in a certificate chain. In many cases, it is possible that the client is missing all or part of the certificate chain used to validate a leaf certificate. AIA extensions are used to locate and retrieve missing intermediate CA certificates. AIA extensions are used by the CertGetCertificateChain() API, which applications call to process certificate chains.
Windows 2000 CAs embed AIA information in all issued certificates, including intermediate certificates. An AIA typically uses LDAP, HTTP, or FILE URLs to point to locations where the intermediate certificates reside. Here is an example of an ldap:/// AIA:
URL=ldap:///CN=W2K%20NTDEV%20Ent%20User%20CA,CN=AIA,CN=Public%2 0Key%20Services,CN=Services,CN=Configuration,DC=ntdev,DC=microsoft,DC=com ?cACertificate?base?objectclass=certificationAuthority
For a certificate chain to be acceptable for smart card logon, all revocation information about each certificate in the chain must be available and each CRL must be time valid. Any certificate (for a smart card or domain controller) that is revoked, or for which revocation information in unreachable, results in a logon failure.
Revocation information for a certificate is stored in each certificate under the CDP extension. As with AIAs, CDPs contain URLs pointing to locations from which the CRLs can be retrieved by applications (using the CertGetCertificateChain() API). This information is also available and viewable through the certificate user interface that you see when you double-click on a certificate in the Certificates snap-in. Here is an example of an ldap:/// CDP:
URL=ldap:///CN=W2K%20NTDEV%20Machine%20CA%202,CN=W2KMACHINE CA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=n tdev,DC=microsoft,DC=com?certificateRevocationList?base?objectclass=cRLDi stributionPoint
Note: Revoked certificates are listed by their serial number in the CRL.
Smart Card Logon Certificate Chain Requirements
Smart card logon uses X.509 version 3 certificates (described in "X.509 Version 3 Certificates" in Appendix B) as an alternative to using passwords for the Kerberos authentication process. For smart card logon to work, both the domain controller and the client must have valid certificates from Windows 2000 enterprise CAs. Both certificates must meet the following requirements:
The smart card certificate must be issued by a Windows 2000 enterprise CA in your forest.
Each certificate in the certificate chain must be acquirable; that is, already on the machine or reachable through common network transports (such as http:, ldap:, or file paths). This means that all revocation information for each certificate in the certificate chain is reachable.
All revocation information for each certificate in the certificate chain must be time valid.
Each certificate in the chain must not have been revoked.
Both certificates must chain to trusted root certificates.
Smart card certificates must be based on SmartCard Logon, or SmartCard User certificate templates.
Appendix B. Interoperability and Standards
This appendix describes standards implemented by Windows 2000 Certificate Services, and it documents which options in the standards are implemented. It also describes how and where the standards are used by Certificate Services. These issues are discussed in the following subsections:
International Telecommunications Union (ITU)
Internet Engineering Task Force (IETF)
Public Key Cryptography Standards (PKCS)
International Telecommunications Union
The International Telecommunications Union (ITU) is an organization, comprised of more than 150 member countries, that sets communications standards. ITU provides a mechanism that lets governments and the private sector coordinate global telecom networks and services. ITU-T is the sector of the ITU responsible for telecommunications standards. ITU-T's responsibilities include standardizing protocols for networks and facsimile transmission and standardizing modem design and operations.
X.509 Version 3 Certificates
Most certificates in use today are based on the X.509 standard set by ITU-T. The standard certificate format used by Windows 2000 certificate-based processes is the X.509 version 3 certificate.
An X.509 certificate includes the public key and information about the person or entity to whom the certificate is issued, information about the certificate, plus optional information about the CA issuing the certificate. Subject information may include the entity's name, the public key, the public-key algorithm, and an optional unique subject ID. Standard extensions for X.509 version 3 certificates accommodate information related to key identifiers, key usage, certificate policy, alternate names and attributes, certification path constraints, and enhancements for certificate revocation, including revocation reasons and CRL partitioning by CA renewal.
Using industry-standard X.509 version 3 certificate formats and open interfaces lets Windows 2000 Certificate Services interoperate with many other products and technologies that support the use of public-key cryptography and PKI.
Internet Engineering Task Force
The Internet Engineering Task Force (IETF) is an open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture. The IETF is divided into several working groups organized by topic areas. Each workgroup produces standards relating to the Internet for its area. Each standard is identified by its Request for Comments (RFC) number. A standard may subsequently be revised, in which case a new RFC number is issued, making the original RFC obsolete.
The IETF working group charged with defining the basis for an interoperable PKI is PKIX. (For the PKIX Web site, see "For More Information.") PKI standards for the Internet are still evolving. However, Microsoft designed Certificate Services to adhere to existing PKI interoperability standards. Specifically, Microsoft intends to conform Windows 2000 Certificate Services to the requirements of RFC 2459 (described next).
The RFC 2459 specification is one part of a family of standards for the X.509 PKI for the Internet. RFC 2459 profiles the X.509 version 3 certificates for use on the Internet. The following subsections describe these features of RFC 2459:
Directory names in certificates
Certificate and CRL extensions
Windows 2000-specific extensions
Year 2000 and certificates
International character sets and DNS names
Directory Names in Certificates
Windows 2000 CAs conform to the requirements of RFC 2459 governing how directory names contained within the subject, issuer, alternate Subject Name, and alternate Issuer names should be encoded in the certificates. The three types of encoding for directory names defined in RFC 2459 for use with certificates are PrintableString, BMPString, and Unicode Transformation Format 8 (UTF-8). TeletexString encoding is also permitted to support clients who do not conform to this RFC. Each type of encoding supports a different character set. The character set used for the names in the certificates dictates the type of encoding that must be applied.
PrintableString encoding is used by default. The character set supported by PrintableString encoding is a subset of the ASCII character set. It consists of the following characters:
(space) ' ( ) + , - . / : = ?
If the PrintableString character set is insufficient to represent the name, BMPString is applied. BMPString is the Unicode character set, so it can represent most international character sets (Unicode uses two bytes for each character, which gives it 65,536 character combinations). Where the PrintableString character set is insufficient and where the client enrolling is known not to support Unicode, then it may be possible to apply the TeletexString character set. The Windows 2000 platform does not currently support UTF-8 encoding.
A number of PKI products cannot support Unicode in certificates. This lack of support can result in interoperability problems that are difficult to diagnose. Most vendors have indicated their intent to support RFC 2459. As more products are updated and support these types of encoding, problems will diminish. At present, it is important to verify that all the PKI products using certificates from a Windows 2000 CA can support Unicode encoded directory names in certificates before using directory names containing characters outside of the PrintableString character set.
RFC 2459 specifies a large number of extensions, many of which are optional. Many extensions contain further options. One of the biggest challenges of interoperability with PKI products using RFC 2459 is the number of permutations of options that this standard permits.
Windows 2000 CAs use the RFC 2459 extensions shown in Table 2 in the certificates that they create.
Table 2 Windows 2000 uses these RFC 2459 CA certificate extensions.
Certificate and CRL Extensions
The following bullets describe some of the important certificate and CRL extensions listed in Table 2:
Basic constraints. The Basic constraints extension is used only in CA certificates; it contains a Boolean flag to indicate a CA certificate. The Basic constraints extension is marked critical in the certificate. Windows 2000 enterprise and stand-alone CAs do not currently support the path length option in this extension.
Key usage. The Key usage extension defines the cryptographic operations for which the key pair can be used. The possible options are:
The Key usage extension in CA certificates asserts digital signature, certificate signing, and CRL signing. Digital signature is asserted, in addition to certificate and CRL signing, because the CA often needs to sign objects other than certificates and CRLs. End-user certificates have three possible combinations:
Signature only. For certificates that can be used only for signature, Digital Signature is asserted.
Key exchange only. For certificates that can be used only for Key exchange; Key encipherment and Data encipherment are asserted with RSA keys. Windows 2000 CAs do not support Diffie-Hellman public keys.
Both signature and key exchange. For certificates that are required to perform both signing and key exchange operations, Digital signature, Key encipherment, and Data encipherment are asserted.
CRL distribution points (CDPs). The CDP extension indicates where the CRL is published, and this location contains the revocation status of the certificate. Windows 2000 CAs use a series of URI types with different transports. Enterprise CAs by default use LDAP and HTTP URIs. Stand-alone CAs use HTTP and FILE URIs. If additional locations are required, you can modify the list of URIs using the CA Microsoft Management Console (MMC) snap-in.
Authority Key Identifier (AKI). The AKI extension identifies which key was used to sign the certificate. This is a useful indicator if the CA has been renewed and potentially has several keys. Windows 2000 CAs can also optionally include the certificate issuer name and serial number, which identify the certificate of the CA that issued the certificate. This option can be useful in high assurance applications.
Authority Information Access (AIA). The AIA extension indicates where the issuing CA's certificate is published. Most PKI protocols include the full certificate chain, but this is not guaranteed. Windows 2000 CAs use a series of types of URI with different transports. By default, enterprise CAs use LDAP and HTTP URIs. Stand-alone CAs use HTTP and FILE URIs. If additional locations are required, you can modify the list of URIs using the CA MMC snap-in.
Subject Alternate Name. Users' certificates have many types of name for identification. Enterprise CAs include the e-mail and Kerberos names in the Subject Alternate Name extension.
Windows 2000-Specific Extensions
Windows 2000 enterprise CAs include two Microsoft-specific extensions. These extensions are used for management purposes:
Certificate Template. This extension is used by enterprise CAs to identify which template was used to create the certificate.
CA Version. The CA version number tracks how many times the CA has been renewed and how many signing keys are in the possession of the CA.
Year 2000 and Certificates
Certificates and CRLs contain dates. For certificates, the dates indicate the lifetime. For CRLs, the dates identify when the CRL was generated and when the next CRL is expected to be generated. RFC 2459 specifies that for dates in the range of 1949–2050, a two-digit year will be used. For dates after 2050, a 4-digit year will be used. Windows 2000 Certificate Services conforms to these recommendations.
International Character Sets and DNS Names
The IETF ensures that all new RFCs include provisions to support international character sets by mandating the use of UTF-8 or by specifying a timetable designating when UTF-8 must be supported—the PKI standards require that UTF-8 be supported by 2003. This is an ongoing process and not all areas have reached the same degree of maturity. One such area concerns how to represent international character sets in URIs. When Windows 2000 Certificate Services were functionally complete, no standard existed concerning how this should be done. URIs are used within certificates to indicate the location where CRLs and CA certificates are published. The URIs are partially derived from the server DNS name for the CA. Therefore, Windows 2000 CAs do not support international character sets in the server DNS name.
Public Key Cryptography Standards
Public Key Cryptography Standards (PKCS) are a family of standards for public-key cryptography that were developed by RSA Laboratories in collaboration with Apple, Digital, Lotus, Microsoft, MIT, Northern Telecom, Novell, and Sun. PKCS describes the syntax for a number of data structures used with public key cryptography.
Specifically, PKCS describes the syntax for the following:
Digitally sign a message. How to digitally sign a message in such a way that others can verify who signed the message, and that the message has not been modified since it was signed.
Encrypt a message. How to encrypt a message without any prior data exchange with the recipient in such a way that no one, other than the recipient, can decrypt the message.
Ensure requester has private key. How to make a certificate request to a CA in such a way that the CA can verify that the message was signed with the public key contained in the request, thereby ensuring the requestor is in possession of the private key.
The standards are identified by number (1–15). The following PKCS numbers are used by a Windows 2000 Certificate Services CA:
PKCS #1. PKCS #1 describes how digital signatures are constructed using the RSA public key algorithm in conjunction with hash algorithms. It also describes how symmetric keys are encrypted for key exchange using the RSA algorithm. This standard is used in conjunction with PKCS #7 for defining how to construct signed messages. PKCS #1 also describes how to represent RSA public keys and private keys. Windows 2000 Certificate Services follows RFC 2459, which references PKCS #1 for how to construct signatures for X.509 certificates using RSA, and when representing RSA public keys in X.509 certificates.
PKCS #7. PKCS #7 describes how digital signatures and encryption are applied to any block of data. It also describes how, in addition to the data, other attributes, such as the message signing time, can be included in the message and protected by the same signature. A special form of a PKCS #7 message, known as a degenerate message, is used for transporting certificates and CRLs. PKCS #7 also specifies how data can be encrypted using a symmetric-key algorithm to encrypt the data (for example, a content-encryption algorithm) and an RSA public key for encrypting the symmetric keys (for example, a key-exchange algorithm).
PKCS #10. PKCS #10 describes how to construct a certificate request message. A certificate request consists of a public key and an optional set of attributes, such as the distinguished name or the e-mail name of the requestor, which is signed by the private key matching the public key in the request. PKCS #10 messages are the standard that Windows 2000 Certificate Services uses to receive a certificate request. After Windows 2000 Certificate Services receives a request, it then processes the request, issues the X.509 certificate and returns it to the requestor, or, it denies the request. The information returned to the requestor is either in the form of a single X.509 certificate, or the certificate plus its chain up to the root certificate (in the form of a degenerate PKCS #7 message).
For More Information
For the latest information on Windows 2000 Server, check out our Web site at http://www.microsoft.com/windows2000/. For additional information, see Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C. 2nd Ed. John Wiley & Sons, 1995. This is a common cryptography primer.
|1||In Windows 2000, an access control list (ACL) is a list of security protections that apply to an entire object, a set of the object's properties, or an individual property of an object. Each Active Directory object has two associated ACLs: The discretionary access control list (DACL) is a list of user accounts, groups, and computers that are allowed (or denied) access to the object. A DACL consists of a list of access control entries (ACEs), where each ACE lists the permissions granted or denied to the users, groups, or computers listed in the DACL. An ACE contains a SID with a permission, such as Read access, Write access, or Full Control access. The system access control list (SACL) defines which events (such as file access) are audited for a user or group.|
|2||LDAP, a directory service protocol that runs directly over TCP/IP, is the primary directory access protocol used to add, modify, and delete information stored in Active Directory, as well as to query and retrieve data from Active Directory. Active Directory clients must use LDAP to obtain information from Active Directory or to maintain information in Active Directory. Active Directory uses LDAP to enable interoperability with other LDAP-compatible client applications. Given the appropriate permission, you can use any LDAP-compatible client application to browse, query, add, modify, or delete information in Active Directory.|
|3||MIME is a common method for transmitting non-text data through Internet e-mail. MIME encodes non-text data as ASCII text and then decodes it back to its original format at the receiving end. S/MIME is an extension of MIME that supports secure mail. It enables message originators to digitally sign e-mail messages to provide proof of message origin and data integrity, and it lets messages be transmitted in encrypted format to provide confidential communications.|
|4||Secure Sockets Layer (SSL) is a proposed open standard developed by Netscape Communications for establishing a secure communications channel to prevent the interception of critical information, such as credit card numbers. Primarily, it enables secure electronic financial transactions on the World Wide Web, although it is designed to work on other Internet services as well.|
|5||Transport Layer Security (TLS) is a standard protocol used to provide secure Web communications on the Internet or intranets. It enables clients to authenticate servers or, optionally, servers to authenticate clients. It also provides a secure channel by encrypting communications for confidentiality.|
|6||EFS, a new feature in Windows 2000, protects sensitive data in files that are stored on NTFS-formatted volumes. EFS uses symmetric key encryption in conjunction with public key technology to provide confidentiality for files.|
|7||The KDC is a network service that supplies session tickets and temporary session keys used in the Kerberos authentication protocol. In Windows 2000, the KDC runs as a privileged process on all domain controllers. The KDC uses Active Directory to manage sensitive account information, such as passwords for user accounts.|
|8||Security context refers to the security attributes or rules that are currently in effect. For example, the rules that govern what a user can do to a protected object are determined by security information in the user's access token and in the object's security descriptor. Together, the access token and the security descriptor form a security context for the user's actions on the object.|
|9||For a general description of Active Directory replication, see the link to the white paper "Active Directory Architecture" in "For More Information." For a detailed discussion, see the link to the Web document "Active Directory Replication."|
|10||A URI is a character string used to identify a resource (such as a file) from anywhere on the Internet by type and location. URIs include Uniform Resource Names (URNs) and Uniform Resource Locators (URLs).|
|11||SGC is generally available to qualified banking and financial institutions worldwide. Exceptions include banks and financial institutions that are located in countries subject to a U.S. embargo (a partial list as of this writing includes Cuba, Iran, Iraq, Libya, North Korea, Syria, and Sudan) and several additional restricted destinations (a partial list includes Russia and the People's Republic of China).|
|12||The Secure Channel (schannel) security package supports the public-key based protocols Secure Sockets Layer (SSL) versions 2 and 3 and Transport Layer Security (TLS). TLS is the IETF standard for SSL and for the Private Communication Technology (PCT) protocol. Schannel determines which of these protocols to use when communicating with another machine. The SSL, TLS, and PCT protocols use certificates to represent identity. IIS 5.0 ships internationally with an SCHANNEL.DLL file that supports standard 40-bit encryption schemes. Additionally, if the IIS server gets an SGC Certificate from a CA, the SCHANNEL.DLL supports creating a 128-bit channel using the SGC Certificate keys.|
|13||Every Active Directory object has an LDAP distinguished name (sometimes abbreviated DN). For information about how Active Directory handles LDAP DNs, see the reference to the white paper "Active Directory Architecture" in "For More Information."|