0

I converted my development SP 2007 content db to SP 2010 using database attach method from a Win 2003 virtual machine to a Win 2008 VM. Everything worked fine on my old VM, and also works fine on our production server (SP 2010, Win 2008) that was converted by an administrator. But my new development VM seems to have an issue: We use a custom EditForm.aspx for one of our SP libraries to capture metadata from the user. When the user selects "Edit properties" from the ECB of the library item, they get our custom EditForm (we used SP Designer to change the default EditForm to user ours). This EditForm application is installed under our SharePoint application in IIS. In the EditForm code behind, we call the UpdateListItems web method of the SP Lists web service. When it hits that line of code, it throws a 401 Unauthorized error. That's the problem.

I am using DefaultCredentials in the code behind, impersonate has been set to true in the SP web.configs (both: the one under inetpub/wwwroot/wss/Virtualdirectories and the one in the 14 hive Config folder) and in the web.config of my custom EditForm.aspx application; the web.config also has Windows Auth. mode set to ture; in IIS I have only ASP.NET Impersonation and Windows Authentication enabled (Anonymous, Basic, Digest, and Forms Auth are disabled). In the inetpub log files, I see that the attempt to hit /_vti_bin/Lists.asmx is using the NT Authority/IUSR account (not my current logged in acct.), the Identity of the application pool for the SP app is Administrator, which is what I log in with; Administrator has full privs to the farm, site collection, site, and library; I can hit the SP web service via the browser; if I change the web.config of my EditForm application to impersonate with an explicit acct (Administrator acct and p/w), then it works, but I can't use that because that's not how our production web.config is set up, and we would lose the ID of who made the change in the version history of the item.

So, I'm missing an impersonation (delegation?) setting somewhere in my machine setup. All of the existing code was ported to SP 2010 in Win 2008 without code mods or changes to the EditForm web.config file (have compared production with mine), and it works there, just not on my VM. I have seen many posts like this with the solution offered up as change your code, or use the explicit login id for impersonation, or change to Kerberos. None of these solutions is an option for me. I need to keep the code and web.config the same as what runs on production. Besides, we want impersonation to work because we want the user's credentials to be authenticated by the SP Lists web service, and not use some acct. that is always authenticated successfully (security issue), and we want the version history of the updated library item to reflect the actual user ID who last updated the item, and it does that just fine on production.

This question posted on StackOverflow was close, but the solution was to change to Kerberos, I don't have that option: "IIS 7.5 site using impersonation does not have permissions to access Sharepoint web services"

Kyle Trauberman
  • 25,414
  • 13
  • 85
  • 121
KevinHou
  • 151
  • 1
  • 2

1 Answers1

0

Solved it. Messed up an early step, during the process of converting SP 2007 to SP 2010, I needed to recreate a Web Application in SP 2010 to match my original from SP 2007. Problem is, I selected "Claims Based Authentication" rather than "Classic". From this article: http://technet.microsoft.com/en-us/library/cc262350(v=office.14).aspx, I had found this sentence: "You can use any of the supported authentication methods with the claims-based authentication mode or you can use classic mode authentication, which supports only Windows authentication." So I assumed claims-based was the 'new' way to go. Apparently not. Dismounted my content db, deleted the web app from central admin, re-created the web app using Classic, attached the content db - all is well. Lesson learned somewhere in there. KevinHou

KevinHou
  • 151
  • 1
  • 2