Add Outlook Web Access Login Options to the APM Logon Page
Outlook Web Access is the web interface to the Microsoft Exchange environment, and many customers have secured the portal behind their BIG-IP APM architecture. In looking at the OWA logon page, however, you'll notice that there are a couple extra options than the default APM logon page supports:
This article will show you how to add these options to a custom BIG-IP APM logon page, however, it assumes the portal app with SSO is already configured and working. If you need help with that, drop a comment below.
Configuration Steps
First, enable two additional text boxes on the APM Logon page
Now that you have the variables where they will be part of the session you need to modify the logon page to display radio boxes and checkboxes for the fields we added instead of the textbox. You do this by first going to the customization section of the access policy module.
Next, change the Edit Mode to Advanced.
Then navigate to the logon page.
Find this section of code in logon.inc:
foreach( $fields_settings as $id=>$field_settings )
{
if( $field_settings["type"] != "none" )
{
Immediately after the opening curly brace in that section of code, add these lines (highlighted in red) so that the section of code now looks like this:
foreach( $fields_settings as $id=>$field_settings )
{
if( $field_settings["name"] == "pubpriv" ) { continue; }
if( $field_settings["name"] == "lightversion" ) { continue; }
if( $field_settings["type"] != "none" )
{
The section should look like this now:
Note the closing four curly braces at the bottom of the screen shot. You need to add this section of code below between the third and fourth curly brace:
?>
<tr>
<td colspan=2 class="credentials_table_unified_cell" >
<label for="text">Security</label>
<input type="radio" name=pubpriv value="public" checked> This is a public or shared computer<br>
<input type="radio" name=pubpriv value="private"> This is a private computer
</td>
</tr>
<tr>
<td colspan=2 class="credentials_table_unified_cell" >
<label for="text">Light Version?</label>
<input type="checkbox" name=lightversion value="yes"> Use the light version of Outlook Web App
</td>
</tr>
<?
Now the section, complete, should look like this:
Now click Save Draft, the click Save in the editor tool bar.
Now that the customizations are done, we need to create an iRule to see what the form values are and then set the values will push into the SSO object. The values are found by looking at the post variables OWA uses. Go to "Local Traffic" section in the menu, then iRules and click "Create". I named my iRule "owa_form_values_iRule" and pasted the following code
when ACCESS_POLICY_AGENT_EVENT {
if {[ACCESS::session data get "session.logon.last.pubpriv"] eq "private"} {
if {[ACCESS::session data get "session.logon.last.lightversion"] eq "yes"} {
ACCESS::session data set "session.custom.owa.flags" 5
ACCESS::session data set "session.custom.owa.trusted" 4
} else {
ACCESS::session data set "session.custom.owa.flags" 4
ACCESS::session data set "session.custom.owa.trusted" 4
}
} else {
if {[ACCESS::session data get "session.logon.last.lightversion"] eq "yes"} {
ACCESS::session data set "session.custom.owa.flags" 1
ACCESS::session data set "session.custom.owa.trusted" 0
} else {
ACCESS::session data set "session.custom.owa.flags" 0
ACCESS::session data set "session.custom.owa.trusted" 0
}
}
}
Next go back to the visual policy editor and add an iRule Event after the logon page in the process flow but before the resource assign and enter the name of the iRule we created in the ID field.
Finally, edit the SSO configuration object. In the hidden form parameters modify the values of "flags" and "trusted" to use the new session variables created in the iRule. The other variables should remain the same.
flags %{session.custom.owa.flags}
trusted %{session.custom.owa.trusted}
Shown in the SSO object:
Now apply the policy and you are good to go! OWA through APM will provide the same functions as the direct OWA logon page!
- Roo_150490NimbostratusHi Seth,
- Lucas_Thompson_Historic F5 AccountThe other way to accomplish this is to simply add headers into the client request, in case you need to use HTTP authentication instead of Forms. Two headers "X-Experience" and "X-LogonType" control OWA's behavior:
- Andrew_Garvin_1NimbostratusThis is great, but assumes you are using forms-based authentication on your OWA/CAS Exchange servers. This will not work if you use Basic/NTLM authentication on the servers. Is there another way to make it work if you use Basic/NTLM?
- gbbaus_104974Historic F5 AccountVery Cool, thanks for sharing. This is a common problem