Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have some strange behaviour happening in SharePoint 2010, which I believe is something to with Impersonation but I'm not entirely sure.

I'm not sure how to word this, so I'll do it like this:

Scenario:

  1. A user (User A) is logged into Windows.
  2. The user (still User A) opens up a SharePoint 2010 site and then signs in under a different user (User B).
  3. The user (now logged in as User B in SharePoint) edits a Word document which is required to be checked out.
  4. SharePoint 2010 checks out the document as User B but when Word opens up a message is displayed saying 'This document is checked out by User B'.

The Word document should be able to be edited because the user context from SharePoint sent to Word should be as User B not User A. It seems that Word is still opening up as User A and because the document is actually checked out to User B it can't be edited.

(User A and User B are both AD accounts)

I'm not sure if this is a SharePoint configration issue or if our network is somehow configured so impersonation of an AD account isn't allowed (I'm not even sure that's possible).

Has anyone seen or had this problem before?

Also, the same thing happens when opening Explorer View. If I'm logged into Windows as User A but logged into SharePoint as User B when I open up Explorer View I cannot access the view because WebDAV thinks I am User A.

I hope this makes sense? It's pretty difficuly to explain...

Thanks!

share|improve this question
add comment

1 Answer 1

up vote 2 down vote accepted

The short answer is that Office and SharePoint do not share the same context in IE and thus, do not share the same credentials. All office apps open up a new instance of Internet Explorer internally and then connect to the SharePoint site using that. If the site is such that it can pass windows/domain credentials (i.e. it is listed as in the Intranet Zone) then Office will pass the default windows credentials instead.

To put it in terms of your example, User A opens IE, then logs in as User B. User B then opens a document for editing which checks out the document in sharepoint as user B. Office then launches (which opens a new instance of IE) and attempts to interact with the document using the default windows credentials (user A) and is then told by SharePoint that they cannot do that since User B already has it locked.

As to working around it, there are a few possibilities:

  • Remove the site from the local "Intranet Sites" or "Trusted Sites" zone which will force authentication both for IE and for Office
  • Give UserA proper permissions and simply use that ID instead.
  • Remove permissions to the item from UserA which will force an authentication request
  • Log into the workstation as UserB

Regardless of the above, it is also not a best practice to have users using multiple logins when interacting with a site as it makes basic accountability almost impossible. For example, if User B deletes a document but the credentials for User B are shared around the office, you have no idea who actually made the change.

share|improve this answer
    
Thanks for the explanation and workarounds. The reason we would have a user logged into Windows as one user and using SharePoint as another user is because we work in a hospital where computers are shared on wards. For instance, a workstation will be left logged on all day as 'WardA' and then UserA and UserB will log into SharePoint but will have different permissions. This just saves time from logging off and on as different users every 5 minutes. –  Jamie Aug 4 '11 at 8:39
    
Dave has explained what's happening very well, i'd like to add another possible solution which i have been looking into and hopefully implementing in the near future. in my scenario we have restaurants with a generic restaurant account for logging into the computer, this account is shared by a few managers for stock takes, cash up etc. we needed a way to allow these managers to log into sharepoint with their own identity for personal tasks such as expense claims and hr portal access. using forefront TMG as a proxy we were able to authenticate the user and carry that through for their whole ses –  user7808 Apr 11 '12 at 8:27
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.