Embedded videos asking company users to sign in. Is there a way to turn this off?

Deleted
Not applicable

So I've uploaded a video on Stream and decided to embedd the video within a Word document. I've made sure the setting "Allow everyone in your company to view this video" is turned on within permissions for the video. And under Viewers I have myself, Companywide channels and the channel I've created to upload the video. 

 

The word document I've embedded the video in will be used as a tutorial / step-by-step guide. Once I upload it to our company server where everyone can access it if needed, I want our users to be able to watch the video without much trouble. In this case, the prompt to "sign in or sign up" after clicking on the video is what I'm trying to remove. Most of our users will not know their email passwords, so this could cause issues.

 

Is this possible?

31 Replies

@Dustin Halvorson @Tiger Boshomane Hi guys, we apologize that this behavior persists. A number of people have added onto this thread about a number of different embed scenarios but my understanding is that your issues stem from being logged into a sharepoint page but not being able to automatically view your videos. This could happen for one of two reasons:

 

1) You're signed into sharepoint and federated through a system like ADFS that authenticates a user through an accelerated path that doesn't necessarily show that there's an active AAD session existing and as such Stream prompts a manual login because the login flow uses that as a fallback. 

 

if this is the case let me know and we can walk you through how to use a domain hint (pointing to the endpoint you use to authenticate with) to respect the auto-acceleration flow and hopefully improve this behavior. 

 

OR 

 

2) your admin has set conditional access policies on certain resources at your company that require a condition like Multi-factor authentication. Since Stream utilizes MS Graph to pull the right data in to keep your permissions and videos up to date, we have to abide by that conditional access policy. SharePoint may have a separate policy that doesn't require the same authentication so you may be signed in at a lower level (maybe just user name and credentials) which is NOT enough for Stream. As such, Stream prompts you to "step-up" sign in with the correct level of authentication. 

 

If this is the case, we are working with the Graph team to make improvements to this user experience and relieve as much of the user's friction as possible. There are some experiments in the works but this is a large systematic change that needs to be handled delicately in order to not potentially negatively impact any other scenarios. We also understand that the sign in prompt can be confusing and are working towards having a more meaningful message displayed. 

 

if you have any more questions or are looking to stay in the loop with these changes more feel free to DM me directly OR you can send me an email (saraje@microsoft.com)

 

We are seeing the same experience no matter where the link is shared.  If we click 'share' on a video, and put the link in Sharepoint, email message, web page, etc....it auto redirects to the 'start' screen (https://stream.microsoft.com/en-us/) .  Users have to click sign-in on the top right hand side, and then it works.

 

For all other O365 products (Planner, OneNote, Teams, Forms, etc.) if you share a link, it auto logs in, and users never have to click 'sign-in'

 

We are using ADFS internally.

hi @Dustin Halvorson if you are looking to not include the stream page (that explains that a user has a stream video shared with them) then you can append "?noSignUpCheck=1" to your video URL. 

If you'd like to discuss your ADFS scenario offline more, I'd be happy to DM you. 

 

@Saili Raje -  If I read your comment correctly, it sounds like if we are using MFA for all O365 apps, including SharePoint and Stream, then this is an Office Graph access policy issue between the two O365 apps that is still being looked into. Is that correct? 

 

Would this address our root issue of embedded Stream videos not playing on a classic SharePoint Publishing Site? If a users is authenticated in SharePoint already, then it should be able to pass that through to Stream on the back end for a seamless user experience. 

 yes it does, it only required the step up flow if SharePoint didn't have the same conditional access policy. that being said, we've officially been able to decouple them so you should no longer be impacted by this issue. 

 

let me know your thoughts

 yes it does, it only required the step up flow if SharePoint didn't have the same conditional access policy. that being said, we've officially been able to decouple them so you should no longer be impacted by this issue. 

 

let me know your thoughts

@Saili Raje- I haven't had any issues with embedded Stream videos asking for login creds recently, so it appears the decoupling fixed it. Thanks for the update!

awesome! Glad this is working now :) 

Hi @Saili Raje 

 

We're also experiencing the sign-in/sign-up prompt for Yammer embedded Stream video. Do we have any work around or specific settings to trigger automatic sign-in on this? We verified this is not a network/account issue but rather a setting on the organization/Yammer/Stream. Your response will be appreciated. Thank you.

Hey Jessa, is this issue occurring in the mobile app or in the browser? on what device? @Jessa Marie Mojica 

@Saili Raje -

 

In response to your note about this scenario, this fits us. We are seeing issues with Stream videos embedded in Classic pages (requiring sign-in) ... this happens in Safari and IE, but not in Chrome. Can you send me details on the domain hint you mentioned?

 

"

1) You're signed into sharepoint and federated through a system like ADFS that authenticates a user through an accelerated path that doesn't necessarily show that there's an active AAD session existing and as such Stream prompts a manual login because the login flow uses that as a fallback. 

 

if this is the case let me know and we can walk you through how to use a domain hint (pointing to the endpoint you use to authenticate with) to respect the auto-acceleration flow and hopefully improve this behavior. "