This article contains the basic troubleshooting steps for Authentication, Authorization, and Auditing (AAA) single sign-on issues when integrating Outlook on the Web (Exchange 2016) or Outlook Web Access (Exchange 2007, 2010, 2013) with NetScaler. In this scenario, Outlook on the Web (OotW) or Outlook Web Access (OWA) is configured with forms-based authentication.

Background

The issue behavior observed is that users accessing OotW/OWA coupled with the NetScaler AAA feature are forced to log on twice after authentication through AAA. The first login presented to the user sources from the AAA Application Traffic virtual server, but then a second login presents to the user, sourced from the Exchange server. The second login is unexpected, resultant from a failure of the Single Sign-On (SSO) to replay the user credentials.

Troubleshooting Steps

Troubleshooting AAA integration is split into categories: AAA Settings, Rewrite Settings, Examination by Packet Capture, and Examination by AAA Debug.

AAA Settings

1. The AAA feature requires a Traffic policy, Traffic Profile, and Form SSO profile in order to carry out SSO successfully. Verify which Traffic policy is assigned to the AAA Application Traffic virtual server. Note that a Traffic policy could also be assigned globally, to a group, or to a user.
 
Navigate within the NetScaler GUI to Security > AAA - Application Traffic > Policies > Traffic > Traffic Policies, and open the traffic policy.

2. Within the Traffic Policy, find the Profile field and click the Edit link (represented as a pencil icon) to edit the properties.

 
3. Now, find the Form SSO Profile field and click the edit icon.

4. The most critical field in Form SSO Profile is the Action URL. This setting is responsible for storing the OotW/OWA URL to which the NetScaler will submit credentials.
 
2007:

/owa/auth/owaauth.dll

2010, 2013, 2016:

/owa/auth.owa

5. Next, verify that both the User Name Field and the Password Field have the appropriate values.
 

username

password

6. Then, check the Success Criteria Expression. The same expression is used for OotW/OWA versions 2007, 2010, 2013, and 2016.

HTTP.RES.SET_COOKIE.COOKIE("cadata").VALUE("cadata").LENGTH.GT(70)

7. Scroll down and find the Response Size field. The correct value varies according to the version of Exchange.
 
2007:

15000

2010, 2013, 2016:

60000

8. Then, verify the Extraction field is set to DYNAMIC, which is the default setting.
 
9. Finally, verify that the Submit Method field is set to POST.
 
If any adjustments were made, click OK. Otherwise, click the X or Close to return to the Traffic Profile.
 
10. Now, verify the attributes of the Traffic Profile. First, check the AppTimeout field and verify it is set to 1.
 

11. Next, verify that Single Sign-on is set to ON.
If any adjustments were made, click OK. Otherwise, click the X or Close to return to the Traffic Policy.
 
12. Within the Traffic policy, check the expression to ensure that the policy is looking for the logon URL shared by both OotW and OWA:

2007:

HTTP.REQ.URL.PATH.ENDSWITH ("/auth/logon.aspx")

2010:

HTTP.REQ.URL.CONTAINS("owa/auth/logon.aspx")

2013, 2016:

HTTP.REQ.URL.CONTAINS("/owa/auth/logon.asp")

2013, 2016 alternative:

HTTP.REQ.URL.CONTAINS("/owa/auth/logon.aspx")

Rewrite Settings

1. In some rare instances, OWA may not issue a session cookie called PBack when the login occurs, causing a login failure.
Configure the rewrite action and policy suggested below using the NetScaler command line so as to ensure the special characters are entered properly.

add rewrite action set_pback_cookie insert_before "http.REQ.HEADER(\"Cookie\").VALUE(0)" "\" PBack=0;\""
add rewrite policy set_pback_cookie "http.REQ.URL.CONTAINS(\"logon.aspx\") && http.REQ.Cookie.contains(\"OutlookSession\")" set_pback_cookie

2. Bind the new rewrite policy within the necessary AAA Application Traffic virtual server, group or user.  The following syntax will assist with binding the policy to the Default Global scope.

bind rewrite global set_pback_cookie 1 END -type REQ_DEFAULT 

