Forum Discussion
Sharing Folders with External Users spams Organization Login Prompts
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 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
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 😞
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?
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?
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?
