Types of Security

Windows 2000 and Active Directory have three primary security mechanisms.

• Kerberos

• Public key infrastructure (PKI)

• IP Security (IPSec)

All three of these overlap in some ways and are distinctly different in other ways. They are used for different purposes in an Active Directory deployment. To design a security strategy that takes best advantage of the different security offerings in Windows 2000, it is important to understand the differences of the three primary security mechanisms.

Kerberos

Kerberos is the default authentication protocol utilized by Active Directory and Windows 2000. The version of Kerberos used by Windows 2000 is based on the Massachusetts Institute of Technology (MIT) Kerberos version 5 and has been extended to support public key authentication. Active Directory is the security account database for the Windows 2000 implementation of Kerberos.

Kerberos is a standards-based method of authentication. There are two primary versions of Kerberos: the version started and supported by MIT, and a variation now known as distributed computing environment (DCE) Kerberos. Microsoft opted to base the version of Kerberos in Windows 2000 on the MIT version because of its broad market acceptance. The Kerberos protocol provides several advantages over NTLM, the previous form of authentication in Windows NT.

• Interoperability —Kerberos provides a framework for interoperability with Kerberos implementations on other networks with different operating systems.

• Client and Server Authentication —Previously, with NTLM authentication , it was only possible for a client computer to authenticate to a server. However, it was not possible for a client computer to verify the identity of a server. Consequently, it was possible for someone to switch the server on the backend of a client connection and replace it with a different server than the one with which the client originally authenticated. Kerberos provides for mutual authentication, which enables clients to authenticate the servers to which they connect.

• Efficient Authentication —Kerberos provides for the authentication of clients by applications or file servers, rather than strictly by Domain Controllers (DCs), as was the case with NTLM authentication.

Kerberos authentication is provided via the exchange of secret keys between a client and server, or between a server and another server, on a network. The secret keys utilized in the authentication process never actually cross the network. Instead, they are used to encrypt information sent from one party to another. Another key is then used by the receiver to decrypt the information. The two keys used are known only by the two parties involved. One of the primary reasons the Kerberos protocol is so secure is that each participating party, whether client or server, in an authenticated session has its own encryption key. These keys are distributed by a key distribution center (KDC) .

The KDC in Windows 2000 is integrated on a DC just like any other Windows 2000 service. The KDC utilizes Active Directory as the security repository of account information for all the security principals in the KDC realm. The concept of a realm in Kerberos is similar to the concept of a Windows NT domain. In Windows 2000, the Kerberos realm is referred to as a domain.

Every DC in the domain has a KDC running, as well as a copy of Active Directory. Consequently, it is possible for clients to access Kerberos authentication information from every DC. Although the Kerberos protocol specification does provide a definition for the replication of data between KDCs and security databases, Windows 2000 does not utilize Kerberos replication. Instead, it utilizes Active Directory replication.

For each security principal in the domain (user, client or server) the KDC stores a cryptographic key known only to the principal and the KDC. This key is used in Kerberos protocol exchanges between the KDC and the security principal. This long-term key, as it is known, is derived from the user's logon password.

If a client wants to access resources on a server, the client sends a request to the KDC for a short-term session key. This short-term session key is used by the server and the client during the pending session. The KDC encrypts a copy of the short-term session key for the client with the client's long-term key. The KDC also encrypts the short-term session key for the server with the server's long-term key. Both short-term session keys are then sent to the client in a single data packet. The KDC is the primary intermediary between security principals (clients and servers) in a Kerberos domain, as shown in Figure 15.1.

After the KDC has issued the encrypted session keys, the steps to establishing a session can be launched:

One of the advantages of Kerberos over NTLM authentication is that clients can ask for mutual authentication, as shown in Figure 15.2. If this has been requested by the client, the server uses its copy of the short-term session key to encrypt the timestamp from the client's authenticator information and sends the encrypted packet back to the client as the server's authenticator.

Ticket Granting

