Thursday, April 2, 2015

Did You Know: Repliability Problems are Real! Still! Part 1 #MSExchange

It is always interesting when you hear people talking about problems they encountered while managing a messaging environment that you encountered many years ago. In this case, about 17 years ago! The thought still prevails that Exchange uses SMTP to route mail between internal mailboxes. While trying to solve end user mailbox problems, some export the contents of the mailbox to PST, delete the mailbox, recreate a new mailbox, and import the contents of the PST and move on. Hey, it solves the problem (at first glance). Inevitably several hours later the admin receives a new ticket that the user that he or she helped earlier cannot reply to older emails from internal colleagues.

The issue of “repliability” still exists. Sigh…

Today, I’m going to define how maintaining “repliability” of email housed in mailboxes that are moved or recreated (and between foreign Exchange systems) is achieved. I’m going to walk you through the early versions of Exchange, starting in the early 90’s with the X.500 specification, all the way through the release of Exchange 2013 and the legacyExchangeDN attribute.

This story is a long and bumpy road and definitely requires a beverage of choice. Back in the early stages of the Internet there was a need to store information about large organizations and their users. Early users of the Internet recognized that a virtual phonebook of sorts was required to find people of interest. This virtual phonebook would need to be crafted in such a way that it could scale massively large to accommodate a global list of members. In 1988, the X.500 specification was developed jointly between ITU-T and ISO/IEC. This specification was aimed to help solve the lack of global organization and accountability. Within the X.500 directory specification, information about individuals in each organization or company such as the surname, given name, address, telephone, and even password could be stored as attributes within an object.

We can think about the construct of an object\attribute relationship like this:

The X.500 directory specification provided a method in which a unified naming convention could be used to address each element or object on a network within a directory structure. The objects within the X.500 network allowed for an easy to follow hierarchy to be created.

Originally, the X.500 specification provided a protocol to be used when communication between different X.500 directories was required. The default method to communicate with X.500 directories was through the Directory Access Protocol or DAP. As the use of the Internet started to steadily increase, many users found the DAP protocol to be difficult to use. After all, the TCP/IP protocol is the default communication mechanism used within the Internet and the DAP protocol was not compatible with TCP/IP.

This was a problem…

Enter the Lightweight Directory Access Protocol:
The Lightweight Directory Access Protocol or LDAP was created to replace the X.500's DAP communication mechanism. LDAP proved to be a simple way to access X.500 directories over the Internet by using TCP/IP as the transport method. Since adoption of the Internet in the early 90's was growing by leaps and bounds, the adoption of LDAP took off and everyone forgot about DAP.

Since the LDAP specification exploded on the scene, and became extremely popular, the architects of the specification saw fit to further enhance the protocol. Soon LDAP was expanded to include its own directory server components so it could directly compete with X.500. It is important to note here though that the LDAP specification "borrowed heavily" from the X.500 framework, but was regarded as much simpler and lighter than X.500. An example of this is the use of X.509 as the security foundation for authentication based on a PKI infrastructure.

The end result of this work left LDAP essentially as a branch of the X.500 specification. The lighter-weight LDAP clients work well with X.500, but did not explicitly require X.500 in order to work.

How does this relate to Exchange?
Exchange has always required a repository database to keep track of all the user and mail objects within the messaging environment. All the detailed information that comes with these types of objects need to be stored in a simple, fast, and easy to use hierarchy. The Exchange directory has always been a rather important component of the overall messaging solution.

I'm smiling as I say this, but back in the day, Exchange 4.x and 5.x had its own X.500-based directory to store user and mail object data. When I first started working with messaging environments in the Exchange 5.5 timeframe, we had to map a user in the Windows NT directory to a mailbox in the Exchange directory.

So in the Windows NT\Exchange 5.5 scenario we would have two directories to support. Horrible right? Hold on to your beverage of choice because things start to get good. The real world performance of the Exchange 5.x directory was so positive that Microsoft decided to use this X.500-based directory as the foundation of the initial implementation of Active Directory with the release of Windows 2000.

The initial implementation of Active Directory was not simply an X.500 directory. In fact, Active Directory used LDAP as the communication protocol. Microsoft decided to take components of the X.500 standard, DNS, and LDAP to provide an API to manage directory resources. Now Active Directory could be used as the hierarchy for users, computers, services and other devices like printers and would be accessed via LDAP.

I think it is interesting to note how Microsoft choose to approach and define a naming standard that would be used within Active Directory by taking bits of DNS and the X.500 specification. This is why many of the legacy X.500 components of the original X.500 specification are still relevant today within Active Directory and Exchange.

Today, Exchange still relies completely on Active Directory, whose roots are based in the X.500 specification, to serve as the central repository for provisioning, authentication and storage of user information.

Next, we are going to discuss the obstacles with names in Exchange today.

No comments:

Post a Comment