300101008 "Unable to Authenticate" error opening URL hyperlink referenced in Microsoft Office PPTX file via Access Gateway

  • 7014518
  • 07-Feb-2014
  • 11-Feb-2014

Environment

NetIQ Access Manager 3.2
NetIQ Access Manager 3.2 Access Gateway (Service or Appliance)
NetIQ Access Manager 3.2 Identity Server configured to 'Require authentication requests'
NetIQ Access Manager 3.2 Access Gateway signs Authentication Requests to Identity Server
NetIQ Access Manager 3.2 Access Gateway has following web.xml setting enabled

<context-param>
<param-name>IDFFMaxURLLength</param-name>
<param-value>2048</param-value>
</context-param>

Situation

Access Manager setup and working well ie. users can access protected resources behind the Access Gateway (AG) after having successfully authenticated at the Identity (IDP) server. The Liberty protocol exchange between the two hosts are signed, adding extra length to the Authentication request (the AG will send this authnrequest via a 302 redirect Location header by default but fallback to a POST with javascript if greater than 2048).

After rolling out a new application, some users reported "Unable to Authenticate" (300101008 status reported in catalina log file) errors accessing AG protected resources from Microsoft Office applications, without any login page from the IDP server being displayed. A specific example of this was a user that opened a Powerpoint presentation that included a link to an AG protected resource - when clicking this link, a "Unable to Authenticate" error was reported on the user browser, and the catalina log files on the IDP server would indicate a 300101008 signature validation error.

"<amLogEntry> 2014-01-07T17:06:25Z INFO NIDS IDFF: AM#500106006:
AMDEVICEID#A4895C4EA9290A99: Validation failure on message from
https://int.mystream.com:443/nesp/idff/metadata : It should be
divisible by four </amLogEntry>"

Looking at traces and logs from both the server and client, it became clearer where the issue lay and what triggered the problem. The problem stems from the MS Office client truncating Authentication requests received from the AG. These authentication requests would arrive at the MS Office client as a form that would need to be submitted, and not via the typical 302 HTTP redirect approach.

If we look at the client side requests into the IDP server, we saw the following that clearly shows an issue with the browser (IE or FF User-Agent) after falling back from an MS-Word (User-Agent). It looks like MS-Word fallsback to IE/FF user-agent when the URL (HTTP headers, or URL length) size is greater than a certain size, and then truncates it.
 
 
// 1st AuthnRequest from MS-Office user agent (formatted to show truncation)
 
Signature=FZ08xenWs5U6Vc28uqmikqe%2BZZ2S2GwDqn%2FhH5%2F68mtQVK5dFPp8oUcWngghpNvWDHBmfhiqIAwZt9%2B8GJLcr%2FinXzr%2B%2FQ%2FCTCWOYiZrLfNhzEUBtKvtqYuo35KfyAlOU0TbwV5wdGMt9VUxTbovre30Cp%
2BQSpW1uABtCmAeY3Ar8USMkitwksKvivApyRO9GBAU0jhaKI9QLauZ7FrodZAtU5ZxCAaZ0bD4Rg4vBrSc9geQm
pjy4vukMXAvMO27aBtml5YeyqjarJM%2BQaNMGBh0%2Fw85fdhVIafYSlrdRnkPZmQ%2FzFafcXjCElbjhY3t0cFEX019OMqXSAxM0GPDVQ%3D%3D HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E; EIE10;ENUSWOL; ms-office)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: idp.mystream.com
Pragma: no-cache
Cookie: IPCZQX03a36c6c0a=030087000a4ba3f0488b22d3ed79eb4dae341d44
 
// 2nd and subsequent AuthnRequest from IE user agent - note the truncated signature that causes the IDP server to error out
 
Signature=FZ08xenWs5U6Vc28uqmikqe%2BZZ2S2GwDqn%2FhH5%2F68mtQVK5dFPp8oUcWngghpNvWDHBmfhiqIAwZt9%2B8GJLcr%2FinXzr%2B%2FQ%2FCTCWOYiZrLfNhzEUBtKvtqYuo35KfyAlOU0TbwV5wdGMt9VUxTbovre30Cp%
2BQSpW1uABtCmAeY3Ar8USMkitwksKvivApyRO9GBAU0jhaKI9QLauZ7FrodZAtU5ZxCAaZ0bD4Rg4vBrSc9geQm HTTP/1.1
Accept: */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E; EIE10;ENUSWOL)
Accept-Encoding: gzip, deflate
Host: idp.mystream.com
DNT: 1
Connection: Keep-Alive
Cookie: JSESSIONID=60A000AD42DE698A9711157FB51AB22A; IPCZQX03a36c6c0a=010064000a4ba3f0f2137ccd88976296ae341d44
 

Resolution

A few options exist here:

a) Disable the 'must sign authentication request' parameter on the IDP server. By doing this, we reduce the size of the AuthnRequests to the point that they will always fit into the 302 Redirect Location header, which MS-Office never seems to have an issue with.

The downside of disabling signed authentication requests is that they may be replayed or possibly tampered with. Given that the transport is SSL in this case, tampering is difficult to execute. If the message is tampered with, there are numerous cross site scripting checks within the IDP code to prevent these types of attacks. The Liberty SSO protocol itself includes timestamps and transaction IDs to detect replay attacks, which will result in errors on the IDP server.


b) Make client side changes as per http://support.microsoft.com/kb/218153

This allows you to set a registery key on the host machine (Office 2010: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Registration\Internet\ForceShellExecute) so that when set to "1" allows the embedded video links started to work when clicked within PowerPoint.