Enabling impersonation with a header variable involves completing the procedures in the following sections.
Reviewing all Requirements for Impersonation with a Header Variable
Prepare the environment and confirm that it is operating properly before implementing Windows impersonation with the OAM Server.
Table 60-1 identifies the Access Manager platform requirements when you enable impersonation using a header variable.
Table 60-1 Requirements for Impersonation with a Header Variable
11g WebGate (and Impersonation dll)
Microsoft IIS 7.x and Windows Server 2008 and 2013
Kerberos Key Distribution Center (KDC) and Active Directory
Windows Server 2008 and 2013
Client and Server machines
Must have Act as operating system privileges.
Note: IWAM_Machine is not recommended
Mutual authentication is required
Mutual authentication is supported remotely.
Whether you enable impersonation using a HeaderVar or user profile attribute, the return value must be a trusted user in Active Directory. This special user should not be used for anything other than impersonation.
The example in the following procedure uses SPPSImpersonator as the New Object - User. With OWAImpersonator as SPPSImpersonator denotes SharePoint impersonation specifically. Your environment will be different.
Windows 2008 or 2012: Select Start, Programs, Administrative tools, Active Directory Users and Computers.
Oracle recommends that you choose 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.
Figure 60-1 Setting up a Trusted User Account for Windows Impersonation
You can give the trusted user the right to act as part of the operating system.
To assign rights to the trusted user:
Windows 2008: Select Start > Programs > Administrative tools > Local Security Policy.
You must modify the group policy object that applies to the computer where the Webgate is installed.
Figure 60-2 Configuring Rights for the Trusted User in Windows Impersonation
You need to bind the trusted user to the WebGate by supplying the authentication credentials for the trusted user.
The procedure presumes that you have registered an 11g WebGate with Access Manager. The values in the procedure are provided as an example only. Your environment will be different.
Find All Enabled: Select State All, click the Search button, click the desired Webgate name in the results list.
A bind has been created for the WebGate and the trusted user. The WebGate is now ready to provide impersonation on demand. The demand is created by an Authorization Success Action in the application domain created for impersonation.
You must create or configure an application domain to protect your OWA resources.
For this you must add Responses in Authorization Policies (Header type Responses), as described in this procedure.
The procedure presumes that you have an application domain created for the 11g WebGate you registered. The application domain in this example is MyImpersonationDomain. Your environment will be different.
Navigate as follows:
Complete the form as follows:
From the Type list, choose Header.
In the Name field, type a unique name for this response. For example, IMPERSONATE.
In the Value field, type a value for this response. For example, $user.userid.
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.
To add an Impersonation DLL to IIS:
By default, the path is:
Where Webgate_install_dir is the directory of your WebGate installation.
If any spaces exist in the path (for example,
C:\Program Files\Oracle\...) surround the entire string with double quotes (" ").
IISImpersonationModule.dllfile added in these steps is applied only to "owa" and "ecp" applications and removed from the site level.
Go to OWA, double-click modules, Configure Native Modules, and check the desired module (for example, Oracle Impersonation Module).
Go to (ecp): Double-click modules, Configure Native Modules, and check the desired module (for example, Oracle Impersonation Module).
You can test Impersonation using an Event Viewer or a web page.
Following are the two ways of testing Impersonation:
To test the impersonation feature outside the Microsoft OWA 2010 context or to test single sign-on, you will need a target Web page on an IIS virtual Web site.
You create such a virtual Web site by performing the following task.
When you perform impersonation testing using the Windows 2008 Event Viewer, you must configure the event viewer before conducting the actual test.
To test impersonation:
Your Event Viewer is now configured to display information about the headerVar associated with a resource request.
Figure 60-3 Verifying Event Viewer Settings
If impersonation is working correctly, the Event Viewer will report the success of the access attempt.
You can test impersonation using a dynamic test page, such as a
.asp page or a Perl script, that can return and display information about the request.
To test impersonation:
.asppage or Perl script that will display the parameters AUTH_USER and IMPERSONATE. It can resemble the sample page presented in the following listing:
<TABLE border=1> <TR> <TD>Variable</TD> <TD>  </TD> <TD>Value</TD></TR> <%for each servervar in request.servervariables%> <TR> <TD><%=servervar%></TD> <TD>  </TD> <TD><%=request.servervariables(servervar)%> </TD> </TR>
.asppage or Perl script (such as the sample in the preceding listing) anywhere in the tree of the new virtual site.