K2 Distributed Installation: Why is Originator the SharePoint Service Account?

  • 26 March 2009
  • 3 replies
  • 1 view
A
Badge +1

Hello all:


We have the following hardware-decoupled installation running:



  • SharePoint 2007 (MOSS) front-end farm, serving InfoPath Forms Services
  • K2 workflow engine on a dedicated server
  • SQL server farm hosting the K2 and SharePoint back-ends

The entire thing is glued together by Kerberos (satisfactory configuration of which took quite a bit of finagling). We have the following scenario:


When a Forms Services (web) InfoPath form is submitted from our MOSS front-end, it is accepted by K2, whirls nicely through the various processes and then reaches a state ready for the next step in the workflow. However, in the workspace Process list, the originator is listed as the service account that the MOSS app pool has been configured to run as - as opposed to the user that is currently authenticated (logged in) in the SharePoint context.


At this time, we are not experiencing any specific authentication, Forms Services, K2, or SharePoint errors. However, the fact that K2 thinks the originator is the SharePoint service account messes up subsequent handling of the form through the workflow, as it then appears that users further downstream don't have proper rights to open the form. In other words, it looks like the form doesn't belong to them, even though they submitted it!


During development in a "standalone" configuration (K2/SQL/MOSS on one server; no Kerberos), of course the originator information was as expected - i.e. the user that was logged into SharePoint at the time and submitted the InfoPath form.


What are we missing in order to be able to reflect the proper originator in our distributed scenario? Any ideas, thoughts, etc. most welcome. Thanks in advance,


Allen Racho
System Development Specialist
Brokerage Services Division
Arthur J. Gallagher

3 replies

G
Badge +5

Hi Allen,


There could be a number causes for his to happen. To start troubleshooting please ensure the following :



  • Your MOSS site is set up for Identity Impersonation. Verify this by opening the MOSS site's Web.Config (default "InetpubwwwrootwssVirtualDirectoriesxxx") and ensuring the "<identity impersonate="True" />" entry has been added.
  • Also ensure that Anonymous logon is not enabled on the MOSS site.
  • Both points mentioned should be true for the K2 Runtime Services virtual directory.
  • Ensure that the WorkflowServer environment field does not contain a specific UserName and Pwd in the Connection String.

Once this has been verifed we can take it further.


Kind Regards,


Gert

A
Badge +1

Gert,


Thank you for the reply. You are indeed correct: the impersonate directive in the web.config of the MOSS FE was commented out (and therefore false). Logins for anonymous are also definitely not allowed on the MOSS FE.


However, when setting impersonate=True, we now get a "Some rules were not applied" error when opening InfoPath forms. Examining our SharePoint trace logs (where we have Forms Services output trace information) shows errors like this:


"Forms Server | Forms Services Data Objects | 13zh Exception  System.Net.WebException: The remote server returned an error: (401) Unauthorized.     at System.Net.HttpWebRequest.GetResponse() at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.GetResponseHelper(WebRequest request ...etc."


The thing that stands out is the "(401) Unauthorized" - and from the flip side, examining the Security log of the K2 box then shows login attempts by NT AUTHORITYANONYMOUS LOGON. From what I gather, this means that user credentials are not being passed successfully back to the K2 server?


Allen Racho
System Development Specialist
Brokerage Services Division
Arthur J. Gallagher

T
Badge +9

Allen,


If this issue has been resolved, could you please share the resolution with the community?  Thanks!

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings