Many SharePoint developers have come from a background with ASP.NET and so most are familiar with the Membership Provider concept. SharePoint uses ASP.NET at its core the membership providers you have build for custom web applications can be used in your SharePoint web application. The advantage of this is that you can abstract your web parts, application pages, etc in SharePoint so they use the Membership Provider to get user information rather than coding your own Active Directory calls into a library or the web part/application page itself.
Although SharePoint can use membership providers for authenticating users it does not require the membership providers be configured unless you want to use them. So what happens when you use a web part or application page with membership provider logic on a SharePoint site that does not have the membership providers configured?
What ends up happening is that SharePoint, by default, assumes you are trying to talk to a SQL Membership Provider. In fact, SharePoint assumes you want to use the default ASP.NET SQL Membership Provider (System.Web.Security.SQLMembershipProvider). This surprised me because SharePoint by default uses Windows Authentication (Active Directory or local machine accounts) for authentication, not SQL. The resulting error is also not very clear as it simply states “Unable to connect to SQL Database”. This error may also occur if you have not specified a membership provider default provider in the web.config xml.