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:


 



 


Step 1. The client makes a Http request to the Front End sever


 


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


Comments (9)
  1. Mr Moose says:

    1: Why port 80 and not 443?

  2. Adam says:

    Ummm, okay thanks for the great insight into FE/BE logons.

    Why don’t we just goto

    http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3FrontBack ?

  3. Rob says:

    Good information thanks!

  4. Edwin says:

    So at Step 7, does it mean the BE will contact the DC to authenticate again and GC to get user info again?

    Thanks!

  5. indy says:

    What is up with the Visio 2000 graphics? Eat your dogfood!

  6. Tim Hackbart says:

    In step 7 the BE will have to re-authenticate the user again. Everytime we access a resource on the IIS machine we have to authenticate and authorize the request.

    Hope this helps

    Tim

  7. Tim Hackbart says:

    I am not exactly sure why the developers chose to use HTTP:80 for ALL requests between the FE and BE. I am sure there are configuration and performance reasons.

    Exchange 2003 did address this issue by attempting to use Kerberos and NTLM if possible to protect the Basic credentials in the HTTP packets.

    Tim

  8. Rudy says:

    I would like to know the exact LDAP query that EXPROX.DLL uses to find the user in AD (step 5).

    I had an OWA issue today where I think the problem might have been in that step.

  9. Tim Hackbart says:

    Here is the info on the LDAP request from step 5 and some more info as well.

    Step through an Explicit Authenticated Private Information Store request

    -Exprox requests the path for the incoming URL request, for instance the client request is http://mail.microsoft.com/exchange/username , the resulting path replied via IIS would be something like m:redmond.microsoft.comMBX/username

    -Since this is an EXPLICIT login (/exchange/username) exprox requests information on this user from DsAccess based on a proxy address it creates from the username given in the URL and the SMTP domain that is used in the Local path information returned by IIS (Note: This local path is constructed using the SMTP domain selected upon creation of the virtual directory for mailboxes via the ESM when typing in “insertdomainnamehere.com” mailboxes for:).

    -Once the proxy address is constructed, the LDAP query issued is a search filter for proxyAddresses=SMTP:username@smtpdomain.com and objectclass=user, the requested attribute for the mailbox is the msExchHomeMDB attribute to determine what private information store database the user is on.

Comments are closed.