The Scenario:
Not a lot of people have started doing this yet, however, if you’re like me your FBA (forms based authentication) users are stored in a SharePoint list and you wrote a custom ASP.NET membership provider to authenticate users against the list rather than AD or a SQL database. However, when I set this up I ran into a perplexing exception, “Exception from HRESULT: 0x8107025D”.
I was doing some ‘googling’ on this exception and I couldn’t find ANYTHING helpful, so I figured I would post my resolution to the problem in case someone else runs into the same issue.
The thing I noticed that gave me some insight into the problem is that if a user logs into the site via windows authentication, thereafter the FBA user can login just fine. Then if I did an IIS reset, the FBA authentication would break again. This led me to conclude that something was being cached that the FBA user didn’t have access to read. I took it a step further and noticed in the SharePoint logs (12\template\logs\most recent log.txt) a request to a schema.xml file was denied.
It turns out that the problem was because I built my SharePoint list, which houses the users, off a custom list definition and content type that are stored in the 12 hive. This in it of itself is fine to do, however, when I deployed my features into the features directory, the folders did not inherit the permission of the parent folder. Because of this, an anonymous user cannot access the schema.xml or elements.xml files needed to authenticate. The reason why the windows user logged in and thereafter the FBA user could log in is that the windows user kicked off the creation of the W3WP process which goes to the 12 hive and caches all xml therein. In my case, the anonymous user didn’t have the read rights necessary to access those files and get them into the cache.
What’s new information to me is that even AFTER a list is instantiated off a list definition, requests to that list either programmatically or through the browser STILL touch this file. This is a good thing to note.
The fix is simple, right click on the “FEATURES” folder and click security -> advanced. Check the radio button to propagate all permission down into all sub folders. This should take care of it. If it doesn’t, you can give “IUSER_SERVERNAME” read rights onto your feature folders. IUSR is the anonymous internet user.
Good Luck!