Hi Marian,

When you export your processes to the K2 Server, it is essential that you grant the "Anonymous" user the "Start" privilege/permission, so that SharePoint can start/plan the process. Depending on what interactions the process is to make with SharePoint, you may need to grant some of the other privileges to the Anonymous user as well.

We've configured our environment for Kerberos authentication/delegation and found that the web part seems to work fine with our configuration.

The following might be useful:

• Ensure that the K2 Server Service is configured to run as a Domain Account rather than as "LocalSystem"
  Ensure that the K2 Service Account is "Trusted for Delegation"
  Ensure that the K2 Server is "Trusted for Delegation"
  Add the following values to the K2 Service Account "servicePrincipleName" attribute:
  
  • http/

[K2ServerName]
http/[K2ServerName].[DomainName]
K2Server2003/K2[K2ServerName]
K2Server2003/K2[K2ServerName].[DomainName]

Ensure that the K2 Service Account is granted the "Log on as a service" and "Log on as a batch job" user rights on the K2 Server


We've also changed the IIS Application Pool used by the K2 Web Components (DefaultAppPool in our environment) to run as a named user. This user was also added to the "IIS_WPG" group on the K2 server.

We also added the K2 Service Account to the "Administrators" group on the K2 server.

Hope this helps.

Regards,
Dave

---

Hi

I seem to be having the same problem as marian, It seems that sharepoint is only sending the anonymous user rather than the authenticated user to find the list of tasks for a user. I remember in the k2 training being told that Sharepoint only sends the anonymous users and can not send the authenticated user ???

I've tried the suggestions given by Dave but no luck in getting sharepoint to send the authenticated user rather than the anonymous one

Regards

Rich

Richard Hyams | Global IT Development Mgr| Eidos

> Tel. +44 (0)20 8636 3000
> Fax +44 (0)20 8636 3001

Eidos PLC
Wimbledon Bridge House
1 Hartfield Road
Wimbledon
London SW19 3RU
www.eidos.com

---

Hi,

We've also used the following authentication settings on the various K2 Virtual Directories on the K2 Server's IIS installation:

K2V3

• Basic Authentication:

Enabled

• Default Domain:

[DomainName]
InfoPathService

• Integrated Windows Authentication:

Enabled
Basic Authentication: Enabled

• Default Domain:

[DomainName]
SharePointProcessService

• Integrated Windows Authentication:

Enabled
Basic Authentication: Enabled

• Default Domain:

[DomainName]
Workspace

• Basic Authentication:

Enabled

• Default Domain:

[DomainName]
WorkspaceService

• Basic Authentication:

Enabled

• Default Domain:

[DomainName]

NOTE: We also have a requirement for Basic Authentication in our environment.

NOTE: We have disabled Anonymous access on all of these Virtual Directories on the K2 Server.

You'll also need to make sure that any virtual directories you've created to host SmartForms also have a suitable authentication method set in IIS - In our environment, this is to enable Basic Authentication and specify a Default domain - See Workspace example above

On our SharePoint Server we also set the following Authentication Methods for the Default Web Site which hosts our SharePoint installation:

Default Web Site

• Integrated Windows Authentication:

Enabled
Basic Authentication: Enabled

• Default Domain:

[DomainName]

We also made a change to one of the web.config files for to enable user impersonation - I'll have to check which one it was and post an update.

Regards,
Dave.

---

thanks a lot Dave that has helped a lot....

The biggest problem was we forgot to set the SPN for the domain Service account that runs Sharepoint (we had just set it for the account that runs k2) so Kerberos authentication was not being passed correctly to the K2 server

Cheers

Rich

---

Hi,

David, thank you for the advice, this will help many people in the future!

Rich, You are correct by saying process planned by SPS can only pass Anonymous, the reason for this is because SPS raises the event used by K2.net as the SPS service account. This makes it impossible to impersonate the actual user that caused the event to fire.

The issues experienced in the postings was based on the actual account that was impersonated by the Worklist web part to K2.net, because delegation is taking place in a scenario like this it is required that the various machines and accounts needs to be trusted for delegation, refer to the K2.net 2003 Task List Configuration document (available on http://portal.k2workflow.com/downloads/product.aspx)
for more information.

Regards,
R

---

This makes it impossible to impersonate the actual user that caused the event to fire.

is there any way around? In my case I need to send an email to a user (the originator) when he inserts a document in a document library.

Please help (or confirm it's impossible)

Thanks

---

Hi

You could add a column in the document library that captures the identity of the person who has uploaded the document. Then you can import the value into your process and send mail (or do whatever you need to). Here is a posting that could help you with creating the column:
http://forum.k2workflow.com/viewtopic.php?t=51

---

thanks alot

---

We are also having a similar problem except we do not use Kebros Authorisation, is this a requirement to get this web part working?

---

Hi everyone - how is it going with Sharepoint? I have a new girlfriend

---