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

You should use IPSec to secure traffic from the FE to the BE server.

Nue
"j5" <johnnynewsgroups@xxxxxxxxx> wrote in message
news:1137701983.778351.275900@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>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--
>


.

Loading