Another aspect of Kerberos authentication that is important to understand is the concept of a ticket-granting ticket (TGT) . Each time that a user logs on to a workstation, the long-term key is calculated by the Kerberos client on the workstation. The password is converted to a cryptographic key and is then passed to the KDC for authentication. The KDC then retrieves another copy of the user's long-term key from the security database, Active Directory. This ticket is compared with the ticket received from the client. If the two tickets are the same, the KDC returns a session ticket for the KDC, known as a TGT, to the client. The use of a TGT enables the KDC to respond to requests for other session tickets from the client without having to retrieve the user's password from Active Directory each time a new session is required. This helps to limit the load on the DC hosting the KDC and to increase performance for the client.

Inter-Domain Authentication

In previous versions of Windows NT, it was necessary to establish explicit trust relationships between domains for clients and servers to establish authenticated sessions if the client was in one domain and the server in another domain. With Kerberos authentication, this is not the case. With Kerberos authentication in place, it is possible for a client to obtain a TGT from a KDC in one domain and use it to request a session ticket from a KDC in another domain, using an explicit trust between the two domains.

Authentication across domain boundaries is enabled by the sharing of an inter-domain key between domains. This occurs automatically between Windows 2000 domains in the same Forest. This can also be configured manually by establishing explicit trusts between domains. After the two domains have exchanged inter-domain keys, the ticket-granting service of each KDC is registered in as a domain security principal in the security database of the other KDC. After this has happened, the ticket-granting service in each domain can treat the ticket-granting service in the other domain as a regular service for which clients can request session tickets.

If a client requests access to a service that is in another domain, the KDC in the user's domain responds to the client's request with a TGT encrypted with the inter-domain key. This is called a referral ticket. The client then uses this referral ticket to request a session ticket from the KDC in the other domain.

PKI

In the previous section, Kerberos was examined as an encryption and authentication protocol. The basic assumption with Kerberos authentication is that the cryptographic key that is used to encrypt a packet of data is the same key that is used to decrypt it. This is known as symmetric key cryptography, or secret key cryptography. A cryptography system based on a PKI is fundamentally different from Kerberos. PKI relies on encryption and authentication based on keys that are not symmetrical. Every participant in the encryption/decryption process has a pair of keys—one public and one private. Users make their public key available to other users who want to send encrypted data. This data can then be decrypted by using your private key.

In addition to being able to encrypt data without a prior exchange of secret or symmetrical keys, public key cryptography also enables the use of digital signatures. Digital signatures can be used to verify that a document, or email message, was originated by a specific user. The users can "sign" the message with a digital signature that has been encrypted by the private key in a key pair. The public key can then be used to validate whether the signature originated from the private key and has not been altered.

Certificate Authority

In the case of Kerberos, symmetrical keys can be exchanged between the users of the cryptography system because each user trusts Active Directory and the KDC as a security authorities. Each user can trust that when the KDC delivers a session ticket for a specific service, it is the correct ticket. In the case of public key encryption, there is no mechanism for explicit trust, such as the KDC, between parties in the encryption process. Consequently, a trust broker must be established. This trust broker is commonly called a Certificate Authority (CA) because the most common way to verify the authenticity of public keys is via an accompanying certificate.

A CA issues certificates that are digitally signed by the issuer (the CA) and attests to the validity of the public key and the identity of the key's owner. The certificate typically contains additional information about the key's owner, such as what company they work for and what their contact information is.

An example of a public CA is VeriSign, which issues certificates for individuals wanting to encrypt and sign email and documents. As public key encryption becomes more widespread across the Internet, more and more companies are beginning to implement their own CAs, or they are beginning to utilize the services of other organization's CAs.

PKI in Windows 2000

In Windows 2000, PKI does not replace the need for Kerberos as the default authentication protocol. Instead, PKI is utilized as an extension of the security service provided by Kerberos. PKI can provide for scalability and extensibility beyond what Kerberos provides in a Windows 2000 domain environment.

The first basic element of the PKI in Windows 2000 is the Microsoft Certificate Services, which provides the mechanism to establish a CA for the organization. Certificate Services manages the issuing of certificates to validated users and verifies that all certificates issued are consistent with the public key security policy for the organization. The service also manages relationships with other external CAs that might be trusted by the PKI in the organization.

For example, in Wadeware, there might be a need to provide external vendor access to a server in the finance department to submit invoices on a monthly basis. The administrators for Wadeware can establish a trust with the vendor's external CA; this then enables all client certificates issued by the vendor's CA to be used for authentication to resources in the Wadeware domain environment.

The PKI within Windows 2000 is based on the concept of a CA hierarchy. A CA hierarchy is based on the parent-child relationships that are established between CAs. A parent-child relationship stipulates that a CA, which has issued a certificate, is trusted by a root CA. This way, any other CA has only to verify the validity of a certificate by contacting the root CA, not by having to navigate the CA hierarchy.

The concept of a CA hierarchy in Windows 2000 requires that there is a plan established for when and why to segment the CAs in an organization. There are essentially three reasons why CAs should be segmented into a hierarchy. These reasons tend to follow the same logic for dividing the domain structure into multiple OUs; however, there are also some key differences.

• Geographic Distribution —Organizations might divide CAs in to a hierarchy based upon geographic segmentation of network resources and users. If there were slow wide-area network connections between geographic locations, it would be necessary to place a CA at each geographic location so that clients could seek certificate validation without a dramatic impact to performance. In this type of configuration, there is usually a root CA based at the organization headquarters, which would trust all the regional CAs, as seen in Figure 15.5.

• Business Segmentation —As with the distribution of organization units discussed earlier in the book, it might be necessary to distribute the CA hierarchy according to the business segmentation of the company. In the case of Wadeware, it might be necessary to have a CA for the manufacturing department, a CA for the Sales department, and a CA for the mergers and acquisitions group. All these CAs are trusted by a root CA, which is managed by the Information Technology (IT) department, as seen in Figure 15.6.

• Load and Usage —It might also be necessary to segment a CA hierarchy based upon the measured or expected load that is placed on the CAs or by the type of function that the CA performs. One CA might be used for issuing and verifying certificates for email, whereas another is used for external vendor network authentication. The types of security policies and the client load on these CAs would differ greatly, and so, it would be wise to segment them in to a CA hierarchy, as seen in Figure 15.7.

Windows 2000 PKI and Microsoft Exchange

One of the first applications that organizations find for the PKI in Windows 2000 is integration with the key management services in Microsoft Exchange 2000 and later versions. By leveraging PKI and public key encryption, it is possible to provide Exchange and Outlook users with S/MIME (secure MIME), which includes encryption and digital signature capability. By deploying Windows 2000 and Active Directory, it is possible to provide the integration of secure and signed mail between disparate Exchange organizations.

IPSec

IPSec is a security mechanism that can be leveraged in a Windows 2000 environment with practically no impact to users and with minimal need for additional training. The reason for this is that IPSec is a security protocol that exists entirely below the transport level, and it is transparently inherited by all applications over the transport level. IPSec supports network-level authentication, encryption, and data integrity.

The IPSec protocol definition provides for the encryption of all data traffic that crosses a network from one host to another. To do this, IPSec uses an authentication header and an encapsulated security payload for each data packet. The authentication header enables the receiving host to identify that the sending host is indeed the desired host. The encapsulated security payload ensures that the data, which is received, has not been tampered with since it was sent.

IPSec relies upon a combination of both secret key cryptography and public key cryptography. In the case of an encapsulated security payload, only the sending and receiving hosts know the secret key for encryption and decryption. As with Kerberos, if the authentication data is valid, the receiving host knows that the data came from the sending host, and that it was not tampered with during transit.

To create the authentication header, two hosts on a network exchange public information. The public information of each host is then combined with its own secret information, and the result is the shared-secret value. This is known as the Diffie-Hellman technique. After the authentication header has been created, the sending host then uses data encryption standard-cipher block chaining (DES-CBC) to generate a random number that is used with the shared-secret value to encrypt the encapsulated security payload.

Because IPSec is completely transparent to users and to applications on the network, it is entirely up to the Network Administrator to decide when IPSec security policies should be applied. Security policies can be assigned to the default domain policy, the default local policy, or to a customized policy that the administrator creates. When hosts log in to a domain, they automatically assume the properties of the default domain and default local polices, which includes the IPSec policy assigned to the domain.

To establish security policies for a Windows 2000 and Active Directory implementation, administrators should follow three steps: