First of all, let me describe the scenario. I am trying to set up a little organizational network for a relatively small private organization (assume ~30-40 people), with primary services needed being email, calendaring, and shared documents. There's no physical premises there so there's no "on-prem", strictly speaking - everyone is going to access it online. There's no need for an internal network, nor for domain-joined machines. Also, there's no existing deployment - this is all being built from scratch. The budget is also fairly limited.

Ideally, we'd like an all-cloud solution to minimize maintenance hassle. At the same time, we also want to minimize the monthly cost per user. It seems that the most efficient way to do so is to get the Office 365 Exchange Online Kiosk plan - at $2/user this gives email and calendaring, but not documents - and then spin up the cheapest (A0) Azure VM with SharePoint Foundation running on it to provide the document service. While the latter would be very slow for a server, but this is also something that would be accessed very rarely, pretty much never concurrently, and mostly to read rather than author, so performance implications are acceptable; while the cost savings from paying $15/month for all 30 users, rather than the extra $2/user, to upgrade to Office 365 Enterprise K1 (which includes SharePoint Online) is significant given the tight budget.

Now on to the question itself. With this setup, I want the Office 365 identity to be the primary one for the users, and for them to only have to remember that one login and password; and if at all possible, I'd like to avoid having to run and maintain any local services on that VM beyond what is necessary. So, ideally, I would like some way to just tell a local SharePoint instance to authenticate users against Office 365, and leave it at that. If that is impossible, I need to come up with some scheme that would enable account sharing and/or synchronization between the local AD instance on the SharePoint VM, and Office 365.

Trying to figure out how to do this has proven to be rather difficult, though. There are many documents on the subject of interop between a local domain and Office 365, but they all seem to assume that the local identities are primary, so the synchronization direction is from on-prem to the cloud, rather than vice versa, as I intend. There is also a lot of seemingly overlapping and confusingly named tech covering that area - ADFS, Azure FS, DirSync are the three ones that keep popping up.

So, where exactly do I need to look, and what do I need to learn, to figure out how to set this all up the way I want? If there are several different options, then which one will be the least brittle and maintenance-heavy in the long run?

  • Aside from cheap, I also want minimal hassle going forward, even if that means spending more time now. If I have the same user database, I don't need to create accounts twice, can't forget to disable one of the accounts when the user goes away, don't have handle people changing one password but not the other and then forgetting which is which etc. Basically, even if it's a more complicated system, so long as it's going to be mostly chugging along on its own once set up, I would prefer that. Oct 18, 2015 at 10:19
  • I think you should look into ADFS since you're going to use a Microsoft SharePoint product then. Oct 18, 2015 at 10:22

2 Answers 2


Sharepoint 2013 accepts logins using SAML 1.1 authentication. Since you're using Office365, your users are in an Azure AD instance. Azure AD supports lots of authentication shcemes directly, but SAML 1.1. Is not one of them. However, The Azure Access control service can work as a "relay" and provide you with SAML 1.1-based authentication services. You'll find tons of blog posts about the setup, but I'll refer you to the official documentation from MS technet: Using Microsoft Azure Active Directory for SharePoint 2013 authentication.

That said, using Sharepoint Online is obviously much easier, so if I were you I'd definetely check out if that meets your requirements before going down the path of setting up your own Sharepoint infrastructure.

  • Looks hairy indeed! I'll have to ponder whether I really want to go down that route now :) But thank you for a comprehensive answer, this really nails down pretty much everything I was asking. Oct 25, 2015 at 21:55
  • Hairy indeed, and not without limitations. I think we can expect Sharepoint 2016 to enable much more modern authentication schemes such as OpenID Connect/Oauth and SAML 2.0, which you will be able to use directly with Azure AD.
    – Trondh
    Oct 27, 2015 at 14:33

What you're trying to achieve is very complex for a small business, I can't imagine how you will support issues that occurs in the future since you're trying to implement an unsupported solution.

The only possible way for you to allow users authentication to SharePoint using the same Office 365 accounts is to enable Synced (Azure AD Connect) or Federated (ADFS) against a local in-perm (or in your case, an Azure VM) Active Directory deployment, which you currently don't have. https://support.office.com/en-us/article/Understanding-Office-365-identity-and-Azure-Active-Directory-06a189e7-5ec6-4af2-94bf-a22ea225a7a9

If cost is an issue, @PJ Mahoney provided an excellent suggestion, educate your users of the existence of two different systems and let them live with it. keep in mind that this might have hidden costs for support and maintenance of two different systems.

If cost is not an issue, Go with the Office 365 Business Essentials plan, which will cost 5 USD a month/user, you get Skype for business on top of the deal, it would double the original suggested 2 USD price you're looking for, but in the long run I would say this is a better investment to keep things organized and simple.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .