Exchange 2000/2003 Front End Server Logon Process

Working in Support Services, I get to explain this subject a lot, so I thought I’d share it here too. This blog post will explain what the flow of the client access a BE server through a FE server looks like, including access to domain controllers that has to happen as part of this process. The illustration shows the steps, which are then covered in more detail further down:

Http://server/exchange

In this case the request is made over port 80-Http.  The client must first resolve the Host name and then attempt a connection to the returned IP address.

Step 2. The firewall has port 80 open to allow Http traffic

Note: Port 443 would be required for SSL traffic.

Step 3. The IIS server is listening on Port 80 and responds to the http request made by the client.  IIS will first determine which Web site to direct the http request to.  If there is only a Default Web site then ALL http requests will be sent to the Default Web site.  If there are multiple Web Sites configured then IIS will determine the appropriate web site to direct the request to depending on the Port, IP address or host header that uniquely identifies the individual web site.

Step 4. Once the http request has been sent to the correct web site, then that web site will send the request to the correct directory, in our case "\exchange".  IIS will then enforce the logon method using the Authentication Method specified in the Directory Security Tab- Anon, Basic or Integrated.  IIS will contact a Domain controller using RPC to authenticate the user and get a SID for that user using LogonUserEX API.  Note: Authentication will only be enforced at the Virtual Directory level.  We do NOT have to Authenticate to the Default Web Site, just to the specific resource requested, in our case the “Exchange” virtual directory.

Step 5. After the logon method is enforced by IIS the request is sent to the Exchange directory.  For this example the Exchange virtual directory has Basic authentication selected.  Since Exprox.dll is set as the application mapping for all (*) mappings Exprox will handle every request that is not picked up by the listed Application Extensions.  (In Exchange 2003 only Exprox.dll will then build a Kerberos Ticket and NTLM hash to send to the Back End Server.) Exprox will take the SID that IIS got and use Dsaccess to query the Global catalog returned by DNS over port 3268 for information about the user logging in.  The Global Catalog will respond to the LDAP queries with user information including the users Home MDB and SMTP proxy addresses.

Step 6. Exprox now knows the users home mailbox server and smtp addresses.  Exprox will then compare the Exchange path of the virtual directory and make sure that the user has an smtp address that matches.  If no matches are found, the user is returned an error message. (In Exchange 2003 SP1 this behavior changes, and you no longer need to have an SMTP address that matched the Exchange path).  If there is a match then exprox will proxy the request to the users home mailbox server over port 80.

Step 7. IIS on the back end server then has to again determine the correct web site to send the http request to. Then the request is sent to the Exchange directory, where it must be Authenticated again using the LogonUserEX API, then Davex.dll intercepts the request.  Davex will then once again use Dsaccess to query for the users Home mdb and smtp proxy addresses.  Davex will also check to make sure the user has an smtp address that matches the Exchange path (Unless you are at Exchange 2003 SP1, as mentioned before).  Davex will then send the request through Epoxy, Epoxy then talks to Exoledb which then talks to the store.  The data is then returned through the same process to Davex.  Davex then returns the web content to the user.  The response is sent to the Fe server over port 80

Step 8. The FE server receives the response and proxies the response to the client.

That is basically it! Hope this was useful!

- Tim Hackbart