Background on SharePoint FBA and SQL External User Accounts
Most companies do not want to store external user accounts in AD, so the built-in SQL-based account store that has been part of ASP.NET since .NET 2.0 is a great way to store the external user accounts in a standard SQL Server database. SharePoint, FBA and the SQL Membership Provider have proven to be a very secure and industrial-strength way of providing business this capability. (See our white paper on why this approach works so well for businesses).
When you set up the SQL Membership Provider in your SharePoint Farm and hook it up to SharePoint as an authentication provider, there are a number of settings you can configure in the web.config file for the SharePoint web application that you want to use the SQL user accounts with. You can see some of them in use in a sample web.config file shown on MSDN here: https://msdn.microsoft.com/en-us/library/system.web.security.sqlmembershipprovider(v=vs.110).aspx#Anchor_7
A couple of them are really important for purposes of this discussion: passwordFormat and enablePasswordRetrieval.
passwordFormat can have its value set to Clear, Encrypted or Hashed. Hashed is considered the best practice as it will cause the passwords to be stored using a hashing algorithm that takes a randomly generated “salt” value to do the hashing. This approach makes the storage of the passwords in SQL Server very secure.
enablePasswordRetrieval accepts a value of True or False, but when the passwordFormat is set to Hashed, this value is ignored. Hashed passwords can never be retrieved from the database in their unhashed form by man or software.
This level of security provided in the SQL Membership Provider is awesome when it is used in conjunction with SharePoint FBA for storing external user accounts. And, like I already mentioned, this has long been considered the best practice way of setting up SharePoint FBA\SQL extranets and many, many companies around the world have done it this way. (Again, our white paper on the subject is an excellent resource.)
Background on Office 365 Subscriber Accounts and External Sharing Accounts
Of note is the fact that Office 365 differentiates the status of an Azure AD account depending on what content is being shared and by whom. An Azure AD account is treated as an Office 365 subscriber account when a user is working on content within their paid instance of Office 365. Conversely, when something is shared with that user from someone else’s Office 365 instance, Office 365 treats the first user’s account as an external sharing account.
We wrote a recent blog post on what is different for the user when their account is treated by Office 365 as an external sharing account:
The Problem(s) with Migrating SharePoint FBA SQL Accounts to Office 365 External Sharing Accounts
Problem 1: The existing external user passwords cannot be retrieved in order to be migrated.
This would be a huge issue for many companies because their on-premise SQL Membership Provider database stores accounts for thousands or tens of thousands of external users. Some of the ones that come immediately to mind are those at very large law firms and very large accounting firms. They can have huge external user account databases!
Problem 2: Office 365 does not allow you to create\maintain accounts for your external users, only the external users themselves can do this.
Problem 3: If you are migrating externally shared content, all of the sharing permissions will break, regardless of the content migration tool that you use.
So, even if you are able to successfully migrate all of your existing on-premise extranet content to Office 365, all of your permissions granted to external user accounts will be “orphaned” and there will be no way to re-link these permissions to valid Office 365 external sharing accounts, even if you could find those accounts.
ConclusionIf you have made a significant investment in an on-premise SharePoint Extranet application that uses FBA and the SQL Membership Provider, you are best served to keep it on-premise if it is important to you to be able to retain all of your external user accounts and passwords, and the content permissions that your user’s have granted.
If your company has mandated that “everything must move to the Cloud”, then your options are to A) have your external users start over from scratch with new Office 365 external sharing accounts and then manually re-share everything with them, or B) move your existing on-premise SharePoint Extranet server(s) to run as Azure or Amazon virtual machines so they are “in the Cloud”.
With Option B, you can “check the box” that your extranet runs in the Cloud, but continue to use the same SQL Membership Provider account database that you have been using all along and not impact your external users in any way :). For a brief overview of how this would work, check out this article we wrote a while back: