Home > Articles > Information Technology

Exchange 2000 Security

  • Print
  • + Share This
Like this article? We recommend

Kerberos Authentication

On any secured network, before access to a resource is granted, the requestor must first provide proof of identity. This process is known as authentication. In Windows NT, the NTLM authentication protocol provides servers with the capability to identify clients requesting access to a resource. Servers on an NT network are assumed to be trusted resources, with clients having no reason to verify server identities.

The authentication framework changes in Windows 2000 with the introduction of the Kerberos standard.


The name Kerberos is taken from Greek mythology, associated with the three-headed dog responsible for guarding the gate to the underworld. This mythical beast is best known by his Latin name, Cerberus.

Kerberos authentication is limited to Windows 2000 domain controllers and Windows 2000 clients. Windows 9x clients can install the Directory Services client to utilize Kerberos, but Windows NT clients must be upgraded to Windows 2000. To provide for backward compatibility, Windows 2000 maintains the NTLM protocol for authentication of down-level clients. In addition, Windows 2000 servers utilize NTLM authentication when accessing resources in Windows NT domains.

The Kerberos version 5 protocol integrated with Windows 2000 is designed without the trusted server assumption and allows both the server and the client to verify the identity of each other. This process is known as mutual authentication.

Mutual authentication requires a trusted third party, the Key Distribution Center (KDC), to verify the identity of all participants. Before a network connection is opened between a client and a server (or between a server and a server), the KDC will verify the identity of each participant. After all identities have been verified, the KDC will ensure that each participant in the connection that the other participants are authentic.

Kerberos is based on the use of shared secret keys for authentication. The secret key is unique to each client because it is a hashed derivative of the user's logon password. When a user logs onto a Windows 2000 domain controller, the user's password is captured in volatile memory on the workstation and run through a one-way hashing algorithm to generate a key. The key is passed to the Key Distribution Center for verification. The KDC is a service that runs on all Windows 2000 domain controllers and uses password information in Active Directory to determine the identity of a client. At the KDC, the key information obtained from the workstation during logon is compared to the key entry for that user in the Active Directory. If the keys match, the user is authentic and the KDC replies by sending a special session ticket to the workstation called a ticket-granting ticket (TGT). Because both the client and the KDC are aware of the secret key, the authentication method is known as shared secret key.

The Microsoft implementation of Kerberos provides extensions to use private/public key pairs from a Certificate Authority for logon authentication. With this method, an additional layer of security is added because the client is identified using the shared secret key but must request a TGT using an X.509 private key certificate. The KDC validates the private key using the client's public key certificate stored in the user object of the Active Directory. After the authentication has completed, the client is issued a TGT. The private/public key method of Kerberos authentication is implemented only during the initial logon process. Subsequent connections with the KDC are negotiated using standard Kerberos protocols.

Every connection between a Windows 2000 client and Windows 2000 server (or service) requires a unique Kerberos session ticket. Before making a connection to a service, the client requests a session ticket for that service from the KDC. To save resources and processing requirements, the KDC does not maintain a list of all authenticated security principles. Instead, a ticket-granting ticket is given to the client during the initial authentication process. When a client later requests a session ticket for a service, the TGT is passed back to the KDC as evidence of the client's authenticity and capability to request session tickets. If the TGT is valid, a new session ticket for the requested service is generated and given to the client. The client uses this session ticket to authenticate with the target server, create a session, and access the requested service.

In reality, the client receives two copies of the session ticket from the KDC. The first copy is encrypted using the client's secret key. Included in the client's copy of the session ticket is a KDC-generated key that will be used to negotiate a session between the client and the target server. The decrypted session key information is placed in a secure cache on the client. By keeping a copy of the session ticket in cache, future connections to the same server will not require a request to the KDC for a new session ticket. Cached session tickets are valid for the length of time specified in the Kerberos policy for the domain.


You can view basic information on cached session tickets by using the KLIST utility in the Windows 2000 SDK.

