Sharing Folders with External Users spams Organization Login Prompts

Copper Contributor

In OneDrive, I can create a sharing link for a folder and set the link so "Anyone with the link can edit". I assume this means that even users outside my organization can edit the folders and files within the shared folder.

 

If I test this with an external account, I'm able to edit the files and folders. However, I'm periodically prompted with a Microsoft login pop-up window. I can ignore/close the login prompt and continue editing the files. However, the login prompt keeps popping up periodically, including every time I refresh the screen. If I try to log in with the external user account, it gives me an error saying I'm not part of the tenant and I need to be added as an external user to the tenant. But then I can still close that and continue editing the files.

 

If I send the invite link for a folder via a graph API call, I'm forced to set the "requireSignIn" property to True in the body of the request. If I set it to False, I get an error: 

 

 

RequireSignIn cannot be false for folders

 

 

 

I do not run into the same issue when sharing files. Whether I create the link in OneDrive UI or via the API, the external user does not get hit repeatedly with login prompts. 

 

Am I doing something wrong or is this a bug? If sharing a folder is not allowed outside an organization, why does it allow me to create a sharing link where "Anyone with the link can edit"? And why is the external user still able to edit the files despite the repeated login prompts?

14 Replies

We're having about the same behavior using OneDrive for business. We shared a folder with external users using their email addresses, where when they got the shared folder email from OneDrive they click the open button and get to the shared folder as normal.

We've been using this from November and about a week ago every time a shared user tries to view the shared folder, when they enter the folder they get a popup to enter their login information from OneDrive, even though they are connected using the link from the shared folder email. If they close the popup they can upload, delete, edit documents, but every now and then they get the poup again, which is very annoying for the user.

Has anything changed from OneDrive? This is very frustrating...

@cre8gr - We are now having this issue.

@fstephane 

Is there a resolution to this?

@ExternalUsers007 

Not to my knowledge. It seems like it's been resolved in certain environments, but I still get it regularly in Chrome.

 

It was becoming too onerous to deal with Microsoft support on this, so we will just advise our clients to block the login pop ups if they are a problem.

@fstephane - Wow. That isn't a solution nor a fix. I hope this gets better because folders are shared all the time. 

@ExternalUsers007What we found is that Microsoft's Edge doesn't show the login popup every time, just the first time we login and then it's OK. But on some PCs it popsup on Edge too.

I had previously given up on this issue as I was getting nowhere with MS support. However, many of my company's clients are getting frustrated with the confusion this is causing in their own sharing activities, so I have opened up another ticket with MS support. I had a call with a support rep, which I will summarize below:

 

  • Support rep explained that there are two reasons the login prompts appear when sharing OneDrive folders:
    • Link recipient has O365 credentials stored in their browser. When they access the shared folder, O365 tries to automatically log them in with their stored credentials. That doesn't work (because their account isn't part of the organization), so the pop-up appears prompting them to log in.
    • There are multiple different levels of access/permissions on the shared folder, which creates a conflict. O365 has trouble determining who is accessing the folder and what permissions they should have, so it prompts the user to log in.
  • The support rep explained that there are two "workarounds" to the problem
    • Always access shared folders in a private (incognito) browser session.
    • Create a guest account on your tenant for each user that you share the folder with. This requires sending an invitation by email to the person you're sharing with, and having them accept the invitation. I believe they are required to have their own O365 account. Once the guest account is created, you must re-share the folder with the user's guest account. Now, if the guest uses the new sharing link, they will not receive the login prompt.
  • I explained that these workarounds are not sufficient for our purposes and do not address what I see as a significant bug in the OneDrive sharing model. Microsoft is advertising these sharing links as being able to share with "anyone", and yet the login prompts make it appear as though you need to be part of the folder owner's organization in order to access the folder at all. This is creating confusion and a sense of unprofessionalism with many of my company's clients, who are considering going with a different storage service altogether. When you are sharing OneDrive folders regularly with many different people - as our clients are - it is not reasonable to coordinate these workarounds with each link recipient. It should be Microsoft's responsibility to provide a solution to this issue.
  • The Microsoft support rep said he would discuss with his dev team again. I asked him to keep me updated.
  • Furthermore, after the support call I was able to reproduce the issue in a manner that refutes the supposed causes of the bug: I shared a folder with an anonymous link and there are no other access permissions or links on that folder. I accessed the folder via the anonymous link in a private browser session. I still got the login prompt, even though there should not have been any permissions conflicts and there were no O365 credentials stored in the browser since I was using incognito mode.

I finally made some progress in getting this issue addressed by Microsoft. I've been working with a new support ticket for a couple months now. They've resolved most of the issues and there's just one remaining edge case I'm trying to get resolved.

 

How it works now:

  • If you have no O365 profile info saved in your browser (or you're in private browsing), you are not prompted to log in anymore.
  • If you do have O365 profile info saved in your browser, you are prompted to log in with your O365 account. However, now it doesn't throw an error if you log in with an account that is not part of the organization that owns the shared resource. Once you've logged in, it does not ask you to log in again.

 

The last issue I'm trying to get resolved:

  • If you access a sharing link that was shared with your specific email, and your email is not an O365 account - you still get the login prompt every time you view a PDF file within the shared folder. There is no way to get the prompts to stop, since you do not have an O365 account to log in with. Hopefully this one will be resolved soon as well!

@fstephane I tried both cases but still with the same error with both.

  • Case 1, I use a incognito windows and pop-up windows for sign in are showing frequently (really annoying for end users)
  • Case 2 didn't work. I have in my browser session registered two accounts o365 (both different from the original org that owns the share link). I login using one of them and I receive an error in the login process
AADSTS50020: User account 'my email' from identity provider xxxxx does not exist in tenant <yyyy> and cannot access the application '08e18876-6177-487e-b8b5-cf950c1e598c'(SharePoint Online Web Client Extensibility) in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.

 

Does anyone have any updates about this issue?

@fstephane Problem is unchanged for us also.  This is a major problem and will very likely cause us to move off the Microsoft platform as our primary data store.  Did you have to do anything to get the new improved behavior or did it just start working for you?  IF we could get to the point you are we'd be much less likely to exit the MS platform.
Private window still never works, continuing to prompt for host tenant credentials.
Trying to login with credentials from another tenant account throws the error:


That didn't work
We're sorry but (other user account) can't be found in the (hosting tenant) directory. Please try again later while we try to automatically fix this for you.

Here are a few ideas: 

...(none of which work)
...

Issue type: User not in directory

 

 

 

@angelmottap 

 

Sorry to hear you're still having the same issues. I've just tested on a variety of different browsers, private/normal mode, and two different laptops - sharing with O365 and non-microsoft accounts. I did get one case with a link I had sent to an O365 email, where it asked me to sign in with the O365 account and then gave me a similar error to what you received in Case 2. But then I tried again with the same email and it worked fine (can't remember what browser this was in). I tried with that same O365 email across multiple other browsers and modes and it worked in every case - so I'm not sure what happened in that one instance when it threw the error.

 

I am also not getting any login prompt popups, and I don't see any blocked popups showing up in the address bar.

 

Just to confirm - for Case 2, are you signing in with one of the accounts that you shared the OneDrive item with?

@IC_Sid

Sorry to hear you're still having issues. As I mentioned in my reply to @angelmottap, I did some more testing and I did get an O365 login error in one case, but I was not able to reproduce that. Overall it seems to be working as expected for me now.

I wonder if there are differences in our O365 plans/setup, or regions that might explain why it's behaving differently on different accounts? To clarify, I'm using OneDrive for Business on a O365 developer license.

You may need to open a support ticket with Microsoft and be very persistent. That was the only way I was able to make any progress on my issues...

 

Unfortunately my own ticket has been closed for a long time now and I won't be much help to MS support if I'm not able to reproduce the issues anymore :(

@fstephane 

So you didn't have to make any local changes, it just started working for you?  Did MS Support say they actually implemented some changes?

 

@IC_Sid1020
If I recall correctly - it wasn't any changes I made to my account that resolved the issues. I worked closely with MS Support over a period of a few months. They made several rounds of changes on their end and requested that I test them on my end, and we had a handful of sessions where they remoted onto my computer via Quick Assist to observe me creating sharing links and accessing them in different browsers - and to grab diagnostic info. It was a pretty long process. I assumed the changes they made would resolve the issues across the board, so it's disappointing to hear that it's still affecting others. That makes me worried that my company's clients (who use our OneDrive integration to share files/folders with their own clients) may still experience the issue in production.

@fstephane Y, hard to know what to expect.  We are just getting started with this.  I'm going to keep an eye on it and see how it plays out across our deployment.  Hoping it will end up being minor.   Thanks for the info, it will help understand what is really going on if people report more problems.