This post explains how to get a smart link which persists authentication, scroll down to the wrap-up if you’re just looking for a quick solution.
We recently had an interesting situation with a customer. They are using SharePoint Online (or to be more precise, Office365) which is federated with their own domain and using their own domain name for the SharePoint sites. They have Single Sign On working by using a portal for authentication and redirection to the Microsoft Online Services with smart links ( http://community.office365.com/en-us/w/sso/using-smart-links-or-idp-initiated-authentication-with-office-365.aspx ).
So what’s the twist?
The thing about the users in this company is that they like to open document libraries in Windows Explorer, using the «Open in explorer» button in the SharePoint library and then dragging the URL to the left-hand shortcut tab in Windows Explorer (folder names blurred on purpose):
This function works pretty good now, unlike a couple of years ago which many of you may remember (WebDav has been a source of frustration for many sysadmins over the years), but it has one major drawback:
When the security token issued for the SharePoint Online site expires, you will no longer be able to open the document library in Windows Explorer. In fact you’ll get an error message which can be caused by several different root causes, and might send you off on a wild goose chase, trying to find out what’s wrong with the Internet Explorer settings, why the ADFS-server isn’t accepting your credentials, and others (see the following blog ). The reason for this is the Forms Based authentication used by SharePoint Online, and Windows Explorer does not have a function to authenticate automatically with forms based authentication. This means that you’ll have to re-authenticate against that SharePoint root site to be able to browse the WebDav folder again.
NOTE! The security token accepted for a SharePoint site is bound to the site’s domain URL (eg: example.sharepoint.com/site1 and example.sharepoint.com/site2 uses the same security token, but example-my.sharepoint.com does not use the same token as example.sharepoint.com). This means that you’ll have to open the correct root site to get a valid token.
So how do we communicate this to end users? The answer is you don’t, and the solution is easier than you might think. When a user tries to access their company’s SharePoint Online site they may enter https://example.sharepoint.com, which will give them the following log on screen (sorry for the Norwegian version):
That’s why we use smart links, because they allow us to send the domain information so we get redirected to our ADFS (presumably) server and authenticated, without having to type our username:
The issue with this is that the security token issued will not be persistent (Remember me), which means that the WebDav folder will still not be accessible, even though you’re logged in to SharePoint again. So what I did was start up Fiddler, and I checked the web requests sent from Internet Explorer when I logged in the «hard way» with persistent authentication (Remember me). What I found was that the Microsoft Online portal redirected me to our ADFS-server with an insane URL (whitespace inserted to make the blog post readable):
https://sts.example.com/adfs/ls/?cbcxt=&popupui=&vv=&username=user%40example.com&mkt=&lc=1044&wfresh=&wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1%252E0%26rpsnv%3D3%26ct %3D1967435096%26rver%3D6%252E1%252E5474 %252E0%26wp%3DMBI%26wreply%3Dhttps%253A %252F%252Fexample%252Esharepoint%252Ecom %26lc%3D1044%26id%3D5878324%26%26bk%3D14327786597%26LoginOptions%3D1
Now, this might look like a hash or some obscure meta-information at first, but what you can get from this is that the portal redirects you to your ADFS-server, with the original request as a reference (which is used by the ADFS server to redirect you back to Microsoft online with a reference to the SharePoint server you’re trying to reach, which makes the Microsoft Online portal redirect you to SharePoint Online. Like a merry-go-round of authentication madness). The interesting part is the last bit, which says LoginOptions%3D1, where %3D is code for the equals (=) sign, and 1 is a value (duh). So I ran the request again with the Remember me box unchecked, and to nobody’s surprise this gave me the exact same result, except with LoginOptions%3D3 at the end.
Huzzah! We have a 380 character string we can use as for reathentication……
Not quite. To make this simpler without using a webserver and a vanity URL (in which case I recommend using this insanely long URL to reduce the redirect madness with one hop. As long as single-sign-on is working with your ADFS server you can use ‘domain.com’ instead of ‘user%40example.com’ to prevent confusion), just take the last part of the URL and add it to your smart link:
Now, just add that URL as a favorite in Internet Explorer, in a log-on script (remember to specify IE as the browser), set it as the home page, or however you want to do it and users will be able to easily re-authenticate and continue to browse their WebDav directories.
On a side note, should we allow our users to keep traversing folders like it’s 1999? Why not use the functionality SharePoint gives you instead, and demand that your system owners and/or Microsoft Partner optimize search and browsing experience instead of letting users make mistakes by dragging/moving folders all over the place using Windows Explorer? The easy answer is ‘Use search!’, but in reality you have to find out if users are ready to change the way they work, and this ‘quick fix’ will make things much better for a low cost until you decide to move things forward. Manually browsing filesystems can be useful, but more often than not what you’re doing is looking for files you don’t really know where are, so why not use the functionality you’ve already payed for?
The wrap up
To get single-sign-on with SharePoint Online by using a single URL to do the job, simply enter your company’s details in the following URL (replace the orange text) and use that to make it easy for users to log in and stay authenticated (for 8 hours or until the browser cache and cookies are cleared, whichever comes first):
Marius Agur Pedersen
Super Potato at Skill AS