In a distributed Exchange/OWA single sign-on environment, each server needs Access Manager to impersonate the current user. When you enable Impersonation, you need to include additional HTTP headers in the "Response" tab of the Authorization Policy of your impersonation application domain.
The following solution has been tested in both standalone and distributed OWA environments.
IISImpersonationModule.dll
to your IIS configuration, as described in "Adding an Impersonation dll to IIS".See Also:
Before you proceed with impersonation setup for Outlook Web Application, ensure that OWA is not using Integrated Windows (or any other) Authentication.
If it is not, you can use the following steps to set up OWA with Windows Authentication.
The special user should not be used for anything other than impersonation. Oracle recommends that you chose a very complex password, because your trusted user is being given very powerful permissions.
Also, be sure to check the box marked Password Never Expires. Since the impersonation module should be the only entity that ever sees the trusted user account, it would be very difficult for an outside agency to discover that the password has expired.
To create a Trusted User Account for Outlook Web Application:
You need to give the trusted user the right to act as part of the operating system.
To assign rights to the Outlook Web Application trusted user:
You need to bind the trusted user to the WebGate by supplying the authentication credentials for the trusted user.
When the bind has been created for the WebGate and the trusted user, WebGate is ready to provide impersonation on demand. The demand is created by a Response set in the Authorization Policy of application domain created for impersonation.
The following procedure presumes that you have registered a 11g WebGate (ImpersonateAgent) with Access Manager. The values in the following procedure are provided as an example only. Your environment will be different.
You must create or configure a application domain to protect your OWA resources (/owa and /ecp only).
Ensure that IISImpersonation Module.dll
is applied only to "owa" and "ecp" applications in IIS7.x, and removed from the site level. The Authorization policy must set several HTTP Header variables (Header type Responses in the Authorization policy).
This procedure presumes that you have an existing application domain for the 11g WebGate (ImpersonateAgent) you registered with Access Manager.
See Also:
The chapter on managing policies to protect resources and enable SSO in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.
This Response is used for the second Webgate request (for authorization).
You are ready to configure IIS by adding the IISImpersonationModule.dll
to your IIS configuration.
You also need to set Enable Anonymous Access because this is required for impersonation of a user.
Be sure to configure IIS Security before you continue. Figure 60-4 shows an example.
The following options are provided to test the Impersonation configuration for OWA.
You can test impersonation through the Event Viewer.
To test:
You can test impersonation using a dynamic test page that can return and display information about the request.
To test:
You can conduct negative testing for impersonation by unbinding the trusted user from the WebGate.
AUTH_USER
and IMPERSONATE
are necessary for impersonation credentials to be bound to a Webgate.