000014760 - AxM-How to Integrate Access Manager with Microsoft SQL Server Reporting Service 2005

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000014760
Applies ToRSA Access Manager 6.0.2
Microsoft SQL Server Reporting Service 2005
RSA Access Manager 4.x agent for IIS 6.0
IssueAxM- How to Integrate Access Manager with Microsoft SQL Server Reporting Service 2005
HTTP Error 404 - File or Directory not found when accessing http://server.fqdn/reportserver and http://server.fqdn/reports
Resolution There is a setting in the reporting services web.config that forces it to pass basic credentials on each HTTP get method call. This parameter allows third party cookies to flow through Reporting Services.
<UI>
   <CustomAuthenticationUI>
      ...
      <PassThroughCookies>
         <PassThroughCookie>CTSESSION</PassThroughCookie>
      </PassThroughCookies>
   </CustomAuthenticationUI>
      ...
</UI>
NotesAccess Manager (AxM) provides a security layer on top of Reporting Services, where when AxM is used, the IIS directory security settings are set to "Anonymous" instead of IWA and AxM performs Protocol Transition to impersonate the browser user. AxM agent, which runs as IIS filter, performs the authentication, whereas AxM facilitates the protocol transition via a combination of an IIS extension and a Windows Service (running under system account). Below are the steps that take place when AxM is involved:
1. A browser user attempts to access http://server.fqdn/reportserver, AxM attempts to locate the cookie, if one is not found the user is redirected to a logon webserver to obtain AxM cookie, where it is authenticated against corporate directory and post authentication the user is redirected back to http://server.fqdn/reportserver for continuing the request.
2. When request arrives on http://server.fqdn/reportserver, the AxM agent parses the cookie and obtains the userid and windows UPN from the cookie, and calls LsaLogonUser to impersonate the user on the local machine to obtain Kerberos token for the user.
3. Once the token is obtained, the AxM agent running inside the IIS process impersonates the user and hands off the request to IIS and lets the request continue.
Legacy Article IDa42673

Attachments

    Outcomes