Authentication prompt issue when opening an office file in a document library with read permission for domain users RRS feed

  • Question

  • An user as part of the domain users tries to open an office file from a document library but he got an authentication prompt asking him to authenticate. Domain users has only access to this library and not to the whole site. This uses to work in SharePoint 2007 without any problem but not in SharePoint 2013, we didn't have a workflow on SP2007.

    Domain users has read access to only this document library in the site, but he shouldn't get an authentication prompt since he is part of the domain users and he is not trying to modify the document, he can open the document but gets two prompts, he can't also see the list using explorer view since nothings appears using the explorer view.

    Now, when opening the file, we can see..Updating Workflow Status, but we don't have any workflow working on this site or library, event any feature related to workflow.

    If we go to the event viewer in the server, we find this information,

    I also checked this thread but I couldn't find this scenario.


    I also created another list with the same permissions and using other office files but got the same behavior.

    Now, we have migrated this site from SP2007 to SP2013.

    Any ideas?

    Tuesday, March 10, 2015 10:04 PM


  • In my case the root cause of this issue was:

    • "Limited-access user permission lockdown mode" site collection feature

    when deactivated the aforementioned issue with login prompt and updating workflow status disappeared.

    You could try activate and deactivate this feature and check if it will work.

    • Marked as answer by Javi Cartin Tuesday, July 7, 2015 3:51 PM
    Tuesday, July 7, 2015 11:25 AM

All replies

  • Authentication prompts are often because the browser does not trust the destination. Try manually adding the SharePoint server / hostname to Internet Explorer's list of Intranet or Trusted sites. Chrome also pulls info from IE regarding trusted sites if I remember correctly. Firefox does its own thing, as does Safari, so I don't know how you would accomplish the same thing with those.
    Wednesday, March 11, 2015 1:25 PM
  • Hi Javi, I agree with Golf, probably an authentication issue. Probably a browser issue. Couple things to add- make sure they're using only IE 32-bit version. In the browser settings, make sure "Enable Protected Mode" is not checked, "Require server verification" is not checked and that "Automatic logon with current user name and password" is checked. 

    cameron rautmann

    Wednesday, March 11, 2015 8:54 PM
  • Hi all, thank you for your reply, I forgot to mention something. I tried this using officewebapps and it worked fine, it happens when the file is open by the office application. Yes, I agree that this should be something related to the permissions of the site because if I add domain users into the whole site, it works, but in this case, domain users have access only to this library not to the whole site. But, why is behaving that way? why am I getting an authentication prompt if that doesn't make since since domain users have read access and it should open without asking to login. Could it be related to claims authentication? Why I am getting a workflow message if there is no relation to workflows at all. Could it take something from old sharepoint 2007 to sharepoint 2013 somehow?
    Wednesday, March 11, 2015 9:18 PM
  • Cameron makes very good suggestions. Let's go one step farther and narrow down a few things:

    1. Can the user download the document and save it on their desktop (or wherever)?

    If so, they have access to the document as you believe. Proceed to the next step.

    2. If you give them write access, does the problem go away?

    Office tries to put a lock on any file you open through SharePoint. I doubt this is the cause but it is something to be aware of, especially if you ever try to develop an EventReceiver for a document library.

    3. What version of Windows are users using, 7-32 bit, 7-64 bit, or 8? What version of Office, 2010 or 2013 (32/64 also)? And what is the version of SharePoint and IE? 

    There are certain combinations that have trouble passing through authentication. There may be an add-in component involved, too.

    Thursday, March 12, 2015 7:53 PM
  • Thank you Golfarama.

    1. Upgrading the permissions to write, same behavior

    2. SharePoint 2013, Office 2010 Professional edition, Internet Explorer v10 32 bits edition

    3. I have open Excel in safe mode, same behavior

    What comes to my attention is the message...updating workflow status. There is no relation at all of any workflow, not even with Office

    Thursday, March 12, 2015 9:38 PM
  • How about question 1? Are users able to download the document and save it? I presume so.

    What if you go up to the Library tab of the list and click Workflow Settings > Workflow Settings? Are you sure the list doesn't have a workflow listed there? Again, I presume so.

    Another option is that there is an EventReceiver attached to the list. Google around for getting the list of EventReceivers using PowerShell to see if there's something hidden / not readily apparent that is firing when Office tries to open the document.

    Also, on this same web is there a Workflow Tasks list? If so, try giving all domain users Write access to it just as a quick test.

    One other thing: Are you testing all of these things by using Remote Desktop to run Office / IE directly on the server or are you running all of these tests from a different machine? The loopback issue may get you if you are running directly on the server.

    Thursday, March 12, 2015 9:51 PM
  • Thank you.

    Yes, users can download the files into their computers.

    Workflow settings on the list, nothing in here.

    There is a feature that activates event receivers option, there's one event receiver, I removed it. Same thing

    For the workflow tasks, I gave domain users read/write access. Same behavior.

    This happens on a computer, not on the server, but, I can try to open the file from the server to see how it works.

    Thursday, March 12, 2015 11:23 PM
  • OK, I am going to throw out a lot of ideas here so hopefully they get you closer to a diagnosis. Hang on :)

    Does it happen to work for some users but not others? If so, try logging in on the "good" computer with the "bad" username. This will tell you if the problem is related to the end-user's system. Also, once the user downloads a document successfully can they open and work on it in Word? Also, does the document library have any custom content types associated with it or does it just use 'Document'?

    I notice that there are other folks on the web that have run into this same problem and the similarity seems to be that they are either on SharePoint 2007 or have upgraded from 2007. Did this doc library start out as a 2007 library?

    What you might want to do is this: Make a site collection from scratch in 2013 (or find one that you know was created in 2013). Choose team site (or whatever you want) for the root web and set up the security the same way you have it on the malfunctioning library. Now, use windows explorer to copy and paste some of the documents to the new location. Be sure you recreate any needed content types. Now test it from the troubled user's computer.

    I'm thinking there may be something that is different about the library since it was migrated through various versions and updates since 2007. I've sometimes found that there can be problems (especially with user profiles but that's a different story) with things that go through this evolution.

    Friday, March 13, 2015 1:43 PM
  • Thank you for your help on this.

    1. It happens with all users when they open a file in the list. Yes, if you save a copy on your computer you can work on the file. No content types activated in the library.

    2. Yes, it started as a SP2007 library and was migrated. But I created another doc library from scratch and putted the same permissions and upload some dummy office files, same behavior.

    3. I will create a new site collection from scratch and will try this out regarding permissions.

    4. We usted ntml authentication with SP2007, with SP2013 is claims.

    Friday, March 13, 2015 7:50 PM
  • In broad terms claims is just an aggregator for multiple auth methods. Under the covers Windows Auth is still doing the work. If Windows Auth wasn't working the users couldn't log in at all.

    Are you sure you have added the EXACT host name the users are putting into their address bar into the Trusted Sites area (explicitly) of the browser. The fact that they are getting a login box in an AD environment (they are logged into their machines with an AD account, correct?) is the first thing we need to solve. Google for reasons IE is asking you to log in. I know there are those three items that Cameron suggested above. Let's not worry about the documents until we can get IE to log you in without a prompt.

    • Marked as answer by Rebecca Tu Monday, March 23, 2015 1:31 AM
    • Unmarked as answer by Javi Cartin Wednesday, April 8, 2015 6:20 PM
    Friday, March 13, 2015 9:27 PM
  • Hi, I have tried;

    Create another site collection and break inheritance, same behavior.

    Somehow, if you have access only to a document library but not to the whole site, you get the prompt and the message, updating workflow status. Even if you have write access.

    But, when you give access to the whole site, like read, the problem goes away.

    This didn't work this way with SP2007, even if you only have access to a document library, you can open the file without an authentication prompt. Somehow, in SP2013 it doesn't work this way.

    Wednesday, April 1, 2015 5:37 PM
  • Javi -    You ever get this resolved?   I am having a similar issue.    I migrated from 2010 to 2013 and when Anonymous users try to access an Office document, it says 'Updating Workflow Status'.   No workflows associated to it though. 

    Thursday, May 7, 2015 2:22 PM
  • Hi, No, the issue is not solved yet, we are escalating a ticket to Microsoft. Somehow when we migrated to SP2013, it is bringing something that it shouldn't and it is causing a problem. I tested this on a different new farm with a brand new site and it works fine. We used a tool from Metalogix called Content Matrix to do the migration.
    Thursday, May 7, 2015 4:29 PM
  • Thanks.   One thing I noticed is that if i do a 'Download as copy' it works fine.  But if I click on the document link, it prompts for credentials and shows 'Updating Workflow Status'
    Thursday, May 7, 2015 7:55 PM
  • Hello Javi,

    I'm facing the same issue on SP2013, did you find a solution to this strange behavior with MS? 

    Monday, June 29, 2015 7:02 AM
  • Hi, we found a workaround;

    1. Create a permission level with only these checkmarks,

    2. Add the group at site level with this permission level. By doing this, you are not given full access to the whole site to the group or user just to the library.

    That should do the trick

    Wednesday, July 1, 2015 5:49 PM
  • In my case the root cause of this issue was:

    • "Limited-access user permission lockdown mode" site collection feature

    when deactivated the aforementioned issue with login prompt and updating workflow status disappeared.

    You could try activate and deactivate this feature and check if it will work.

    • Marked as answer by Javi Cartin Tuesday, July 7, 2015 3:51 PM
    Tuesday, July 7, 2015 11:25 AM
  • Hi, I have tested this and it works, you are right, this feature was causing this problem, also a problem to share a second folder on a doc library, two in a row.

    I am going to investigate what this feature is about.

    "Limited-access user permission lockdown mode"

    Thank you very much.

    Tuesday, July 7, 2015 4:19 PM
  • Excellent, was unaware of this feature. Became a problem after migration from 2007 to 2013. Libraries that were opened up to specific users in other areas of the business misbehaved. Couldn't see any files in explorer view and login prompts when opening Word & Excel files.
    Friday, June 16, 2017 9:11 AM