Weird error when creating a site collection from a Claims authentication WCF service

Question

I'm having trouble adding a new site collection, from a service hosted in a claims enabled SharePoint web application. The authentication works just fine (I can confirm the identity of the user while stepping through the site collection creation).

For some reason, I get the below error message. The only thing that seems to resolve it is to add the client user to the local administrator group. I've tried changing web app security policies, adding all kinds of users as database sysadmin and so forth, but that doesn't help at all.

Another thing I find weird is the fact that the error stems from SetSiteQuota. According to the ULS logs, the site collection appears to be created, then some subsequent operation fails. The stack trace supports this.

Any clues would be most welcome.

0#.w|domain\testuser caused exception trying to create a site with owner domain\client.   ExceptionType: 'ThreadAbortException'   ExceptionMessage: 'Thread was being aborted.'   StackTrace: '  
 at System.Threading.Thread.AbortInternal()      
 at System.Threading.Thread.Abort(Object stateInfo)      
 at System.Web.HttpResponse.End()      
 at Microsoft.SharePoint.Utilities.SPUtilityInternal.SendResponse(HttpContext context, Int32 code, String strBody)      
 at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(HttpContext context)      
 at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(Exception ex)      
 at Microsoft.SharePoint.Library.SPRequest.SetSiteQuota(String bstrUrl, UInt16 quotaId, Int64 diskQuota, Int64 diskWarning, Int32 userQuota, Double resourceUsageMaximum, Double resourceUsageWarning, Boolean bForSSC)      
 at Microsoft.SharePoint.Administration.SPQuota.Update()      
 at Microsoft.SharePoint.SPSite.set_Quota(SPQuota value)      
 at Microsoft.SharePoint.Administration.SPSiteCollection.Add(SPContentDatabase database, SPSiteSubscription siteSubscription, String siteUrl, String title, String description, UInt32 nLCID, String webTemplate, String ownerLogin, String ownerName, String ownerEmail, String secondaryContactLogin, String secondaryContactName, String secondaryContactEmail, String quotaTemplate, String sscRootWebUrl, Boolean useHostHeaderAsSiteName)      
 at Microsoft.SharePoint.Administration.SPSiteCollection.Add(SPSiteSubscription siteSubscription, String siteUrl, String title, String description, UInt32 nLCID, String webTemplate, String ownerLogin, String ownerName, String ownerEmail, String secondaryContactLogin, String secondaryContactName, String secondaryContactEmail, Boolean useHostHeaderAsSiteName)      
 at Microsoft.SharePoint.Administration.SPSiteCollection.Add(String siteUrl, String title, String description, UInt32 nLCID, String webTemplate, String ownerLogin, String ownerName, String ownerEmail)      

Update:

I found a somewhat related post on MSDN, at http://social.technet.microsoft.com/Forums/en-CA/sharepoint2010programming/thread/51ad553a-ec7b-46b6-873c-d49b2544c55f. At the end of this post, Microsoft confirms an issue with SPSiteCollection.Add().

While some aspects do apply to my case (Claims, SPSecurity.RunWithElevatedPrivileges), the custom auth handler doesn't. What makes it all utterly weird is that RunWithElev() should cause the site collection creation to be run by the SharePoint system account (which would have privileges to do whatever). Yet the problem goes away entirely if the account calling the Claims service is added to the server's administrators group.

My point: it looks as though part of SharePoint's internal site collection creation process runs as the current thread's identity, even when the creation is spawned from RunWithElevatedPrivileges. At the end of the day, this brings me no closer to a conclusion or solution, as it's completely out of the question to add users to the server's administrators group.

Answer 1

In my experience ThreadAbortExceptions are normally caused by permission problems.

Did you try to create the SPSite from code or using the SharePoint UI?

If you created it from code try setting the SPSecurity.CatchAccessDeniedException property to false. This will hopefully cause the ThreadAbort to be reported as a real access denied exception that you can then diagnose further.

If you created it from the SharePoint UI then either verify all the permissions of the user trying to create the SPSite or try to create an SPSite from code as that user and apply the CatchAccessDeniedException trick.