We faced this error during the last days and couldn’t find (quickly) a solution for it. The solution in our case was very simple and stupid 🙂

Most of the time, getting this errors will result in a long search on the internet finding out that you are not the only one with that error message (sometimes it is the case :-)) The message itself is very general and can occor in lots of different configurations (so not only SharePoint). I will first elaborate on our configuration and the things we checked and then finally mention the cause of our problem…

The error occured on the moment we wanted that add a new extranet user (FBA-user) to SharePoint via the SPWeb.EnsureUser() method. Adding Active Directory-accounts was not a problem! And last but not least, the code worked in the past and on the same systems!

a custom MembershipProvider was created en in-place(partially re-use of code from other projects).

We checked that the name of that provider was not misspelled in all config files and code blocks)

the superuseraccount and superreaderacount was defined (keeping in mind that you use the claims-prefix (“i:0#.w|domain\account”)

this setting is actually not required for the actually solution. We have an environment without these settings and everything was working well…

Cause:

When using the SPWeb.EnsureUser() method, SharePoint is loading your Membershipprovider assembly and executes the GetUser() methods. Since the user was not present in our internal user database, SharePoint throwed that exception.

But why did it worked in the past? => the responsible code of creating the records in the DB was moved by mistake and put after the SPWeb.EnsureUser() statement.

Afterwards it’s easy to say: look at the message! “I cannot find a user!” but in a lot of case error messages are not always straight-forward and the cause is often something else…but not in this case 🙂 …so exceptions on exceptions do occur.

We had a mind-breaking issue on our demo environment today. In the matter of security, a site collection administrator is always capable of browsing through the intranet. But security tests with “normal” users didn’t succeeded (Permission Level: Contribute), we’ll received always an “Access Denied”:

We followed these steps to identify the problem:

Checking al common libraries (Master Pages, Style Library, Site Collection Images) on the following topics:

The security group or the user can at least read the library (Check Permissions for users…)

Our Homepage and MasterPage contains custom webparts

one by one, remove everything in your MasterPage
the layout became so basic but at a suddent moment, the “Access Denied” was vanished 🙂

the actual cause:

one custom webpart had a routing for checking if a user is member of a certain SharePoint group, changing this piece into SPRunWithElevatedPrivileges did the trick 🙂 A normal user with Contribute rights has no rights to check for security settings…

It is a pitty that the logging of SharePoint is not smarter enough to elaborate more information when an Access Denied exception is thrown. Hopefully this is getting better in the next release 🙂

Do you need to implement an ASP:TreeView in you website based on a xml file with a nice nested Parent – Child structure? I think that everyone already wrote, at least one time in his life, a recursive function to accomplish this but this can be better 🙂