Exchange Server 2010 : Standards and Protocols - Active Directory: The Foundation of Exchange 2010

Active Directory is a big topic with lots of moving parts, so we're only going to skim the surface here. There are three key protocols, however, that you need to know about, far more than we have room to talk about here:

• The Domain Name System (DNS), which Exchange uses to look up other servers and services within the Active Directory domains and forests in the organization

• The Lightweight Directory Access Protocol (LDAP), which Exchange uses to find key configuration information for organization-wide objects, as well as to discover users and other mail-enabled objects

• Authentication protocols (such as Kerberos), which provide a central and secure mutual authentication mechanism not just for users, but for each machine in the Active Directory domains and forests

1. Finding Messaging Hosts with the Domain Name System

In the early days of the Internet, all of the hosts on the network were maintained in a single file called HOSTS. If you wanted to add a new computer to the Internet, you called the guy who maintained the file and asked him to add your computer's name and IP address. Periodically, everyone on the Internet downloaded the latest version of the HOSTS file.

You can see how that would be a bit difficult today; the file would be huge, slow to search, and changing constantly. Plus it would require a massive team of people to maintain it. In 1984, a standard was proposed and adopted to allow name resolution by creating a hierarchical namespace where different owners of the namespace would be responsible for maintaining their own hosts.

The hierarchy of this name resolution system is based on domains. The top of the hierarchy is the root and is defined by "." Beneath the root domain are zones, such as .com, .net, .edu, and so forth. Root servers would provide referrals to clients so that they could contact the correct servers that held the information. So, for example, if you own a domain called somorita.com, you can control any hosts in that particular domain. The root servers on the Internet provide referrals to other servers on the Internet and point them to the servers that hold the somorita.com data.

As you may have guessed by now, we are talking about the Domain Name System (DNS); this is documented in RFC 1034. You may be wondering how DNS directly (or indirectly) affects mail servers, though. One obvious way that DNS and Exchange are related is through Active Directory; an Active Directory domain incorporates and relies on DNS. Because Exchange is in turn integrated with Active Directory, it too depends on DNS for name resolution of directory information and mail routing information.

1.1. Fully Qualified Domain Names

Each machine can be referred to by one of at least two names: the short hostname, which is typically the same as the NetBIOS name, and the fully qualified domain name (FQDN), which is the hostname plus the full DNS domain suffix. The FQDN uniquely identifies the host on the Internet or within a private intranet.

1.2. Canonical Addresses

Canonical address or hostname records (also called A records) are DNS entries that resolve the hostname to a corresponding IP address. A given hostname can have more than one IP address, in the case of a shared hostname or a host with multiple interfaces, and one IP address can have multiple A records pointing to it.

For more information on A records and an overview of the various types of DNS records, see http://en.wikipedia.org/wiki/A record.

$ORIGIN somorita.com.
exch01  IN   A     192.168.254.117

1.3. Aliases

