By understanding the flow of data and the different authentication methods, it is easier to determine where the logon attempt is failing and where to begin troubleshooting.
Some of the terms used maybe new to you so here is a quick glossary of some of the terms you will encounter in this article.
- DSAccess – an internal Exchange 2000/2003 component that is used to access directory information.
- Eprox.dll – a DLL that handles communication between the Exchange front-end server and IIS
- DaveX.dll – a DLL that handles communications between the Exchange back-end server and IIS
- Epoxy.dll – a DLL that is responsible for Inter-process communication between Exchange and IIS
- Exoledb.dll – a DLL that is responsible for communicating with the Information Store.
How OWA Authentication Works
Let’s start by taking a look at a typical Exchange 2003 Front-End/Back-End (FE/BE) scenario. In this scenario we have the two Exchange 2003 servers, a Domain Controller, a Global Catalog and a DNS server. The Domain Controller, Global Catalog and DNS can be housed on the same server, on multiple servers, or spread out across severs. You are also likely to see a firewall in-between the servers and the remote client. See Figure 1.
The first step is the most obvious, the client opens up their browser and enters http://domain.com/exchange or if SSL is configured https://domain.com/exchange. DNS is used to resolve the domain name to an IP address and then a request is made over the appropriate port, TCP 80 for HTTP or TCP 443 for SSL. If there is a firewall in-place, and there should be, the appropriate port must also be open.
Here is where the real fun begins. The IIS service on the Exchange 2003 front-end server will be listening on port 80/443 and will determine which website should handle the request. In a perfect world, the front-end server would be a front-end for Exchange and that is it. In this case you would only have the “Default Web Site” and the request would be sent there. However, if the front-end is also a web server hosting other websites IIS will need to figure out the right website to direct the request too. This is done using either the Port, the IP address, or a host header.
Now that IIS has sent the request to the proper website, the website must then forward it to the correct directory on the website. For Outlook Web Access this directory is called Exchange. Here is where the logon process gets into the nitty gritty! Now that the request is in the proper directory IIS will enforce the specified Authentication Method. The Authentication Methods are configured via the Internet Services Manager (IIS) MMC. On the Properties page for the website Virtual Directory select the Directory Security tab and then press the Edit button in the Authentication and Access Control section. See Figure 2.
Next, using RPC over TCP Port 135, IIS will authenticate the user against a Domain Controller. IIS will also use the LogonUserEx Application Programming Interface (API) to obtain a Security Identifier (SID) for the user.
Once IIS has applied the logon method to be used Exprox.dll comes into play. Eprox.dll is a DLL that handles communication between the Exchange 2003 front-end server and IIS. By default, all requests that are not handled by the defined Application Extensions are answered by Exprox.dll. Using the SID, Exprox.dll will query the Global Catalog with DSAccess and gather information on the user. This information includes the users mailbox and SMTP address. This transaction takes place over port 3268 and it is important to know this if you have a firewall in-between your servers. Exchange 2003 will then use Exprox.dll to create a Kerberos Ticket and an NTLM hash, which is sent to the Exchange 2003 back-end server.
Now that Exprox.dll knows the users SMTP address and the back-end server holding the users mailbox, it will do a comparison of the path to the Exchange Virtual Directory and the users SMTP address. It gets a little tricky here depending on the Service Pack level. Pre-Exchange 2003 SP1 the user would be given an error if there were no match. However, Exchange 2003 SP1 changed this behavior and there is no more need for the SMTP address to match the path to the Exchange Virtual Directory. Exprox.dll will now relay the request to the Exchange 2003 back-end server that contains the user’s mailbox over TCP 80.
Now that the request is on the back-end IIS must determine the web site and the path to the Exchange Virtual Directory. This request is authenticated using LogonUserEX API again however this time, once the logon method is determined, the request is handed off to Davex.dll instead of Exprox.dll. Davex.dll is the DLL that handles communications between the Exchange 2003 back-end server and IIS. Davex.dll will now use DSAccess to query the Global Catalog and determine the users SMTP address and mailbox information and check to see if the information matches. Again, pre-Exchange 2003 SP1, if there is no match the user will receive an error, however Exchange 2003 SP1 or greater, the need for a match is no longer required.
Davex.dll will now send the request through Epoxy.dll. Epoxy.dll is the DLL responsible for Inter-process communication between Exchange 2003 and IIS. Epoxy.dll will pass the request to Exoledb.dll, which is the DLL that is responsible for communicating with the Information Store. The data is retrieved from the Information Store by Exoledb.dll and returned via the same path to Davex.dll.
Davex.dll will take the data and send it to the Exchange 2003 front-end server over TCP 80. The Exchange front-end then relays that data back to the client over the appropriate port depending on whether or not SSL is being used.
Using Your Knowledge
Now that we have a clear understanding of what happens when a remote user logs on to OWA and requests data, we can efficiently troubleshoot some of the errors that may occur. First off, it is important to know the ports that are required. If you have your servers separated by firewalls it is necessary to have the appropriate ports open. In addition to the ports I have mentioned, Microsoft has a list of ports used by Exchange Server 2003, which you can find here.
Secondly, Exchange 2003 requires at least one Domain Controller that is also a Global Catalog server in the same Active Directory site. Without access to a Global Catalog, the logon will fail because DSAccess will be unable to retrieve the required information from Active Directory.
Effective troubleshooting begins with knowing the fundamentals. I hope this gives you some insight into the process that takes place when a user logs on to OWA and requests data.