Every once in a while I come across a problem which is vexing and irritating and equally, an absolute joy when it is finally resolved.
This particular issue had been on-going for some time with one of my customers with reports coming in from various people saying that they were being prompted to authenticate when opening an Office document in SharePoint Online. “I’ve already logged in so why do I keep getting these prompts?!” – It’s a fair question, especially since the organisation had implemented AD FS to reduce the frequency of authentication dialogue boxes. It seemed that Microsoft was not only being overprotective but overbearing as well. Here’s the dialogue I’m talking about by the way:
Figure 1 – Overprotective
Along with this issue, the customer had started to map network drives to SharePoint. Let’s face it, it’s easier to manage files in a folder structure than in the SPO web interface, and with improvements over the last few years with SharePoint mapping network drives actually works, or at least is should work. While it was working some of the time, there were reports of access issues to these mapped drives, and a different dialogue box which while uglier, on first glance appeared more promising from a technical perspective. A recommendation for a fix and a reference to a KB article!
Figure 2 – Ugly but useful
There are a plethora of articles, wikis, forum posts, etc out there which all talk about adding your SharePoint Online sites to your browser’s Trusted Sites list. The referenced KB article covers it off nicely, and I’ve added the link in case you’ve not come across it, here.
In my particular case the SharePoint Online domains were all happily existing in the IE Trusted Sites list (I checked about 30 times during my investigations)
I’ve mentioned that AD FS is in play, further a redirection URL http://Intranet.KloudySky.com.au is used with a Smart Link in this particular environment to provide a more seamless login experience. Until very recently you were not able to customise the Office 365 Portal page, https://login.microsoftonline.com. Check out this article for more info on how to brand the Sign-In Page with company branding.
While you can now brand the Sign-In page to your heart’s content (if you have an Azure subscription along with your O365 subscription), you’ll need to type in your UPN at least once (normally not an experience IT wants to establish for a new Intranet rollout), and so smart links are not yet dead.
I’ve set the scene, and for most of you you’ve probably bypassed everything above and come straight to this point. For those of you who took the slow route of reading from the top; Thanks for sticking around!
The problem I was seeing was due to a very simple issue really. You need to check the check box which says “Keep me signed in”. It even says so in the ugly helpful dialogue box above. The thing is, if you’re using AD FS and SmartLinks you don’t actually hit the Office 365 login page and so don’t get the opportunity to sign in. We need to pass the “Keep me signed in” option to the AD FS server somehow, and the only way to do that is to encode it in the URL.
How do we do that? As it turns out there’s a way!
At the end of the SmartLink is the LoginOptions attribute.
LoginOption=3 will pass the “Keep me signed in” option as off (Not checked)
LoginOption=1 will pass the “Keep me signed in” option as on (Checked)
Don’t keep me signed in. Boo!!!
Keep me signed in. Yay!!!
I only made this change on the Internal SmartLinks by the way. I’ve left the SmartLinks published to the Internet with LoginOptions=3, we don’t really want people on untrusted PCs and devices to remain logged into Office 365 services.
I’d like to make a big thankyou to Carolyn at Microsoft PSS for helping me resolve this issue.