I could be barking up the wrong tree with this suggestion but...

1. 
   
2. How is Internet Explorer configured for the user who cannot see the workspace? Is the workspace hostname or host header part of the intranet or trusted domain? Is IE allowing credentials to be sent automatically to the website?
   
3. Are you using Kerberos as your authentication method, if so, check the SPNs
   
4. Check that anonymous login is not enabled in IIS for the workspace app pool
   
5. Look in the Event Log -> Security for any suspect entries

Martin

Martin -

Thanks for the response. IIS is setup fine. Everything works fine if I login to Workspace as the K2Admin. I am running Kerberos so I will check the SPN's. Also, I don't see anything in the event log, just in console. All it says is that Anonymous access is not allowed. Same as the error that I posted.

I will check and let you know.

Here is the output of my SPNs. It looks like they aren't all set and the ones that are are incorrect. Host is right, but not SMTP, and there is no mention of the NLB Name K2 or FQDN k2.corp.DOMAIN.com. I didn't set this up. I typically don't work with Kerberos....I develop workflows. I found this blog on the underground http://k2underground.com/blogs/johnny/archive/2007/12/07/k2-blackpearl-hf2-01-distributed-installations.aspx which gives great details for setting SPN.

My question I guess would be should I set more SPNs like in the blog/document?

C:Program FilesSupport Tools>setspn.exe -l k21
Registered ServicePrincipalNames for CN=K21,CN=Computers,DC=corp,DC=DOMAIN,DC=com:
    SMTPSVC/K21
    SMTPSVC/K21.corp.DOMAIN.com
    HOST/K21
    HOST/K21.corp.DOMAIN.com

C:Program FilesSupport Tools>setspn.exe -l k22
Registered ServicePrincipalNames for CN=K22,CN=Computers,DC=corp,DC=DOMAIN,DC=com:
    SMTPSVC/K22
    SMTPSVC/K22.corp.DOMAIN.com
    HOST/K22
    HOST/K22.corp.DOMAIN.com

Okay.. so the SPNs might not be correct, this is something that should be checked. A good whitepaper is: http://k2underground.com/files/folders/technical_product_documents/entry21001.aspx for the SPNs.

I have a hunch that your problems are related to Internet Explorer....

can I just make sure I understand, you are logging in with K2 Admin and the other user from the same machine and from the same Internet Explorer... am I correct?

Does Internet Explorer prompt you with a login window when you navigate to the Workspace? If it does... then either Kerberos is not working, or Internet Explorer is not 'automatically' sending credentials... this is a security setting.

Martin

When I log in to workspace as "K2Admin" I don't get any errors or prompted for anything and it works fine. If I go to a different machine or the same and I am logged in to XP or Server as me "coryc" I get the error.

 As for Kerberos I will look at the doc you mentioned. This is just a test lab and the production servers will be setup in 2 weeks so as long as it doesn't happen there than I am good.

Just so I can understand things... are you doing a Run As on Internet Explorer or are you logging into the machine as K2Admin?

Something smells fishy... perhaps you should log a support ticket or post some nice detailed screenshots if you think its worth your while sorting it out.

Sorry I can't be more help on this one

Martin

Thanks Martin for your help. The only thing I have changed now is I added :389 in the AD connection string for Workspace. Still no fix for it.

When I am logging in and it works I am logged into the PC as K2Admin and simply opening workspace. If I log into the PC as ccalcut and open workspace I get the error. I also will get the error if I do a Run As and use ccalcut as the username.

Here is the error if I log in as myself not K2Admin.

Here is the console data which you can see I am authenticated with kerberos and K2.

Hi there,

I'm afraid after trying to recreate this problem unsuccesfully using a VM, I haven't a clue what to try next.

Is your user in the Domain User's group?

How has your Kerberos delegation been constrained?

Martin

Hi ccalcut,

I am guessing that your application pool identity for the Workspace site is either set to Localhost or Network Service. This will explain why Kerberos still works.

The other error might be that the users do not have access to the Workspace on the file system.

Make sure the web.config file for the Workspace is still set to not impersonate.

I suggest that you change the application pool identity to a domain account. Refer the the link in the previous posts.

HTH

That probably will not address the root of the problem.  By turning impersonation off, it means that it is using the app pool account to connect to the K2 server.  i.e. you are accessing the worklist of the app pool account.

I did a check and apparently you are right.  I think that also explains why you see a connection being made to the K2 server using the K2 workspace app pool account when launching the workspace.  Could it be related to the new ImpersonateUser functionality? *guessing*

This seems somewhat different than the K2.net 2003 workspace web.config (identity impersonate tag was set to true).