OWA, FBA, and the front-end back end authentication process.

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

I have encountered some conflicting information regarding the
processing of forms based authentications in a front-end /back end
exchange 2003 implementation. Hopefully someone here can shed some
light.

Here's what I know (from an article in WindowsITpro):

0. The user enters https://fe/exchange into the browser's Address field
for the first time. (fe=front-end, be=back-end))
1. The ISAPI filter intercepts the request and determines whether a
cookie is attached; in this case, no cookie is present.
2. The filter lets the request pass through unmodified, and the
Exchange front-end server processes the request.
3. The filter intercepts the response from Exchange and checks for a
401 Access Denied message. In this case, the response does contain the
401 Access Denied message because the initial request had no
authentication host header.
4. The filter changes the response to a 302 Moved Temporarily message
that specifies
https://fe/exchweb/bin/auth/owalogon.asp?url=https://fe/exchange as the
new location.
5. The client now resends the request to this URL. At this point, no
credentials are required to access this URL because the auth virtual
directory is enabled for Anonymous access. Owalogon.asp extracts the
Accept-Language header from the incoming requests and transfers the
execution to logon.asp in the appropriate language-specific folder, and
the browser displays the HTML logon form. The form has two radio
buttons that let the user choose either the premium or basic client.
Because the ISAPI filter can adjust host headers, it can downgrade the
User-Agent header to the basic client.
6. The user fills in the form, and the browser performs a POST to the
ISAPI extension DLL on the front-end server (i.e.,
\exchsrvr\exchweb\bin\auth\owaauth.dll), putting the form data in the
message body. This data includes the username, password, and the
original URL that the user requested.
7. The extension creates a cookie, generates a base64 encoding of the
user credentials, and uses CryptoAPI to encrypt the data with the
current symmetric key. The extension then instructs the browser to
attach this cookie (through a Set-Cookie header) to all HTTP requests
within the same session and returns a 302 Moved Temporarily message to
the browser, specifying the original URL as the new location. The
browser then accesses the original URL.
8. We're now back at Step 1, except that the HTTP request has a cookie
containing an encrypted version of the base64-encoded credentials.
However, the request still has no valid authentication header.
9. The ISAPI filter again intercepts the request and finds the cookie.
10. The filter decrypts the cookie with the symmetric key and extracts
the base64-encoded credentials, which the filter adds to the request as
an authentication header before letting the request pass through to the
Exchange front-end server.
11. Exchange processes the request, which by this time looks like a
typical request formatted for valid Basic authentication. The
difference, however, is that the user never saw the standard logon
dialog box that the browser presents when a server challenges a browser
to use Basic authentication.


Here's my question, and where I'm getting conflicting information:

At step 11, are the credentials sent in clear-text or is Kerberos used
to encrypt them? If they are in clear-text, can they be encrypted? Can
IPsec or similar be utilized?

Thanks,
--john--

.

Quantcast