In addition to the client copy of the session ticket, the client receives a copy to present to the target server. Included in the server copy of the session ticket is the session key, verification of the client's identity, and the user's access token (individual SID and group SIDs). The target server is the only principle capable of decrypting the server copy of the session ticket because it is encrypted by the KDC using the target server's secret key. After the target server has decrypted the ticket, verified the client's identity, and determined the client's access rights, a session is negotiated. If the client requested authentication of the target server (mutual authentication), an additional step is taken before the session is established. The target server encrypts the time stamp of the session ticket using the server's copy of the session key. This information is returned to the client and decrypted using the client's copy of the session key. If the decrypted time stamp matches the client's copy, the server is authentic because the session time stamp and session keys match.


Time synchronization within the domain is a critical component of Kerberos. All clients and servers should be configured for time synchronization with a reliable source. Windows 2000 comes with the Windows Time service and can be configured using the NET TIME command line and a new /SETSNTP: switch.

Kerberos authentication can play a foundational role in the security configuration of your Exchange organization. Kerberos surpasses the authentication capabilities of the NTLM protocol and helps ensure a more secure environment, especially when used in conjunction with X.509 certificates.

Trust Relationships

Kerberos is critical for the Windows 2000 implementation of domain trust relationships. Trusts enable clients from a trusted domain to access resources in a trusting domain. For example, a Software Spectrum user located in Garland who logs onto Domain A needs access to a resource in Domain B. Because Domain B, located in Los Angeles, has a trust relationship with Domain A, the Domain B resources are available to this user. In previous versions of Windows NT, all trust relationships were manually configured and were not transitive. For example, if A trusted B, and B trusted C, A did not automatically trust C. A separate trust relationship between A and C had to be created. Windows 2000 extends the trust model by providing transitive trusts in any Windows 2000 forest. Kerberos credentials issued in one domain of a Windows 2000 tree are accepted by Kerberos services in any other domain of that tree. In addition, any tree trusts the Kerberos credentials issued by any other tree in the Windows 2000 forest. This is considered a transitive trust environment.

For many organizations, not all domains will fall under the same Windows 2000 forest. Some companies will have multiple forests or retain several NT domains within the company. Trusts between these domains must be created manually. There are several types of trusts:

  • One-way—Domain A trusts domain B (A =>B). Users in Domain B (the trusted domain) can be granted access to resources in Domain A (the trusting domain). Users in Domain A cannot be granted access to resources in Domain B because B does not trust A.

  • Two-way—Domain A and Domain B trust each other (A<=>B). Both Domain A and Domain B are trusted and trusting domains. Users in either domain can be granted access to resources in the other domain.

  • Transitive—Transitive trusts are always two-way trusts and are accessible by any other domain that is trusted. For example, A<=>B, B<=>C; therefore, A<=>C.

  • Nontransitive—Nontransitive trusts do not extend to domains beyond the domains that established the trust. Trusts in Windows NT are nontransitive.

When authentication must occur between trusting Windows 2000 and Windows NT domains, nontransitive NTLM trusts are used for pass-through authentication. All trusts (with the exception of trusts automatically created within a forest) are created using the Domains and Trusts MMC snap-in for Active Directory. Right-click a domain, choose Properties, and change to the Trusts tab. From here you can add, edit, or remove trust relationships for the target domain.

Depending on your Exchange implementation, you might be required to manually establish trust relationships between domains in your organization. Ideally, you will be able to use the built-in transitive trusts between Windows 2000 domains.

Kerberos and Exchange

Kerberos is critical for Exchange 2000 security because it is the foundation for user authentication. Kerberos tickets ensure the identity of clients requesting access to the Exchange services and store. As mentioned earlier, access tokens are embedded in Kerberos session tickets and are used to determine permissions for specific Exchange resources.

One advantage of the Kerberos system will be realized in Outlook Web Access. A limitation with Exchange 5.5 Outlook Web Access (OWA) is that all OWA users must be granted Logon Locally rights to the OWA server(s). In addition, if the user's mailbox is housed on an Exchange server other than the OWA server, logon credentials must be passed using Basic (clear-text) authentication. SSL can be used to encrypt the logon session, but this is not enabled by default. The reasons for these configurations revolve around the incapability for NTLM credentials to be impersonated by the OWA server. Kerberos removes these limitations because session tickets can be used by a service to impersonate the user. A front-end server can securely access resources on behalf of the Kerberos-enabled client by presenting the user's authentication ticket in remote connections.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020