An alias record (also called a CNAME) usually points to a canonical address record. This gives you the ability to define an alias hostname for one or more systems (perhaps a user-friendly name such as mail for a farm of Client Access servers so users don't know about or have to remember the individual hostnames of the servers in the farm).

While you can point a CNAME to another CNAME, chaining aliases in this fashion can quickly get confusing and is generally discouraged.

For more information, see http://en.wikipedia.org/wiki/CNAME_record.

$ORIGIN somorita.com.
exch01  IN   A     192.168.254.117
mail    IN   CNAME exch01.somorita.com.

$ORIGIN somorita.com.
exch01  IN   A     192.168.254.117
mail    IN   CNAME exch01.somorita.com.

1.4. Reverse Pointers

A pointer record (PTR), also known as a reverse lookup, maps a given IP address back to a corresponding domain name. PTR records are not added specifically to your domain, but rather to a domain name that represents an IP subnet. PTR records allow clients to take the IP address of an Internet host and look up the name associated with the IP address.

All of these reverse domains are found in DNS in the in-addr.arpa domain; portions of this domain are delegated to companies that have been assigned blocks of IP addresses. PTR records are usually created and managed by the owner of the IP subnet block, not the manager for a domain like somorita.com.

It's not as commonly known, but PTR records can point to a CNAME record instead of an A record. This allows the maintainer of a reverse DNS zone to delegate the pointer lookup to a zone under someone else's control. Many ISPs, for example, use this technique to allow customers with only a handful of addresses to maintain control over both the forward and reverse DNS lookup information of their hosts without returning to the ISP helpdesk to update the PTR records when hostnames change. This type of solution can be helpful if you have external systems that refuse to accept messages from your system because your reverse DNS is not in order.

For more information, see http://en.wikipedia.org/wiki/Reverse_DNS_lookup.

$ORIGIN 254.168.192.in-addr.arpa.
117     IN   PTR    exch01.somorita.com.

1.5. Mail Exchangers

The Mail Exchanger (MX) record is the DNS entry for your domain that allows mail servers on the Internet to look up the hostnames of systems that accept mail for your domain. These DNS records point to public address (A) records of the SMTP servers that accept mail for your organization; this may be your Hub Transport or Edge Transport server, a third-party message hygiene system, a simple SMTP relay server, or even a third-party managed provider. To provide some degree of redundancy and availability, you can define multiple MX records for each domain, and you can assign a priority value to each of them.

You can use the nslookup command to look up and validate MX records for your domain. Here is an example of looking up the servers that accept mail for apple.com:

nslookup -q=mx apple.com
Server:   dnsserver1.somorita.com
Address:   192.168.254.71
Non-authoritative answer: apple.com
MX preference = 100, mail exchanger = mail-in3.apple.com apple.com
MX preference = 10, mail exchanger = mail-in11.apple.com apple.com
MX preference = 10, mail exchanger = mail-in12.apple.com apple.com
MX preference = 20, mail exchanger = mail-in1.apple.com apple.com
MX preference = 20, mail exchanger = mail-in2.apple.com

Notice in the MX records that the preference values are different for different records.

Mail servers are always supposed to choose the record with the lowest preference value first and then only use the records with the higher preference values if the lower ones do not respond. If two or more records are equal, the sending mail server is supposed to rotate between them to provide a degree of load balancing.

For more information, see http://en.wikipedia.org/wiki/MX_record.

$ORIGIN somorita.com.
@       IN   MX 10 exch01.somorita.com.
exch01  IN   A     192.168.254.117

1.6. Sender Policy Framework

Sender Policy Framework (SPF) records are special DNS records that help a receiving mail server determine whether the mail server that originally sent a message is authorized to send mail for that domain. These records are used both by SPF and Sender ID–compliant systems. Although the SPF system proposes a separate record type (SPF, or type 99), the standards also permit the use of the common text (TXT) records. Most organizations that publish SPF or Sender ID policies use TXT records to do so. SPF is often billed as an antispam system, but it is better defined as an antispoofing system.

For more information on the SPF system and records, see www.openspf.org.

$ORIGIN somorita.com.
@       IN   TXT   "v=spf1 mx -all"

1.7. Service Location

Service location records (SRV) records are DNS records that help a client locate a specific service type that is provided for a domain, including service-specific information such as which specific protocol and network port it is using.

Active Directory publishes SRV records for a number of different services, including enumerating Active Directory sites and locating global catalog servers. Since Exchange relies on global catalog servers and domain controllers for proper function, it will regularly perform lookups to determine which controllers exist in its local AD site. There might be multiple global catalog SRV records for a particular domain, as well as a separate listing of domain controllers by site.

Another good example of the use of an SRV record is the option to use SRV records with Outlook 2007 Service Pack 1 to publish an Autodiscover URL on a nonstandard hostname.

1.8. Split Brain DNS

Split brain DNS systems are systems that have two or more different views of the same DNS namespace. This, in turn, requires two or more sets of DNS servers that host the same DNS namespace (or a DNS server that can handle multiple versions of the same namespace).

Usually one set of DNS servers hosts the domain name for an internal network and is used to resolve the hostnames to internal IP addresses, while the other set is used to resolve IP addresses for hosts on the Internet. This configuration is commonly used when the organization's public and private domain name are the same and the organization does not want internal host information available to Internet users. It is also commonly used to provide a fast, limited view of specific DNS information to servers in a perimeter network.

1.9. Disjoint DNS namespace

Machines joined to an Active Directory domain by default are configured with a primary DNS suffix, which is by default the same domain name as the Active Directory domain and its corresponding DNS zone. When the primary DNS suffix for a machine does not match the DNS domain of the Active Directory domain, it is said to have a disjoint namespace. While disjoint namespaces are supported under some circumstances, they can cause problems, so be sure these configurations are thoroughly tested. For more information, see

http://technet.microsoft.com/library/cc773264.aspx

2. Finding People and Services with Directory Services

One important aspect of messaging systems is how they look up message senders and recipients. Modern Exchange systems rely on Active Directory for this functionality. However, early messaging systems used simple flat-file lookups — typically out of the same files that listed user accounts, such as the passwd files on a Unix system. Flat files quickly got unwieldy for a large number of users, though, so various systems began using alternatives:

• Sun's Unix variants offered the Network Information Services (NIS), which provided a shared directory service, including messaging aliases and delivery information, across hundreds or even thousands of hosts within an organization.

• Early versions of Windows NT offered the local SAM database — their equivalent of the Unix passwd file — as well as Windows NT domains. NT domains allowed multiple Windows machines to share the same user information, including email addresses.

Other messaging systems often provided tight integration with a corresponding directory service. The OSI networking stack (which, if you remember, included the X.400 messaging transport and system) provided the X.500 directory service. X.500 was a behemoth, requiring a lot of effort to implement, deploy, and maintain.

Although the concept of X.500 was interesting and useful, it was far too complicated to implement in conjunction with SMTP systems. Not even the original versions of Exchange used a full X.500 implementation, but they used many of the same concepts in their built-in proprietary directory service. Messaging systems such as Exchange were not, however, the only systems in need of a fast, flexible, and extensible directory service to provide centralized authentication and configuration lookups for users and applications.

The University of Michigan had an X.500 deployment, but found that there was too much overhead for application developers to use it. At the same time, this central directory implementation proved to have many useful concepts. They took these concepts and the directory service as a back-end store and created a lightweight X.500-like front-end service, offering a simplified API. Thus was born the prototype of what would eventually become known as the Lightweight Directory Access Protocol (LDAP).

LDAP, which provided an extensible and hierarchical data access model that was less rigid (and more customizable) than X.500, proved to be a good complement for a variety of applications, including messaging systems. Today, almost all modern MUAs and MTAs provide the ability to look up contacts, users, and other configuration information from an LDAP-based directory service. Windows Server Active Directory, Novell's Novell Directory Service, and eDirectory products are direct adaptations and extensions of the LDAP standard.

Unlike many of the other common Internet protocols developed through the IETF RFC process, LDAP queries and responses are defined using the ASN.1 grammar. ASN.1 is commonly used in International Telecommunication Union (ITU)-developed protocols as a fundamental building block for structured character encoding, allowing a common definition for data interchange between systems that may use different internal byte orders for representing data. Although LDAP was originally developed outside the RFC process, it has since been described and codified by RFCs, as shown in Table 1.

LDAP objects are organized in a hierarchical fashion. The distinguished name (DN) is the key identifier for LDAP objects; it uniquely identifies the position of any object within a specific directory store and provides a unique fully qualified name for that object. The DN is in turn built up from comma-separated substrings derived by each level of the directory hierarchy, moving in order from most specific to least specific, as shown in Table 2.

3. Kerberos

Kerberos is the third key technology for Active Directory, which is funny if you know where Kerberos got its name: from Cerberus, the giant three-headed dog that kept watch over Hades. Just like Cerberus, Kerberos helps ensure that only the people who are supposed to can access Active Directory resources.

Kerberos was initially developed during the 1980s at MIT as part of Project Athena, an educational-focused distributed computing environment. (Another technological offspring of Project Athena, known as the X Window System, provides Unix systems with the framework for a graphical user interface.) The first public version of Kerberos was v4, published by MIT in 1987. The current version, Kerberos v5, was published in September 1993 in RFC 1510.

Kerberos was designed to allow the various workstations and servers in this environment to securely function and to allow users to securely pass credentials to network resources over an untrusted network:

• Unlike other authentication mechanisms such as the legacy Windows NTLM, Kerberos provides mutual authentication between all computers in a transaction; NTLM assumes that the servers are trustworthy and never explicitly allows the initiating system to verify that the server it has connected to is in fact genuine. This is a weakness an attacker can exploit under certain conditions.

• Each computer, user, and network-aware application participating in a Kerberos-enabled network is represented by a security principal. These principals request tokens from a central Key Distribution Center (KDC) and can then pass those tokens on to other systems. The practical upshot is that each principal must only have a trust relationship with the KDC.

• Another core Kerberos principal is that credentials must never be passed over the network. The KDC and all associated principals are known as the realm; every principal in the realm can leverage its trust relationship with the KDC to securely authenticate itself to other resources in the realm without sending credentials over the network. In Active Directory, each domain controller acts as a KDC, preventing the KDC from being a single point of failure. Additionally, each server can validate a given token without calling a domain controller to validate the token.

• Kerberos realms can form trust relationships with other realms, allowing principals in one realm to access resources in another realm. In Windows Active Directory, the forest is equivalent to the Kerberos realm. Multiple Active Directory forests can be linked through forest trusts, and third-party Kerberos implementations can also be linked through Kerberos realm trusts. This allows interoperability with non-Windows environments and operating systems.

• Kerberos allows the concept of delegation, where applications and services can access other network resources on behalf of a client within the client's security context, without having to have the client's credentials. This is not possible with legacy authentication protocols and helps prevent the dissemination and proliferation of client credentials.

This is all well and good, but why do we care about Kerberos in Exchange 2010? The answer is simple: it's the default authentication mechanism in Active Directory. Depending on how complex you make your Exchange 2010 deployment (and how many forests you need to join into a single organization), you will be relying more heavily on proper Kerberos functionality than in previous versions of Exchange. Even mailbox access protocols like POP3 and IMAP have been made Kerberos aware ("Kerberized"). Exchange servers within the organization use Kerberos-authenticated SMTP to securely transmit all traffic by default, falling back to NTLM only when there is a problem that prevents the use of Kerberos and when security policies permit.

Preventing Replay Attacks

While Kerberos presents a robust design, there's one potential weakness that could allow an attacker to record a network session and later replay the relevant parts to gain illicit access to resources. This type of attack, known as a replay attack, is prevented by using an authenticator in the network packets. This authenticator is tied to the current network time and is only valid for a short window — by default, five minutes.

One of the consequences of this is that all of the computers in the Active Directory forest, as well as those in any other trusted forests or third-party Kerberos realms, must share the same time source and be configured to be within five minutes of each other. Computers whose clocks are not in synchronization are said to be skewed. Within a domain, the Windows Time Synchronization service will usually take care of time skew, although use of a more robust protocol such as the Simple Network Time Protocol (SNTP) or Network Time Protocol (NTP) is preferred, especially when coordinating time between multiple realms.

If you need to change the acceptable level of time skew, refer to Microsoft Knowledge Base article 837361, "Kerberos Protocol Registry Entries and KDC Configuration Keys in Windows Server 2003," at http://support.microsoft.com/kb/837361.