Examination by Packet Capture

Despite the knowledge that the Form SSO profile Action URL field is a documented value, there is value in examining the SSO attempt in a packet capture should it continue to fail.  Examining the packet capture can reveal if the Exchange server is only returning the relative URL or another, unexpected value.

1. Using Fiddler or Wireshark, find HTTP 200 OK response for the initial GET request to access the /owa URL. Then, check for the values set within the "form action" tag of the resultant HTML. For example:

Request

Response

​

If the action URL is different, then change the Action URL field in the Form SSO profile.  
 
2. In addition, SSO can fail sometimes because the Form SSO profile is configured with a Response Size that is too small. The response size can be validated in the packet capture when accessing the Exchange Server directly and when accessing OotW/OWA.

For example:

Note the content length of this HTTP response from OWA is 16000.

If the Form SSO profile configuration is configured with a response size of 15000, but the actual response has a content-length of 16000, SSO will fail.  If the packet capture reveals this type of disparity, then adjust the Form SSO profile "Response size" field to accommodate the content size.

Examination by AAA Debug

SSO can also fail to function as intended if the configured authentication source is LDAP querying against Active Directory.

Typically, an LDAP against an Active Directory environment will return a group membership for a user. However, a user's Primary Group is not included in the membership list returned in the LDAP response, per design of Active Directory.

For example, the account User10 is shown to be in both the Domain Users group and Shipping group, with the Domain Users group set as the Primary Group.

However, when User10 attempts to login, the AAA debug group membership output only lists what the Active Directory server provides in the response, which is just the Shipping group.

ns# cat /tmp/aaad.debug
Sun Oct 14 01:19:29 2017
/home/build/rs_111_55_5_RTM/usr.src/netscaler/aaad/naaad.c[614]: process_kernel_socket call to authenticate
user :User10, vsid :9055
Sun Oct 14 01:19:29 2017
/home/build/rs_111_55_5_RTM/usr.src/netscaler/aaad/ldap_drv.c[124]: start_ldap_auth attempting to auth User10 @ 10.217.130.227
Sun Oct 14 01:19:29 2017
/home/build/rs_111_55_5_RTM/usr.src/netscaler/aaad/ldap_drv.c[415]: recieve_ldap_bind_event receive ldap bind event
 
Sun Oct 14 01:19:29 2017
/home/build/rs_111_55_5_RTM/usr.src/netscaler/aaad/ldap_drv.c[770]: recieve_ldap_user_search_event built group string for user of:Shipping
 
Sun Oct 14 01:19:29 2017
/home/build/rs_111_55_5_RTM/usr.src/netscaler/aaad/naaad.c[1466]: send_accept sending accept to kernel for : User10

Thus, if the NetScaler configuration depended on enumerating membership of the Domain Users group upon login, an appropriate configuration adjustment of the policies would be necessary.

This article contains the basic troubleshooting steps for Authentication, Authorization, and Auditing (AAA) single sign-on issues when integrating Outlook on the Web (Exchange 2016) or Outlook Web Access (Exchange 2007, 2010, 2013) with NetScaler. In this scenario, Outlook on the Web (OotW) or Outlook Web Access (OWA) is configured with forms-based authentication.

NetScaler deployment guides and resources - Microsoft Exchange 2013 with NetScaler: Authentication and Optimization - This guide can be used to deploy Outlook on the Web for Exchange 2016.

CTX128197 - How to Configure Single Sign-On for Exchange 2010 through NetScaler

CTX129182 - How to Configure Single Sign-On for Outlook Web Access 2007 on NetScaler

CTX233034 - [NetScaler Trace Study] - AAA Single-Sign On to OWA

CTX116557 - How to Decrypt SSL and TLS Traffic Using Wireshark
 
CTX200229 - Troubleshooting NetScaler for AAATM Form-based Single Sign-on Failure
 
CTX135603 - Active Directory Group Extraction Does Not Work on NetScaler

New features coming to Outlook on the web - "Formerly known as the Outlook Web App (or OWA for short), [the] browser-based Outlook experience will simply be referred to as “Outlook on the web” going forward."