We have developed a custom complied .net 4.0 dll library that that is deployed on a standard IIS server. The library is used by a vendor created application, Spotfire Web Player, which is run in its own Application Pool on the IIS server. The plug-in connects to another server running tomcat for the purpose of retrieving data via web request. To make this request, the plug-in generates an authentication token using negotiate security, converts it to a base64 string, and passed to the other server to facilitate pass through authentication. At the Application level in IIS, the Spotfire Web Player application is configured to use Windows Authentication, further in the Providers under Windows Auth, we have specified Negotiate:Kerberos be the only authentication method as well as disabling kernel mode authentication in advanced settings (required when removing NTLM). This was done in attempts to overcome the NTLM double hop limitation, which we thought may be the issue. The application pool is a standard .net 4.0 integrated pipeline pool, run under the systems NetworkService account.
Here are a couple scenarios that demonstrate to us that a security issue or IIS configuration is interfering with the proper authentication methods.
Failure Scenario (double hop)
State
• Server is running as described above with no remote/interactively logged in users.
Action
• User on remote laptop open internet explorer browser and attempts to open document that will utilize plugin.
Result
• Authentication failure results.
Functional Scenario (single hop)
State
• Server is running as described above with an administrator logged in via remote desktop
Action
• Administrator opens internet explorer on server session and proceeds to open document that will utilize plugin
Result
• Authentication success. Administrator’s credentials successfully passed to Zema server and authenticated.
Functional Scenario (double hop)
State
• Server is running as described above, administrator logged in via remote desktop, AND administrator has successfully opened a document (via IE in remote desktop) that utilized the plug-in and successfully authenticated.
Action
• Any other standard user, from their laptop, in chrome or IE, attempts to open a document that will utilize the plugin
Result
• All users are able to be authenticated. Only after a document was opened on the server itself first.
Functional Scenario (single hop)
State
• Unlike in the above IIS server, this plug-in can also be utilized on a client side .net application which runs on a user’s local laptop. The exact same DLL library is used by IIS as is sued by this desktop application (Spotfire analyst software).
Action
• Any user opens a documents on their laptop which uses the plug-in
Result
• In this scenario, the users laptop runs the plug-in, generates the authentication token, and sends it directly to the Zema server. The IIS server is not in the picture at all. This scenario always results in a successful authentication.
Thanks!
